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

[Russ White <[e-mail]>]

> for me, the word "update" is an inprecise reference fo "UPDATE message" 
> which is clearly a message beween to BGP neighbors, and not somthing 
> transitive. The BGP draft also states that "Routes are stored in the 
> Routing Information Bases (RIBs): namely, the Adj-RIBs-In, the Loc-RIB, 
> and the Adj-RIBs-Out, as described in Section 3.2.". So no updates are 
> stored, but routes (= content of an update) are put into different RIBs.

Correct. I would actually much rather discuss this in terms of routes, 
rather than updates, but the entire current language is built around 
updates, rather than routes.....

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.

>> Now, let's expand this further, and say we'd like to state this:
>> 
>> "On receiving an update, any proposed solution MUST verify the update has
>> passed through the pairwise peerings represnted by the AS Path attribute
>> contained in the update."
>> 
>> And base it on this reasoning:
>> 
>> "The sense of the BGP specification is that the protocol will not operate 
>> correctly is this rule is not followed, or that's what the BGP 
>> specification authors meant to say, or that's what the BGP specification 
>> should say, and it was just missed."

> the AS-PATH attribute is important functionally to avoid loops and is 
> somewhat important as a metric. From a security point of view, the 
> as-path is much more important in my eyes. When you want to check, wether 
> the route of the route is authorized, the as-path would be a logic basis 
> for this. If the as-path does not mirror the route of the route, on what 
> basis would you otherwise want to check this?

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), ....

>> -- Add additional information to an AS Path, causing it to _not_ represent
>> the list of peerwise AS peerings the update has passed through. A common
>> example of this is AS Path prepend.
>
> 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?

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.

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.

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?

>> -- Remove information from the AS Path, causing it to _not_ represent the
>> list of peerwise AS peerings the update has passed through. A common
>> example of this is stripping private AS numbers out of the AS Path at an
>> autonomous system boundary.
>
> not quite aggreed: even if the BGP spec would be hurted by this behavior,
> it's an internal operation and not visible for the rest of the internet. This
> could impact security but does not necessarily...

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.

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.

>> -- Advertise a set of reachable addresses which contains address space
>> reachable through a different AS Path than that listed in the update. A
>> common instance of this is the re-origination of routing information at an
>> autonomous system border.
>
> 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.

> I aggree that operators practise and software features differ from the 
> exact wording of the BGP spec and at least use grey space for some of the 
> example you describe. For that reason I also think that the BGP spec as 
> single basis is not sufficient.

Agreed.

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.

-- The requirements document should state and proposed solution must verify 
the AS Path attribute of any received route exists (represents a valid set 
of peerings within the internetwork), since this is all we can actually 
prove or validate. We can't prove authorization using any of the various 
definitions we've tried to use, so we shouldn't require any proposed 
solution to prove authorization.

I think the second is the most logical choice, but I'm willing to allow 
both to be included in the draft as alternatives, in either of the two ways 
I've proposed on list. Either word the requirements to cover both options, 
or have two separate requirements.

:-)

Russ

__________________________________
[e-mail] CCIE <>< Grace Alone

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