At 7:48 AM -0400 5/4/11, Sam Hartman wrote:
>>>>> "Stephen" == Stephen Kent <kent@xxxxxxx> writes:
Stephen> The BGPSEC protocol being defined does not pass around ROAs
Stephen> or other RPKI repository objects. It defines two new,
Stephen> signed objects that are passed in UPDATE messages, and are
Stephen> not stored in the repository. These objects are verified
Stephen> using RPKI certs and CRLs, so there is a linkage.
OK, so how will the upgrade work for these signed objects? In
particular during phase 2, when both old and new certs (under the old
and new profile) are in use, what happens with these signed objects?
Can a party generate both old and new signed objects? If so, will the
protocol scale appropriately? If not, how does a party know which
signed object to generate?
Sam,
The BGPSEC protocol will have to accommodate changes in the algs used
to validate BGPSEC signed objects, and changes in algs used to
validate RPKI objects, and key (not alg) changes in the RPKI objects,
especially the certs associated with routers. So, format changes are
just another example of a change in the RPKI that BGPSEC will have to
accommodate. This is a legitimate discussion point for the BGPSEC
protocol design discussions that will take place in SIDR. It is out
of scope for the current set of docs, since they deal only with
origin AS validation.
It would be inappropriate to suggest delaying this doc (or to suggest
changes to it) based on discussions that will take place in the
future, for a protocol that is just being adopted as a WG item now.
Steve
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf