These ideas have floated around for 20+ years. They have even appeared in early BGP specs ... See "LINK TYPE" in http://www.ietf.org/rfc/rfc1105.txt.
I actually think this is a useful idea, but the discussion always rat holes in the supposition of absolute filtering rules and proof by counter examples. I think it would be simple for transmitters to indicate and sign their view of the peering relationship they are sending an update over. Customer, provider, peer, or unspecified. (where/how you encode this is a detail, I would suggest in the PATH SIG unless we decide to take on the more general approach below). What receivers do with that information ... Just like validation state, would be a matter of local policy. Worse case is everyone chooses unspecified and we waste two bits under the signature. Best case for those who don't care about declaring who their customers/providers are to their customers/providers .... Then receivers can choose to filter "V" routes if they wish. dougm -- Doug Montgomery Mgr. Internet & Scalable Systems Research / ITL / NIST On 11/21/11 10:01 AM, "[email protected]" <[email protected]> wrote: >What about using a "BGP community" to set your bit "1/0" and propose >mechanisms to sign the communities tagged by an AS? > >Mickael > >-----Message d'origine----- >De : [email protected] [mailto:[email protected]] De la part de >Jakob Heitz >Envoyé : vendredi 4 novembre 2011 06:18 >À : Brian Dickson; Stephen Kent >Cc : sidr wg list >Objet : [sidr] Route Leak fix: V free routing > >I had a different idea. > >Model the internet as providers, customers and peers. >A provider is above you, a customer is below you and >a peer is level to you. > >Add a "down" bit to the BGPSEC signature block. >If an AS sends an update to a customer, it sets the >"down" bit. > >The rule is "V" free routing. >Once an update goes "down", it can not come back "up". >Sending to peers is always ok. >If an AS receives from a customer an update >that has a "down" bit in the BGPSEC attribute, >it will detect the update as a route leak. >Policy will dictate how to deal with it. > >An AS sets the "down" bit to indicate its wish that >the announced prefix stay within the customer's bounds. >As it is signed, it can not be changed further down >the path. > >-- >Jakob Heitz. > >On Tuesday, November 01, 2011 4:01 PM, Brian Dickson <> wrote: > >> Upon further consideration, in the interest of not revealing >> information that is currently not revealed in BGP, I'll suggest >> modifying my earlier proposal as follows: >> - the proposed flag needs to exist and be signed by the sender, but >> only the last instance of the flag is carried with the route. >> - the enforcement of not-promote still needs to be done by the >> protocol >> - the route will only have the "transit" bit on a per-route basis, of >> the last AS (regardless of where demotion occurred, if at all) >> - the receiver of a route with the "transit" bit set will generally >> already be aware that the receiver is providing transit service, if >> legitimately set >> >> Otherwise, everything else still stands to reason... >> >> Brian >> >> On Tue, Nov 1, 2011 at 6:45 PM, Brian Dickson >> <[email protected]> wrote: >>> 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr >_______________________________________________ >sidr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sidr >_______________________________________________ >sidr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
