Subject: [RPSEC] issue: ASPATH

From: Sandy Murphy <[email-masked]>
Date: Tue, 8 Mar 2005 13:57:26 -0500 (EST)

The AS_PATH validity test says the ASPATH must match the topology.
This eliminates a large set of bogus AS_PATHs.  But as we all know,
the fact that adjacencies exist does not necessarily imply that the
the peers will forward the traffic.

                 AS1
                /   \
              AS2    AS3
             /        |
            AS4       |
            |         |
            ...       |
            |         |
            AS17      |
               \     /
                 AS18

AS 1 is not currently announcing an prefix to AS3 - that is the
backup.  So AS3 is not announcing the prefix to AS 18.  (Or maybe AS 1
is announcing the prefix to AS3 with NO_EXPORT, so AS3 is not
announcing the prefix to AS18.)  But AS18 goes wacko one day and
starts announcing a path AS18-AS3-AS1 to all comers.  This path
satisfies the "adjacency" test of the draft.  But if AS 18's peers
choose that path, that could put traffic over the AS1-AS3 link, which
is probably a bad thing.  Or it gets traffic to AS3 which doesn't have
an entry in its routing table and can't forward the traffic.

Do we have a mechanism in mind to inform everyone whether the
path will carry traffic?  Should we specify one?

If not, then I think it should be explicitly noted that this
test does not absolutely ensure that the AS_PATH is now or
ever has been set up to pass the traffic.

Suppose that A1 and A3 have a non-transit agreement, but A3 goes
wacko one day and starts advertising the path to A1 to all comers.
The path would carry the traffic, but might not be what A1 would
like.  Is that a problem?

I ran across this one, I think on NANOG:

   major ISP                              major ISP
   west coast ----------------------------east coast
       |                                      |
       |                                      |
        \--big national multi-homed customer--/

Major ISP has an outage on the cross continent link and starts routing
traffic through the customer's network.  (Charging double to boot,
according to the message - once on the down-link and once on the
up-link.)

I do not believe that the validity test would declare this an invalid
path.  Should it?

--Sandy

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Mar 2005 15:12:50 -0500

>path will carry traffic?  Should we specify one?

you raise a very good point, i.e., the current version of the 
document refers to existence of links but fails to define the 
reference basis for this, nor does it say why mere existence of a 
link is the right sort of check to make. BGP sends UPDATEs as the 
means of advertising, in a directional fashion, precisely what 
traffic each AS is soliciting  via a specific link.

>ever has been set up to pass the traffic.

right, which raises questions as to why we consider a crude topology 
representation of this sort is an appropriate reference for AS_PATH 
validity checking.

>The path would carry the traffic, but might not be what A1 would

I would think so, as it presumably violates the intent of route 
advertisements made by A1 to A3.

>I do not believe that the validity test would declare this an invalid

I'd say so, and I'd guess the unnamed customer would agree :-)

Steve

---

From: Doug Montgomery <[email-masked]>
Date: Tue, 08 Mar 2005 18:27:48 -0500

Stephen Kent wrote:

> you raise a very good point, i.e., the current version of the document
> refers to existence of links but fails to define the reference basis for
> this, nor does it say why mere existence of a link is the right sort of
> check to make. BGP sends UPDATEs as the means of advertising, in a
> directional fashion, precisely what traffic each AS is soliciting  via a
> specific link.
> 

It seems that a few of the documents have insufficient vocabulary in discussing
such things.  I will note that (in general) what we usually think of as "links"
are not visible in the BGP system.   One might want to talk about the graph of
BGP peering relationships among ASes.  Note, that one might be able
to check more specific details about your immediate neighbor peer (e.g.,
specific link/interface/AS bindings), but from afar all these details disappear.

One might be tempted to establish some vocabulary along the lines of the following:

Taxonomy of BGP PATHS per NLRI as seen by an individual node:

Potential Paths: the set of acyclic paths among all configured AS peering
relationships. i.e., the set before we apply policy, routing decisions,
administrative and operational state.  In general, a given BGP node may not
be able to infer much of the membership of this set.

Feasible Paths: a subset of potential paths that reflect current administrative
polices for route distribution and BGP administrative state.  i.e., the set
before routing decisions and operational state.  In general, it is conceivable
that a given BGP node could see any of the members of this set, but at any one
moment, much of this set may not be inferable from the BGP protocol alone.

Viable Paths: a subset of feasible paths that reflect currently propagated BGP
routes.  i.e., the subset of feasible routes that reflect current network
operational states and routing decisions.  A given BGP node will be able to see
this set of PATHS as the cumulative contents of its Adj-RIB-ins.

Optimal Paths: a subset of viable paths that reflect the local node's local
routing preferences and decisions processes.  While the result of one nodes
choice of optimal paths is made visible in its subsequent updates, it is
impossible from afar to verify from afar a remote nodes choices among viable
paths.

Some documents refer to "valid" and "correct" PATHs / routes.  In general, I
think that is a poor choice of term, but one might wish to think about PATH
tests in terms of what information you might have to perform the test and which
set from the above taxonomy you are testing membership in.

>> The path would carry the traffic, but might not be what A1 would

It is.  But without global distribution of policy information, one
man's wacko is indistinguishable from a shrew business decision.

dougm

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Mar 2005 11:13:31 -0500

Doug,

I agree that we need to use more precise terminology, and your 
example list is a good start. Terms like "valid" are too imprecise 
when used to refer to these graphs.

>	<SNIP>

Not exactly true, as Sandy noted.

The routes (legitimately) advertised by ASes are the result of 
applying local policies and current link status, etc., and, 
ultimately, this is what we want to secure. Comparing advertisements 
to a mix of topology and policy data provides a basis for rejecting a 
set of bad advertisements, but it does not represent a way to verify 
that a given advertisement is authentic.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 10 Mar 2005 12:46:49 -0500 (Eastern Standard Time)

>> Do we have a mechanism in mind to inform everyone whether the path will 
>> carry traffic?  Should we specify one?
>

Policy is separate from existence. Although the _intent_ of advertising 
information, with an attached AS Path, is to draw traffic, you _cannot_ 
infer from that information that every possible address or set of addresses 
listed in the information is actually reachable, through policy or in fact, 
through the AS Path listed. Some parts may be, other parts may not be, 
there's no way to gather this information from the update itself.

The _only_ way to infer this information is to attach a policy outside the 
information in the update (or to ban aggregation from the Internet as a 
whole).

> representation of this sort is an appropriate reference for AS_PATH 

See above....

>> I do not believe that the validity test would declare this an invalid

It is a _valid_ path, in that traffic could flow across the path in 
question. It is out of policy for traffic to flow across this link, which 
is another problem altogether.

The problem is we forget to separate the concept of the logical graph 
across which traffic could flow from that of the actual path someone is 
"authorized" to use to pass that traffic. We face this problem all the time 
in routing--traffic engineering and multitopology routing are possible 
examples among many.

Further, what do you do about finer granularity policies? For instance, 
perhaps the customer has, beforehand, stated they will allow some types of 
traffic across their network, but not others. Would the mere precesnce of 
an update stating "this path exists" be able to express these sorts of 
policies?

:-)

Russ

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2005 10:19:52 -0500

At 12:46 PM -0500 3/10/05, Russ White wrote:
>>>Do we have a mechanism in mind to inform everyone whether the path 
>>>will carry traffic?  Should we specify one?
>>
>Policy is separate from existence. Although the _intent_ of 
>advertising information, with an attached AS Path, is to draw 
>traffic, you _cannot_ infer from that information that every 
>possible address or set of addresses listed in the information is 
>actually reachable, through policy or in fact, through the AS Path 
>listed. Some parts may be, other parts may not be, there's no way to 
>gather this information from the update itself.

The BGP spec says that an advertisement is precisely a claim by the 
advertiser that the NLRI is reachable via the advertiser. Let's not 
argue again about examples where a portion of a prefix associated 
with an AS has been delegated to another AS and is no longer 
reachable via the first AS. We've discussed this before. There is an 
underlying assumption in BGP that, in this case, if an AS fails to 
learn of the longer prefix being advertised by another AS, then the 
traffic will flow inappropriately to the first AS. That's the way the 
system works, it's consistent with the spec, and so it is not 
appropriate to argue that securing advertisements is inadequate 
because of this intrinsic characteristic of BGP.

>The _only_ way to infer this information is to attach a policy 
>outside the information in the update (or to ban aggregation from 
>the Internet as a whole).

This is an approach, but not the only approach.

>>right, which raises questions as to why we consider a crude 
>>topology representation of this sort is an appropriate reference 
>>for AS_PATH validity checking.
>
>See above....

and see my comments above.

>question. It is out of policy for traffic to flow across this link, 
>which is another problem altogether.

it was not a valid path for transit traffic, as we all agree. however 
the failure here seems to be a result of both the ISP and the 
multi-homed subscriber not causing forwarding tables in their border 
routers match their local policies. If EITHER of them  did that 
correctly, the misdirected traffic flow would not happen. One does 
not need to publish the local policies each each As to avert this 
problem; the ASes merely need to ensure that their own policies are 
correctly reflected in the forwarding tables of routers that they 
locally control.

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 14 Mar 2005 10:40:54 -0500 (Eastern Standard Time)

> advertiser that the NLRI is reachable via the advertiser.

But, it says nothing about the policies of the receiver to actually _use_ 
the path described, not does it garauntee the path described in the AS Path 
is the path the traffic fowarded through the transmitter of the update will 
actually be used to forward the traffic.

Thus, reachability is not the same as policy--I may be able to do 
something, but shouldn't do it. I may not be able to do something, but 
should be able to. They are different concepts.

If you want to include "authorized to use this path" in the concept of "a 
valid path," we will be a long time coming to concensus on a set of 
requirements, because you simply can't prove "authorization to use a path" 
from a piece of routing information. You can ascertain your immediate peer 
intends for you to send traffic to them, across the link through which 
you've learned this routing information, but you can't ever know that 
someone more than one AS hop away from you ever intends for you, two AS 
hops away, to transit traffic through them.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2005 13:06:38 -0500

At 10:40 AM -0500 3/14/05, Russ White wrote:
>But, it says nothing about the policies of the receiver to actually 
>_use_ the path described, not does it garauntee the path described 
>in the AS Path is the path the traffic fowarded through the 
>transmitter of the update will actually be used to forward the 
>traffic.

You are right that the RFC does not explicitly say that a received 
path is usable by the AS that receives it. But I believe that a 
reasonable reading of the RFC makes it pretty clear that this is the 
primary intent of route advertisement. Moreover, in several places 
that I cited in previous messages, the RFC does say that the path 
described in the advertisement is the path via which traffic will be 
forwarded, at least nominally.

>something, but shouldn't do it. I may not be able to do something, 
>but should be able to. They are different concepts.

Why would AS A send an advertisement to AS B if AS A has no intent to 
accept traffic from that AS for the indicated NLRI, and forward the 
traffic to the indicated origin?

>If you want to include "authorized to use this path" in the concept 
>of "a valid path," we will be a long time coming to concensus on a 
>set of requirements, because you simply can't prove "authorization 
>to use a path" from a piece of routing information. You can 
>ascertain your immediate peer intends for you to send traffic to 
>them, across the link through which you've learned this routing 
>information, but you can't ever know that someone more than one AS 
>hop away from you ever intends for you, two AS hops away, to transit 
>traffic through them.

We've had this argument before. Lte's not bore the list by repeating it.

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 14 Mar 2005 15:32:03 -0500 (Eastern Standard Time)

> You are right that the RFC does not explicitly say that a received path 
> is usable by the AS that receives it. But I believe that a reasonable 
> reading of the RFC makes it pretty clear that this is the primary intent 
> of route advertisement. Moreover, in several places that I cited in 
> previous messages, the RFC does say that the path described in the 
> advertisement is the path via which traffic will be forwarded, at least 
> nominally.

>From this, you're taking as a truism that if I receive an advertisement for 
some destination, it should always be "in policy" to transit traffic along 
the path described. If the traffic actually took that path.

Of course, neither of these are provable, so there's point in arguing this. 
You can't gaurantee the traffic will take the path described in the routing 
information, and you can't gaurantee every transit AS listed agrees with 
this specific traffic stream transiting, nor the final hop AS agrees this 
is the correct entry point.

Routing is hop by hop by design. It's not a circuit, it wasn't designed to 
be, and it won't ever be. If you want packet stream security, then you need 
to design and solve that problem at the packet stream level (IPsec, etc). 
You're not going to get it at the routing level.

> traffic to the indicated origin?

I've given plenty of examples where this happens, so it's not a matter of 
intent, it's a matter of fact.

:-)

Russ