Subject: [Idr] Kathleen Moriarty's No Objection on draft-ietf-idr-add-paths-14: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 02 May 2016 10:58:01 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-idr-add-paths-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. I'd like to see the security considerations explicitly state that this
could result in a denial of service attack.  The resource consumption is
stated nicely, but it would be good (following RFC3552) to state the type
of attack.

  "This document defines a BGP extension that allows the advertisement
   of multiple paths for the same address prefix without the new paths
   implicitly replacing any previous ones.  As a result, multiple paths
   for a large number of prefixes may be received by a BGP speaker
   potentially depleting memory resources or even causing network-wide
   instability."

Adding something like: "This could result in a denial of service
attack."

2. Change the last sentence of the security considerations section in
light of the first paragraph to something like:

From:
   This document introduces no new security concerns in the base
   operation of BGP [RFC4271].

To:
  Security concerns in the base operation of BGP [RFC4271] also apply.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 3 May 2016 14:49:09 +0000

On 5/2/16, 1:58 PM, "iesg on behalf of Kathleen Moriarty"
<[email-masked] on behalf of
[email-masked]> wrote:

[Author hat on.]

Kathleen:

Hi!

Yes, we'll take on both suggestions in the next revision.

Thanks!

Alvaro.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 May 2016 10:32:10 -0400

Kathleen,

> Adding something like: "This could result in a denial of service

The considerations of a BGP peer's normal protocol interactions with a BGP
speaker - with or without add-paths - being considered a Denial of Service
seems to be unnecessary scare words.

While the add-paths case does permit a much larger number of paths to be
propagated, the same issue may apply to simply sending along a much larger
amount of some routing table than expected.  This could include sending a
full Internet routing table to a router scaled for a few thousands of
routes.

I recommend against this change.

>   Security concerns in the base operation of BGP [RFC4271] also apply.

I think this covers it nicely.

-- jeff

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 May 2016 10:29:20 -0400

Hi Jeff,

Thanks for your response.  Inline.

> I recommend against this change.

This is just a comment, so it's up to the shepherd and AD, but adding
this would be in line with the guidance from RFC3552.

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

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 12 May 2016 12:08:22 -0400

Hi Kathleen,

> https://tools.ietf.org/html/rfc3552

Looking at RFC 3552 S. 2.3.3 ("Denial of Service") it does suggest that DoS be considered and identified when relevant. I think Jeff's point (which I agree with) is that add-path doesn't change the fundamentals of BGP with respect to DoS -- the peer can send me a bazillion routes, differentiating them by prefix, or by path-id, or both. It just comes down to which bits in the NLRI are used to make the routes unique.

Anyway, point taken that we should think about this more before making any definite conclusion, and if add-path does create any new DoS vulnerability we should identify it.

Regards,

--John

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 12 May 2016 12:41:51 -0400

> Anyway, point taken that we should think about this more before making any definite conclusion, and if add-path does create any new DoS vulnerability we should identify it.

Thanks, John!

-- 

Best regards,
Kathleen