> 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).
yes. though i imagine the security assertions you can make between two
BGPsec islands across a non-secured gap could be weak. interesting
issue.
> 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?
what i have in my edit buffer is
3.3 As cryptographic payloads and memory requirements on routers
are likely to increase, a BGPsec design MAY require use of new
hardware. I.e. compatibility with current hardware abilities
is not a requirement that this document imposes on a solution.
As BGPsec will likely not be rolled out for some years, this
should not be a major problem.
> 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
the intent is absolute, as much as there are absolutes in this life
> 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?
i believe that the intent is that the originator of the prefix would be
able to choose.
randy
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
