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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
