draft-ietf-ipsecme-rfc7321bis-03.txt   draft-ietf-ipsecme-rfc7321bis-04.txt 
Network Working Group D. Migault Network Working Group D. Migault
Internet-Draft J. Mattsson Internet-Draft J. Mattsson
Obsoletes: 7321 (if approved) Ericsson Obsoletes: 7321 (if approved) Ericsson
Intended status: Standards Track P. Wouters Intended status: Standards Track P. Wouters
Expires: August 06, 2017 Red Hat Expires: August 19, 2017 Red Hat
Y. Nir Y. Nir
Check Point Check Point
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
February 02, 2017 February 15, 2017
Cryptographic Algorithm Implementation Requirements and Usage Guidance Cryptographic Algorithm Implementation Requirements and Usage Guidance
for Encapsulating Security Payload (ESP) and Authentication Header (AH) for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-ietf-ipsecme-rfc7321bis-03 draft-ietf-ipsecme-rfc7321bis-04
Abstract Abstract
This document updates the Cryptographic Algorithm Implementation This document updates the Cryptographic Algorithm Implementation
Requirements for ESP and AH. The goal of these document is to enable Requirements for ESP and AH. The goal of these document is to enable
ESP and AH to benefit from cryptography that is up to date while ESP and AH to benefit from cryptography that is up to date while
making IPsec interoperable. making IPsec interoperable.
This document obsoletes RFC 7321 on the cryptographic recommendations This document obsoletes RFC 7321 on the cryptographic recommendations
only. only.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 06, 2017. This Internet-Draft will expire on August 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 27 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Updating Algorithm Implementation Requirements and Usage 1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5 4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5
5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7 5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7
6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9 6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9
7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9 7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Encapsulating Security Payload (ESP) [RFC4303] and the The Encapsulating Security Payload (ESP) [RFC4303] and the
Authentication Header (AH) [RFC4302] are the mechanisms for applying Authentication Header (AH) [RFC4302] are the mechanisms for applying
cryptographic protection to data being sent over an IPsec Security cryptographic protection to data being sent over an IPsec Security
Association (SA) [RFC4301]. Association (SA) [RFC4301].
skipping to change at page 5, line 15 skipping to change at page 5, line 10
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
We define some additional terms here: We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, it is likely SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at some that an algorithm marked as SHOULD+ will be promoted at
future time to be a MUST. some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future marked as SHOULD- may be deprecated to a MAY in a future
version of this document. version of this document.
MUST- This term means the same as MUST. However, we expect at some MUST- This term means the same as MUST. However, we expect at
point that this algorithm will no longer be a MUST in a some point that this algorithm will no longer be a MUST in
future document. Although its status will be determined at a a future document. Although its status will be determined
later time, it is reasonable to expect that if a future at a later time, it is reasonable to expect that if a
revision of a document alters the status of a MUST- future revision of a document alters the status of a MUST-
algorithm, it will remain at least a SHOULD or a SHOULD- algorithm, it will remain at least a SHOULD or a SHOULD-
level. level.
IoT stands for Internet of Things. IoT stands for Internet of Things.
Table 1
3. Manual Keying 3. Manual Keying
Manual Keying is not to be used as it is inherently dangerous. Manual Keying is not to be used as it is inherently dangerous.
Without any keying protocol, it does not offer Perfect Forward Without any keying protocol, it does not offer Perfect Forward
Secrecy ("PFS") protection. Deployments tend to never be Secrecy ("PFS") protection. Deployments tend to never be
reconfigured with fresh session keys. It also fails to scale and reconfigured with fresh session keys. It also fails to scale and
keeping SPI's unique amongst many servers is impractical. This keeping SPI's unique amongst many servers is impractical. This
document was written for deploying ESP/AH using IKE ([RFC7296]) and document was written for deploying ESP/AH using IKE ([RFC7296]) and
assumes that keying happens using IKEv2. assumes that keying happens using IKEv2.
skipping to change at page 6, line 18 skipping to change at page 6, line 24
| ENCR_AES_CBC | MUST | No | [RFC3602][1] | | ENCR_AES_CBC | MUST | No | [RFC3602][1] |
| ENCR_AES_CCM_8 | SHOULD(IoT) | Yes | [RFC4309] | | ENCR_AES_CCM_8 | SHOULD(IoT) | Yes | [RFC4309] |
| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
+-------------------------+-------------+---------+--------------+ +-------------------------+-------------+---------+--------------+
[1] - This requirement level is for 128-bit and 256-bit keys. [1] - This requirement level is for 128-bit and 256-bit keys.
192-bit keys remain at MAY level. (IoT) - This requirement is for 192-bit keys remain at MAY level. (IoT) - This requirement is for
interoperability with IoT. Only 128-bit keys are at the given level. interoperability with IoT. Only 128-bit keys are at the given level.
Table 2
IPsec sessions may have very long life time, and carry multiple IPsec sessions may have very long life time, and carry multiple
packets, so there is a need to move to 256-bit keys in the long term. packets, so there is a need to move to 256-bit keys in the long term.
For that purpose the requirement level for 128 bit keys and 256 bit For that purpose the requirement level for 128 bit keys and 256 bit
keys are at MUST (when applicable). In that sense 256 bit keys keys are at MUST (when applicable). In that sense 256 bit keys
status has been raised from MAY in RFC7321 to MUST. status has been raised from MAY in RFC7321 to MUST.
IANA has allocated codes for cryptographic algorithms that have not IANA has allocated codes for cryptographic algorithms that have not
been specified by the IETF. Such algorithms are noted as been specified by the IETF. Such algorithms are noted as
UNSPECIFIED. Usually, the use of theses algorithms is limited to UNSPECIFIED. Usually, the use of theses algorithms is limited to
specific cases, and the absence of specification makes specific cases, and the absence of specification makes
skipping to change at page 7, line 46 skipping to change at page 8, line 5
Encryption without authentication MUST NOT be used. As a result, Encryption without authentication MUST NOT be used. As a result,
authentication algorithm recommendations in this section are authentication algorithm recommendations in this section are
targeting two types of communications: Firstly authenticated only targeting two types of communications: Firstly authenticated only
communications without encryption. Such communications can be ESP communications without encryption. Such communications can be ESP
with NULL encryption or AH communications. Secondly, communications with NULL encryption or AH communications. Secondly, communications
that are encrypted with non AEAD encryption algorithms mentioned that are encrypted with non AEAD encryption algorithms mentioned
above. In this case, they MUST be combined with an authentication above. In this case, they MUST be combined with an authentication
algorithm. algorithm.
+----------------------------+-------------+------------------------+ +------------------------+------------------+-----------------------+
| Name | Status | Comment | | Name | Status | Comment |
+----------------------------+-------------+------------------------+ +------------------------+------------------+-----------------------+
| AUTH_NONE | MUST / MUST | [RFC7296] AEAD | | AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD |
| | NOT | | | AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] | | AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] | | AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |
| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] | | AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |
| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] | | AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |
| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] | | | | (IoT) |
| | | (IoT) | | AUTH_AES_128_GMAC | MAY | [RFC4543] |
| AUTH_AES_128_GMAC | MAY | [RFC4543] | | AUTH_AES_256_GMAC | MAY | [RFC4543] |
| AUTH_AES_256_GMAC | MAY | [RFC4543] | | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |
| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | +------------------------+------------------+-----------------------+
+----------------------------+-------------+------------------------+
(IoT) - This requirement is for interoperability with IoT (IoT) - This requirement is for interoperability with IoT
Table 3
AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The
only reason NULL is acceptable is when authenticated encryption only reason NULL is acceptable is when authenticated encryption
algorithms are selected from Section 4. In all other cases, NULL algorithms are selected from Section 4. In all other cases, NULL
MUST NOT be selected. As ESP and AH both provides authentication, MUST NOT be selected. As ESP and AH both provides authentication,
one may be tempted to combine these protocols to provide one may be tempted to combine these protocols to provide
authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to
use ESP with NULL authentication - with non authenticated encryption use ESP with NULL authentication - with non authenticated encryption
- in conjunction with AH; some configurations of this combination of - in conjunction with AH; some configurations of this combination of
services have been shown to be insecure [PD10]. In addition, NULL services have been shown to be insecure [PD10]. In addition, NULL
authentication cannot be combined with ESP NULL encryption. authentication cannot be combined with ESP NULL encryption.
skipping to change at page 9, line 31 skipping to change at page 9, line 34
| Name | Status | Comment | | Name | Status | Comment |
+----------------+----------+-------------+ +----------------+----------+-------------+
| IPCOMP_OUI | MUST NOT | UNSPECIFIED | | IPCOMP_OUI | MUST NOT | UNSPECIFIED |
| IPCOMP_DEFLATE | MAY | [RFC2393] | | IPCOMP_DEFLATE | MAY | [RFC2393] |
| IPCOMP_LZS | MAY | [RFC2395] | | IPCOMP_LZS | MAY | [RFC2395] |
| IPCOMP_LZJH | MAY | [RFC3051] | | IPCOMP_LZJH | MAY | [RFC3051] |
+----------------+----------+-------------+ +----------------+----------+-------------+
(IoT) - This requirement is for interoperability with IoT (IoT) - This requirement is for interoperability with IoT
Table 4
Compression was not mentioned in RFC7321. As it is not widely Compression was not mentioned in RFC7321. As it is not widely
deployed, it remains optional and at the MAY-level. deployed, it remains optional and at the MAY-level.
7. Summary of Changes from RFC 7321 7. Summary of Changes from RFC 7321
The following table summarizes the changes from RFC 7321. The following table summarizes the changes from RFC 7321.
RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE
TABLE BELOW WITH THE NUMBER OF THIS RFC TABLE BELOW WITH THE NUMBER OF THIS RFC
+-------------------+----------+-----------------+ +-------------------+----------+-----------------+
| Algorithm | RFC 7321 | RFC XXXX | | Algorithm | RFC 7321 | RFC XXXX |
+-------------------+----------+-----------------+ +-------------------+----------+-----------------+
| ENCR_AES_GCM_16 | SHOULD+ | MUST | | ENCR_AES_GCM_16 | SHOULD+ | MUST |
| ENCR_AES_CCM_8 | MAY | SHOULD | | ENCR_AES_CCM_8 | MAY | SHOULD |
| ENCR_AES_CTR | MAY | (*) | | ENCR_AES_CTR | MAY | (*) |
| ENCR_3DES | MAY | SHOULD NOT | | ENCR_3DES | MAY | SHOULD NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- | | AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_128_GMAC | SHOULD+ | MAY | | AUTH_AES_128_GMAC | SHOULD+ | MAY |
| AUTH_NONE | MAY | MUST / MUST NOT | | AUTH_NONE | MAY | MUST / MUST NOT |
skipping to change at page 10, line 9 skipping to change at page 10, line 19
| ENCR_AES_CTR | MAY | (*) | | ENCR_AES_CTR | MAY | (*) |
| ENCR_3DES | MAY | SHOULD NOT | | ENCR_3DES | MAY | SHOULD NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- | | AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_128_GMAC | SHOULD+ | MAY | | AUTH_AES_128_GMAC | SHOULD+ | MAY |
| AUTH_NONE | MAY | MUST / MUST NOT | | AUTH_NONE | MAY | MUST / MUST NOT |
+-------------------+----------+-----------------+ +-------------------+----------+-----------------+
(*) This algorithm is not mentioned in the above sections, so it (*) This algorithm is not mentioned in the above sections, so it
defaults to MAY. defaults to MAY.
Table 5
8. Acknowledgements 8. Acknowledgements
Some of the wording in this document was adapted from [RFC7321], the Some of the wording in this document was adapted from [RFC7321], the
document that this one obsoletes, which was written by D. McGrew and document that this one obsoletes, which was written by D. McGrew and
P. Hoffman. P. Hoffman.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. Security Considerations 10. Security Considerations
The security of a system that uses cryptography depends on both the The security of a system that uses cryptography depends on both the
strength of the cryptographic algorithms chosen and the strength of strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on the keys used with those algorithms. The security also depends on
skipping to change at page 10, line 45 skipping to change at page 11, line 10
leads us to believe that they will likely remain secure into the leads us to believe that they will likely remain secure into the
foreseeable future. However, this is not necessarily forever. foreseeable future. However, this is not necessarily forever.
Therefore, we expect that revisions of that document will be issued Therefore, we expect that revisions of that document will be issued
from time to time to reflect the current best practice in this area. from time to time to reflect the current best practice in this area.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>. <http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>. <http://www.rfc-editor.org/info/rfc4303>.
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm
Implementation Requirements and Usage Guidance for Implementation Requirements and Usage Guidance for
Encapsulating Security Payload (ESP) and Authentication Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,
<http://www.rfc-editor.org/info/rfc7321>. <http://www.rfc-editor.org/info/rfc7321>.
[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the
Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,
DOI 10.17487/RFC7634, August 2015,
<http://www.rfc-editor.org/info/rfc7634>.
11.2. Informative References 11.2. Informative References
[PD10] Paterson, K. and J. Degabriele, "On the (in)security of [PD10] Paterson, K. and J. Degabriele, "On the (in)security of
IPsec in MAC-then-encrypt configurations (ACM Conference IPsec in MAC-then-encrypt configurations (ACM Conference
on Computer and Communications Security, ACM CCS)", 2010. on Computer and Communications Security, ACM CCS)", 2010.
[RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, DOI Payload Compression Protocol (IPComp)", RFC 2393,
10.17487/RFC2393, December 1998, DOI 10.17487/RFC2393, December 1998,
<http://www.rfc-editor.org/info/rfc2393>. <http://www.rfc-editor.org/info/rfc2393>.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998,
<http://www.rfc-editor.org/info/rfc2395>. <http://www.rfc-editor.org/info/rfc2395>.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November
1998, <http://www.rfc-editor.org/info/rfc2403>. 1998, <http://www.rfc-editor.org/info/rfc2403>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <http://www.rfc-editor.org/info/rfc2404>. 1998, <http://www.rfc-editor.org/info/rfc2404>.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, DOI 10.17487/ Algorithm With Explicit IV", RFC 2405,
RFC2405, November 1998, DOI 10.17487/RFC2405, November 1998,
<http://www.rfc-editor.org/info/rfc2405>. <http://www.rfc-editor.org/info/rfc2405>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
November 1998, <http://www.rfc-editor.org/info/rfc2410>. November 1998, <http://www.rfc-editor.org/info/rfc2410>.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, DOI 10.17487/RFC2451, November Algorithms", RFC 2451, DOI 10.17487/RFC2451, November
1998, <http://www.rfc-editor.org/info/rfc2451>. 1998, <http://www.rfc-editor.org/info/rfc2451>.
[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using
ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051,
January 2001, <http://www.rfc-editor.org/info/rfc3051>. January 2001, <http://www.rfc-editor.org/info/rfc3051>.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566,
September 2003, <http://www.rfc-editor.org/info/rfc3566>. September 2003, <http://www.rfc-editor.org/info/rfc3566>.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/ Algorithm and Its Use with IPsec", RFC 3602,
RFC3602, September 2003, DOI 10.17487/RFC3602, September 2003,
<http://www.rfc-editor.org/info/rfc3602>. <http://www.rfc-editor.org/info/rfc3602>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC (GCM) in IPsec Encapsulating Security Payload (ESP)",
4106, DOI 10.17487/RFC4106, June 2005, RFC 4106, DOI 10.17487/RFC4106, June 2005,
<http://www.rfc-editor.org/info/rfc4106>. <http://www.rfc-editor.org/info/rfc4106>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", RFC Mode with IPsec Encapsulating Security Payload (ESP)",
4309, DOI 10.17487/RFC4309, December 2005, RFC 4309, DOI 10.17487/RFC4309, December 2005,
<http://www.rfc-editor.org/info/rfc4309>. <http://www.rfc-editor.org/info/rfc4309>.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
DOI 10.17487/RFC4543, May 2006, DOI 10.17487/RFC4543, May 2006,
<http://www.rfc-editor.org/info/rfc4543>. <http://www.rfc-editor.org/info/rfc4543>.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, DOI 10.17487/ Authentication Header (AH)", RFC 4835,
RFC4835, April 2007, DOI 10.17487/RFC4835, April 2007,
<http://www.rfc-editor.org/info/rfc4835>. <http://www.rfc-editor.org/info/rfc4835>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 384, and HMAC-SHA-512 with IPsec", RFC 4868,
10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<http://www.rfc-editor.org/info/rfc4868>. <http://www.rfc-editor.org/info/rfc4868>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the
Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,
DOI 10.17487/RFC7634, August 2015,
<http://www.rfc-editor.org/info/rfc7634>.
Authors' Addresses Authors' Addresses
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
Phone: +1 514-452-2160 Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com Email: daniel.migault@ericsson.com
 End of changes. 28 change blocks. 
69 lines changed or deleted 57 lines changed or added

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