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

[Andrew Chi <[e-mail]>]

On 4/6/2012 11:21 AM, Shane Amante wrote:
> 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.

Right, I'm familiar with loop detection and K/P.

If someone has modified AS_PATH to cause another AS to drop it, then 
they inserted someone else's AS.  This no longer counts as "legitimate 
reachability info", and therefore it should be dropped, and the sooner 
the better.

It sounds like there's another issue mixed up in here (but perhaps not 
in scope of the -bgpsec-threats document): you're trying to resolve the 
ambiguity on what to do with AS_PATH, as Matt notes at the end of the 
following section.

http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5

    EDITOR'S NOTE: Text will be inserted here for dealing with the
    AS_PATH attribute.  Note that the BGPGSEC_Path_Signatures attribute
    now contains all of the information needed to construct the AS_PATH
    attribute.  Therefore, there seem to be two options.  One option the
    BGPSEC speaker checks the AS_PATH attribute against the information
    in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the
    two do not match.  The other option is that the BGPSEC speaker
    discards anything in the AS_PATH attribute and reconstructs the
    AS_PATH from the data in the BGPSEC_Path_Signatures attribute.  I
    believe that there are no interoperability problems if the choice
    between these two options is left up to the BGPSEC speaker.


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

Yes, this is true -- there's always DoS by feeding garbage to your 
neighbor, BGPSEC or not, but crypto lets you waste more CPU.  DoS on a 
BGP router is mentioned briefly at the end of 4.1 -- would you like more 
text?