George,
Thanks a lot for your comments. Answers tagged with [pfr].
On 12/12/11 4:07 PM, George, Wes wrote:
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.
[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 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.
[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 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.
[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.
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.
[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 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.
[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 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.
[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.
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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
