draft-ietf-ipsecme-implicit-iv-09.txt   draft-ietf-ipsecme-implicit-iv-10.txt 
IPSECME D. Migault IPSECME D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track T. Guggemos Intended status: Standards Track T. Guggemos
Expires: April 20, 2020 LMU Munich Expires: April 22, 2020 LMU Munich
Y. Nir Y. Nir
Dell EMC Dell EMC
October 18, 2019 October 20, 2019
Implicit IV for Counter-based Ciphers in Encapsulating Security Payload Implicit IV for Counter-based Ciphers in Encapsulating Security Payload
(ESP) (ESP)
draft-ietf-ipsecme-implicit-iv-09 draft-ietf-ipsecme-implicit-iv-10
Abstract Abstract
Encapsulating Security Payload (ESP) sends an initialization vector Encapsulating Security Payload (ESP) sends an initialization vector
(IV) in each packet. The size of IV depends on the applied (IV) in each packet. The size of IV depends on the applied
transform, being usually 8 or 16 octets for the transforms defined by transform, being usually 8 or 16 octets for the transforms defined by
the time this document is written. Some algorithms such as AES-GCM, the time this document is written. Some algorithms such as AES-GCM,
AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to
generate a nonce that is used as an input parameter for encrypting generate a nonce that is used as an input parameter for encrypting
and decrypting. This IV must be unique but can be predictable. As a and decrypting. This IV must be unique but can be predictable. As a
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2020. This Internet-Draft will expire on April 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 49 skipping to change at page 5, line 49
which can be used for both ESP and IKEv2, these transforms are which can be used for both ESP and IKEv2, these transforms are
defined for ESP only and cannot be used in IKEv2. The reason is that defined for ESP only and cannot be used in IKEv2. The reason is that
IKEv2 messages don't contain a unique per-message value that can be IKEv2 messages don't contain a unique per-message value that can be
used for IV generation. The Message-ID field in IKEv2 header is used for IV generation. The Message-ID field in IKEv2 header is
similar to the SN field in ESP header, but recent IKEv2 extensions similar to the SN field in ESP header, but recent IKEv2 extensions
([RFC6311], [RFC7383]) do allow it to repeat, so there is not an easy ([RFC6311], [RFC7383]) do allow it to repeat, so there is not an easy
way to derive unique IV from IKEv2 header fields. way to derive unique IV from IKEv2 header fields.
8. IANA Considerations 8. IANA Considerations
The IANA has assigned the following code points: The IANA has assigned the following code points to the registry
Transform Type 1 - Encryption Algorithm Transform IDs [IANA]:
- ENCR_AES_CCM_8_IIV: 29 - ENCR_AES_CCM_8_IIV: 29
- ENCR_AES_GCM_16_IIV: 30 - ENCR_AES_GCM_16_IIV: 30
- ENCR_CHACHA20_POLY1305_IIV: 31 - ENCR_CHACHA20_POLY1305_IIV: 31
These algorithms should be added with this document as ESP Reference These algorithms should be added with this document as ESP Reference
and "Not Allowed" for IKEv2 Reference. and "Not Allowed" for IKEv2 Reference.
9. Acknowledgements 9. Acknowledgements
 End of changes. 5 change blocks. 
5 lines changed or deleted 6 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/