Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 12 Nov 2014 21:56:40 +0000

Matt,

Thanks for all your efforts and time in keeping this I-D updated.
Some technical and some editorial comments on the new version 10 follow.

Technical comments:

1. At the top of sec. 5.1, say something like – 
Here we focus only on validation of BGPSEC_Path or Secure_Path attribute. 
And refer to RFC 6811 for the recommended origin validation algorithm. 

2. In sec. 5.1 and 5.2, wherever there is mention of validation of *BGPSEC update message*, 
it should be replaced by “validation of BGPSEC_Path (or Secure_Path or Signature_Block).

3. In sec. 7 (Security Considerations), the vulnerability to replay attacks is currently 
not mentioned? Should it be mentioned?

Editorial comments:

1. Some references to Internet Drafts have old dates (not showing the actual updated dates).

2. Perhaps RFC 6811 should be a normative reference.

3. p. 5, 1st para: 

“A BGP speaker SHOULD
   NOT advertise the capability of BGPSEC support for a particular AFI
   unless it has also advertised the multiprotocol extension capability
   for the same AFI combination [3].”

s/ a particular AFI/ a particular set of AFIs/

4. p. 7, para 1: s/in the same way/ in a similar way/

5. The following sentence is repeated on pages 6 and 7:

“A BGPSEC update message
   containing the BGPSEC_Path attribute MUST NOT contain the AS_PATH attribute.”

6. p. 7, para 2: s/for one AS number/for each AS number/

7. p. 7, para 2: s/secure path segment/ Secure_Path segment/

8. p. 8, para 4: 

“(The pCount field is also
   useful in managing AS Number migrations, see [18] for details.)”
Could be replaced with:
(The pCount field is also
   useful in managing route servers (see Section 4.2) and AS Number migrations, see [18] for details.)

9. p. 10, para 2:

“When originating a new route
   advertisement and sending it to an internal peer, the BGPSEC speaker
   creates a new BGPSEC_Path attribute with zero Secure_Path segments
   and zero Signature Segments.”

This sentence is a bit verbose. There is no BGPSEC_Path attribute if it has zero 
Secure_Path segments  and zero Signature Segments.

So why not reword it simply as:
“When originating a new route
   advertisement and sending it to an internal peer, the BGPSEC speaker
   sends only the NLRI (to an iBGP peer).”

10. The last paragraph on p.11 and the top two paragraphs on p.12 can be moved to the preamble of 
Section 4 (to a spot just before start of Sec. 4.1). 
This is because these three paragraphs are generally applicable to both Sections 4.1 and 4.2.

11. p.13, 2nd last para: s/ to the RPKI router corresponding to the
   BGPSEC speaker / to the RPKI router *certificate* corresponding to the
   BGPSEC speaker/

12. p.16, para 2: s/ in the Subject Key Identifier extension of
   the RPKI router corresponding to / in the Subject Key Identifier extension of
   the RPKI router *certificate* corresponding to/

13. p.17, last para: s/ the most recently added Secure_Path *segments*/ the most recently 
added Secure_Path *segment*/  (make “segments” singular)

14. p 18, para 3: s/ for a signature
   produced by a BGPSEC speaker outside of a confederation/ for a signature
   produced by a *peer* BGPSEC speaker outside of a confederation/

15. In Sections 5.1 and 5.2, search “update message” and see if it should be replaced by 
“BGPSEC_Path attribute” or Secure_Path” or “Signature_Block” 
as the case may be. (In the context of validation)

16. p.28, 3 rd last para: s/ A BGPSEC speaker/ a BGPSEC speaker/  (should be lower case A)

Sriram

---

From: "George, Wes" <[email-masked]>
Date: Sun, 16 Nov 2014 18:23:42 -0500

Matt-

Per discussion during IDR/SIDR meeting Friday, there may need to be some
text in the security considerations around the attack vector of sending
many updates with long (but valid) AS_Paths, since the analysis Sriram
provided indicated a correlation between the length of the AS Path to be
validated and CPU impact or convergence time impact. Sounds like we don't
have a problem with long paths comprised of  multiple prepends because
Pcount means that there aren't multiple signatures, but validly signed
strings of unique ASNs could still trigger this problem, whether they are
generated accidentally or maliciously. We may also need to make the
observation that rapid route churn with these sorts of prefixes are likely
to make the impact even higher, such that it may be advisable to implement
route flap dampening to provide additional protection against route churn.

That said, I'm not sure that this is strictly a security considerations
addition, because we may need to make some suggestions in the design to
protect against these sorts of scaling problems.
I'm not sure if we can use analysis of existing routing table data to
identify an 80/20 threshold of the longest credible AS Path and put a
recommendation on a max_as_length value for the limit for protection
against this attack, or whether we cannot recommend a value, and have to
simply acknowledge that this is a problem and recommend that implementers
provide a knob for setting a limit on AS Path such that implementations
can intercept and drop long AS_Paths before the BGPSec machinery tries to
validate them. Perhaps both, i.e. A reasonable default limit that can be
raised or lowered if a user sees fit. Alternatively, we could suggest a
fall-back method whereby excessively long-path BGPSec updates are
deprioritized or throttled to avoid causing adverse performance impacts,
perhaps in conjunction with existing RFD implementations for routes that
are both long-path and churning.

I can try to contribute some text once the WG weighs in on what direction
they want to take to address this, but I wanted to at least get the
discussion started.

Thanks,

Wes George

On 10/27/14, 7:40 PM, "Matthew Lepinski" <[email-masked]> wrote:

>Just posted the -10 revision of the document.
>
>The only normative change was to decouple BGPsec validation from
>Origin Validation. (This is a normative change to the validation
>algorithm in Section 5.) This is based on working group discussions at
>IETF 90 and confirmed on the list in September.
>
>Additionally, there were some text changes made, including a reference
>to the AS-Migration document (and an accompanying text change
>regarding pCount=0).
>
>I have a couple of improvements to the security considerations text
>that I wasn't able to fold into this version of the document.
>
>Other than improving the security considerations, I am not aware of
>any open issues in this particular document.
>
>- Matt Lepinski
>
>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Nov 2014 11:13:25 +0600

> Per discussion during IDR/SIDR meeting Friday, there may need to be
> some text in the security considerations around the attack vector of
> sending many updates with long (but valid) AS_Paths

could you please describe how an attacker can send many long bgpsec
paths?  how are these long paths signed?

randy

---

From: Warren Kumari <[email-masked]>
Date: Mon, 17 Nov 2014 12:21:07 -1000

> paths?  how are these long paths signed?

I'm not Wes, but I could imagine an attacker who has 2 ASNs making a
path that looks like:

192.0.2.0/24   174 3561 17 42 17 42 17 42 .... 17 42 17 42 701

Seems like it would be a lot of work for very little fun, but that's
what I'd understood the question to be.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "George, Wes" <[email-masked]>
Date: Mon, 17 Nov 2014 17:27:07 -0500

>paths?  how are these long paths signed?

Though I'm guessing it might be possible to try it as a replay attack
(grab a string of signed ASNs from the path of one or more routes that go
past you, then add them to another set of routes that doesn't already have
them), I was thinking the attacker likely has to have the ability to sign
those ASNs (they have the keys) so that they're valid, otherwise the route
just gets dropped.
It's not hard to get an ASN or 10. $Dayjob have 12 or 15 that I know
about, Comcast has 30+ ASNs, and plenty of hosting providers use an ASN
per location to avoid needing ways to connect islands of the same ASN
together. Normally they don't have routes that go through each ASN, but
spinning up BGP speaking VM instances on Quagga or similar to generate
routes to inject and sign from one ASN to another is not hard. In order to
avoid the protections that Origin Validation would provide, it's less
likely that this is going to be done at origin, but rather by an ASN that
is in the middle of the path.
I.e. <origin> -- <upstream 1> -- <bad upstream> -- <upstream 3>
Bad upstream receives routes from its downstream, and adds the list of
ASNs it can sign for plus any churn it wants to induce, sends it to
upstream 3, which in this case would be the target of the attack, and if
it propagates the routes further, networks beyond it would also be
affected. Even if the added ASNs in the path have the result of
redirecting traffic to another candidate with a shorter AS Path, the route
update itself will propagate on and still eat CPU and memory on the
routers it transits, and maybe even be amplified as it gets duplicated to
be sent to the learning router's BGP peers. This attack is different from
the normal AS Path attacks BGPSec was designed to protect against, because
it's not necessarily trying to add a specific ASN to shift traffic to a
certain network, that's just a side-effect of the attempt to attack the
routers running BGPSec themselves.

I'm thinking of this in terms of worst-case scenario, where one builds a
nice long ASN path, then uses it to lengthen a few thousand routes as they
pass, and then churn them, either on the assumption that RFD isn't
configured, or keeping the churn on an individual route low enough to keep
from triggering the dampening, but churn lots of routes simultaneously.

I admit that this seems like a stretch since exploiting it requires access
to ASNs and keys and possibly compromising a router in the middle of a
network so that you can have a platform to launch the attack, but there is
also the possibility that the simple act of having a long string of valid
ASNs in the actual forwarding path could cause this, especially in
conjunction with churn, lots of route deaggregation, and misconfiguration
(route leaks) that has the net result of taking a long AS path and making
it longer. The key question as to how much of a problem this actually
might be is, "how long of an AS Path is too long in BGPSec?" or
alternately, "when does the product of number of signed routes and number
of ASNs per route start causing performance degradation during
validation?") I'm not sure we can know that at this point, because it'll
depend on a lot of things, so unless we can make some common-sense
inferences based on what we see in the routing table, we mainly have to
identify it as a potential problem.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Nov 2014 14:35:20 -0500

Wes,

To first order I agree with your concern of this DoS vulnerability,
but with some minor clarifications.

1. BGPsec-signed updates are sent only between ASes that agree to
send and receive (separate choices) this signed data. So, an
attack of this sort is perpetrated only against an immediate neighbor
that agrees to accept BGPsec traffic from you. You cannot send
a BGPsec route to an arbitrary AS that it not configured for you
as a neighbor.

2. As you noted, an AS can generate a path only for ASes that it
holds, and thus, for which it holds private keys. So, a long path
of the sort you describe is directly traceable to the resources holder,
creating a "smoking gun" effect, for forensic purposes.

If we can agree on a max path length, based on real world data, and
RECOMMEND that routers enforce this limit, we can mitigate the
ability of an AS to Dos it's neighbor (and others). That, combined with
the ability to identify who added all of the questionable AS entries,
might provide a deterrent to this behavior.

Still, even with a max path length, there is the potential to add just a 
few,
unnecessary ASes to every signed route that traverses an evil AS, to add to
the burden of neighbors and those beyond. Given all the folks who track
routing updates, this too will probably be noted by a bunch of folks, and
because of the signatures, there will be no doubt about the source(s). So,
here too, that may prove to be a deterrent.

I believe someone at the meeting observed that smart implementations will
try to address this sort of concern by postponing BGPsec crypto processing
when resources get scarce. While I agree that this represents another attack
vector, the ability to identify the perpetrators may diminish the attraction
of this attack strategy.

In any case, this is a good topic to address, perhaps in the BGPsec
security considerations section, plus a separate document that suggests
implementation notes.

Steve

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 24 Nov 2014 20:08:39 +0000

Wouldn't GTSM and tcp-ao help with DOS attacks?

I would recommend they be put in in the paragraph below.

7.3<https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-10#section-7.3> Mitigation of Denial of Service Attacks

BGPSEC speakers
   should implement an update validation algorithm that performs
   expensive checks (e.g., signature verification) after performing less
   expensive checks (e.g., syntax checks).  The validation algorithm
   specified in Section 5.2<https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-10#section-5.2> was chosen so as to perform checks which are
   likely to be expensive after checks that are likely to be
   inexpensive.

https://tools.ietf.org/html/rfc5082

https://tools.ietf.org/html/rfc5925

As examples or recommendations for the "less expensive" checks.

In fact it should be GTSM, tcp-ao THEN bgpsec validation.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: sidr [[email-masked]] on behalf of Stephen Kent [[email-masked]]
Sent: Monday, November 24, 2014 12:35 PM
To: [email-masked]
Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10

Wes,

Steve

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.