A few questions and comments. I don't think they have been mentioned
before, excuse me if they have.
3.1 A BGPsec design MUST be able to be incrementally deployed on
today's Internet.
Does this allow for long-term eventual coexistence of BGPsec and
normal BGP without compromise of security of the BGPsec? I can imagine
scenarios where incremental deployments are possible at the cost of a
weaker assurance, but with the expectation that eventually at least
islands will appear where BGPsec is used everywhere (and only then
will BGPsec be in full power).
3.3 As cryptographic payloads and loading on routers are likely to
seriously increase, a BGPsec design may require use of new
hardware. It must be possible to build routers that do BGPsec
with within acceptable (to operators) bounds of cost and
performance.
may -> MAY, must -> MUST?
4.2 A BGPsec design MUST enable the recipient of an UPDATE to
formally determine that the UPDATE has traversed the AS path
indicated in the UPADTE. Note that this is more stringent than
showing that the path is merely not impossible.
Are we talking about absolute assurance or probabilistic (with a
tunable confidence value) assurance? Is a distinction needed?
4.3 Replay of BGP UPDATE messages need not be completely prevented,
but a BGPsec design MUST provide a mechanism to control the
window of exposure to replay attacks.
Is this control mechanism something that each AS can choose?
Dongting
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
