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

[Stephen Kent <[e-mail]>]

Shane,

>To expand on my comments at the mic earlier today on this draft, I 
>think there is universal acknowledgment that there should be 
>statements that attacks involving path shortening should be 
>acknowledged as a "threat" in this document.

Section 4.2, near the top of page 12,  addresses this attack, in the 
BGPSEC context:

       Secure Path Downgrade: A router might remove signatures from a
       BGPSEC update that it receives, when forwarding this update to a
       BGPSEC-enabled neighbor.  This behavior violates the BGPSEC spec
       and thus is considered an attack.

This is the path shortening attack, expressed in terms of an attack 
against a BGPSEC-protected path.

>OTOH, with respect to path-lengthening, my comment was NOT aimed at 
>the normal, operation practice of AS_PATH prepending for the 
>purposes of Traffic Engineering.

Section 4.2, bottom of page 11, says:

       AS Insertion: A router might insert one or more ASNs, other than
       its own ASN, into an update message.  This violates the BGP spec
       and thus is considered an attack.

This seems to address the K/P attack, in the BGPSEC context.

>The larger point here is that documenting, preferably in this I-D, 
>the Kapela/Pilsov threat and other threats related to 
>upgrade/downgrade threats discussed at the Prague IETF allows us to 
>more holistically consider whether, or not, BGPSEC addresses it.

So, ignoring the "threat" vs. "attack" terminology issue that we 
discussed at the mic :-), I could add some text to describe classes 
of attacks in terms of vanilla BGP, as well as BGPSEC.  But, RFC 4272 
already did this in a fair level of detail, so I didn't see the need 
for this doc to include an attack enumeration for BGP.

When discussing security, it is generally preferable to define what 
constitutes secure or "correct" operation for a protocol, rather than 
trying to enumerate attacks against the protocol. If one wants to be 
more specific, then one can
describe classes of attacks, and provide some illustrative examples. 
That's what we have tried to do here.


Not sure I understand you last comment:

>d)  Further, what if an attacker did this to valid, BGPSEC-signed 
>paths that he/she was originating and/or receiving and propagating 
>downstream toward other ASN's?

Steve