Re: [RPSEC] Thoughts on BGP Security Req's Draft (I)

[Russ White <[e-mail]>]

>> A---B---C---D
>> 
>> Suppose A sends an update to B, and this update finally gets to D through 
>> some process. Now, there are two questions we can ask about this update:
>> 
>> -- Did the update actually traverse the path A/B/C/D?
>> 
>> -- Does the path A/B/C/D actually exist?
>> 
>> I think these are two fundamentally different questions--one is a question 
>> about non-repudiation, the other about the validity of the information 
>> contained in the update. I don't know that we should assume answering the 
>> first question always answers the second question, and even if we did, I 
>> don't think such an assumption should be buried in the document.
>
> As I noted elsewhere, NR is not the right security term here, but I 
> understand the question you are raising. I think the answer is that we do 
> care about how the Update got to D, at least to some extent.
>
> There are lots of inter-As links in the Internet, but each AS decides 
> what traffic is allowed to traverse which links, in a local sense. BGP is 
> the way that ASes tell one another the subset of path info that they want 
> to advertise, and for what traffic (based on destination address prefix 
> matching rules) vs. the much larger set of paths (sequences of links) 
> that exist, or even paths that exist but are restricted to other sets of 
> NLRI.
>
> This says that even if we receive an Update that represents a path that 
> exists, that does not necessarily imply that the route represented by the 
> Update has been authorized by the ASes along the path. Moreover, there is 
> an issue of timeliness, i.e., do these ASes currently authorize 
> advertisement of this route?

You can't know this from the update, anyway, as is shown in 
draft-white-pathconsiderations, the latest version of which is here:

http://www.riw.us/temp/draft-white-pathconsiderations-05.txt

Basically, you're assuming that if I receive an update, I'm somehow 
"authorized" to use the path contained in the update to forward traffic. 
That plainly isn't true, for two reasons:

-- An update contains a block of addresses which may be advertised by 
someone other than the owner of the block of addresses, and outside the 
owner's control.

-- The traffic may not flow along the AS Path contained in the update, so 
the concept of being "authorized to use a path" is not applicable in the 
case of BGP.

Now, you'll say this doesn't imply traffic flow, but clearly the paragraph 
above _does_ imply traffic flow, and policy, rather than securing the 
routing information in the proper sense.

> I'm not saying that one cannot find other ways to verify that all of the 
> ASes along the path authorize propagation of the route in an Update. But, 
> I am saying that the simplest model is the one that the BGP spec defines. 
> if we try to develop another model that promises to yield the same 
> answer, we will have a much harder job, since we will bneed to 
> demonstrate that the results are equivalent in all cases.

BGP doesn't have the concept you're talking about. The problem should be 
split into two pieces, at least, and possibly three or four:

-- Does the path exist?
-- Was the update actually originated by/forwarded along this path
    (which only applies to some form of non-repudiation, and nothing else)?
-- Am I authorized to use this path (outside the set of questions
    answerable within BGP today)?
-- Am I authorized to advertise this route to my peer (covered by many
    various mechanisms within BGP today, and coverable using many
    mechanisms within various possible security systems)?

Trying to munge all of this into a single requirement simply muddies the 
problem, and takes away the designer's ability to address them in various 
ways.

:-)

Russ

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

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