Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening

[Shane Amante <[e-mail]>]

On Apr 6, 2012, at 8:26 AM, Andrew Chi wrote:
> On 3/29/2012 9:04 AM, Shane Amante wrote:
>> Regardless, I think
>> that its best to acknowledge, in this draft, that there is a threat of
>> DoS to the availability of the BGP control plane
> 
> Maybe I'm missing something.
> 
> Intermediate routers or MITM entities can always drop updates.  If BGPSEC is enabled, then forging an AS4_PATH or modifying BGPSEC_PATH_Signature achieves no more than dropping the update.
> 
> Can you give a specific example of DoS that applies only to BGPSEC-enabled routers?


RFC 4271, Section 9.1.2, "Phase 2: Route Selection":
---snip---
   If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
   route should be excluded from the Phase 2 decision function.  AS loop
   detection is done by scanning the full AS path (as specified in the
   AS_PATH attribute), and checking that the autonomous system number of
   the local system does not appear in the AS path.  Operations of a BGP
   speaker that is configured to accept routes with its own autonomous
   system number in the AS path are outside the scope of this document.
---snip---

So, what if there's a "bad actor" and he/she forges and AS4_PATH and/or BGPSEC_Path_Signature with the intent of making *another* AS, which is 'playing by the rules of BGP and/or BGPSEC', drop the UPDATE?  As I said previously, there's two things to think about here:
a)  BGP performs loop detection on the AS_PATH attribute *before* verifying any BGPSEC_Path_Signature, in which case you drop the UPDATE, thus causing a DoS because you're not propagating what *may* be legitimate reachability info further downstream.
b)  BGP performs loop detection on the AS_PATH attribute only /after/ verifying the BGPSEC_Path_Signature is valid, in which case there is a /potential/ for another type of DoS, because there will always be a limited amount of crypto verifications/sec that can be performed.  There's also the concern that this will slow down propagation of reachability information, because it first needs to be crypto-verified before it's used/propagated.  Note, this is unlikely to be a problem during "steady-state", but is more likely to appear during some amount of churn in BGP due to link and/or router failures, for example.

Note, there is likely no easy answer here, but it would be good for the WG to think about the problem and see if it could recommend a "best practice" to operators ...

In addition, I believe there is a substantially larger question here for the WG: is SIDR planning to, eventually, change RFC4271 so that AS loop detection is no longer performed on the AS_PATH attribute and, instead, is going to be performed only on the BGPSEC_Path_Signature attribute?  If so, is SIDR "allowed" to make that change or will this change be made within the IDR WG?

-shane