Prefix hijacking, how to prevent and fix currently
Job Snijders
job at instituut.net
Fri Aug 29 10:25:59 UTC 2014
On Fri, Aug 29, 2014 at 06:17:09AM -0400, Sandra Murphy wrote:
> > 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.
Correct.
> Here you say "not invalid", which would mean a route that is
> "unknown", i.e. no ROA exists.
Sorry, with "not invalid" i meant "valid".
> 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.
I'd like to accept more-specifics, only in the absense of the
less-specific ROA covered prefix.
> So which do you mean? The less specific has a ROA or the less
> specific may not have a ROA?
The less specific has to have a ROA, for any loose mode to make sense.
Loose mode A & B came into existence 15 minutes ago, its good to discuss
what a loose mode could mean. ;-)
Kind regards,
Job
More information about the NANOG
mailing list