The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)' <draft-ietf-ipsecme-implicit-iv-07.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email protected] mailing lists by 2019-10-07. Exceptionally, comments may be sent to [email protected] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and saves in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
