[sidr] Route Leak fix: V free routing

[Jakob Heitz <[e-mail]>]

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