Re: [sidr] Route Leak fix: V free routing

["Montgomery, Douglas" <[e-mail]>]

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, "[e-mail]"
<[e-mail]> 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 : [e-mail] [mailto:[e-mail]] 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
>> <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>_______________________________________________
>sidr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sidr
>_______________________________________________
>sidr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sidr