Steve,
Thanks for the response. First, a high-level comment before more specific
responses below.
The challenge I'm having is trying to reconcile threats against the existing
AS4_PATH attribute vs. threats against the BGP_Path_Signature attribute. More
specifically, the AS4_PATH attribute is used by the BGP protocol for loop
detection, (i.e.: if I find my own ASN in the AS4_PATH, today, then I drop the
route because the BGP protocol considers that a routing information loop). So,
the question is: if/when BGPSEC is deployed, will BGP be expected to perform
this loop detection check on the AS4_PATH attribute /prior/ to verification of
the BGPSEC_Path_Signature attribute or after? If it's before, then there's the
potential for someone to forge a AS4_PATH attribute to cause a receiver to drop
a BGP UPDATE causing a DoS attack. OTOH, if loop detection is after
verification of the BGPSEC_Path_Signature attribute, then this may be another
form of DoS attack, given that the UPDATE needs to be run through crypto
processors, (which like general purpose CPU's have a finite # of Ops/sec they
can run), to check the BGPSEC_Path_Signature validity before going through
protocol correctness checks on AS4_PATH attribute. There may be a third
answer, which is that the SIDR WG will deprecate the AS4_PATH attribute and
replace it with the BGPSEC_Path_Signatures attribute, but even in this case I
think the same two choices I just outlined need to be decided upon.
I don't see an easy answer here; however, I suspect that from a security PoV,
there is likely a "preference" to verify the BGPSEC_Path_Signature attribute,
first, before running protocol correctness checks (loop avoidance), which may
result in the threat of a DoS. 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 and/or to the feasibility of unvalidated paths carried
in the control plane, (until they are later, perhaps "lazily", validated via a
background process).
Please see below.
On Mar 29, 2012, at 11:07 AM, Stephen Kent wrote:
> 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.
I suspect that this, and other, text was written a little while ago when there
was a much tighter coupling of the AS4_PATH attribute & the proposed
BGPSEC_Path_Signature attribute. However, given recent discussions around
(ab)using pCount = 0 for Route Servers at IX'es, ASN migrations, etc., then
perhaps Section 4.2 of this draft should be revisited in light of whether the
BGP Path Selection algorithm is going to use data from the AS4_PATH attribute,
at all, (even after verification of the BGPSEC_Path_Attribute) and the
potential for various DoS threats that /may/ have wrt availability vs. validity
of reachability ...
>> 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.
Same comment as above. At a minimum, can the above text be more clear on
whether those statements are in relation to the AS4_PATH attribute or
BGPSEC_Path_Attributes attribute, or both?
>> 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.
Understood.
> 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?
There is text about MITM threat in Section 4.2; however, that seems to relate
to crypto security between two adjacent routers over, say, a directly connected
link. However, what about MITM attacks that create what appear to be valid
BGPSEC_Path_Signature attribute that would pass verification by downstream
parties?
Thanks,
-shane
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
