[ncc-services-wg] 2013-04 New Policy Proposal (Resource Certification for non-RIPE NCC Members)

> I keep seeing/hearing this when RPKI is discussed.  While strictly
> true, the way I've understood this, it will also defeat one of the
> main purposes of RPKI, namely to be able to defend against certain
> route hijacking or route leak events, where more-specific routes are
> propagated and accepted.
> 
> In order to defend against that type of events, due to the "longest
> matching prefix always wins, irrespective of BGP attributes" behaviour
> (which isn't a trait of BGP but of how our routers look up forwarding
> entries), you cannot have your router configured to install RPKI-
> invalid prefixes in your forwarding table.

from draft-ietf-sidr-origin-ops-20.txt Sec 5. Routing Policy

   Operators should be aware that accepting Invalid announcements, no
   matter how de-preffed, will often be the equivalent of treating them
   as fully Valid.  Consider having a ROA for AS 42 for prefix 10.0.0.0/
   16-24.  A BGP announcement for 10.0.666.0/24 from AS 666 would be
   Invalid.  But if policy is not configured to discard it, then longest
   match forwarding will send packets to AS 666 no matter the value of
   local preference.

   As origin validation will be rolled out incrementally, coverage will
   be incomplete for a long time.  Therefore, routing on NotFound
   validity state SHOULD be done for a long time.  As the transition
   moves forward, the number of BGP announcements with validation state
   NotFound should decrease.  Hence an operator's policy SHOULD NOT be
   overly strict, and should prefer Valid announcements, attaching a
   lower preference to, but still using, NotFound announcements, and
   dropping or giving a very low preference to Invalid announcements.

as you point out, that latter is ill advised, and i have a fix in my
edit buffer for the next rev as follows:

   Merely de-preffing Invalids is ill-advised, see previous paragraph.

randy