Re: [RPSEC] Back to the Basics: The AS Path

Hi Russ,

Russ White wrote:
> Of course, actual implementations don't have an adj-rib-in, loc-rib, and 
> adj-rib-out (I always confuse all of these names, and call them the 
> wrong thing), so these are models of behaviour, not requirements.

sure, but requirements should rather be based on these models of
behavior than on how it is usually implemented. Otherwise it would
make unusual and may be better ways of implementation impossible.

> I'm not certain what you mean by authorizing: "the route of a route." I 
> suppose there are a number of ways I could take this. Suppose I have:
> 
> A---B---C
> 
> Are you saying you want to show that A is authorizing B to send routing 
> information to C? But, if the AS Path doesn't always actually reflect 
> the path the routing information has taken (as you acknowledge in at 
> least one case), ....

the fact that there are currently situations, where the as-path does
not reflect the actual forwarding path, is at least partially based
on the fact, that it wasn't a critical requirement. As you wrote many
things are being done today because it didn't hurt anybody so far.
If now it starts hurting, maybe we should more think about how to
avoid these situations.

For me, origin authorisation is just the beginning. The authorization,
to pass on routes (and by this permit traffic to flow in the opposite
direction) is relevant to network stability (what happends if a big
traffic flow due to a wrong announcment starts to use a network path
that doesn't have the capacity to carry it) and can have an impact on
the economic  result, i.e. who is earning money with which traffic.

I don't want my customers to announce my prefixes to another transit
of them and my wish would be, that a future security architecture
would be able to actually make it verifiable, wether a received route
was sent by the other side in an authorized way. You can not keep
"an attacker" from announcing routes he isn't authorized to announce
to another BGP neighbor. On the other hand as an honest BGP neighbor
you should be able to check, if an advertisement is not authorized.

How do you verify, wether an announcement is authorized? Not by checking
the RIR database but by checking contracts between BGP neighbors. And
thats exactly the point where current policies are not precise enough.
The only contain what's beeing announced to whom but not what he is
allowed to do with it.

Now if you want to check that authorization chain, on which data
do you base it? There's just the as-path, that in many/most cases
reflects the ASes it traversed, but in many cases it does not. My
point is that in the latter case, authorization is just not verifiable
without adding another bgp attribute that truely reflects the path
the update took.

Concerning the difference between routing path and forwarding path,
you still have the problem, that you can avoid loops on routing plane
but you can not on forwarding plane. For me a routing protocol with
this behavior is a real danger. You didn't reply to this so far.

>> agreed, this is a valuable usage e.g. when merging ASes
> 
> 
> ....how can you prove this using the AS Path? I'm not certain how to get 
> to "authorization to advertise routing information" from "prove the 
> route has followed the path listed in the AS Path?", since the AS Path 
> doesn't actually represent the path the routing information took through 
> the network, in all cases?

I don't see any problems here. If two ASes merge, authorizations don't
change for that reason. If there is still a physical separation of the
networks or not is not relevant for the rest of the internet.

> Beyond this, why do we want to prove this "authorization chain?" Is it 
> to prove the sender is authorizing packets to flow along the reverse 
> path than the one the routing information took? Since you can't ever 
> prove traffic flows along the reverse path the routing information 
> takes, this doesn't seem to be helpful, either. 
> draft-white-pathconsiderations-04 shows some examples of this occuring.

just because something is broken, it doesn't mean we shouldn't try
to fix ist :)

> Finally, you could say you're actually trying to authorize the 
> advertisement of reachability information, since the route is actually 
> made up of a prefix and attributes, which is what we would call 
> reachability information. "Is my peer authorized to advertise 
> reachability to 10.1.1.1 to me?" is the sort of question we're talking 
> about here. And, here again, draft-white-pathconsiderations-04 shows how 
> this doesn't work in the real world, the first example is the simplest.

that means to me, that a verification of authorization is not achievable :(

> So, I suppose I'm confused by the concept of "authorization" in the 
> context of the AS Path as carried in BGP routes. What does it mean, 
> exactly? What are we attempting to authorize?

the current state is: if you have a route, you can do what you want
with it and the only thing you can do is withdraw a route from a BGP
peer if he's announcing it in a way it's not authorized from your point
of view (e.g. a customer announces one of your prefixes to a peer or
transit provider, the only thing you can do is withdraw the route).
I hate it but it seems to be a similar problem the media industry
is facing with music/video...

> The path of the routing information is actually {65100,1,2,3}, but 
> you're reporting the path of the routing information as {1,2,3}. It's 
> not a matter of the operation being "internal," it's a matter of the 
> path of the routing information not matching the reported path of the 
> routing information.

I consider AS65100 as not being autonomous, but as being part of
AS1.

> Another example is confederations, where AS' are inserted into, and then 
> removed from, the AS Path. Again, the confed AS appears to be a single 
> AS to the remainder of the internetwork, but there are path elements 
> that are added and removed, showing the AS Path is not a sacrosant 
> version of the actual path of the routing information.

same point here. The sub-ASes of the confederations are not autonomous.
They can only interoperate with other ASes by using the official ASN.

>> I didn't get this :-/
>> If the routing path differs from the forwarding path, this can lead to
>> loops on the forwarding plane. For this reason this is very dangerous
>> and should never be constructed intentionally. I know there are con-
>> stellations with route reflectors and more specifics where this can
>> occur without anybody doing "something wrong", but this should not
>> be a basis to consider this behavior as accepted.
> 
> 
> draft-white-pathconsiderations-04, first example. I would consider each 
> entity's actions within the internetwork perfectly acceptable and normal 
> behaviour.

sorry, for me it's not acceptable and is far from normal.
Just one example to show how fragile such constructs are: Assume
AS D somehow looses the route to E, then B is blackholing
all traffic to E.

> There are two camps here:
> 
> -- The requirements document should state any proposed solution must 
> verify/prove/etc. the path the routing information actually took is the 
> same as the AS Path attribute of the route.

that's me. But I also see that this is hard to achieve at the moment,
but it could be achieved, if people would understand, that its dangerous
if routing plane and forwarding plane do differnt things. I'd be glad
if somebody would tell me that I got it all wrong and there's no problem
but so far nobody did. You could be the first one, who illustrates me
not only that this is common practise, but also that there are no
disadvantages and dangers whatsoever with this practise...

    tschuess
              Stefan Mink
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA

Re: [RPSEC] Back to the Basics: The AS Path

Attachment: signature.asc