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

["Murphy, Sandra" <[e-mail]>]

Speaking as regular ol' member

Shane, I'm having some trouble following your argument.

Here's what I think you are saying.

You are exploring options for dropping an update based on detecting a loop - whether the loop detection should be before or after the check of the path signatures.

If you do the loop detection first, you say, that's a potential dos attack, because....

    "But the problem is: how do you know it's *not* "legitimate reachability info"
    if you've (only) based the decision to drop the UPDATE based on unverified info 
    in the AS_PATH attribute?  If you do, that's a _threat_ of a DoS attack, which 
    presumably the whole point of BGPSEC is designed to protect against."

And that's where I lose you.  I don't see why detecting the loop first provides a dos attack

Case 1: If the update has actually looped, then dropping the update because of loop detection is just fine.

Case 2: If the update has not actually looped, then someone has managed to inject an AS (yours) into the AS_PATH *illegitimately* (the update did not actually go trough your AS).  So dropping the update is just fine here also, because this is an attack.

In this case, testing the bgpsec signatures will necessarily fail.  So dropping the update because of loop detection is not a denial of service.  Whether you do loop detection first or bgpsec signature test first, the update will be dropped.

So where's the dos attack?

(Do note that the bgpsec signatures would detect this at the first point that checked the signatures, so your neighbor would have spotted the injection - unless it was the source of the injection.)

--Sandy, regular ol' member
________________________________________
From: [e-mail] [[e-mail]] on behalf of Shane Amante [[e-mail]]
Sent: Friday, April 06, 2012 1:02 PM
To: Andrew Chi
Cc: sidr wg list
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &        lengthening

On Apr 6, 2012, at 10:20 AM, Andrew Chi wrote:
> 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.

But the problem is: how do you know it's *not* "legitimate reachability info" if you've (only) based the decision to drop the UPDATE based on unverified info in the AS_PATH attribute?  If you do, that's a _threat_ of a DoS attack, which presumably the whole point of BGPSEC is designed to protect against.

At some point in the future, the SIDR WG will resolve *how* it's going to prescribe that BGP loop detection is supposed to work.  Either way, it needs to acknowledge there are two types of potential threats:
a)  Use unverified AS_PATH info for loop detection; or,
b)  Use verified BGPSEC_Path_Signature info for loop detection.
Ultimately, if the SIDR WG prescription *eventually* resolves that loop detection is only going to be performed on the BGPSEC_Path_Signature attribute, then the text in sidr-threats can be modified, at that future point in time, to say something like:
- Attacks against BGP loop detection are mitigated by only using verified info on the path from reconstruction of the path in BGPSEC_Path_Signature; however,
- This has the potential to introduce a DoS on the BGP control plane itself, either through normal operation (high churn) or an operator injecting false UPDATE's, into the system, which exceed the capacity of routers to perform crypto verification fast enough ...


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

Given the above, then I suggest the next revision of draft-ietf-sidr-bgpsec-protocol explicitly says: "Updates: RFC 4271" and that future updates of draft-ietf-sidr-bgpsec-protocol start to be shared with IDR WG mailing list, (particularly in light of discussions at the recent IDR WG meeting where the SIDR co-chairs have pointed out the need for cooperation between SIDR & IDR).  I do not believe that the SIDR WG is in a position to make a call as to whether, or to what extent, there are going to be interoperability concerns with legacy, non-BGPSEC capable routers wrt AS_PATH loop detection ... IMO, that should be the responsibility and call of the IDR WG.


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

Yes.  I think the text "... DoS attacks against BGP routers" is extremely vague, because there are two things that come to mind:
a)  A packet DDoS attack against the router, which may not have anything to do with the BGP control plane itself -- i.e.: some attacker trying to overwhelm links with too much traffic causing [severe] packet loss; and,
b)  A DoS attack against the actual BGP _control_plane_ itself.  More specifically, threats that either:
    i)  overwhelm the I/O, CPU (and/or, memory) capabilities of the BGP router; and,
    ii) in the future, overwhelm a new component, namely, the crypto verification capabilities of the BGP protocol.

I care about the latter (b), in the context of the SIDR WG, and I believe that is what the current text in Section 4.1 is attempting to say, just not well enough, yet.

Thanks,

-shane
_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr