Re: Need for historical prefix blacklist (`rogue' prefixes) information

[Amir Herzberg <amir.lists () gmail com>]

(this is an answer to Matthew but also with a question to all NANOGers, see
below, under `is this true?')

Matthew, thanks for your feedback on our paper - always welcome - although
the email I sent wasn't about ROV++ but on our need for historical data on
blacklisted prefixes. (our use is not limited to ROV++ as we are
investigating other attacks and defenses, including our own and proposed by
others).

Anyway let me briefly respond to the issues you raised.

I read your paper. I note "ROV provides disappointing security benefits". I
> think we all know that ROV provides very little in the way of security from
> deliberate hijack without the protection of BGPsec as you later point out
> in your paper.

I mostly agree. Not fully, since, actually, there _is_ an advantage to an
attacker to perform prefix-hijack (and esp. subprefix hijack) compared to
path manipulation attacks (which ROV fails against). Basically the reason
is exactly the fact that most paths are short, as you mention. [E.g., see
our `path-end' paper in SigComm'16]


> What you seem to have failed to understand is that most traffic hijacks
> on the internet are not malicious in nature, they are "fat finger" incidents

Apparently, I somehow caused you to believe that I think that most hijacks
are due to attacks; never my intention (or belief). I'm well aware that
errors are more common than attacks.


> where someone has accidentally announced something they did not intend to,
> either because of faulty software (the infamous "BGP optimizer") or someone
> leaking internal "blocks" such as the Pakistan/YouTube incident

Let's not mix route-leakage here... (but of course, that incident wasn't a
leakage but a hijack - probably meant to be only within Pakistan, so I
guess you could say it was also leakage)


> -- certifying the origin of a prefix allows you to mitigate most of this
> as the origin AS will change. Anyone seen deliberately causing hijacks is
> likely to be depeered very quickly -- commercial pressure rather than
> technical.

Now, is this true?  I'm really curious to know if all/most NANOGers agree
that an AS deliberately causing hijacks would be very quickly depeered.

My concern is that providers may not disconnect a customer AS (or even a
peer) `just' due to what may be an intentional hijack. Indeed one advantage
of hijack (cf. to more advanced attacks) is that it may be _excused_ as a
mistake, and there were some (in)famous incidents... And I suspect
depeering is not such a quick response by an admin suspecting foul play;
there are contracts and payments involved... Am I wrong?

> Likewise, the core purpose of ROV is not to secure the entire address
> space. It is (as I understand it) to prevent *your* address space from
> being stolen, and

Matthew, I know you know this stuff, so I think you mis-typed here, no?
Obviously, you protect your address space by publishing ROAs. The purpose
of ROV is _only_


> to prevent your network from being affected by false advertisements.

(we agree on that!)


> The superprefix attacks you mention are pretty much theoretical only at
> this time,

I really like to do applied research, but sometimes I also do some research
which is more for fun, and I agree these superprefix attacks are probably
not very practical against _announced_ prefixes. Of course, sometimes we
later find these works `for fun' do have practical importance...

And in this case... superprefix attacks may become practical against
_unannounced_ prefixes (with ROA 0), _if_ ROV is widely deployed (making it
ineffective to hijack them by simple prefix hijack). So, there is
motivation to think about them!

btw, superprefix attacks can also allow foiling of feasible-uRPF, you
know... so, again, could be practical.


> because of the maximum prefix length attribute and the nature of peering
> in that networks either tend to be adjacent (therefore very low AS Path) or
> via transit (and most transit providers deploy ROV validation). It's true
> that traffic could be re-routed if the longer prefixes are not advertised
> to all parties, but that would also come under the AS Path length case.

I don't quite see how this is relevant to the superprefix attacks; clearly
the attack fails if a more specific prefix is available, but that's
obvious.

> Hijacking a prefix is not useful unless you can do something with it,
> either to hand out to customers (in which case, the prefix is going to be
> sufficiently ignored around the internet that it's not practically useful)
> or to engage in denial of service activities in which case there are far
> easier measures to use.

Intentional hijacking has different goals, many of which don't require
universal success.

> > Any help would be appreciated. I'm not sure the list would be interested
> > so I recommend you respond to me privately; if there are useful responses,
> > I could post a summary to the list after few days (of collecting responses,
> > if any).
>
> I would strongly encourage engaging with the IETF (
> https://datatracker.ietf.org/wg/sidrops/about/ et al) who are much more
> likely to be able to point you in the right direction.

Thanks - I agree, it'll be good idea to ask there (too).

Best, Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
 https://sites.google.com/site/amirherzberg/applied-crypto-textbook
<https://sites.google.com/site/amirherzberg/applied-crypto-textbook>




On Fri, Oct 29, 2021 at 8:13 AM Matthew Walster <matthew () walster org> wrote:

> Hi,
>
> On Fri, 29 Oct 2021 at 00:48, Amir Herzberg <amir.lists () gmail com> wrote:
>
> > Hi NANOGers, for our research on ROV (and ROV++, our extension, NDSS'21),
> > we need access to historical data of blacklisted prefixes (due to spam,
> > DDoS, other), as well as suspect-hijacks list (beyond BGPstream which we
> > already have).
>
> I read your paper. I note "ROV provides disappointing security benefits".
> I think we all know that ROV provides very little in the way of security
> from deliberate hijack without the protection of BGPsec as you later point
> out in your paper.
>
> What you seem to have failed to understand is that most traffic hijacks
> on the internet are not malicious in nature, they are "fat finger"
> incidents where someone has accidentally announced something they did not
> intend to, either because of faulty software (the infamous "BGP optimizer")
> or someone leaking internal "blocks" such as the Pakistan/YouTube incident
> -- certifying the origin of a prefix allows you to mitigate most of this as
> the origin AS will change. Anyone seen deliberately causing hijacks is
> likely to be depeered very quickly -- commercial pressure rather than
> technical.
>
> Likewise, the core purpose of ROV is not to secure the entire address
> space. It is (as I understand it) to prevent *your* address space from
> being stolen, and to prevent your network from being affected by false
> advertisements. The superprefix attacks you mention are pretty much
> theoretical only at this time, because of the maximum prefix length
> attribute and the nature of peering in that networks either tend to be
> adjacent (therefore very low AS Path) or via transit (and most transit
> providers deploy ROV validation). It's true that traffic could be re-routed
> if the longer prefixes are not advertised to all parties, but that would
> also come under the AS Path length case.
>
> Hijacking a prefix is not useful unless you can do something with it,
> either to hand out to customers (in which case, the prefix is going to be
> sufficiently ignored around the internet that it's not practically useful)
> or to engage in denial of service activities in which case there are far
> easier measures to use.
>
>
> > Any help would be appreciated. I'm not sure the list would be interested
> > so I recommend you respond to me privately; if there are useful responses,
> > I could post a summary to the list after few days (of collecting responses,
> > if any).
>
> I would strongly encourage engaging with the IETF (
> https://datatracker.ietf.org/wg/sidrops/about/ et al) who are much more
> likely to be able to point you in the right direction.
>
> Matthew Walster