Subject: Re: [RPSEC] issue: coverage

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

I'm having trouble understanding your example, as the argument seems
to contradict itself:

You say:
>-- B and C are under contract to A to transit traffic from A to A', but A 
>doesn't even want D to know about this relationship, for whatever reason.
>
>Now, suppose A marks the route it advertises to B with a community so B 
>marks the route NO_EXPORT towards C. But, through some problem, or 
>malicious intent, C actually advertises the route to D.
>
>...
>What should D take from receiving 
>an update on which B has marked NO_EXPORT? That it shouldn't have received 
>the update, and should therefore discard it?

then later you say:

>BGP isn't designed to 
>provide secrecy of routing information

So your example is showing our inability to provide a feature that we 
know BGP is designed to exclude.  I'd say the answer is to gently
inform A that it asked for the impossible.  Then there's no
*security* problem in D's seeing the update.

OTOH

If you changed your example to say that A didn't want D sending
traffic it's way through B/C, then we could discuss whether the
security requirements should say that AS's could state such a
policy and expect a secure system to make it so.  BGP is supposed
to be able to represent an AS's desires of where traffic goes - such
a requirement would not violate the BGP paradigm.

But I'm not confident that we could fulfill such a requirement:

>Essentially, all of A's trust is in B and C to do the right thing.

Indeed, indeed, indeed.  (Is three times enough?)

It is a very hard thing to ensure that some other entity does the
right thing.  There are few cases I can think of where that is
possible.  There's a lot of work going on to try to prevent people
who are allowed to see a document to forward it to someone who can't.
Byzantine protocols try to ensure that a group comes to a right answer.
And so forth.  The solutions generally make assumptions about trusted
computing bases or multiple parties that must agree to perform an
action.  In general, not easy solutions.

One thing that we can ensure is that C can not deny that it
leaked the route it wasn't supposed to.  Non-repudiation can
help.

--Sandy

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

---

From: Russ White <[email-masked]>
Date: Sat, 12 Mar 2005 07:39:29 -0500 (Eastern Standard Time)

> If you changed your example to say that A didn't want D sending traffic 
> it's way through B/C, then we could discuss whether the security 
> requirements should say that AS's could state such a policy and expect a 
> secure system to make it so.  BGP is supposed to be able to represent an 
> AS's desires of where traffic goes - such a requirement would not violate 
> the BGP paradigm.

Yes, we could.... I would suggest such language could be injected (I've 
suggested possible language below), but I'm not certain how to say: "This 
is the line over which we won't go when discussing policy." Perhaps it's 
valid to say we will put in requirements involving policy relating to the 
acceptability of a specific AS in terms of transit, but leave it at that 
(?). It seems like a logical place to draw the line, and I don't see how it 
could get us into trouble....

> But I'm not confident that we could fulfill such a requirement:

Which is why I suggested the "but if" type statement in my wording:

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

Of course, I'm also not certain it should be a MUST or a SHOULD, if we 
placed this in the draft--I'm fine with it either way, I'll leave it to 
others to speak their minds... :-) I'm also certain the wording could use a 
little help....

> One thing that we can ensure is that C can not deny that it leaked the 
> route it wasn't supposed to.  Non-repudiation can help.

Non-repudiation is already in as a "SHOULD," so I think we've already 
covered that (though not using that specific term, since it's a term with a 
lot of baggage). I wouldn't want to make it a "MUST," for two reasons:

-- I don't know that it can be proven in relation to the AS Path, 
specifically.

-- I don't know what the total set of tradeoffs are in providing 
non-repudiation, and believe the users of any given system should be 
allowed to determine the actual tradeoffs based on deployment 
considerations.

:-)

Russ

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