Prefix hijacking, how to prevent and fix currently

Tue Sep 2 15:08:28 UTC 2014

>Please help me understand the argument.

>

>> Some Org. D can maliciously announce a subprefix under Org. C's

>> prefix, and get away with it due to the 'Loose' mode.

>

>So C is advertising valid 192.0.2.0/24

>Is D advertising valid 192.0.2.0/23?

>

>This is unfixable problem? If D is advertising invalid or unknown, C

>would still work and win, as longest prefix match is done first to the 'valid'

>population, if search is found, other populations are not searched.

The example that I gave was not that.

In my example, C has legitimate ownership of the less specific (e.g., 192.0.2.0/23).

D is malicious and attempting to hijack a subprefix (e.g., 192.0.2.0/24).

Importantly, C has a created a ROA for 192.0.2.0/23 only to protect its address space,

but currently *does not advertise* this prefix or any part of it.

So D's more specific announcement (hijack) is 'Invalid' in this scenario,

but the 'Loose' mode operation would accept/install D's route.

Am I right about that? If yes, that is the side effect or CON that I was trying to highlight.

>> I think, 'Loose mode', if used at all, should not be used beyond a short grace period.

>We need to be pragmatic and ready to compromise. Right now deploying

>RPKI puts you in competitive disadvantage, loose mode would remove the

>business risk and make it easier to justify deployment.

I agree about making some compromises. But we need to bear in mind

the side effects such as the above in the transition period.

For example, to mitigate the above stated CON, the operator (C in our example)

should go ahead and announce its prefix (e.g., 192.0.2.0/23) in BGP even though

he/she may not currently intend to set up any servers/services in that address space.

Further, at a later/more mature stage of RPKI, when most operators have

implemented the paragraph I cited from RFC 7115, then routers can drop 'Loose' mode.

Sriram