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 protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Thursday, December 08, 2011 5:52 AM > To: [email protected] > Cc: [email protected] > 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. > > 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 > > _______________________________________________ > GROW mailing list > [email protected] > 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. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
