Subject: [GROW] Route leaks

From: Doug Montgomery <[email-masked]>
Date: Fri, 25 Jul 2014 13:40:06 -0400

The last point that Sriram made is important to the higher level discussion
of the problem.

Semantically what we are proposing is that a BGP speaker can ad a semantic
tag to a route that describes restrictions on the intent of the
authorization that is implicit in sending a peer a BGP route.

Note that the one tag we suggested was not "DOWN" or "CUSTOMER" it was the
intent that the sender expects that you will not redistribute this update
to transit providers.

"I am sending you this route, but I do not wish it propagated to your
providers"

So discussing the semantics of the tag: what that tag applies to (e.g.,
specific route, vs peering session), what the tags attempt to signal, what
the security properties of such a tag should be, and what policies might
one build using such tags ... is the important part.

The specific encoding proposed was the result of one attempt to think
through these issues ... but not all the thoughts made it into the draft.

dougm
-- 
DougM at Work

---

From: Tony Tauber <[email-masked]>
Date: Fri, 25 Jul 2014 15:12:33 -0400

How is this different than tagging with communities today?
In either case, the provider's correct action on the semantics is needed
(and can go awry through misconfiguration).

Tony

On Fri, Jul 25, 2014 at 1:40 PM, Doug Montgomery <[email-masked]>
wrote:

> The last point that Sriram made is important to the higher level
> discussion of the problem.
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
>

---

From: Jared Mauch <[email-masked]>
Date: Fri, 25 Jul 2014 15:27:33 -0400

Communities are not sent by default (eg Cisco). Route leaks come for free on Cisco too. 

Jared Mauch

> On Jul 25, 2014, at 3:12 PM, Tony Tauber <[email-masked]> wrote:
> 
> In either case, the provider's correct action on the semantics is needed (and can go awry through misconfiguration).
> 
> Tony
> 
>> On Fri, Jul 25, 2014 at 1:40 PM, Doug Montgomery <[email-masked]> wrote:
>> The last point that Sriram made is important to the higher level discussion of the problem.
>> 
>> Semantically what we are proposing is that a BGP speaker can ad a semantic tag to a route that describes restrictions on the intent of the authorization that is implicit in sending a peer a BGP route.
>> 
>> Note that the one tag we suggested was not "DOWN" or "CUSTOMER" it was the intent that the sender expects that you will not redistribute this update to transit providers.
>> 
>> "I am sending you this route, but I do not wish it propagated to your providers"
>> 
>> So discussing the semantics of the tag: what that tag applies to (e.g., specific route, vs peering session), what the tags attempt to signal, what the security properties of such a tag should be, and what policies might one build using such tags ... is the important part.
>> 
>> The specific encoding proposed was the result of one attempt to think through these issues ... but not all the thoughts made it into the draft.
>> 
>> 
>> 
>> dougm
>> -- 
>> DougM at Work
>>

---

From: Tony Tauber <[email-masked]>
Date: Fri, 25 Jul 2014 15:36:03 -0400

> Communities are not sent by default (eg Cisco). Route leaks come for free

Right, I meant "intentionally implemented" communities.
Anyway, so the idea is to introduce a new knob that's on by default and
which is more resistant to breaking off?

Not so compelling to me as to warrant a wholesale protocol extension.

Tony

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 25 Jul 2014 17:23:22 -0400

as in the room, I'd hope to focus on-list on:
   "What is a route-leak?"

I thought that a taxonomy:
   "a scheme of classification."

of what route-leaks/hijacks are would be helpful. It's possible that
we could call all 'hijacks', 'mis-originations', 'valley-free
violations'  the same thing: "Route Leaks"... but having a definition
and a method to view these from either a direct neighbor OR (ideally)
2 as-hops away would be much better.

Sriram/doug's document talks about 4 types of leak, of these 1, 2, 3
all basically look the same to me, the original set is:
   1 - prefix-hijack with path to legitimate origin
   2 - u-turn with more specific prefix
   3 - u-turn with full-prefix
   4 - internal-prefix-leak

To me this sounds like:
   1, 2, 3 are all saying the same thing: "Someone leaked all or part
of my prefix, but provided transit to me anyway"

and 4 is mostly lost to me... though I suppose it might mean: "my peer
leaked my prefix to his transits"

The goal for this work really ought to be:
  define route-leak

Then the next follow-on is:
    "Do operations folks view this thing as defined to be a problem?
should someone fix that problem?"

-Chris

---

From: Tony Tauber <[email-masked]>
Date: Sat, 26 Jul 2014 11:21:44 -0400

Well described, Chris.   I agree this work is relevant, appropriate and
useful.

Tony

On Fri, Jul 25, 2014 at 5:23 PM, Christopher Morrow <
[email-masked]> wrote:

> >> Communities are not sent by default (eg Cisco). Route leaks come for
> free
> >> on Cisco too.
> >
> >

---

From: Pedro Andres Aranda Gutierrez <[email-masked]>
Date: Sat, 26 Jul 2014 18:46:57 +0200

I agree that an attempt at a taxonomy is significant.

However I'd keep the leak and hijack separate.

Leak diverts traffic to an unintended path whereas hijack causes DoS or is
used for a man-in-the-middle.

/Pedro A. Aranda

---

From: Doug Montgomery <[email-masked]>
Date: Sat, 26 Jul 2014 13:14:18 -0400

What seems necessary to address the set of problems we examined is the
ability to:

1. Tag additional semantics for an individual announcement who's meaning is
globally known.

2. To have these tags be transitive, remaining on the route end to end (not
just one hop).

3. In speaking to operators who were concerned about intentional leaks of
routes to critical infrastructure, it seems that the tags should be secured
so that a party anyone where on the net could verify which AS added the tag
on transmission to specific peer, and verify if a tag had be modified or
stripped in transit.

It did not appear to us that this was achievable with current community
mechanisms.   One could easily implement such semantics through some new
variant of community+protections, but it did not seem the current mechanism
addressed what we perceived as the requirements.

dougm

On Fri, Jul 25, 2014 at 3:12 PM, Tony Tauber <[email-masked]> wrote:

>> Semantically what we are proposing is that a BGP speaker can ad a
>> semantic tag to a route that describes restrictions on the intent of the
>> Note that the one tag we suggested was not "DOWN" or "CUSTOMER" it was
>> the intent that the sender expects that you will not redistribute this
>> update to transit providers.
>>

-- 
DougM at Work

---

From: Thomas Mangin <[email-masked]>
Date: Sat, 26 Jul 2014 19:21:22 +0100

Hello,

It is from 2007 but may still be relevant to this work :-)
http://thomas.mangin.com/data/pdf/LINX%2057%20-%20Mangin%20-%20BGP%20Leak.pdf

IMHO, any solution should allow to implement the solutions presented but more easily.

Thomas

On 26 Jul 2014, at 18:14, Doug Montgomery <[email-masked]> wrote:

> What seems necessary to address the set of problems we examined is the ability to:
> 
> 1. Tag additional semantics for an individual announcement who's meaning is globally known.
> 
> 2. To have these tags be transitive, remaining on the route end to end (not just one hop).
> 
> 3. In speaking to operators who were concerned about intentional leaks of routes to critical infrastructure, it seems that the tags should be secured so that a party anyone where on the net could verify which AS added the tag on transmission to specific peer, and verify if a tag had be modified or stripped in transit.
> 
> It did not appear to us that this was achievable with current community mechanisms.   One could easily implement such semantics through some new variant of community+protections, but it did not seem the current mechanism addressed what we perceived as the requirements.
> 
> dougm
> 
> 
> 
>

---

From: Doug Montgomery <[email-masked]>
Date: Sat, 26 Jul 2014 14:28:03 -0400

In some ways I think building a taxonomy of scenarios that could be called
route-leaks is useful,  but I do think there is a danger is overly fixating
on a precise definition of a commonly used term (i.e., arguing too much as
to what is or is not a route leak).

The real essence of the problem (in my mind) is that the robustness of the
global BGP system, as a practical matter makes assumptions about some
transitive (3+ AS path) properties of announcements, with out any/enough
well know transitive mechanisms in the protocol (other than AS_PATH) to
assist in implementing these assumptions, and or detecting that they have
been violated.

Sending a BGP update to a peer is an implicit authorization  to that peer
to route traffic from them towards the destination prefix.   But the
business models of the Internet are such that sending such authorization to
a peer is not saying I am willing (or engineered) to route traffic from any
and all other networks that my peer might distribute that update too.
 Often the business model / engineering dictate that the sending AS only
intended for that update to be distributed to some subset of the next hops
peers.

No strictly bi-lateral mechanism will assist a 3rd party to be able to
detect that they received an updated that was not the intent of the
announcing peer 2+ hops prior.

Previous attempts/ideas to completely prescribe solutions to specific
problems in this space seem to have failed due to relying on mechanisms
that can not be universally prescribed, or on broad access to data sets
that have privacy concerns.

Our motivation was to think of the problem in this context.   Could one add
simple mechanism to the protocol that would allow interested parties (both
BGP senders and receivers) to indicate some minimal, but useful intended
transitive properties of routes, and allow interested receivers to detect
in some scenarios that these intended properties have been violated.

We chose to look at a set of BGP robustness problems that we could find in
the recent literature and trade press.   We identified a simple signaling
mechanism, not present in the current protocol, that could enable
detection/mitigation of all of the scenarios we found in those documents.

Solutions to this by definition transitive problem that suggest that
everyone just bi-laterally do the right thing, certainly have the problem
that they are not robust to single AS, or implementation, failures
(implementation or configuration), nor are they robust against a single AS
purposefully violating the bi-lateral policy/mechanism.

So, another approach to thinking about the problem is to consider if there
are common BGP robustness problems that could benefit from a mechanism to
tag individual hops along the AS path with additional transitive semantic
information.

If so, what are those problems, what semantics would  tags need to address
the problem, and what properties should those tags have (e.g., security,
known/wellknown, transitivity, etc).

We identified a set of such transitive problems (often called as a "leak"
by most) and proposed a simple transitive tagging mechanism that could
assist in mitigating them.

Other transitive robustness problems maybe addressable with such a
mechanism.   Those problems may or may not be commonly known as "leaks".
Some might identify other scenarios that they might  call "leaks" that
would not be addressable by such mechanisms.

Clearly we need to bound the problem space (in particular, it seems clear
that it is not possible to address all bi-lateral policy violations with a
simple signaling mechanism) .... an there are some folks who refer to any
announcement that violates policy as a leak.

dougm

-- 
DougM at Work

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Jul 2014 16:57:40 -0400

Doug,

> 2. To have these tags be transitive, remaining on the route end to end (not

The first property is describable in the semantics of a community, but more
likely via an extended community.

The second property suffers the issue that much of people's policies end up
being "throw out all communities that aren't mine".  This is one of the
things that hampered NO_PEER.

> on transmission to specific peer, and verify if a tag had be modified or

I'm not sold on this property being essential, but it's certainly a Nice To
Have item.  My reasoning on this is that the behavior of this feature would
be to inform a receiving peer that someone previously in the as-path had
suggested that it shouldn't be accepted at a given level of the hierarchy.

Rather than "maliciously" setting that property, they could have simply not
have propagated the route.

The attack space for such malicious behavior is probably that of the AS
hop-limit features that had previously been discussed.  You'd need to find
something that violates expected forwarding behaviors.

> addressed what we perceived as the requirements.

The other property I find worth thinking about, discussed with Sriram in a
prior hallway conversation, is that "up" will be not only with respect to a
given prefix, but who is setting "down".  

I find it somewhat likely that a cooperating set of tier1/tier2 providers
could simply achieve the desired behaviors of a version of this feature
simply by agreeing to look for this bit as set by any of them.

Or, as I hand-waved in the hallway using the CAIDA skitter graph of AS
connectivity as an example, one provider may be willing to accept a
violation of "up" depending on who and where it came from.  But as long as
the information about who set the bit is kept, each receiving party may make
this independent choice.

-- Jeff

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 28 Jul 2014 22:39:29 -0400

I'd really like to urge us to stick to 'what is the problem we are
trying to solve?'
Specifically:
 "Can you define a 'route-leak' please"

and I'm OK with there being more than one TYPE of 'route-leak', job 1
for GROW should be to do this, then move along to: "And operations
folk really don't like these types of things, could there be a remedy
please?"

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 28 Jul 2014 22:40:17 -0400

> to what is or is not a route leak).

The state today is: "I know it when I see it"
which isn't super helpful in the 'gosh, it'd sure be nice to stop
having ISPA leaking my routes all over creation' fight.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 30 Jul 2014 23:06:10 +0000

>> 3. In speaking to operators who were concerned about intentional 
>> leaks of routes to critical infrastructure, it seems that the tags 
>> should be secured so that a party anyone where on the net could 
>> verify which AS added the tag on transmission to specific peer, and 
>> verify if a tag had be modified or stripped in transit.
>
>I'm not sold on this property being essential, but it's certainly a 
>Nice To Have item.  My reasoning on this is that the behavior of this 
>feature would be to inform a receiving peer that someone previously in 
>the as-path had suggested that it shouldn't be accepted at a given level of the hierarchy.
>
>Rather than "maliciously" setting that property, they could have simply 
>not have propagated the route.

Jeff,

Reading your last statement above, I feel there is a misunderstanding here.
Take the example:
Provider A ----[tag(A) = 'Not Up'] ----> 
Customer X ----[tag(A) = 'Unrestricted'; tag(X) = 'Unrestricted'] ---->Provider B

Customer X is multi-homed and wants to maliciously leak the prefix update learned from
Provider A to Provider B. Tags are added to the update on each hop and are transitive.
Note that Customer X is maliciously changing the tag value set by Provider A.

Customer X does not benefit merely by not propagating (as you suggested).
Instead, Customer X benefits by maliciously modifying Provider A's tag from
'Not Up' to 'Unrestricted' while forwarding the update to Provider B.
That is why securing the tag values (end-to-end) may be necessary.

Sriram

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 31 Jul 2014 01:21:08 +0000

>> In some ways I think building a taxonomy of scenarios that could be 
>> called route-leaks is useful,  but I do think there is a danger is 
>> overly fixating on a precise definition of a commonly used term ...
>

Chris,

If we step back for a moment and look at how we tackled prefix hijacks, 
there is a valuable lesson there that applies also to tackling route leaks.

Initially, we classified prefix hijacks into two types:
1. Prefix hijack,
2. Subprefix hijack.
This was based on commonly observed hijack incidents.

We started looking at solutions, and determined that generating 
ROAs for the prefixes would be a solution for the first one.
Then we thought a bit more, and determined that specifying 
MaxLength in the ROA would be a partial solution for the second one.

After we included ROAs in our design, we realized that there are these 
two new classes of prefix hijacks that try to defy ROAs and maxLength:

3. Subprefix hijack where maxLength is not violated, 

4. Faked-origin (prefix/subprefix) hijack.

Thus, our understanding evolved to classify prefix hijacks into four types, 
each calling for possibly a different solution component.
This was, in part, the consequence of the solutions we were considering.
Then we thought that perhaps we can put two ASes in the ROA (origin AS and the second AS) 
to try to disadvantage the faked-origin hijacks. 
Because then the hijacked route is at least two hops longer compared to the legitimate one.
But eventually, we decided to do the path signatures since we had to protect AS path anyway, 
and path signatures approach also solved prefix hijacks of Type 3 and Type 4 above
-- because they are essentially path modifications.
Viola: Now we have the solution for all four classes of hijacks plus full AS path protection!
(Granted -- our solution is not yet complete because it doesn't solve route leaks.)

The essential lesson that I think we learned from the above is that 
classification based on observed or easily conjectured scenarios works!
So yes, classify and conquer should be the motto here.
As is evident from the above, starting to propose solutions based on what we know
-- even if it is partial knowledge -- is helpful.
And with some solution components in place, further taxonomy naturally evolves 
to provide greater clarity into problem definition and classification.

Sriram