Subject: [sidr] BGPsec - proposal for threat model, protocol, requirements

From: Brian Dickson <[email-masked]>
Date: Tue, 1 Nov 2011 18:45:03 -0400

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-masked]> 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

---

From: Brian Dickson <[email-masked]>
Date: Tue, 1 Nov 2011 19:00:56 -0400

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

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 4 Nov 2011 01:18:01 -0400

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:

>> 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
>> 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) 
>> The real question is, fundamentally, are there unavoidable
>> limitations that make it impossible for BGPSEC to do particular
>> things? 
>> 
>> 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
>> 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.
>> 
>>> 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. 
>> 
>> 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
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: <[email-masked]>
Date: Mon, 21 Nov 2011 16:01:32 +0100

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-masked] [mailto:[email-masked]] 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.

-- 
Jakob Heitz.

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 21 Nov 2011 11:37:06 -0500

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-masked]"
<[email-masked]> 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
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 22 Nov 2011 15:45:24 +0200

> can choose to filter "V" routes if they wish.

[ thanks for the only actual constructive hint i have seen on this list
  for a while.  being still on travel and very time constrained, i have
  started just hitting delete to the repeat blather from the failed
  rpsec wg. ]

do you expect it to be covered by the signature?  if so, then the
business relationship is published globally.  do you see a way to assure
veracity and non-repudiation while not exposing globally?

randy

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Tue, 22 Nov 2011 10:37:49 -0500

On 11/22/11 8:45 AM, "Randy Bush" <[email-masked]> wrote:

>Randy

I think the exposure thing is a red herring.

Yes I expect it to be covered by a signature.

It will travel by BGP as far as the update travels, to exactly the same
set of players.   So that set of folks already know you have a peering
relationship, I suspect they can figure out what the effective
relationship is, if they care, with a little analysis already.

Of course collectors might capture the update ... Just as they do now
revealing the peering existence.

Concerned about that?   I would like to understand how the exposure is any
greater than just sending the update today?

Still if you are concerned, set the relationship to "unspecified".

It is just a low cost tool.    I think one of our great mistakes is trying
to engineering what the end use cases will be for some of these
mechanisms.   I contend we have little idea exactly how all of this will
play out.   Providing a low cost mechanism that would allow interested
communities to address these forms of "leaks" .... especially if we don't
mandate that everyone has to either (a) reveal the relationship (I.e.,
unspecified) or (B) enforce any policy relative to it (e.g., drop "V") ...
Seems pretty harmless.

If 20 years for now 99% of the peering hops in AS_PATHS are "unspecified"
... We hashed and extra byte for nothing ... A risk I would be willing to
take.

I will note that all previous attempts at this (there was another interim
BGP spec years later that proposed a partial ordering among confederations
that imposed similar no-"V" properties, I could not find a stable
reference to that idea) suggested that it was an fixed property of the
peering relationship.

I will note that, so far, BGPSEC is 1 NLRI per update.  While I am not
suggesting sane reasons to do so, one might envision that some prefixes I
might transmit with "unspecified" while others I might not.

As far as veracity and non-repudiation .... I am setting a flag in an
update, not attesting to a contract.   The main (only?) use of which is to
suggest that you don't want your customers to transit the Internet through
you ... Nothing about that needs to be proved other than I set it.

Maybe I see an emotional issue here ... What if the bits were call "no
export to providers", "no export to peers", "unspecified", "free
distribution"... i.e., this is not a declaration of a contractual status,
it is a request by a transmitter to limit the distribution of an update
potentially multi-hops down stream.   I set this if I care, or think it
would be a public service, to constrain the flow of this update.  Mind you
this naming conveys that it is the transmitter who is trying to effect
policy, not the receiver.

The difference in having this under the PATH SIG is my preferences remain
with the update, unless someone strips the whole sig.

Once again, if receivers care about any of this, they would write policies
to implement their concerns ... Just as they will have to to react to the
validation state itself.

dougm

---

From: Brian Dickson <[email-masked]>
Date: Tue, 22 Nov 2011 11:50:48 -0500

> veracity and non-repudiation while not exposing globally?

I see a way...

[I'm assuming here, that the the places where business relation ships
need to be possible to hide, are only where there is the potential for
that hiding to have some effect:

- Transit providers know the relationship they have with their
customers, and their customers' customers...
- Peers expect to only hear their peers' customers (and customers' customers)
- (Leaving aside "special" arrangements)
- The only place where any announcement of non-customer routes occurs
is from transit to customer

end assumption]

What is needed, is a separate signature chain, "provenance".

The provenance chain is required ONLY when sending a customer prefix
to a non-customer.

The provenance chain consists of signatures over (the current "apex"
bit + previous signature)
The apex bit is either zero (on customer->transit AS path hops), or
one (peer->peer).

Once received from a peer or transit provider, and validated (if
present), the provenance chain MAY be stripped from the prefix.

If a prefix has no provenance chain, it is to be treated as if it has
at least one apex bit set.

Transit providers SHOULD reject any prefix from a customer, if any
"apex" bit is set (or if there is no provenance chain).

Peers SHOULD reject a prefix from a peer, which has no provenance
chain, or has a provenance chain with the "apex" bit set anywhere
except on the peers' entry on the chain.

Note that the vast majority of prefixes received by any AS, will be
non-customers' and can have their provenance chains removed. This
significantly reduces the impact of another set of signatures.

The absence of a provenance chain achieves the hiding of business relationships.

The absence of a provenance chain also permits the receiver of routes
to detect and stop leaked prefixes.

This mechanism would be applied on a prefix basis, not blindly on an
neighbor AS basis, although it would require knowledge of the
relationship with the neighbor to function correctly.

I think this meets all Randy's requirements, as well as Danny's.

Brian

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 22 Nov 2011 12:11:04 -0500

That's like making the British drive on the right: you can not incrementally deploy.

--
Jakob Heitz.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 22 Nov 2011 12:17:06 -0500

> That's like making the British drive on the right: you can not incrementally deploy.

I don't understand your comment - can you be more specific and precise?

What can you not deploy incrementally?

BGPsec? An end-to-end BGPsec secured path?

Or are you talking about adding this to the spec - clearly this would
be incompatible
with BGPsec implementations that didn't have it.

If the latter, note: the deployed set is currently the null set, so
your argument is moot.

Brian

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 22 Nov 2011 13:02:11 -0500

I stand corrected. Good idea.

If I understand it right, the presence of a BGPSEC signature
AND the absence of a provenance signature signals that
the prefix has left the set of AS's that are contracted
to provide it reachability.

--
Jakob Heitz.

> -----Original Message-----
> From: Brian Dickson [mailto:[email-masked]]
> Sent: Tuesday, November 22, 2011 9:17 AM
> To: Jakob Heitz
> Cc: sidr wg list
> Subject: Re: [sidr] Route Leak fix: V free routing
> 
> Or are you talking about adding this to the spec - clearly this
> would be incompatible with BGPsec implementations that didn't have
> it.
>