I have a proposal, to address the route-leak issue. It necessarily requires changes to all of the following documents, if it is adopted: - threat model - protocol - requirements - NB: this proposed element does not have a corresponding value in vanilla BGP. - (If BGP had this already, there would not be any route leaks.)
Here is what I propose: Add an announced Path Attribute, "Transit", to every BGPSEC signature block on an announced prefix. "Transit" is a flag bit, and applies to the _announcement_ between ASNs in the path. Include this Transit flag in the set of things that are signed. Make this attribute mandatory to BGPSEC, applied to every signature block on a route. Every BGPSEC peering session is either Transit, or Not-Transit, from the perspective of the local AS. For BGPSEC speakers A and B, all four combinations are legitimate scenarios: A and B are "strictly speaking, peers" - e.g. 'tier-1' networks A and B: - A->B is "not-transit" - B->A is "not-transit" A provides transit to B (or vice versa; exchange labels A and B): - A->B is "not-transit" - B->A is "transit" A and B provide "mutual backup transit": - A->B is "transit" - B->A is "transit" The last scenario *should* be extremely rare. The last scenario happens to also be the default behavior for BGP when unconstrained routing announcements exist, i.e. inexperienced network engineers are given "enable" and asked to "do BGP". Here are the specific details and semantics, that in general make "the right thing" happen, and stop route leaks from happening, whether by accident or design. 1) The "transit" bit can be demoted to "not-transit" (on received, signed BGPSEC routes). 2) The "transit" bit cannot be promoted from "not-transit" to "transit" (on received, signed BGPSEC routes). 3) Routes can be originated as "transit" or "not-transit". The sensible default behavior is "transit". 4) Routes that are received, under a default configuration, SHOULD be demoted to "non-transit". 4a) Transit ISPs MUST change the (default) configuration on their customers' BGP sessions to not-demote their customers' routes. 4b) Mutual-Transit arrangements MUST change the (default) configuration to not-demote their respective routes. 5a) A route with the "transit" bit MAY be sent over any BGPSEC peering session. 5b) A route received with the "transit" bit set MAY be accepted by the receiver. 6a) A route with the "transit" bit not set (i.e. a not-transit route) MAY NOT be sent over a peering session that does not permit "transit" routes in unmodified (i.e. a peering session that demotes to not-transit). 6b) A route with the "transit" bit not set (i.e. a non-transit route) MAY ONLY be accepted over a peering session configured to send "transit" routes (i.e. an "upstream" peer). If this logic is implemented in the PROTOCOL, and outside of user configuration control (i.e. limiting user control to "not-demote" and "send-transit"), route leaks cannot happen, or at worst have a scope of the next local AS if the _receiver_ makes a configuration error. That is to say, route leaks become, at worst, non-transitive. Here's a summary of how and why: Not-transit (peer) routes can only be sent "downstream", where "downstream" can include mutual-transit links. Transit routes can be sent everywhere, but only retain their "transit" bits when _both_ the sender _and_ receiver agree that the link is a transit link. As soon as a route loses its "transit" bit, it can never regain it, whether by accident or design. Note the following: - "Transit" or "not-Transit" is applied on the sender side of peering. Default is "Transit". - "Demote" or "not-Demote" is applied on the receiver side of peering. Default is "Demote". - The originator of a route sets "Transit". - "Transit" on a sender-side really means "Do not demote this on send". - Thus, a sender with "Transit" configured, will never _promote_ a non-transit route to transit. - And thus, a receiver will automatically filter out "non-transit"-marked routes from a combined set of routes that includes "transit" and "not-transit", if only "transit" are allowed (e.g. an upstream ASN) [The original motivating discussion follows...] On Tue, Nov 1, 2011 at 9:57 AM, Stephen Kent <k...@bbn.com> wrote: > At 4:20 PM -0400 10/29/11, Danny McPherson wrote: > > Some comments on sidr-bgpsec-threats-00 below.. > > Most substantial of my concerns is Section 5's "Residual > Vulnerabilities", specifically: > > "BGPSEC has a separate set of residual vulnerabilities: > > - BGPSEC is not able to prevent what is usually referred to as > route leaks, because BGP itself does not distinguish between > transit and non-transit ASes- This is a chicken-and-egg issue. Since there are several documents before the WG, some of which have not yet even been accepted by the WG, it is premature to say what BGPSEC does and does not do. We are (in this WG) collectively defining what BGPSEC does and does not do. The real question is, fundamentally, are there unavoidable limitations that make it impossible for BGPSEC to do particular things? > Do we really consider it acceptable that the solution and machinery > we're recommending will NOT prevent "route leaks", IMHO, "No". Frankly, I consider fixing the route leak problem non-negotiable. We can and must fix it. It hasn't been fixed in BGP, because there has always been the ability to mess with transitive attributes. Without enforcement, it can't truly be fixed. Since BGPSEC is solving the attribute-tampering problem, the practical realities that enabled route leaks, no longer strictly exist (within a BGPSEC realm). Which means, we can stop route leaks. I argue that, because we can, now, we MUST. > Route leaks represent a violation of an ISPs local policy, i.e., the ISP > is propagating routes that it, locally, did not intend to propagate. There > is no semantic in BGP that captures this aspect of local policy. Actually, no. Route leaks represent both a violation of a BGP speaker's intended local policy, *and* a violation of other BGP speakers' intended policies. There is nothing that prevents the addition of this new semantic (single bit) alongside signatures, and in particular within the signed data, which unequivocably establishes this intent. By signing the intent, it becomes globally known as well as locally significant. And by being signed, it is tamper-evident. Rejecting tampered paths, or de-prefering tampered paths, eliminates route leaks. Problem solved (IMNSHO). Brian _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
