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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
