Re: [sidr] pCNT & prepending

[Stephen Kent <[e-mail]>]

At 11:02 AM -0400 7/28/11, Danny McPherson wrote:
>Doug et al,
>I like the general objective of pCNT and this seems a good idea to 
>me.  My only comment at the microphone was that if we add this for 
>compression, then validation should require that pCNT MUST be equal 
>to the number of _contiguous ASx appearances in the path (i.e., no 
>more, no less, and only contiguous).
>
>I do wonder if pCNT=0 for transparent route servers introduces the 
>opportunity for some sort of downgrade attack of sorts..
>
>-danny

There is a valid secruity concern when we allow 0 as a valid pCNT value.

I think Roque's suggestion of an EKU to mark an EE cert as being 
associated with a route server is helpful here.  Yes, this is a 
self-assertion, and thus not authoritative. But, it could be a 
convenient mechanism to assist in configuration for checking when 
it's OK to receive an update with a 0 pCNT value. Specifically, if we 
agree that an ISP knows when a configured peer is an RS, then we can 
mandate that an ISP check to make sure that an update received from a 
peer with a 0 pCNT is, in fact, coming from what it believes is an 
RS. Having a marker in a cert that says "HI, I'm an RS" at least 
makes this intent clear.  (One also could imagine that, since IXPs 
are well known and the route servers at IXPs are known, a third party 
could scan the RPKI looking for certs that claim to be associated 
with RSes, and checking to see if they appear to be legit.)

BGPSEC also could mandate some configuration capabilities that enable 
ASes further along a path to filter routes based on 0 pCNT values in 
a path. For example, one might say that any AS can be configured to 
drop a route with 2 or more 0 pCNT hops in a row, or more than 2 
total, or whatever.  If we can reach agreement on any general rules 
with regard to 0 pCNT values, these rules can become part of the 
validation standard.

Steve