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

[Shane Amante <[e-mail]>]

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.

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.

My concern is one that is related to the purported Kapela/Pilosov "threat".  Specifically, think of the following scenario:
a)  Someone is forging an AS4_PATH towards another (remote) party, to stimulate then to drop the UPDATE.
b)  An implementation is checking the AS4_PATH attribute to see if they find their ASN in there. If they find their own ASN, they consider this UPDATE as being looped and, per BGP protocol, should drop it.
c)  I can see a scenario where, similar to GTSM, implementers might have a [strong] preference to verify the AS4_PATH does not have any loops /first/, before doing any crypto verification on BGPSEC_Path_Signatures, since crypto verification is "[much] more expensive".
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?

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.

-shane