Prefix hijacking, how to prevent and fix currently

Fri Aug 29 10:17:09 UTC 2014

On Aug 29, 2014, at 6:08 AM, Job Snijders <job at instituut.net> wrote:

> 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.

In your examples, you presume there's a ROA for the less-specific.

Here you say "not invalid", which would mean a route that is "unknown", i.e. no ROA exists.

Your Loose Mode A relies on the existence of the ROA - you accept more specifics but only when originated by the ASN in the ROA.

So which do you mean?  The less specific has a ROA or the less specific may not have a ROA?

(Just trying to work this out in my head.)

--Sandy

P.S.  All the RPKI use is subject to local routing policy, so working out impact of different policies is a really good thing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140829/35d6018c/attachment.sig>