Prefix hijacking, how to prevent and fix currently

Fri Aug 29 10:08:15 UTC 2014

On Fri, Aug 29, 2014 at 06:39:32PM +0900, Randy Bush wrote:
> >>> Loose mode would drop failing routes, iff there is covering (i.e. less
> >>> specific is ok) route already in RIB.
> >> isn't that exactly the hole punching attack?
> > No, as the the more specific route is signed and is preferred (longest
> > match routing) against the less specific hijacked route
> 
> clearly i am missing something.  got a write-up?

I'll attempt to clarify.

Assume: 

    ROA: 10.0.0.0/16, max_length = 16, origin = AS123
    in RIB: 10.0.0.0/16 origin AS123 (valid)

    With the above two conditions any updates containing more-specifics
    of 10.0.0.0/16 would be rejected/not-installed, just like in todays
    'strict mode'

Loose mode A would look like this:

    In the case that 10.0.0.0/16 origin AS123 is not in your table, the
    loose mode would kick in and one could accept more specifics for
    10.0.0.0/16, but only when originated by AS123.

Loose mode B would look like this:

    In the case that 10.0.0.0/16 origin AS123 is not in your table, the
    loose mode would kick in and one could accept more specifics for
    10.0.0.0/16 originated by any ASN.

The major point is that when the valid route is missing, one might
choose to accept invalid routes. When the valid route returns, the
invalids are purged from your table.

Or in other words: Proposal is, that when additional 'loose' mode is
configured, invalid routes are accepted if and only if they are the only
route to destination. If there is any other route (less-specific) which
is not invalid, it will be used, instead of the invalid route.

Kind regards,

Job