Subject: Re: [RPSEC] Basis of Requirements?

From: Sandy Murphy <[email-masked]>
Date: Wed, 28 Sep 2005 08:38:04 -0400 (EDT)

>Well, the _intent_ of the document is that the AS_PATH contain _all_
>of the ASes.  This is obviously necessary for loop avoidance.

Yes, as Russ White et all say in draft-white-pathconsiderations-05.txt:

>path vector
>protocols, such as [BGP], prove a path is loop free by carrying a
>list of nodes the advertisement itself has traversed.

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Russ White <[email-masked]>
Date: Wed, 28 Sep 2005 08:48:24 -0400

>>list of nodes the advertisement itself has traversed.

Note it doesn't say, anyplace that I can find, that the AS Path 
constitutes an "authorization chain," and such thing. Yes, it does prove 
loop freeness, as I've said many times before. Receiving a route with 
NLRI X doesn't prove that every AS given in the AS Path has authorized 
the transiting of traffic to every destination within the address block, 
as the draft mentioned also shows.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Tony Li <[email-masked]>
Date: Wed, 28 Sep 2005 14:01:18 -0700

> as the draft mentioned also shows.

BGP does not use the AS_PATH to 'prove' loop freedom, it uses the  
AS_PATH for loop avoidance.  This may be a subtle distinction, but  
since we seem to be insisting on being semantically precise, let's do  
it right.  Proofs are for mathematicians, and the AS_PATH is just a  
mechanism.

Similarly, the AS_PATH is in no way an 'authorization chain'.  It's a  
historical record.  From the fact that it has been received, we can  
_infer_ that the advertisement was authorized and can further infer  
that forwarding will follow this path.  However, neither of these  
inferences is 'secure' in any sense of the word.

<Broken Record>
Since we have declared the security of the forwarding plane to be out  
of scope, there is little point in spending a great deal of energy in  
validating the authorization of the advertisement.  From a pragmatic  
point of view, a validated advertisement that is coupled to corrupt  
forwarding is just as effective an attack as a bogus advertisement.   
Thus, any effort spent on validating the AS path is largely futile.   
It's only an expenditure to ensure that Black Hats know to subvert  
traffic at the forwarding plane.  Arguing about how best to validate  
the AS path is only compounding the wasted effort at this point.
</Broken Record>

Tony

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Sep 2005 21:40:48 -0400

Tony,'

I'm afraid that your "broken record" comments are indeed broken.

If we don't believe that the route data will influence forwarding, 
then there is no point in trying to secure the routing data.  So, 
even though we recognize that the two are separate and that we can't 
ensure that forwarding will be controlled by the received routing 
data, to ignore the linkage makes no sense.

A reasonable way to view the situation is that IF an AS is behaving, 
then it wants to make forwarding decisions based on authentic routing 
data.  That's the best it can do. Thus our goal should be to try to 
provide ASes with the ability to determine the authenticity of the 
routing data they receive via BGP.

Steve

---

From: Tony Li <[email-masked]>
Date: Wed, 28 Sep 2005 23:32:15 -0700

Steve,

> even though we recognize that the two are separate and that we  
> can't ensure that forwarding will be controlled by the received  
> routing data, to ignore the linkage makes no sense.
>
> A reasonable way to view the situation is that IF an AS is  
> behaving, then it wants to make forwarding decisions based on  
> authentic routing data.  That's the best it can do. Thus our goal  
> should be to try to provide ASes with the ability to determine the  
> authenticity of the routing data they receive via BGP.

If a transit AS is behaving, then we don't need AS_PATH  
verification.  If a transit AS is misbehaving, then AS_PATH  
verification isn't going to detect it.

Tony

---

From: Stefan Mink <[email-masked]>
Date: Thu, 29 Sep 2005 09:27:58 +0200

>> routing data they receive via BGP.

full ack to what Steve wrote so far

> If a transit AS is behaving, then we don't need AS_PATH  verification. 
> If a transit AS is misbehaving, then AS_PATH  verification isn't going
> to detect it.

sorry, but the mistake in this view is, that if one AS is misbehaving
and another *well behaving* AS is receiving a route from this misbehaving
AS, this AS should/must be able to *detect this misbehavior*. This
is valid for origin authorization, message tempering and redistribution
authorization.

I also had a similar discussion with Russ: security mechanisms can
be preventive (=misbehavior is not possible, i.e. attackers can
not read the text because it is encrypted) or reactive (=misbehavior
can be detected, but not prevented, i.e. a signature only shows,
that the data has been tampered with).

Building a preventive security system for Internet routing is not
impossible but very hard to do (e.g. certified hardware must be
used that makes it impossible to misbehave). This is not how the
internet is being operated today, so I don't see such a solution
in the near future if at all.

Thats why reactive security mechanisms are the most likely short
time solution we can get and this means: give the good ones means
to detect actions (=attacks) of bad ones.

   tschuess
             Stefan
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Russ White <[email-masked]>
Date: Thu, 29 Sep 2005 08:25:04 -0400

> is valid for origin authorization, message tempering and redistribution

The only way you can detect a misbehaving AS is by being able to see 
whether traffic is coming out of the expected exit point (based on your 
view of routing, which may be incorrect) or not. There are two things 
you can do in routing:

- -- Find out if someone advertising X to you has a path to X.
- -- Find out if the person originating X is "authorized," in some way, to 
originate it (and we can quibble about what, exactly, "authorized" means).

Things you cannot prove about routing:

- -- The traffic you send will take the path indicated.
- -- Any node along the graph has "authorized" transiting that specific 
node for that specific destination.

In fact, you cannot even detect attacks involving these two things, 
unless you own both ends of the traffic--the source and the sink. These 
things just aren't possible, in real routing systems.

> that the data has been tampered with).

Sure, and I've said the same things I said above. Forwarding != Routing. 
Routing provides one of many inputs to the forwarding in a network. 
Local policy, in the form of static routes, QOS, and other such things, 
also provide inputs. As time passes, these things are providing more 
input, not less. There used to be a day when you could look at the 
routing table and know, pretty much, how traffic will be forwarded 
through a network. That's just no longer the case.

> used that makes it impossible to misbehave). 

Certified hardware still has to bow to the local policies of the people 
running the networks. As long as people run networks, and people buy the 
equipment that builds networks, and people build the stuff that makes up 
networks, then networks are going to be run for the financial advantages 
of those people. You could envision a "perfect network," where people 
don't run it, and the network runs at perfect efficiency, security, etc, 
but there's a lot of money to be made in the gaps between inefficient 
and efficient behaviour. So long as there is money to be made in this 
gap, networks will remain pretty much the way they are.

You'll have to change the entire financial structure of the Internet to 
do what you're talking about, not the equipment vendors.

And yes, I recognize this is widely off topic for the immediate 
discussion, what to do with the BGP requirements document. But, it's an 
interesting discussion of it's own right, and points to exactly what I 
discussed before--two worldviews, two completely different ideas about 
how routing works, and what it does.

:-)

Russ

- --

---

From: Stefan Mink <[email-masked]>
Date: Thu, 29 Sep 2005 15:58:04 +0200

Hi Russ,

Russ White wrote:
> view of routing, which may be incorrect) or not.

this is one way of detecting misbehaving ASes. Another is, not to detect
misbehaving traffic (forwarding plane) but *initially* detect misbehaving
routes (control plane), i.e. you detect you got a route you were not
meant to receive. The latter is, what we want to do here AFAIK.

Securing the control plane is the fundamental basis on which you can
secure forwarding. No control plane security -> no forwarding plane
security. I completely agree that securing the control plane is just
the first step.

BTW: if my view of routing is incorrect, then routing is quite robust
     because my network is already working for quite some years :)

> There are two things
> you can do in routing:
> 
> -- Find out if someone advertising X to you has a path to X.
> -- Find out if the person originating X is "authorized," in some way, to 
> -- The traffic you send will take the path indicated.

-> forwarding plane issue or rather "glue issue"
-> later

> -- Any node along the graph has "authorized" transiting that specific 

this is just wrong for "node"=AS . We can not detect misbehaving ASes
because we *currently* don't have the means to. We don't know who is
allowed to readvertise which routes, so we can not detect attacks. And
this will stay like this as long as we don't have a database describing,
what is permitted and what is not.

It is the same with origin authorization: as long as we don't have
a database describing who is authorized to originate which prefix
we can not tell who's attacking and who's not.

I find it quite dangerous to say, "we can not defend against such
attacks", so lets ignore this threat.

> how routing works, and what it does.

you deleted follwowing part of my former eMail:

"This is not how the internet is being operated today, so I
 don't see such a solution in the near future if at all."

So at least I am not a proponant of a prevention solution right
now and I didn't want to start a discussion. This was rather
an example, that there are two versions of security: prevention
and detection/reaction :)

As you can see in this eMail, I get more and more frustrated.
I run an AS and I know what problems there are. If you don't care
about these problems, it will be interesting for me to watch future
versions of Internet routing security, if you permantently tell:
this is not possible :-/

I hate getting arrogant (*really*), but it would be interesting for
me to know, who of the actively discussing people here is *actively*
  * operating a part of the Internet, i.e. running an AS (technical part)
  * doing inter-provider contracts (business part)
  * facing routing security problems (technical AND business part).
People not knowing all three parts can only secure Internet routing
partially.

Of course every additional security is better than no security,
thats why I also vote to bring this draft forward:
    $MoveForward += 1;
:)

   tschuess
             Stefan

PS: It may also be that I live in another world, run a part of a different
Internet and face more/other problems. Isn't this the group of Elucidated
Brethren of the Ebon Night? ;)
(-> Terry Pratchett: "Guards! Guards!" Page 5, very funny, definitely
    worth reading :) )

---

From: Russ White <[email-masked]>
Date: Thu, 29 Sep 2005 10:11:58 -0400

> meant to receive. The latter is, what we want to do here AFAIK.

The basic problem is the way the IP address space is set up, there's no 
way to detect what "misbehaving" means today. Is it misbehaving to 
advertise reachability to something you've suballocated? Not today, it 
isn't....

> what is permitted and what is not.

Again, as long as you assume that for any destination, there will be 
precisely one advertisement providing reachability to that destination, 
you can prove a lot of things. As long as multiple advertisements 
provide reachability to a single destination, and some of those 
advertisements can be filtered at will, then....

>  don't see such a solution in the near future if at all."

I didn't delete it this time. :-)

> versions of Internet routing security, if you permantently tell:

Of course, it's possible. As long as you enforce the rule that all 
reachable destinations are reachable through exactly one routing 
advertisement, but I digress....

>   * operating a part of the Internet, i.e. running an AS (technical part)

Or, perhaps, are or have implemented a routing system. Let's not forget 
that this stuff has to be implementable, too.

>     $MoveForward += 1;

Thanks! I hope Tony catches that in this long, off topic thread.... <hehe>

:-)

Russ

- --

---

From: Stefan Mink <[email-masked]>
Date: Thu, 29 Sep 2005 16:26:15 +0200

> advertise reachability to something you've suballocated? Not today, it 

misbehaving = announcing a route to a bgp neighbor you're not authorized
              to announce
-> either you're originating a route withouth permission of a registry
   or you are passing on a route against existing inter provider contracts

> advertisements can be filtered at will, then....

I don't assume this :)

I also never told, that you must use a more specific if there is
a less specific. If you got a route, you can use it. The prime
question is: was it an attack that you got it or not.

I think you maybe somewhat blinded by current "trials" to
"steer" the internet. Thats not what I want to achieve. I
just want to achive that you can check a received route
whether its valid or not. Much more simple!

> I didn't delete it this time. :-)

thanks ;)

> advertisement, but I digress....

wrong assumtion

> that this stuff has to be implementable, too.

I never told I don't trust you concerning the BGP protocol
(implementation), on the contrary, I think I learned quite some things :)
But as I told: Internet routing isn't just the protocol, but is the
whole industry around it. I'm not sure you understand this part,
or maybe you undestand it for the corporate part (without complex
inter provider relationships), but not the ISP part :]

:)

I already told him in private, just wanted to make the point
here as well that I don't want to be destructive, but am
interested in getting forward as well.

   tschuess
             Stefan

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Sep 2005 11:05:58 -0400

> verification isn't going to detect it.

And yet, it'll prevent certain classes of excrement from being injected
into the routing system.

-- 
Jeff Haas 
NextHop Technologies

---

From: Tony Li <[email-masked]>
Date: Thu, 29 Sep 2005 11:07:02 -0700

Russ,

> things just aren't possible, in real routing systems.

Just for a theoretical perspective, you might go look at Radia's work  
on byzantine IGP's.
Yes, these things CAN be checked, and it's not that hard.

Please don't confuse that with advocacy of actually adopting this  
approach for BGP.  I'm not.

I think that we should consider the ENTIRE threat environment before  
setting requirements that are disproportionally expensive.

Tony

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Sep 2005 09:08:11 -0400

>verification isn't going to detect it.

If a transit AS elects to issue UPDATEs that will redirect traffic 
through it, then  routing security mechanisms can help detect that 
form of attack, and allow  well-behaved ASes from being fooled. This 
seems to be a class of attack that the group agrees should be 
addressed, in addition to unauthorized route origination, etc.

Steve

---

From: Tony Li <[email-masked]>
Date: Thu, 29 Sep 2005 13:58:08 -0700

> form of attack, and allow  well-behaved ASes from being fooled.  
> This seems to be a class of attack that the group agrees should be  

This is true.  However, the existence of other attacks that are not  
addressed implies that we should neither spend a great deal of effort  
nor write challenging requirements to address this aspect of the  
problem.

Tony

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 Sep 2005 13:37:49 -0400

At 1:58 PM -0700 9/29/05, Tony Li wrote:
>addressed implies that we should neither spend a great deal of 
>effort nor write challenging requirements to address this aspect of 
>the problem.
>
>Tony

This  WG was established with a scope that includes security for 
routing, but not forwarding. There are classes of adverse outcomes 
that can be effected by attacking routing, independent of forwarding.

In the extreme, arguments like the one you make are valid. One would 
not put a vault door on a typical home, since the windows and walls 
are so much weaker. But, does it make sense to install a solid front 
door with a deadlock vs. a hollow core door with a cheap lock? In 
many contexts the answer will be yes. So, there is clearly a middle 
ground where reasonable folks can disagree over what constitutes an 
appropriate level of security (either requirements or mechanisms), 
vs. what constitutes overkill. However, it certainly makes sense to 
develop countermeasures to routing attacks if these countermeasures 
preclude attacks that can not be effected by the same parties solely 
through forwarding attacks.

Steve

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Sep 2005 15:30:30 -0700

Steve,

> that can be effected by attacking routing, independent of forwarding.

That may well be.  However, from a pragmatic point of view, both the  
routing and forwarding subsystems are integral parts of the whole.   
Ignoring one subsystem is simply creating another Maginot Line.  And  
I think that you will agree that the Black Hats will exploit the  
attack of least difficulty first.

>
> In the extreme, arguments like the one you make are valid. One  
> would not put a vault door on a typical home, since the windows and  
> walls are so much weaker. But, does it make sense to install a  
> solid front door with a deadlock vs. a hollow core door with a  
> cheap lock? In many contexts the answer will be yes. So, there is  
> clearly a middle ground where reasonable folks can disagree over  
> what constitutes an appropriate level of security (either  
> requirements or mechanisms), vs. what constitutes overkill.  
> However, it certainly makes sense to develop countermeasures to  
> routing attacks if these countermeasures preclude attacks that can  
> not be effected by the same parties solely through forwarding attacks.

I agree that we can devote some resources to protecting the control  
plane.  In fact, we must, otherwise we can make no progress at all,  
as one subsystem must be in advance of the other.  However, just as  
with your vault door analogy, we should not be installing 3ft. of  
titanium on the front door at this point: it's not cost effective.  I  
would welcome a solid core door and Schlage lock.  That would be a  
cost that is proportional to the threat that will be directed to the  
control plane.  If we have other resources at our disposal, we should  
focus them on the forwarding plane.

Tony