Subject: Re: [RPSEC] issue: coverage

From: Sandy Murphy <[email-masked]>
Date: Fri, 11 Mar 2005 18:00:08 -0500 (EST)

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

I certainly know of specific cases where the traffic won't follow the
same path:

out-of-protocol:
   the routers don't forward along the path they advertised

in-protocol:
   a router announces an aggregate with an AS_SET or re-originating
   private AS's are invisible in the path, so traffic goes places other
      than the places visible in the AS_PATH
   confederations are invisible in the path, so traffic goes places other
      than the places visible in the AS_PATH

Are there other cases?

I don't believe that the out-of-protocol case is a protocol security
concern.  {First, the protocol is not being used to make this happen.
Second, there is nothing you can do in the protocol to prevent other
changes being made to the forwarding table.  Third, a router that
mis-forwards can effect only that traffic that comes to it, where a
router that mis-advertises can effect a lot of other routers' traffic.}

If there are really only three in-protocol cases, then I don't think
it is insurmountable to provide for those three cases in the protection
of the AS_PATH.

>A routing system provides loop free paths, and 
>doesn't gaurentee traffic sent to the next hop advertising a given loop 
>free path will actually follow the loop free path advertised.

This is a broad statement and my questions above are pointed at seeing
if this is an unnecessarily broad generalization of the specific cases
noted above.

And: I'm not sure that ensuring that traffic follows the advertised
path is the way to state I'm hoping for.  I want to ensure that each
AS has indicated that it is willing to accept that traffic, so traffic
can't be forced to go places that would be harmful.

--Sandy

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

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 14 Mar 2005 17:07:30 -0500 (EST)

>> Note that this changes the meaning of announcements of "here's my
>> route to a prefix, you may send me traffic for that prefix" from
>> "... and that prefix only" to "and anything else you want as long
>> as I haven't told you otherwise".  (This is called "fail closed" vs
>> "fail open").
>
>Actually, the general operation of the Internet is not always "fail open," 
>as a lot of people seem to think. For the failure mode to always be "fail 
>open," we need to abolish the default route and aggregation. It might, 
>today, be fail close or fail open, depending on the specific situation. We 
>can try to close this hole, somewhat, but, see below on the tradeoffs 
>involved....

I'm not certain I'm following, so I'm going to define terms here.

Fail closed:  if you can not provide explicit authorization to do something,
you are forbidden to do it
Fail open:  if you are not explicitly forbidden to do something, then
you are allowed to do it.

So "here's my route to a prefix, you may send me traffic for that prefix
... and that prefix only"  is a "fail closed".
And "here's my route to a prefix, you may send me traffic for that prefix
and anything else you want as long as I haven't told you otherwise" is
a "fail open".
I'm advocating for the "fail close", not the "fail open".

Does that match the way you were using the terms?

--Sandy