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