Subject: Re: [RPSEC] issue: coverage

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

>-- Any proposed security system SHOULD be able to express policies 
>indicating a specific autonomous system should not be transited for any 
>given destination. Note there is no way to gaurantee such a policy would be 
>followed.

I'm not sure what you mean by "a specific autonomous system should not be
transited".  Are you saying AS G sends to AS H an announcement that AS H
should *not* transit prefix P?  (I'm presuming that this announcement
would get propogated so other people could tell whether H was living up
to G's policy.)

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

I think that trying to express a policy of what H is NOT allowed to
transit could mean some pretty big announcements.

--Sandy

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

---

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

> would get propogated so other people could tell whether H was living up 

Suppose we have this:

A---B---C---D

A should be able to say: "I don't want C transiting traffic to me." Whether 
or not another path exists is actually orthogonal to the issue at hand. 
Whether or not C actually enforces this policy is out of bounds--it's a 
forwarding question, not a routing question, as I've stated elsewhere. 
That's the reason for the second part of the statement.

> as I haven't told you otherwise".  (This is called "fail closed" vs

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

> transit could mean some pretty big announcements.

Perhaps, or perhaps not. That's a design issue, not a requirements one, to 
be balanced against other requirements.... :-) Second, I think making it a 
should is appropriate, since it allows designers to take into account just 
such factors--is being able to express this actually worth the tradeoff in 
increased processing/etc? To what level of granularity? There are a lot of 
issues here we've not yet addressed, and it seems to me it's a bit much to 
make this a must....

:-)

Russ

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