Subject: [sidr] Route Leaks

From: Danny McPherson <[email-masked]>
Date: Wed, 27 May 2009 10:23:07 -0600

Folks,
One of the primary misconfiguration modes that happens
today (and I experienced first hand ~15 years ago) is
route leaks where a customer becomes transit between a
set of peers.

That is, customer A is connected to ISP 1 and gets a
new connection to ISP 2.  When ISP 2 is turning up the
session they don't apply any ingress policy set for
explicit prefix or AS path filtering initially, but they
do tag the routes as customer routes (which they often
prefer over routes from bilateral peers).  The result
is that all the traffic in the ISP 2 -> ISP 1 direction
is forwarded through Customer A.

With a strict origin-only validation model the origin
and prefix are preserved, only the AS path changes.
This vulnerability can obviously be crafted to launch
various types of wide-spread or targeted attacks, and
the current solutions here provide no protection mechanisms
whatsoever for this.

The reality is that origin validation is critical, but
unless coupled with some mechanism to automate and
protect against leaks (intentional or not), then there's
a huge hole in the solutions space.  I know this was debated
quite a bit a while back (well, i.e., path v. origin) but
wanted to see how folks envision this being addressed with
the current work underway..

Thoughts?

-danny

---

From: Jared Mauch <[email-masked]>
Date: Wed, 27 May 2009 12:29:39 -0400

> the current work underway..

This happens a lot.  I have a large set of data over the past years  
that is collected here:

http://puck.nether.net/bgp/leakinfo.cgi

There is constant noise visible.  The currently visible problem set  
can be resolved with presently available tools  (eg: better bgp policy  
w/ communities).  There is very little incentive for providers to fix  
this.  We constantly have leaks with some customers leaking their  
transit-learned path for a customer of theirs.

- Jared

---

From: Danny McPherson <[email-masked]>
Date: Wed, 27 May 2009 10:32:38 -0600

On May 27, 2009, at 10:29 AM, Jared Mauch wrote:

> can be resolved with presently available tools  (eg: better bgp  
> policy w/ communities).

And I'm saying if SIDR doesn't protect against this, and
it happens a lot, then we're leaving a very large void.

> There is very little incentive for providers to fix this.

Right, until it's used to launch a targeted attack against
a target someone cares about.  To say there's no incentive
to fix this is to say there's no incentive for SIDR.

> We constantly have leaks with some customers leaking their transit- 
> learned path for a customer of theirs.

That was my experience as well...

-danny

---

From: Jared Mauch <[email-masked]>
Date: Wed, 27 May 2009 13:46:13 -0400

> it happens a lot, then we're leaving a very large void.

The challenge is building the appropriate layers of defense.  We have  
some defenses in our network to prevent these leaks.  They are not  
perfect.  I wish we could express the complex policies consistently  
across our network, but it's not possible without significant  
sacrifices to route cpu.  When they cross the line to customer  
impacting, we lose.

> to fix this is to say there's no incentive for SIDR.

There will always be people who will invest in these technologies,  
even if there is no payoff.  I wouldn't go so far as to say there's no  
incentive for SIDR.

Defense in depth/layered approach seems sensible to me, there is a  
more complex issue of getting people to deploy what the current best- 
practices are.  This is common throughout all unregulated industries.

	- Jared

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 27 May 2009 13:57:51 -0400 (Eastern Daylight Time)

On Wed, 27 May 2009, Danny McPherson wrote:

>> This happens a lot.  I have a large set of data over the past years that is 
>> collected here:
>> 
>> There is constant noise visible.  The currently visible problem set can be 
>> resolved with presently available tools  (eg: better bgp policy w/ 
>> communities).
>

Danny is right that fixing only origination is not complete protection.

But it is not possible to fix the path problem without fixing the origin 
problem first.  Any check of the validity of the path has to start with 
the validity of the origin.

So we're doing the first step first and we will need to do the next step 
next.

And I'd say that the largest void is mis-origination, so IMHO we are 
working on the biggest problem first.

--Sandy

>> We constantly have leaks with some customers leaking their transit-learned 
>> path for a customer of theirs.
>
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Danny McPherson <[email-masked]>
Date: Wed, 27 May 2009 13:42:30 -0600

On May 27, 2009, at 11:57 AM, Sandra Murphy wrote:

> But it is not possible to fix the path problem without fixing the  
> origin problem first.  Any check of the validity of the path has to  
> start with the validity of the origin.
>
> So we're doing the first step first and we will need to do the next  
> step next.

I don't think anything I said diverged from any of the above.
I just don't want folks to confuse the current efforts here with
solving this problem, and would like to ensure that no solution
here is complete until we address the path problem as well.

> working on the biggest problem first.

I'm not sure about that argument.  It's more like we're
putting bars on the windows and leaving the doors wide open,
but everyone is entitled to their opinion :-)

-danny

---

From: Geoff Huston <[email-masked]>
Date: Thu, 28 May 2009 06:18:23 +1000

On 28/05/2009, at 5:42 AM, Danny McPherson wrote:

>> And I'd say that the largest void is mis-origination, so IMHO we  
>> are working on the biggest problem first.
>

The original plot was that path validation would be passed to SIDR  
once RPSEC had managed to reach some form of consensus about what was  
the requirement with respect to path validation.

 From the charter: " The SIDR working group will  develop security  
mechanisms which fulfill those requirements which  have been agreed on  
by the RPSEC working group. In developing these  mechanisms, the SIDR  
working group will take practical deployability into consideration. "

The best that RPSEC could come up with (after some years) on the  
requirements realted to AS Path validation was :

    "AS_PATH Feasibility Check: The AS_PATH list may correspond to a  
valid list of autonomous systems according to the first verification  
category listed in the "Areas to Secure" Section above. Further study  
will determine the extent to which this is a security requirement."

So the options available to SIDR do not look overly inviting right now  
in terms of having a clear understanding ot what approach should be  
used for AS Path validation. The SIDR WG could:
   a) rerun the RPSEC debate on the topic (ugh)
   b) do nothing (hmm)
   c) do something else (???)

So its not exactly like we're doing task A and then heading on in an  
orderly manner to tackle task B. The problem is that while we have  
clear requirements for origination to work to, while the requirements  
for path validation remain unclear, and the last group to attempt such  
clarification got badly bogged.

   Geoff

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 27 May 2009 16:30:51 -0400 (Eastern Daylight Time)

On Wed, 27 May 2009, Danny McPherson wrote:

>> problem first.  Any check of the validity of the path has to start with the 
>> validity of the origin.
>> 

I agree that the problem is bigger than the origin authorization that sidr 
is working on.  However, please remember that origin authorization is the 
first step to full path protection, so everything we do here is vital and 
necessary.

Process-wise, the sidr charter does not talk about working on a solution 
to the path problem.  It talks about working on a solution to the origin 
problem.

At the time of chartering, the RPSEC group was tasked with establishing 
the BGP security requirements.  It was pretty clear at the time that the 
only consensus in that working group was on securing the origin, so that 
was all that the sidr charter specifically mentioned.  Because origin 
authorization protection had to be done as the first step toward path 
authorization, this was not wasted effort.

The charter says that we are tasked to work on RPSEC established 
requirements.  That left an opening for RPSEC to establish more than 
origin authorization as a security requirement.

But then RPSEC sputtered and died, without even publishing a draft that 
said that origin authorization was a requirement, much less saying 
anything about path authorization.

So to address anything beyond origin authorization, we need to re-charter, 
or open a new working group.

But the first step, the vital step, the necessary step, is the work we are 
doing right now on origin authorization.

> but everyone is entitled to their opinion :-)

No, we're talking about putting bars on the outside door and when we are 
done there we will proceed to put bars on interior doors.  Doing path 
authorization WITHOUT origin authorization is a protected structure built 
on sand.  Useless, wasted effort.

The origin authorization has to be done first.  FIRST.  Vital.  Necessary. 
Can't be skipped.  The base case.  We must do this.  We need this - it is 
not a choice.

OK?

--Sandy

---

From: Danny McPherson <[email-masked]>
Date: Thu, 28 May 2009 18:22:34 -0600

On May 27, 2009, at 2:30 PM, Sandra Murphy wrote:

> The origin authorization has to be done first.  FIRST.  Vital.   
> Necessary. Can't be skipped.  The base case.  We must do this.  We  
> need this - it is not a choice.

Again, I never said it was.

What I said is that if the aim here is to actually secure
the routing system then we need to squarely address the path
issue as well, or ALL the vulnerabilities that exist today
pretty much remain with only origin authorization - and if
they remain, it's unlikely operators are going to jump
through hoops to solve 10% of the problem.

That said, if SIDR is only concerned with development and
specification of an RPKI for origin authorization, and BGP
security and future employment of that will address the
rest of the problem, that mostly makes sense to me - but I
don't want folks to be confused about what SIDR is and is
not doing.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Thu, 28 May 2009 18:26:46 -0600

-danny

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 28 May 2009 20:48:28 -0400 (Eastern Daylight Time)

> Again, I never said it was.

Ah.  I thought your window barring vs open door was meant (or could be 
read by others) to indicate that you thought we were addressing the wrong 
problem.  So I said it is required as many ways as I could to try to 
emphasize the point that origin authentication is not the wrong problem.

> through hoops to solve 10% of the problem.

Origin authentication does protect against the accidental announcement of 
mis-origin info.  That's a lot of incidents that occur today.

However, as you and I and others have said, that doesn't stop the 
deliberate attack (or more subtle ways of messing up - there's no such 
thing as fool proof since fools are so ingenious).

> don't want folks to be confused about what SIDR is and is

The path issue could be a re-chartered SIDR work item or it could be a new 
working group work item.  I don't think it matters which.  Doing the path 
proteciton matters.  It is not the task of the SIDR working group right 
now.  SIDR is laying the ground work on which the path protections will be 
built.

--Sandy