Last Call Review of draft-ietf-ipsecme-implicit-iv-07
review-ietf-ipsecme-implicit-iv-07-secdir-lc-nystrom-2019-10-14-00

 I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document defines a mechanism to save on bandwidth in ESP connections
when certain ciphers have been negotiated by using implicit IVs. The
savings are limited to 8 bytes for the current version of this document.



   - Section 2 mentions AES-CCM, AES-CTR, AES-GCM and ChaCha. For all of
   these ciphers, an 8-byte nonce is used. The mechanism to make the IV
   implicit is by coupling it to the sequence number. Yet, Section 4 gives two
   examples of sequence numbers, one  of 4 bytes and one of 8 bytes. This is
   confusing, presumably only the extended sequence number is usable?
   - Also, while the Abstract says the memo offers a mechanism to save on
   the explicit IV also for AES-CTR, and Section 2 includes AES-CTR in its
   description, Section 4 explicitly states that only AES-CCM, AES-GCM and
   ChaCha are subject of the optimization in this memo. This is also
   confusing. Why including AES-CTR in the memo at all if it isn't covered? At
   the very least it seems the Abstract should be updated.
   - It would be very helpful and useful to include an example of a
   handshake with an IIV and the resulting IV in an Appendix; this could
   assist implementors to get things right.


(Editorial: English grammar needs some updates/reviews)

Thanks,
-- Magnus