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

At 4:17 PM -0500 12/28/04, Russ White wrote:
>>>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

Thanks for the pointer.

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

If AS 1 advertises a route to AS 2, I interpret that as an 
authorization for AS 2 to send traffic for the indicated prefix(es) 
to AS 1.  Do you disagree? If so, then what do you maintain is the 
reason that AS 1 advertises a route to AS 2?

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

Do you mean to say that correct BGP behavior allows an a speaker to 
originate a prefix when the AS in which the speaker operates is not 
the owner of the prefix nor has the owner authorized the 
advertisement in any fashion?

Or do you mean to say that correct BGP behavior allows any AS to add 
arbitrary prefixes to an Update?

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

I think we all understand that there is a difference between 
forwarding and routing and thus propagation of a route does not 
ensure that traffic will flow over that route. However, the purpose 
of advertising a route to a neighbor is to make the neighbor aware 
that the advertiser is willing to accept traffic for the indicated 
prefixes, and that if such traffic is sent to the advertiser, then 
the traffic will be forwarded to the the indicated origin AS. That's 
what I believe is true, and your comment above in now way relates to 
the notion of

>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 have no idea what the sentence above means.

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

You still have not answered the question of what you mean by a path 
"existing." If you mean there are communication links between ASes, 
then say so. If you mean that there is local policy in each along the 
path that states that traffic for an indicated prefix will be 
forwarded to the origin AS if received from the indicated neighbor, 
say so.  If you mean something else, say so.

>-- Was the update actually originated by/forwarded along this path
>    (which only applies to some form of non-repudiation, and nothing else)?

As I have said several times, apparently to no avail, this is not NR. 
But yes, I agree that this is a separable question from the bullet 
immediately above.

>-- Am I authorized to use this path (outside the set of questions
>    answerable within BGP today)?

I don't know what you are trying to say here.

>-- 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)?

yes, an important part of routing.

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

the issue is not whether one can identify these as distinct questions 
that can be asked about a path or a route. The question we are 
addressing is what does BGP say about paths and routes, does IT ask 
these questions, and does it make the distinctions you have made 
above, when the BGP route computation algorithm is executed?

It has been suggested that maybe we should not just try to secure BGP 
as it exists, but rather consider what changes could be made to BGP 
to make it better, and then secure the result.  That might be a good 
suggestion, but it is not consistent with the WG charter, or with the 
description of the requirements document that we are working on now. 
That's why I note that the questions we need to ask must be framed in 
the context of the protocol we have and how it is defined to work.

Steve

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec