Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt

From: Danny McPherson <[email-masked]>
Date: Sun, 1 Apr 2012 21:22:02 -0400

On Mar 31, 2012, at 12:12 AM, Murphy, Sandra wrote:

> 
> Origin validation is strictly and only judging whether the origin has the authority to originate announcements of the prefix.  Origin validation does not ensure that the authorized AS is actually making the announcement.

Indeed!  It's not actually "validation" at all, it's more "policy enforcement".  I.e., is the origin AS in the AS_PATH of the received update an origin AS that the resource holder said was "authorized" to originate the prefix in question.

I suppose it's really no different than static AS filter lists except that rtr-rpki is router-wide and storage is soft-state (akin to ORF, though it's in-band per-peer, or flow spec, for that matter) v. persistent static configuration most folks employ today for policy.

> It is bgpsec path validation that ensures that the announcement is currently and authentically being announced by the AS.  That's the "signed injection" you mention.

This reminds me -- we don't have a signing certificate and validation certificate router on-boarding protocol defined yet for BGPSEC (I assume rtr-rpki is the basis, though it currently does not support this), I think we need to begin working that out sooner rather than later as I suspect the operational implications are far more complex and they will markedly impact RPKI system design as well.

Finally, to R.'s point in a different thread:

"If that would not be enough BGP is soon to become completely "hard state" if one would implement http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01"

I suspect we're going to end up with draft-foo-rtr-rpki--proto-persistence-* at some point as well (or we could use BGP itself for on-boarding RPKI data :-)

-danny