Subject: [GROW] I-D Action: draft-ietf-grow-bgp-gshut-03.txt

From: [email-masked]
Date: Thu, 08 Dec 2011 02:51:47 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Global Routing Operations Working Group of the IETF.

	Title           : Graceful BGP session shutdown
	Author(s)       : Pierre Francois
                          Bruno Decraene
                          Cristel Pelsser
                          Keyur Patel
                          Clarence Filsfils
	Filename        : draft-ietf-grow-bgp-gshut-03.txt
	Pages           : 12
	Date            : 2011-12-08

   This draft describes operational procedures aimed at reducing the
   amount of traffic lost during planned maintenances of routers or
   links, involving the shutdown of BGP peering sessions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-grow-bgp-gshut-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-bgp-gshut-03.txt

---

From: "George, Wes" <[email-masked]>
Date: Mon, 12 Dec 2011 10:07:12 -0500

Similar to some comments I gave in SIDR about their recommended use of route policy things like local pref to distinguish between validated and invalid routes, I think you need to spend a bit of time discussing the potential race condition that may exist between a gshut-triggered localpref value and other localpref values that may exist due to other processes, such as listening to communities to raise/lower localpref for traffic engineering between ASNs, or administratively setting a given localpref for a certain class of eBGP peer or route set.

Since the localpref value set by gshut will be configurable via route policy, the operator must take into account what gshut will trigger in terms of secondary route choices. The value for gshut should be set such that there are no other routes that are set with a localpref that is less than or equal to the value set for routes learned from a BGP neighbor undergoing a gshut, or there may be some scenarios where the gshut-tagged routes will not be seen as less-preferable and therefore it'll defeat the purpose of its use.

Regarding security considerations, I think that it might be good practice to recommend (require?) that the BGP session is secured using MD5 or TCP-AO so that you have some reasonable assumption of validity when the gshut community is received. This at least give you assurance that there is no MITM attack posing as the remote peer for the purpose of providing invalid BGP updates.

However, gshut suffers from the same security problem that SIDR is aiming to fix. That is, determining the validity of the *contents* of the announcement, rather than the validity of the TCP session serving as transport for the BGP updates. This isn't about determining intent (did my neighbor mean to set the gshut community or not?), but it is open for someone to set it maliciously. It's not really possible for receivers to determine if the gshut community is being sent legitimately or not, and eBGP peers are usually by definition untrusted. It's not just an issue of people misusing it to do traffic-engineering in a way that may be off-label. The fact that this can be transitive gives an attacker ASN along the path of a given route the ability to tag this community on routes that it propagates downstream and shift traffic away from or toward a given prefix without much validation as to whether the gshut is legitimate or not. For the same reason that the localpref value has to be low enough to ensure that there is no race condition with other local-pref sets in route policy, this ends up being a nuclear option to force traffic a given direction whenever localpref is the deciding factor on best-path. SIDR wouldn't protect against this, because it only secures the prefix + ASN.
I think that you open a very wide scope of attack by allowing a transitive version of this community, with no good way to mitigate it. Therefore, it's probably best to recommend that either the transitive option is used sparingly at best, or better still, to require special handling of this particular transitive community, that while it can move across ASNs (it sort of has to in order to work with eBGP) it MUST not be propagated beyond the receiving ASN (with a possible exception for confederation ASNs). This would limit the scope of this attack vector by virtue of limiting the number of ASNs downstream that can be manipulated using this community. The alternative is a BCP recommendation or even an implementation requirement that a filter is applied that strips this community such that it is not propagated beyond the receiving ASBR.

Generally, I'm not sure that a transitive community is required, because the direct neighbor receiving the gshut community will recompute best path based on this information, and then propagate an update to its downstream neighbors, most likely announcing a new best path. The downstream neighbors don't necessarily need a trigger to separately recalculate their own best path.

It might also be useful to have a configurable option for a timer that fires when gshut communities are detected, such that if it is received and the sending neighbor doesn't shut down within a configurable time limit, the gshut is then ignored. This would prevent some of the cases where people attempt to use it to move traffic around either maliciously or otherwise outside of a maintenance event. The downside of an implementation like that would be that one could set and unset the gshut community such that it generates considerable route churn, which can create processing overhead on downstream ASNs, and may ultimately trigger Route Flap Dampening, both of which could cause service impacts, especially if it is on a route where this is the only available path or the alternate paths are very sub-optimal.

Thanks,

Wes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, December 08, 2011 5:52 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [GROW] I-D Action: draft-ietf-grow-bgp-gshut-03.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Global Routing Operations
> Working Group of the IETF.
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

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: Pierre Francois <[email-masked]>
Date: Fri, 16 Dec 2011 15:33:17 +0100

George,

Thanks a lot for your comments. Answers tagged with [pfr].

> Similar to some comments I gave in SIDR about their recommended use of route policy things like local pref to distinguish between validated and invalid routes, I think you need to spend a bit of ti…

[pfr] In previous versions on the draft, we were saying that the 
local-pref set in the g-shut SHOULD be lower
than any other value of local-preference used in the policies of the 
ISP. This statement unfortunately
disappeared in the skimming process of the draft. Will fix that.

Due to the same concern, we also stated as an optional behavior of the 
ASBR undergoing the g-shut:

" optionally, adds an AS specific g-shut community on these paths
         to indicate that these are to be withdrawn soon.  If some
         ingress ASBRs reset the local preference attribute, this AS
         specific g-shut community will be used to override other local
         preference changes.
"

This behavior is recommended when the egress ASBRs are not the only 
speakers tweaking the local preference.

> Since the localpref value set by gshut will be configurable via route policy, the operator must take into account what gshut will trigger in terms of secondary route choices. The value for gshut sh…

[pfr] Indeed. Setting local pref to 0 is safe within the AS. Setting 
non-0 value is useful to handle transient inter AS behavior during BGP 
convergence. (e.g. g-shut a customer path, iBGP convergence transiently 
select a transit path leading to a withdraw to your peers). This is more 
of an optimization. But if one wants to optimize, it can pick the right 
local pref value indeed.

> Regarding security considerations, I think that it might be good practice to recommend (require?) that the BGP session is secured using MD5 or TCP-AO so that you have some reasonable assumption of…

[pfr] G-shut does not add on the security concerns related to MITM 
attacks, right? Anyone who can add the g-shut community, could already 
withdraw the path or advertise an invalid BGP attribute (value) along 
with it, right?
> However, gshut suffers from the same security problem that SIDR is aiming to fix. That is, determining the validity of the *contents* of the announcement, rather than the validity of the TCP session serving as transport for the BGP updates. This isn't about determining intent (did my neighbor mean to set the gshut community or not?), but it is open for someone to set it maliciously. It's not really possible for receivers to determine if the gshut community is being sent legitimately or not, and eBGP peers are usually by definition untrusted. It's not just an issue of people misusing it to do traffic-engineering in a way that may be off-label. The fact that this can be transitive gives an attacker ASN along the path of a given route the ability to tag this community on routes that it propagates downstream and shift traffic away from or toward a given prefix without much validation as to whether the gshut is legitimate or not. For the same reason that the localpref value has to
>    be low enough to ensure that there is no race condition with other local-pref sets in route policy, this ends up being a nuclear option to force traffic a given direction whenever localpref is the deciding factor on best-path. SIDR wouldn't protect against this, because it only secures the prefix + ASN.

[pfr] Aren't the security considerations of the draft accommodating 
these concerns properly?

> Generally, I'm not sure that a transitive community is required, because the direct neighbor receiving the gshut community will recompute best path based on this information, and then propagate an…

[pfr] I would also prefer g-shut to only rely on non-transitive extended 
communities.
We had to reserve FFFF0000 at the beginning of draft-g-shut because we 
had no means
to reserve a non transitive extended one at the time of the -00, and 
because implementations
of the non-transitivity aspect of these communities were found to be 
somewhat blurry.
> It might also be useful to have a configurable option for a timer that fires when gshut communities are detected, such that if it is received and the sending neighbor doesn't shut down within a con…

[pfr] In the security considerations, we say "the ISP should monitor the 
use of the g-shut community by its peers".
We had in mind that by doing this the ISP will be able to figure out 
transient/unjustified uses of g-shut, and
take appropriate action. I'm not sure it's reasonable to ask that the 
router implements the counter-measure
automatically. Would you want this?

Pierre.