Ballot for draft-ietf-ippm-ipsec
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
I'm clearing my Discuss-for-IANA, now that draft-ietf-ippm-owamp-registry is on the next telechat agenda.
General: the "implementations compatible with this specification" stuff is really awkward and unnecessary. It would be better if it were changed to "implementations of this method" (and similar phrasing, such as "clients implementing this method") throughout the document. But this is non-blocking, and there's no reason to discuss it. I urge you to consider the change, but please do with that urging as you think best. -- Section 3 -- This document reserves from the TWAMP-Modes registry the Mode value IKEv2Derived which is equal to 128 (i.e. bit set in position 7) and MUST be used by TWAMP implementations compatible with this specification. Pete Resnick has left the IESG in body only, but not in spirit. I think what you mean here is that you signal that you're using this method by setting IKEv2Derived. Is that correct? Assuming so, this would be more clearly and simply said in a way such as this (definitely without any 2119 words, which aren't appropriate for that): NEW TWAMP implementations signal the use of this method by setting IKEv2Derived (see Section 7). END Please leave the details of the registry, and which bit was assigned, to the IANA Considerations section, where that stuff belongs. The reference to Section 7 makes it easy to find. -- Section 5.2 -- As in Section 3, it's better just to refer to IKEv2Derived, and not to talk about the registration details here. So: OLD The Modes field in Figure 2 will need to allow for support of key derivation as discussed in Section 5.1. As such, the Modes value extension MUST be supported by implementations compatible with this document, indicating support for deriving the shared key from the IKEv2 SA. The new Modes value indicating support for this specification is IKEv2Derived and is equal to 128 (i.e. bit set in position 7). Clearly, an implementation compatible with this specification MUST support the authenticated, encrypted and mixed modes as per [RFC4656][RFC5357][RFC5618]. NEW The Modes field in Figure 2 will need to allow for support of key derivation as discussed in Section 5.1. Therefore, when this method is used, the Modes value extension MUST be supported. Support for deriving the shared key from the IKEv2 SA is indicated by setting IKEv2Derived (see Section 7). The authenticated, encrypted and mixed modes (see [RFC4656][RFC5357][RFC5618]) MUST also be supported. END
Thanks for addressing my DISCUSS and comments!
Thanks for considering the SecDir review and providing edits in the current draft revision. https://www.ietf.org/mail-archive/web/secdir/current/msg05444.html
Since you're touching on the key managment code, I'd have loved to see you also update the O/TWAMP crypto itself to e.g. use an AEAD cipher rather than AES-CBC. Did the WG consider that? (I assume it's too late now, but I'm not clear from the write-up if this is implemented or not, so I guess there's a small chance that the WG may want to update more than just the key mgmt.)