Subject: Re: [RPSEC] BGP Req's Draft, Section 6 (III)

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Jan 2005 11:27:24 -0500

At 4:38 PM -0500 12/28/04, Russ White wrote:
>>6. Update Verification
>>
>>Update verification refers to the ability of a receiver to 
>>determine that a received Update is accurate, in terms of the 
>>identities of the ASes in the path attribute, the NLRI contained in 
>>the Update, and any other attributes used as inputs for route 
>>computation. Update verification entails several subsidiary 
>>security requirements that derive from the characteristics a 
>>receiver assumes is true of an Update in a non-hostile environment:
>
>>-	the AS listed as the origin originated the Update, and the 
>>NLRI in the Update is "owned' by this AS. (need to modify this to 
>>take into account address aggregation)
>
>With aggregation, this sort of verification simply isn't possible. 
>Aggregation is the exception that proves the entire concept wrong, 
>IMHO.

Aggregation comes in various flavors, so we need to be more precise 
in discussing what types of aggregation cause this simple statement 
to be wrong.

For example, if a speaker aggregates NLRI from several routes with 
identical paths, as allowed by BGP, then the statement is still 
accurate, since, by definition, the paths were identical and thus has 
the same origin AS.

If routes with different origin ASes are aggregated and the new route 
shows an AS as the origin, composed from all of the origins of the 
original routes, the statement is still true, if one interprets it 
appropriately for AS sets.

If a speaker combines routes and makes itself the origin in an 
aggregated advertisement, then you are right that the real origins 
are no longer displayed in the aggregated route, and thus the 
statement above is not accurate. But, in that case I think BGP says 
that the atomic aggregator attribute is present, which alerts other 
speakers that the advertised route no longer reflects the true 
origin. One can reword the simple statement to accommodate this case.

Are there other forms of aggregation that BGP specifies and that 
cause the origin AS in an UPDATE to be "different" and that provide 
no warning to other speakers?

>
>>-	Each AS that appears in the path processed the Update and 
>>forwarded the Update to the next AS in the path (modulo any ASes 
>>removed from the path due to aggregation).
>
>You can't prove this, so it's impossible to make it a requirement.

Two observations here:
	- the BGP spec makes essentially this statement in several 
places.  I went back and reread the BGP spec in detail over the 
holidays, based on our discussions. As a result, I prepared a brief 
analysis of the BGP spec that quotes this and other, 
security-relevant text that I think should be considered as a basis 
for the security requirements document.

	- the S-BGP work we have done shows how to provide speakers 
with the info necessary to verify the bullet above, so I have to 
differ with your comment that one "cannot prove ..."

>
>>-	If a no_export community attribute was included in the Update 
>>by an AS along the path, the attribute has not been removed to 
>>enable forwarding beyond what was intended by the AS than inserted 
>>it.
>
>I don't see how you can prove this one....

Again, this is a BGP spec reqirement, so it seems reasonable to make 
it a part of the security requirements. Moreover, we were able to 
provide a speaker with the ability to verify this property in S-BGP, 
so I again have to disagree with your comment about ones ability to 
"prove" this.

Steve

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