draft-ietf-ipsecme-ikev2bis-11.txt   rfc5996.txt 
Network Working Group C. Kaufman Internet Engineering Task Force (IETF) C. Kaufman
Internet-Draft Microsoft Request for Comments: 5996 Microsoft
Obsoletes: 4306, 4718 P. Hoffman Obsoletes: 4306, 4718 P. Hoffman
(if approved) VPN Consortium Category: Standards Track VPN Consortium
Intended status: Standards Track Y. Nir ISSN: 2070-1721 Y. Nir
Expires: November 18, 2010 Check Point Check Point
P. Eronen P. Eronen
Nokia Independent
May 17, 2010 September 2010
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-ikev2bis-11
Abstract Abstract
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations authentication and establishing and maintaining Security Associations
(SAs). This document replaces and updates RFC 4306, and includes all (SAs). This document replaces and updates RFC 4306, and includes all
of the clarifications from RFC 4718. of the clarifications from RFC 4718.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 18, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5996.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 line 69 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction 1. Introduction ....................................................5
1.1. Usage Scenarios 1.1. Usage Scenarios ............................................6
1.1.1. Security Gateway to Security Gateway Tunnel Mode 1.1.1. Security Gateway to Security Gateway in
1.1.2. Endpoint-to-Endpoint Transport Mode Tunnel Mode .........................................7
1.1.3. Endpoint to Security Gateway Tunnel Mode 1.1.2. Endpoint-to-Endpoint Transport Mode .................7
1.1.4. Other Scenarios 1.1.3. Endpoint to Security Gateway in Tunnel Mode .........8
1.2. The Initial Exchanges 1.1.4. Other Scenarios .....................................9
1.3. The CREATE_CHILD_SA Exchange 1.2. The Initial Exchanges ......................................9
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 1.3. The CREATE_CHILD_SA Exchange ..............................13
Exchange 1.3.1. Creating New Child SAs with the
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange CREATE_CHILD_SA Exchange ...........................14
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA
Exchange Exchange ...........................................15
1.4. The INFORMATIONAL Exchange 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
1.4.1. Deleting an SA with INFORMATIONAL Exchanges Exchange ...........................................16
1.5. Informational Messages outside of an IKE SA 1.4. The INFORMATIONAL Exchange ................................17
1.6. Requirements Terminology 1.4.1. Deleting an SA with INFORMATIONAL Exchanges ........17
1.7. Significant Differences Between RFC 4306 and This 1.5. Informational Messages outside of an IKE SA ...............18
Document 1.6. Requirements Terminology ..................................19
2. IKE Protocol Details and Variations 1.7. Significant Differences between RFC 4306 and This
2.1. Use of Retransmission Timers Document ..................................................20
2.2. Use of Sequence Numbers for Message ID 2. IKE Protocol Details and Variations ............................22
2.3. Window Size for Overlapping Requests 2.1. Use of Retransmission Timers ..............................23
2.4. State Synchronization and Connection Timeouts 2.2. Use of Sequence Numbers for Message ID ....................24
2.5. Version Numbers and Forward Compatibility 2.3. Window Size for Overlapping Requests ......................25
2.6. IKE SA SPIs and Cookies 2.4. State Synchronization and Connection Timeouts .............26
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 2.5. Version Numbers and Forward Compatibility .................28
2.7. Cryptographic Algorithm Negotiation 2.6. IKE SA SPIs and Cookies ...................................30
2.8. Rekeying 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD .......33
2.8.1. Simultaneous Child SA rekeying 2.7. Cryptographic Algorithm Negotiation .......................34
2.8.2. Simultaneous IKE SA Rekeying 2.8. Rekeying ..................................................34
2.8.3. Rekeying the IKE SA Versus Reauthentication 2.8.1. Simultaneous Child SA Rekeying .....................36
2.9. Traffic Selector Negotiation 2.8.2. Simultaneous IKE SA Rekeying .......................39
2.9.1. Traffic Selectors Violating Own Policy 2.8.3. Rekeying the IKE SA versus Reauthentication ........40
2.10. Nonces 2.9. Traffic Selector Negotiation ..............................40
2.11. Address and Port Agility 2.9.1. Traffic Selectors Violating Own Policy .............43
2.12. Reuse of Diffie-Hellman Exponentials 2.10. Nonces ...................................................44
2.13. Generating Keying Material 2.11. Address and Port Agility .................................44
2.14. Generating Keying Material for the IKE SA 2.12. Reuse of Diffie-Hellman Exponentials .....................44
2.15. Authentication of the IKE SA 2.13. Generating Keying Material ...............................45
2.16. Extensible Authentication Protocol Methods 2.14. Generating Keying Material for the IKE SA ................46
2.17. Generating Keying Material for Child SAs 2.15. Authentication of the IKE SA .............................47
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2.16. Extensible Authentication Protocol Methods ...............50
2.19. Requesting an Internal Address on a Remote Network 2.17. Generating Keying Material for Child SAs .................52
2.20. Requesting the Peer's Version 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange ........53
2.21. Error Handling 2.19. Requesting an Internal Address on a Remote Network .......53
2.21.1. Error Handling in IKE_SA_INIT 2.20. Requesting the Peer's Version ............................55
2.21.2. Error Handling in IKE_AUTH 2.21. Error Handling ...........................................56
2.21.3. Error Handling after IKE SA is Authenticated 2.21.1. Error Handling in IKE_SA_INIT .....................56
2.21.4. Error Handling Outside IKE SA 2.21.2. Error Handling in IKE_AUTH ........................57
2.22. IPComp 2.21.3. Error Handling after IKE SA is Authenticated ......58
2.23. NAT Traversal 2.21.4. Error Handling Outside IKE SA .....................58
2.23.1. Transport Mode NAT Traversal 2.22. IPComp ...................................................59
2.24. Explicit Congestion Notification (ECN) 2.23. NAT Traversal ............................................60
2.25. Exchange Collisions 2.23.1. Transport Mode NAT Traversal ......................64
2.25.1. Collisions While Rekeying or Closing Child SAs 2.24. Explicit Congestion Notification (ECN) ...................68
2.25.2. Collisions While Rekeying or Closing IKE SAs 2.25. Exchange Collisions ......................................68
3. Header and Payload Formats 2.25.1. Collisions while Rekeying or Closing Child SAs ....69
3.1. The IKE Header 2.25.2. Collisions while Rekeying or Closing IKE SAs ......69
3.2. Generic Payload Header 3. Header and Payload Formats .....................................69
3.3. Security Association Payload 3.1. The IKE Header ............................................70
3.3.1. Proposal Substructure 3.2. Generic Payload Header ....................................73
3.3.2. Transform Substructure 3.3. Security Association Payload ..............................75
3.3.3. Valid Transform Types by Protocol 3.3.1. Proposal Substructure ..............................78
3.3.4. Mandatory Transform IDs 3.3.2. Transform Substructure .............................79
3.3.5. Transform Attributes 3.3.3. Valid Transform Types by Protocol ..................82
3.3.6. Attribute Negotiation 3.3.4. Mandatory Transform IDs ............................83
3.4. Key Exchange Payload 3.3.5. Transform Attributes ...............................84
3.5. Identification Payloads 3.3.6. Attribute Negotiation ..............................86
3.6. Certificate Payload 3.4. Key Exchange Payload ......................................87
3.7. Certificate Request Payload 3.5. Identification Payloads ...................................87
3.8. Authentication Payload 3.6. Certificate Payload .......................................90
3.9. Nonce Payload 3.7. Certificate Request Payload ...............................93
3.10. Notify Payload 3.8. Authentication Payload ....................................95
3.10.1. Notify Message Types 3.9. Nonce Payload .............................................96
3.11. Delete Payload 3.10. Notify Payload ...........................................97
3.12. Vendor ID Payload 3.10.1. Notify Message Types ..............................98
3.13. Traffic Selector Payload 3.11. Delete Payload ..........................................101
3.13.1. Traffic Selector 3.12. Vendor ID Payload .......................................102
3.14. Encrypted Payload 3.13. Traffic Selector Payload ................................103
3.15. Configuration Payload 3.13.1. Traffic Selector .................................105
3.15.1. Configuration Attributes 3.14. Encrypted Payload .......................................107
3.15.2. Meaning of INTERNAL_IP4_SUBNET and 3.15. Configuration Payload ...................................109
INTERNAL_IP6_SUBNET 3.15.1. Configuration Attributes .........................110
3.15.3. Configuration payloads for IPv6 3.15.2. Meaning of INTERNAL_IP4_SUBNET and
3.15.4. Address Assignment Failures INTERNAL_IP6_SUBNET ..............................113
3.16. Extensible Authentication Protocol (EAP) Payload 3.15.3. Configuration Payloads for IPv6 ..................115
4. Conformance Requirements 3.15.4. Address Assignment Failures ......................116
5. Security Considerations 3.16. Extensible Authentication Protocol (EAP) Payload ........117
5.1. Traffic selector authorization 4. Conformance Requirements ......................................118
6. IANA Considerations 5. Security Considerations .......................................120
7. Acknowledgements 5.1. Traffic Selector Authorization ...........................123
8. References 6. IANA Considerations ...........................................124
8.1. Normative References 7. Acknowledgements ..............................................125
8.2. Informative References 8. References ....................................................126
Appendix A. Summary of changes from IKEv1 8.1. Normative References .....................................126
Appendix B. Diffie-Hellman Groups 8.2. Informative References ...................................127
B.1. Group 1 - 768 Bit MODP Appendix A. Summary of Changes from IKEv1 ........................132
B.2. Group 2 - 1024 Bit MODP Appendix B. Diffie-Hellman Groups ................................133
Appendix C. Exchanges and Payloads B.1. Group 1 - 768-bit MODP ....................................133
C.1. IKE_SA_INIT Exchange B.2. Group 2 - 1024-bit MODP ...................................133
C.2. IKE_AUTH Exchange without EAP Appendix C. Exchanges and Payloads ..............................134
C.3. IKE_AUTH Exchange with EAP C.1. IKE_SA_INIT Exchange .....................................134
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.2. IKE_AUTH Exchange without EAP .............................135
Child SAs C.3. IKE_AUTH Exchange with EAP ...............................136
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
C.6. INFORMATIONAL Exchange Child SAs .................................................137
Appendix D. Changes Between Internet Draft Versions C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA ..........137
D.1. Changes from IKEv2 to draft -00 C.6. INFORMATIONAL Exchange ....................................137
D.2. Changes from draft -00 to draft -01
D.3. Changes from draft -00 to draft -01
D.4. Changes from draft -01 to draft -02
D.5. Changes from draft -02 to draft -03
D.6. Changes from draft -03 to
draft-ietf-ipsecme-ikev2bis-00
D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
draft-ietf-ipsecme-ikev2bis-01
D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02
D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02
D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to
draft-ietf-ipsecme-ikev2bis-03
D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to
draft-ietf-ipsecme-ikev2bis-04
D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to
draft-ietf-ipsecme-ikev2bis-05
D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to
draft-ietf-ipsecme-ikev2bis-06
D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to
draft-ietf-ipsecme-ikev2bis-07
D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to
draft-ietf-ipsecme-ikev2bis-08
D.16. Changes from draft-ietf-ipsecme-ikev2bis-08 to
draft-ietf-ipsecme-ikev2bis-09
D.17. Changes from draft-ietf-ipsecme-ikev2bis-09 to
draft-ietf-ipsecme-ikev2bis-10
D.18. Changes from draft-ietf-ipsecme-ikev2bis-10 to
draft-ietf-ipsecme-ikev2bis-11
Authors' Addresses
1. Introduction 1. Introduction
IP Security (IPsec) provides confidentiality, data integrity, access IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. These control, and data source authentication to IP datagrams. These
services are provided by maintaining shared state between the source services are provided by maintaining shared state between the source
and the sink of an IP datagram. This state defines, among other and the sink of an IP datagram. This state defines, among other
things, the specific services provided to the datagram, which things, the specific services provided to the datagram, which
cryptographic algorithms will be used to provide the services, and cryptographic algorithms will be used to provide the services, and
the keys used as input to the cryptographic algorithms. the keys used as input to the cryptographic algorithms.
skipping to change at line 249 skipping to change at page 5, line 44
"suite" or "cryptographic suite" refers to a complete set of "suite" or "cryptographic suite" refers to a complete set of
algorithms used to protect an SA. An initiator proposes one or more algorithms used to protect an SA. An initiator proposes one or more
suites by listing supported algorithms that can be combined into suites by listing supported algorithms that can be combined into
suites in a mix-and-match fashion. IKE can also negotiate use of IP suites in a mix-and-match fashion. IKE can also negotiate use of IP
Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA.
The SAs for ESP or AH that get set up through that IKE SA we call The SAs for ESP or AH that get set up through that IKE SA we call
"Child SAs". "Child SAs".
All IKE communications consist of pairs of messages: a request and a All IKE communications consist of pairs of messages: a request and a
response. The pair is called an "exchange", and is sometimes called response. The pair is called an "exchange", and is sometimes called
"request/response pair". The first exchange of messages establishing a "request/response pair". The first exchange of messages
an IKE SA are called the IKE_SA_INIT and IKE_AUTH exchanges; establishing an IKE SA are called the IKE_SA_INIT and IKE_AUTH
subsequent IKE exchanges are called the CREATE_CHILD_SA or exchanges; subsequent IKE exchanges are called the CREATE_CHILD_SA or
INFORMATIONAL exchanges. In the common case, there is a single INFORMATIONAL exchanges. In the common case, there is a single
IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four
messages) to establish the IKE SA and the first Child SA. In messages) to establish the IKE SA and the first Child SA. In
exceptional cases, there may be more than one of each of these exceptional cases, there may be more than one of each of these
exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete
before any other exchange type, then all IKE_AUTH exchanges MUST before any other exchange type, then all IKE_AUTH exchanges MUST
complete, and following that any number of CREATE_CHILD_SA and complete, and following that, any number of CREATE_CHILD_SA and
INFORMATIONAL exchanges may occur in any order. In some scenarios, INFORMATIONAL exchanges may occur in any order. In some scenarios,
only a single Child SA is needed between the IPsec endpoints, and only a single Child SA is needed between the IPsec endpoints, and
therefore there would be no additional exchanges. Subsequent therefore there would be no additional exchanges. Subsequent
exchanges MAY be used to establish additional Child SAs between the exchanges MAY be used to establish additional Child SAs between the
same authenticated pair of endpoints and to perform housekeeping same authenticated pair of endpoints and to perform housekeeping
functions. functions.
An IKE message flow always consists of a request followed by a An IKE message flow always consists of a request followed by a
response. It is the responsibility of the requester to ensure response. It is the responsibility of the requester to ensure
reliability. If the response is not received within a timeout reliability. If the response is not received within a timeout
skipping to change at line 299 skipping to change at page 7, line 5
In the description that follows, we assume that no errors occur. In the description that follows, we assume that no errors occur.
Modifications to the flow when errors occur are described in Modifications to the flow when errors occur are described in
Section 2.21. Section 2.21.
1.1. Usage Scenarios 1.1. Usage Scenarios
IKE is used to negotiate ESP or AH SAs in a number of different IKE is used to negotiate ESP or AH SAs in a number of different
scenarios, each with its own special requirements. scenarios, each with its own special requirements.
1.1.1. Security Gateway to Security Gateway Tunnel Mode 1.1.1. Security Gateway to Security Gateway in Tunnel Mode
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | IPsec | | | | IPsec | |
Protected |Tunnel | tunnel |Tunnel | Protected Protected |Tunnel | tunnel |Tunnel | Protected
Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 1: Security Gateway to Security Gateway Tunnel Figure 1: Security Gateway to Security Gateway Tunnel
skipping to change at line 333 skipping to change at page 7, line 39
|Endpoint |<---------------------------------------->|Endpoint | |Endpoint |<---------------------------------------->|Endpoint |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 2: Endpoint to Endpoint Figure 2: Endpoint to Endpoint
In this scenario, both endpoints of the IP connection implement In this scenario, both endpoints of the IP connection implement
IPsec, as required of hosts in [IPSECARCH]. Transport mode will IPsec, as required of hosts in [IPSECARCH]. Transport mode will
commonly be used with no inner IP header. A single pair of addresses commonly be used with no inner IP header. A single pair of addresses
will be negotiated for packets to be protected by this SA. These will be negotiated for packets to be protected by this SA. These
endpoints MAY implement application layer access controls based on endpoints MAY implement application-layer access controls based on
the IPsec authenticated identities of the participants. This the IPsec authenticated identities of the participants. This
scenario enables the end-to-end security that has been a guiding scenario enables the end-to-end security that has been a guiding
principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a
method of limiting the inherent problems with complexity in networks method of limiting the inherent problems with complexity in networks
noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully
applicable to the IPv4 Internet, it has been deployed successfully in applicable to the IPv4 Internet, it has been deployed successfully in
specific scenarios within intranets using IKEv1. It should be more specific scenarios within intranets using IKEv1. It should be more
broadly enabled during the transition to IPv6 and with the adoption broadly enabled during the transition to IPv6 and with the adoption
of IKEv2. of IKEv2.
It is possible in this scenario that one or both of the protected It is possible in this scenario that one or both of the protected
endpoints will be behind a network address translation (NAT) node, in endpoints will be behind a network address translation (NAT) node, in
which case the tunneled packets will have to be UDP encapsulated so which case the tunneled packets will have to be UDP encapsulated so
that port numbers in the UDP headers can be used to identify that port numbers in the UDP headers can be used to identify
individual endpoints "behind" the NAT (see Section 2.23). individual endpoints "behind" the NAT (see Section 2.23).
1.1.3. Endpoint to Security Gateway Tunnel Mode 1.1.3. Endpoint to Security Gateway in Tunnel Mode
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | IPsec | | Protected | | IPsec | | Protected
|Protected| tunnel |Tunnel | Subnet |Protected| tunnel |Tunnel | Subnet
|Endpoint |<------------------------>|Endpoint |<--- and/or |Endpoint |<------------------------>|Endpoint |<--- and/or
| | | | Internet | | | | Internet
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Endpoint to Security Gateway Tunnel Figure 3: Endpoint to Security Gateway Tunnel
skipping to change at line 397 skipping to change at page 9, line 11
In this scenario, it is possible that the protected endpoint will be In this scenario, it is possible that the protected endpoint will be
behind a NAT. In that case, the IP address as seen by the security behind a NAT. In that case, the IP address as seen by the security
gateway will not be the same as the IP address sent by the protected gateway will not be the same as the IP address sent by the protected
endpoint, and packets will have to be UDP encapsulated in order to be endpoint, and packets will have to be UDP encapsulated in order to be
routed properly. Interaction with NATs is covered in detail in routed properly. Interaction with NATs is covered in detail in
Section 2.23. Section 2.23.
1.1.4. Other Scenarios 1.1.4. Other Scenarios
Other scenarios are possible, as are nested combinations of the Other scenarios are possible, as are nested combinations of the
above. One notable example combines aspects of 1.1.1 and 1.1.3. A above. One notable example combines aspects of Sections 1.1.1 and
subnet may make all external accesses through a remote security 1.1.3. A subnet may make all external accesses through a remote
gateway using an IPsec tunnel, where the addresses on the subnet are security gateway using an IPsec tunnel, where the addresses on the
routed to the security gateway by the rest of the Internet. An subnet are routed to the security gateway by the rest of the
example would be someone's home network being virtually on the Internet. An example would be someone's home network being virtually
Internet with static IP addresses even though connectivity is on the Internet with static IP addresses even though connectivity is
provided by an ISP that assigns a single dynamically assigned IP provided by an ISP that assigns a single dynamically assigned IP
address to the user's security gateway (where the static IP addresses address to the user's security gateway (where the static IP addresses
and an IPsec relay are provided by a third party located elsewhere). and an IPsec relay are provided by a third party located elsewhere).
1.2. The Initial Exchanges 1.2. The Initial Exchanges
Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
exchanges (known in IKEv1 as Phase 1). These initial exchanges exchanges (known in IKEv1 as Phase 1). These initial exchanges
normally consist of four messages, though in some scenarios that normally consist of four messages, though in some scenarios that
number can grow. All communications using IKE consist of request/ number can grow. All communications using IKE consist of request/
skipping to change at line 424 skipping to change at page 9, line 38
variations. The first pair of messages (IKE_SA_INIT) negotiate variations. The first pair of messages (IKE_SA_INIT) negotiate
cryptographic algorithms, exchange nonces, and do a Diffie-Hellman cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
exchange [DH]. exchange [DH].
The second pair of messages (IKE_AUTH) authenticate the previous The second pair of messages (IKE_AUTH) authenticate the previous
messages, exchange identities and certificates, and establish the messages, exchange identities and certificates, and establish the
first Child SA. Parts of these messages are encrypted and integrity first Child SA. Parts of these messages are encrypted and integrity
protected with keys established through the IKE_SA_INIT exchange, so protected with keys established through the IKE_SA_INIT exchange, so
the identities are hidden from eavesdroppers and all fields in all the identities are hidden from eavesdroppers and all fields in all
the messages are authenticated. See Section 2.14 for information on the messages are authenticated. See Section 2.14 for information on
how the encryption keys are generated. (A man-in-the-middle who how the encryption keys are generated. (A man-in-the-middle attacker
cannot complete the IKE_AUTH exchange can nonetheless see the who cannot complete the IKE_AUTH exchange can nonetheless see the
identity of the initiator.) identity of the initiator.)
All messages following the initial exchange are cryptographically All messages following the initial exchange are cryptographically
protected using the cryptographic algorithms and keys negotiated in protected using the cryptographic algorithms and keys negotiated in
the IKE_SA_INIT exchange. These subsequent messages use the syntax the IKE_SA_INIT exchange. These subsequent messages use the syntax
of the Encrypted Payload described in Section 3.14, encrypted with of the Encrypted payload described in Section 3.14, encrypted with
keys that are derived as described in Section 2.14. All subsequent keys that are derived as described in Section 2.14. All subsequent
messages include an Encrypted Payload, even if they are referred to messages include an Encrypted payload, even if they are referred to
in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or
INFORMATIONAL exchanges, the message following the header is INFORMATIONAL exchanges, the message following the header is
encrypted and the message including the header is integrity protected encrypted and the message including the header is integrity protected
using the cryptographic algorithms negotiated for the IKE SA. using the cryptographic algorithms negotiated for the IKE SA.
Every IKE message contains a Message ID as part of its fixed header. Every IKE message contains a Message ID as part of its fixed header.
This Message ID is used to match up requests and responses, and to This Message ID is used to match up requests and responses, and to
identify retransmissions of messages. identify retransmissions of messages.
In the following descriptions, the payloads contained in the message In the following descriptions, the payloads contained in the message
are indicated by names as listed below. are indicated by names as listed below.
Notation Payload Notation Payload
----------------------------------------- -----------------------------------------
AUTH Authentication AUTH Authentication
CERT Certificate CERT Certificate
CERTREQ Certificate Request CERTREQ Certificate Request
CP Configuration CP Configuration
D Delete D Delete
EAP Extensible Authentication EAP Extensible Authentication
HDR IKE Header (not a payload) HDR IKE header (not a payload)
IDi Identification - Initiator IDi Identification - Initiator
IDr Identification - Responder IDr Identification - Responder
KE Key Exchange KE Key Exchange
Ni, Nr Nonce Ni, Nr Nonce
N Notify N Notify
SA Security Association SA Security Association
SK Encrypted and Authenticated SK Encrypted and Authenticated
TSi Traffic Selector - Initiator TSi Traffic Selector - Initiator
TSr Traffic Selector - Responder TSr Traffic Selector - Responder
V Vendor ID V Vendor ID
The details of the contents of each payload are described in section The details of the contents of each payload are described in section
3. Payloads that may optionally appear will be shown in brackets, 3. Payloads that may optionally appear will be shown in brackets,
such as [CERTREQ]; this indicates that a certificate request payload such as [CERTREQ]; this indicates that a Certificate Request payload
can optionally be included. can optionally be included.
The initial exchanges are as follows: The initial exchanges are as follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
HDR contains the Security Parameter Indexes (SPIs), version numbers, HDR contains the Security Parameter Indexes (SPIs), version numbers,
and flags of various sorts. The SAi1 payload states the and flags of various sorts. The SAi1 payload states the
skipping to change at line 496 skipping to change at page 11, line 16
offered choices and expresses that choice in the SAr1 payload, offered choices and expresses that choice in the SAr1 payload,
completes the Diffie-Hellman exchange with the KEr payload, and sends completes the Diffie-Hellman exchange with the KEr payload, and sends
its nonce in the Nr payload. its nonce in the Nr payload.
At this point in the negotiation, each party can generate SKEYSEED, At this point in the negotiation, each party can generate SKEYSEED,
from which all keys are derived for that IKE SA. The messages that from which all keys are derived for that IKE SA. The messages that
follow are encrypted and integrity protected in their entirety, with follow are encrypted and integrity protected in their entirety, with
the exception of the message headers. The keys used for the the exception of the message headers. The keys used for the
encryption and integrity protection are derived from SKEYSEED and are encryption and integrity protection are derived from SKEYSEED and are
known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity
protection); see Section 2.13 and Section 2.14 for details on the key protection); see Sections 2.13 and 2.14 for details on the key
derivation. A separate SK_e and SK_a is computed for each direction. derivation. A separate SK_e and SK_a is computed for each direction.
In addition to the keys SK_e and SK_a derived from the Diffie-Hellman In addition to the keys SK_e and SK_a derived from the Diffie-Hellman
value for protection of the IKE SA, another quantity SK_d is derived value for protection of the IKE SA, another quantity SK_d is derived
and used for derivation of further keying material for Child SAs. and used for derivation of further keying material for Child SAs.
The notation SK { ... } indicates that these payloads are encrypted The notation SK { ... } indicates that these payloads are encrypted
and integrity protected using that direction's SK_e and SK_a. and integrity protected using that direction's SK_e and SK_a.
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, [IDr,] AUTH, SAi2,
TSi, TSr} --> TSi, TSr} -->
The initiator asserts its identity with the IDi payload, proves The initiator asserts its identity with the IDi payload, proves
knowledge of the secret corresponding to IDi and integrity protects knowledge of the secret corresponding to IDi and integrity protects
the contents of the first message using the AUTH payload (see the contents of the first message using the AUTH payload (see
Section 2.15). It might also send its certificate(s) in CERT Section 2.15). It might also send its certificate(s) in CERT
payload(s) and a list of its trust anchors in CERTREQ payload(s). If payload(s) and a list of its trust anchors in CERTREQ payload(s). If
any CERT payloads are included, the first certificate provided MUST any CERT payloads are included, the first certificate provided MUST
contain the public key used to verify the AUTH field. contain the public key used to verify the AUTH field.
The optional payload IDr enables the initiator to specify which of The optional payload IDr enables the initiator to specify to which of
the responder's identities it wants to talk to. This is useful when the responder's identities it wants to talk. This is useful when the
the machine on which the responder is running is hosting multiple machine on which the responder is running is hosting multiple
identities at the same IP address. If the IDr proposed by the identities at the same IP address. If the IDr proposed by the
initiator is not acceptable to the responder, the responder might use initiator is not acceptable to the responder, the responder might use
some other IDr to finish the exchange. If the initiator then does some other IDr to finish the exchange. If the initiator then does
not accept the fact that responder used an IDr different than the one not accept the fact that responder used an IDr different than the one
that was requested, the initiator can close the SA after noticing the that was requested, the initiator can close the SA after noticing the
fact. fact.
The traffic selectors (TSi and TSr) are discussed in Section 2.9. The Traffic Selectors (TSi and TSr) are discussed in Section 2.9.
The initiator begins negotiation of a Child SA using the SAi2 The initiator begins negotiation of a Child SA using the SAi2
payload. The final fields (starting with SAi2) are described in the payload. The final fields (starting with SAi2) are described in the
description of the CREATE_CHILD_SA exchange. description of the CREATE_CHILD_SA exchange.
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr} SAr2, TSi, TSr}
The responder asserts its identity with the IDr payload, optionally The responder asserts its identity with the IDr payload, optionally
sends one or more certificates (again with the certificate containing sends one or more certificates (again with the certificate containing
the public key used to verify AUTH listed first), authenticates its the public key used to verify AUTH listed first), authenticates its
identity and protects the integrity of the second message with the identity and protects the integrity of the second message with the
AUTH payload, and completes negotiation of a Child SA with the AUTH payload, and completes negotiation of a Child SA with the
additional fields described below in the CREATE_CHILD_SA exchange. additional fields described below in the CREATE_CHILD_SA exchange.
Both parties in the IKE_AUTH exchange MUST verify that all signatures Both parties in the IKE_AUTH exchange MUST verify that all signatures
and MACs are computed correctly. If either side uses a shared secret and Message Authentication Codes (MACs) are computed correctly. If
for authentication, the names in the ID payload MUST correspond to either side uses a shared secret for authentication, the names in the
the key used to generate the AUTH payload. ID payload MUST correspond to the key used to generate the AUTH
payload.
Because the initiator sends its Diffie-Hellman value in the Because the initiator sends its Diffie-Hellman value in the
IKE_SA_INIT, it must guess the Diffie-Hellman group that the IKE_SA_INIT, it must guess the Diffie-Hellman group that the
responder will select from its list of supported groups. If the responder will select from its list of supported groups. If the
initiator guesses wrong, the responder will respond with a Notify initiator guesses wrong, the responder will respond with a Notify
payload of type INVALID_KE_PAYLOAD indicating the selected group. In payload of type INVALID_KE_PAYLOAD indicating the selected group. In
this case, the initiator MUST retry the IKE_SA_INIT with the this case, the initiator MUST retry the IKE_SA_INIT with the
corrected Diffie-Hellman group. The initiator MUST again propose its corrected Diffie-Hellman group. The initiator MUST again propose its
full set of acceptable cryptographic suites because the rejection full set of acceptable cryptographic suites because the rejection
message was unauthenticated and otherwise an active attacker could message was unauthenticated and otherwise an active attacker could
skipping to change at line 579 skipping to change at page 13, line 7
encrypted and integrity protected, if the peer receiving this Notify encrypted and integrity protected, if the peer receiving this Notify
error message has not yet authenticated the other end (or if the peer error message has not yet authenticated the other end (or if the peer
fails to authenticate the other end for some reason), the information fails to authenticate the other end for some reason), the information
needs to be treated with caution. More precisely, assuming that the needs to be treated with caution. More precisely, assuming that the
MAC verifies correctly, the sender of the error Notify message is MAC verifies correctly, the sender of the error Notify message is
known to be the responder of the IKE_SA_INIT exchange, but the known to be the responder of the IKE_SA_INIT exchange, but the
sender's identity cannot be assured. sender's identity cannot be assured.
Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
Thus, the SA payloads in the IKE_AUTH exchange cannot contain Thus, the SA payloads in the IKE_AUTH exchange cannot contain
Transform Type 4 (Diffie-Hellman Group) with any value other than Transform Type 4 (Diffie-Hellman group) with any value other than
NONE. Implementations SHOULD omit the whole transform substructure NONE. Implementations SHOULD omit the whole transform substructure
instead of sending value NONE. instead of sending value NONE.
1.3. The CREATE_CHILD_SA Exchange 1.3. The CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange is used to create new Child SAs and to The CREATE_CHILD_SA exchange is used to create new Child SAs and to
rekey both IKE SAs and Child SAs. This exchange consists of a single rekey both IKE SAs and Child SAs. This exchange consists of a single
request/response pair, and some of its function was referred to as a request/response pair, and some of its function was referred to as a
phase 2 exchange in IKEv1. It MAY be initiated by either end of the Phase 2 exchange in IKEv1. It MAY be initiated by either end of the
IKE SA after the initial exchanges are completed. IKE SA after the initial exchanges are completed.
An SA is rekeyed by creating a new SA and then deleting the old one. An SA is rekeyed by creating a new SA and then deleting the old one.
This section describes the first part of rekeying, the creation of This section describes the first part of rekeying, the creation of
new SAs; Section 2.8 covers the mechanics of rekeying, including new SAs; Section 2.8 covers the mechanics of rekeying, including
moving traffic from old to new SAs and the deletion of the old SAs. moving traffic from old to new SAs and the deletion of the old SAs.
The two sections must be read together to understand the entire The two sections must be read together to understand the entire
process of rekeying. process of rekeying.
Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
skipping to change at line 619 skipping to change at page 13, line 47
in the CREATE_CHILD_SA exchange). in the CREATE_CHILD_SA exchange).
If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
the SA offers MUST include the Diffie-Hellman group of the KEi. The the SA offers MUST include the Diffie-Hellman group of the KEi. The
Diffie-Hellman group of the KEi MUST be an element of the group the Diffie-Hellman group of the KEi MUST be an element of the group the
initiator expects the responder to accept (additional Diffie-Hellman initiator expects the responder to accept (additional Diffie-Hellman
groups can be proposed). If the responder selects a proposal using a groups can be proposed). If the responder selects a proposal using a
different Diffie-Hellman group (other than NONE), the responder MUST different Diffie-Hellman group (other than NONE), the responder MUST
reject the request and indicate its preferred Diffie-Hellman group in reject the request and indicate its preferred Diffie-Hellman group in
the INVALID_KE_PAYLOAD Notify payload. There are two octets of data the INVALID_KE_PAYLOAD Notify payload. There are two octets of data
associated with this notification: the accepted Diffie-Hellman Group associated with this notification: the accepted Diffie-Hellman group
number in big endian order. In the case of such a rejection, the number in big endian order. In the case of such a rejection, the
CREATE_CHILD_SA exchange fails, and the initiator will probably retry CREATE_CHILD_SA exchange fails, and the initiator will probably retry
the exchange with a Diffie-Hellman proposal and KEi in the group that the exchange with a Diffie-Hellman proposal and KEi in the group that
the responder gave in the INVALID_KE_PAYLOAD Notify payload. the responder gave in the INVALID_KE_PAYLOAD Notify payload.
The responder sends a NO_ADDITIONAL_SAS notification to indicate that The responder sends a NO_ADDITIONAL_SAS notification to indicate that
a CREATE_CHILD_SA request is unacceptable because the responder is a CREATE_CHILD_SA request is unacceptable because the responder is
unwilling to accept any more Child SAs on this IKE SA. This unwilling to accept any more Child SAs on this IKE SA. This
notification can also be used to reject IKE SA rekey. Some minimal notification can also be used to reject IKE SA rekey. Some minimal
implementations may only accept a single Child SA setup in the implementations may only accept a single Child SA setup in the
skipping to change at line 645 skipping to change at page 14, line 25
A Child SA may be created by sending a CREATE_CHILD_SA request. The A Child SA may be created by sending a CREATE_CHILD_SA request. The
CREATE_CHILD_SA request for creating a new Child SA is: CREATE_CHILD_SA request for creating a new Child SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {SA, Ni, [KEi], HDR, SK {SA, Ni, [KEi],
TSi, TSr} --> TSi, TSr} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, optionally a Diffie-Hellman value in the KEi payload, and payload, optionally a Diffie-Hellman value in the KEi payload, and
the proposed traffic selectors for the proposed Child SA in the TSi the proposed Traffic Selectors for the proposed Child SA in the TSi
and TSr payloads. and TSr payloads.
The CREATE_CHILD_SA response for creating a new Child SA is: The CREATE_CHILD_SA response for creating a new Child SA is:
<-- HDR, SK {SA, Nr, [KEr], <-- HDR, SK {SA, Nr, [KEr],
TSi, TSr} TSi, TSr}
The responder replies (using the same Message ID to respond) with the The responder replies (using the same Message ID to respond) with the
accepted offer in an SA payload, and a Diffie-Hellman value in the accepted offer in an SA payload, and a Diffie-Hellman value in the
KEr payload if KEi was included in the request and the selected KEr payload if KEi was included in the request and the selected
cryptographic suite includes that group. cryptographic suite includes that group.
The traffic selectors for traffic to be sent on that SA are specified The Traffic Selectors for traffic to be sent on that SA are specified
in the TS payloads in the response, which may be a subset of what the in the TS payloads in the response, which may be a subset of what the
initiator of the Child SA proposed. initiator of the Child SA proposed.
The USE_TRANSPORT_MODE notification MAY be included in a request The USE_TRANSPORT_MODE notification MAY be included in a request
message that also includes an SA payload requesting a Child SA. It message that also includes an SA payload requesting a Child SA. It
requests that the Child SA use transport mode rather than tunnel mode requests that the Child SA use transport mode rather than tunnel mode
for the SA created. If the request is accepted, the response MUST for the SA created. If the request is accepted, the response MUST
also include a notification of type USE_TRANSPORT_MODE. If the also include a notification of type USE_TRANSPORT_MODE. If the
responder declines the request, the Child SA will be established in responder declines the request, the Child SA will be established in
tunnel mode. If this is unacceptable to the initiator, the initiator tunnel mode. If this is unacceptable to the initiator, the initiator
skipping to change at line 723 skipping to change at page 16, line 7
<-- HDR, SK {SA, Nr, KEr} <-- HDR, SK {SA, Nr, KEr}
The responder replies (using the same Message ID to respond) with the The responder replies (using the same Message ID to respond) with the
accepted offer in an SA payload, and a Diffie-Hellman value in the accepted offer in an SA payload, and a Diffie-Hellman value in the
KEr payload if the selected cryptographic suite includes that group. KEr payload if the selected cryptographic suite includes that group.
A new responder SPI is supplied in the SPI field of the SA payload. A new responder SPI is supplied in the SPI field of the SA payload.
The new IKE SA has its message counters set to 0, regardless of what The new IKE SA has its message counters set to 0, regardless of what
they were in the earlier IKE SA. The first IKE requests from both they were in the earlier IKE SA. The first IKE requests from both
sides on the new IKE SA will have message ID 0. The old IKE SA sides on the new IKE SA will have Message ID 0. The old IKE SA
retains its numbering, so any further requests (for example, to retains its numbering, so any further requests (for example, to
delete the IKE SA) will have consecutive numbering. The new IKE SA delete the IKE SA) will have consecutive numbering. The new IKE SA
also has its window size reset to 1, and the initiator in this rekey also has its window size reset to 1, and the initiator in this rekey
exchange is the new "original initiator" of the new IKE SA. exchange is the new "original initiator" of the new IKE SA.
Section 2.18 also covers IKE SA rekeying in detail. Section 2.18 also covers IKE SA rekeying in detail.
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying a Child SA is: The CREATE_CHILD_SA request for rekeying a Child SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {N(REKEY_SA), SA, Ni, [KEi], HDR, SK {N(REKEY_SA), SA, Ni, [KEi],
TSi, TSr} --> TSi, TSr} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, optionally a Diffie-Hellman value in the KEi payload, and payload, optionally a Diffie-Hellman value in the KEi payload, and
the proposed traffic selectors for the proposed Child SA in the TSi the proposed Traffic Selectors for the proposed Child SA in the TSi
and TSr payloads. and TSr payloads.
The notifications described in Section 1.3.1 may also be sent in a The notifications described in Section 1.3.1 may also be sent in a
rekeying exchange. Usually these will be the same notifications that rekeying exchange. Usually, these will be the same notifications
were used in the original exchange; for example, when rekeying a that were used in the original exchange; for example, when rekeying a
transport mode SA, the USE_TRANSPORT_MODE notification will be used. transport mode SA, the USE_TRANSPORT_MODE notification will be used.
The REKEY_SA notification MUST be included in a CREATE_CHILD_SA The REKEY_SA notification MUST be included in a CREATE_CHILD_SA
exchange if the purpose of the exchange is to replace an existing ESP exchange if the purpose of the exchange is to replace an existing ESP
or AH SA. The SA being rekeyed is identified by the SPI field in the or AH SA. The SA being rekeyed is identified by the SPI field in the
Notify payload; this is the SPI the exchange initiator would expect Notify payload; this is the SPI the exchange initiator would expect
in inbound ESP or AH packets. There is no data associated with this in inbound ESP or AH packets. There is no data associated with this
Notify message type. The Protocol ID field of the REKEY_SA Notify message type. The Protocol ID field of the REKEY_SA
notification is set to match the protocol of the SA we are rekeying, notification is set to match the protocol of the SA we are rekeying,
for example, 3 for ESP and 2 for AH. for example, 3 for ESP and 2 for AH.
skipping to change at line 769 skipping to change at page 17, line 5
The CREATE_CHILD_SA response for rekeying a Child SA is: The CREATE_CHILD_SA response for rekeying a Child SA is:
<-- HDR, SK {SA, Nr, [KEr], <-- HDR, SK {SA, Nr, [KEr],
TSi, TSr} TSi, TSr}
The responder replies (using the same Message ID to respond) with the The responder replies (using the same Message ID to respond) with the
accepted offer in an SA payload, and a Diffie-Hellman value in the accepted offer in an SA payload, and a Diffie-Hellman value in the
KEr payload if KEi was included in the request and the selected KEr payload if KEi was included in the request and the selected
cryptographic suite includes that group. cryptographic suite includes that group.
The traffic selectors for traffic to be sent on that SA are specified The Traffic Selectors for traffic to be sent on that SA are specified
in the TS payloads in the response, which may be a subset of what the in the TS payloads in the response, which may be a subset of what the
initiator of the Child SA proposed. initiator of the Child SA proposed.
1.4. The INFORMATIONAL Exchange 1.4. The INFORMATIONAL Exchange
At various points during the operation of an IKE SA, peers may desire At various points during the operation of an IKE SA, peers may desire
to convey control messages to each other regarding errors or to convey control messages to each other regarding errors or
notifications of certain events. To accomplish this, IKE defines an notifications of certain events. To accomplish this, IKE defines an
INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
after the initial exchanges and are cryptographically protected with after the initial exchanges and are cryptographically protected with
the negotiated keys. Note that some informational messages, not the negotiated keys. Note that some informational messages, not
exchanges, can be sent outside the context of an IKE SA. Section exchanges, can be sent outside the context of an IKE SA. Section
2.21 also covers error messages in great detail. 2.21 also covers error messages in great detail.
Control messages that pertain to an IKE SA MUST be sent under that Control messages that pertain to an IKE SA MUST be sent under that
IKE SA. Control messages that pertain to Child SAs MUST be sent IKE SA. Control messages that pertain to Child SAs MUST be sent
under the protection of the IKE SA which generated them (or its under the protection of the IKE SA that generated them (or its
successor if the IKE SA was rekeyed). successor if the IKE SA was rekeyed).
Messages in an INFORMATIONAL exchange contain zero or more Messages in an INFORMATIONAL exchange contain zero or more
Notification, Delete, and Configuration payloads. The recipient of Notification, Delete, and Configuration payloads. The recipient of
an INFORMATIONAL exchange request MUST send some response; otherwise, an INFORMATIONAL exchange request MUST send some response; otherwise,
the sender will assume the message was lost in the network and will the sender will assume the message was lost in the network and will
retransmit it. That response MAY be an empty message. The request retransmit it. That response MAY be an empty message. The request
message in an INFORMATIONAL exchange MAY also contain no payloads. message in an INFORMATIONAL exchange MAY also contain no payloads.
This is the expected way an endpoint can ask the other endpoint to This is the expected way an endpoint can ask the other endpoint to
verify that it is alive. verify that it is alive.
skipping to change at line 819 skipping to change at page 18, line 6
1.4.1. Deleting an SA with INFORMATIONAL Exchanges 1.4.1. Deleting an SA with INFORMATIONAL Exchanges
ESP and AH SAs always exist in pairs, with one SA in each direction. ESP and AH SAs always exist in pairs, with one SA in each direction.
When an SA is closed, both members of the pair MUST be closed (that When an SA is closed, both members of the pair MUST be closed (that
is, deleted). Each endpoint MUST close its incoming SAs and allow is, deleted). Each endpoint MUST close its incoming SAs and allow
the other endpoint to close the other SA in each pair. To delete an the other endpoint to close the other SA in each pair. To delete an
SA, an INFORMATIONAL exchange with one or more Delete payloads is SA, an INFORMATIONAL exchange with one or more Delete payloads is
sent listing the SPIs (as they would be expected in the headers of sent listing the SPIs (as they would be expected in the headers of
inbound packets) of the SAs to be deleted. The recipient MUST close inbound packets) of the SAs to be deleted. The recipient MUST close
the designated SAs. Note that one never sends delete payloads for the designated SAs. Note that one never sends Delete payloads for
the two sides of an SA in a single message. If there are many SAs to the two sides of an SA in a single message. If there are many SAs to
delete at the same time, one includes Delete payloads for the inbound delete at the same time, one includes Delete payloads for the inbound
half of each SA pair in the INFORMATIONAL exchange. half of each SA pair in the INFORMATIONAL exchange.
Normally, the response in the INFORMATIONAL exchange will contain Normally, the response in the INFORMATIONAL exchange will contain
delete payloads for the paired SAs going in the other direction. Delete payloads for the paired SAs going in the other direction.
There is one exception. If by chance both ends of a set of SAs There is one exception. If, by chance, both ends of a set of SAs
independently decide to close them, each may send a delete payload independently decide to close them, each may send a Delete payload
and the two requests may cross in the network. If a node receives a and the two requests may cross in the network. If a node receives a
delete request for SAs for which it has already issued a delete delete request for SAs for which it has already issued a delete
request, it MUST delete the outgoing SAs while processing the request request, it MUST delete the outgoing SAs while processing the request
and the incoming SAs while processing the response. In that case, and the incoming SAs while processing the response. In that case,
the responses MUST NOT include delete payloads for the deleted SAs, the responses MUST NOT include Delete payloads for the deleted SAs,
since that would result in duplicate deletion and could in theory since that would result in duplicate deletion and could in theory
delete the wrong SA. delete the wrong SA.
Similar to ESP and AH SAs, IKE SAs are also deleted by sending an Similar to ESP and AH SAs, IKE SAs are also deleted by sending an
Informational exchange. Deleting an IKE SA implicitly closes any Informational exchange. Deleting an IKE SA implicitly closes any
remaining Child SAs negotiated under it. The response to a request remaining Child SAs negotiated under it. The response to a request
that deletes the IKE SA is an empty INFORMATIONAL response. that deletes the IKE SA is an empty INFORMATIONAL response.
Half-closed ESP or AH connections are anomalous, and a node with Half-closed ESP or AH connections are anomalous, and a node with
auditing capability should probably audit their existence if they auditing capability should probably audit their existence if they
skipping to change at line 911 skipping to change at page 20, line 5
Definitions of the primitive terms in this document (such as Security Definitions of the primitive terms in this document (such as Security
Association or SA) can be found in [IPSECARCH]. It should be noted Association or SA) can be found in [IPSECARCH]. It should be noted
that parts of IKEv2 rely on some of the processing rules in that parts of IKEv2 rely on some of the processing rules in
[IPSECARCH], as described in various sections of this document. [IPSECARCH], as described in various sections of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD]. document are to be interpreted as described in [MUSTSHOULD].
1.7. Significant Differences Between RFC 4306 and This Document 1.7. Significant Differences between RFC 4306 and This Document
This document contains clarifications and amplifications to IKEv2 This document contains clarifications and amplifications to IKEv2
[IKEV2]. Many of the clarifications are based on [Clarif]. The [IKEV2]. Many of the clarifications are based on [Clarif]. The
changes listed in that document were discussed in the IPsec Working changes listed in that document were discussed in the IPsec Working
Group and, after the Working Group was disbanded, on the IPsec Group and, after the Working Group was disbanded, on the IPsec
mailing list. That document contains detailed explanations of areas mailing list. That document contains detailed explanations of areas
that were unclear in IKEv2, and is thus useful to implementers of that were unclear in IKEv2, and is thus useful to implementers of
IKEv2. IKEv2.
The protocol described in this document retains the same major The protocol described in this document retains the same major
skipping to change at line 962 skipping to change at page 21, line 8
forwarding tables. In IKEv2, each of these SAs has to be created forwarding tables. In IKEv2, each of these SAs has to be created
using a separate CREATE_CHILD_SA exchange. using a separate CREATE_CHILD_SA exchange.
This document removes discussion of the INTERNAL_ADDRESS_EXPIRY This document removes discussion of the INTERNAL_ADDRESS_EXPIRY
configuration attribute because its implementation was very configuration attribute because its implementation was very
problematic. Implementations that conform to this document MUST problematic. Implementations that conform to this document MUST
ignore proposals that have configuration attribute type 5, the old ignore proposals that have configuration attribute type 5, the old
value for INTERNAL_ADDRESS_EXPIRY. This document also removed value for INTERNAL_ADDRESS_EXPIRY. This document also removed
INTERNAL_IP6_NBNS as a configuration attribute. INTERNAL_IP6_NBNS as a configuration attribute.
This document removes the allowance for rejecting messages where the This document removes the allowance for rejecting messages in which
payloads were not in the "right" order; now implementations MUST NOT the payloads were not in the "right" order; now implementations MUST
reject them. This is due to the lack of clarity where the orders for NOT reject them. This is due to the lack of clarity where the orders
the payloads are described. for the payloads are described.
The lists of items from RFC 4306 that ended up in the IANA registry The lists of items from RFC 4306 that ended up in the IANA registry
were trimmed to only include items that were actually defined in RFC were trimmed to only include items that were actually defined in RFC
4306. Also, many of those lists are now preceded with the very 4306. Also, many of those lists are now preceded with the very
important instruction to developers that they really should look at important instruction to developers that they really should look at
the IANA registry at the time of development because new items have the IANA registry at the time of development because new items have
been added since RFC 4306. been added since RFC 4306.
This document adds clarification on when notifications are and are This document adds clarification on when notifications are and are
not sent encrypted, depending on the state of the negotiation at the not sent encrypted, depending on the state of the negotiation at the
time. time.
This document discusses more about how to negotiate combined-mode This document discusses more about how to negotiate combined-mode
ciphers. ciphers.
In section 1.3.2, changed "The KEi payload SHOULD be included" to be In Section 1.3.2, "The KEi payload SHOULD be included" was changed to
"The KEi payload MUST be included". This also led to changes in be "The KEi payload MUST be included". This also led to changes in
section 2.18. Section 2.18.
In Section 2.1, there is new material covering how the initiator's In Section 2.1, there is new material covering how the initiator's
SPI and/or IP is used to differentiate if this is a "half-open" IKE SPI and/or IP is used to differentiate if this is a "half-open" IKE
SA or a new request. SA or a new request.
This document clarifies the use of the critical flag in Section 2.5. This document clarifies the use of the critical flag in Section 2.5.
In 2.8, changed "Note that, when rekeying, the new Child SA MAY have In Section 2.8, "Note that, when rekeying, the new Child SA MAY have
different traffic selectors and algorithms than the old one" to "Note different Traffic Selectors and algorithms than the old one" was
that, when rekeying, the new Child SA SHOULD NOT have different changed to "Note that, when rekeying, the new Child SA SHOULD NOT
traffic selectors and algorithms than the old one". have different Traffic Selectors and algorithms than the old one".
The new Section 2.8.2 covers simultaneous IKE SA rekeying. The new Section 2.8.2 covers simultaneous IKE SA rekeying.
The new Section 2.9.2 covers traffic selectors in rekeying. The new Section 2.9.2 covers Traffic Selectors in rekeying.
This document adds the restriction in Section 2.13 that all pseudo- This document adds the restriction in Section 2.13 that all
random functions (PRFs) used with IKEv2 MUST take variable-sized pseudorandom functions (PRFs) used with IKEv2 MUST take variable-
keys. This should not affect any implementations because there were sized keys. This should not affect any implementations because there
no standardized PRFs that have fixed-size keys. were no standardized PRFs that have fixed-size keys.
Section 2.18 requires doing a Diffie-Hellman exchange when rekeying Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie-
Hellman exchange was optional, but this was not useful (or Hellman exchange was optional, but this was not useful (or
appropriate) when rekeying the IKE_SA. appropriate) when rekeying the IKE_SA.
Section 2.21 has been greatly expanded to cover the different cases Section 2.21 has been greatly expanded to cover the different cases
where error responses are needed and the appropriate responses to where error responses are needed and the appropriate responses to
them. them.
Section 2.23 clarified that, in NAT traversal, now both UDP Section 2.23 clarified that, in NAT traversal, now both UDP-
encapsulated IPsec packets and non-UDP encapsulated IPsec packets encapsulated IPsec packets and non-UDP-encapsulated IPsec packets
packets need to be understood when receiving. need to be understood when receiving.
Added Section 2.23.1 to describe NAT traversal when transport mode is Added Section 2.23.1 to describe NAT traversal when transport mode is
requested. requested.
Added Section 2.25 to explain how to act when there are timing Added Section 2.25 to explain how to act when there are timing
collisions when deleting and/or rekeying SAs, and two new error collisions when deleting and/or rekeying SAs, and two new error
notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were
defined. defined.
In Section 3.6, added "Implementations MUST support the HTTP method In Section 3.6, "Implementations MUST support the HTTP method for
for hash-and-URL lookup. The behavior of other URL methods is not hash-and-URL lookup. The behavior of other URL methods is not
currently specified, and such methods SHOULD NOT be used in the currently specified, and such methods SHOULD NOT be used in the
absence of a document specifying them." absence of a document specifying them" was added.
In Section 3.15.3, added a pointer to a new document that is related In Section 3.15.3, a pointer to a new document that is related to
to configuration of IPv6 addresses. configuration of IPv6 addresses was added.
Appendix C was expanded and clarified. Appendix C was expanded and clarified.
2. IKE Protocol Details and Variations 2. IKE Protocol Details and Variations
IKE normally listens and sends on UDP port 500, though IKE messages IKE normally listens and sends on UDP port 500, though IKE messages
may also be received on UDP port 4500 with a slightly different may also be received on UDP port 4500 with a slightly different
format (see Section 2.23). Since UDP is a datagram (unreliable) format (see Section 2.23). Since UDP is a datagram (unreliable)
protocol, IKE includes in its definition recovery from transmission protocol, IKE includes in its definition recovery from transmission
errors, including packet loss, packet replay, and packet forgery. errors, including packet loss, packet replay, and packet forgery.
skipping to change at line 1056 skipping to change at page 23, line 7
as to exhaust the network or CPU capacities of either endpoint. Even as to exhaust the network or CPU capacities of either endpoint. Even
in the absence of those minimum performance requirements, IKE is in the absence of those minimum performance requirements, IKE is
designed to fail cleanly (as though the network were broken). designed to fail cleanly (as though the network were broken).
Although IKEv2 messages are intended to be short, they contain Although IKEv2 messages are intended to be short, they contain
structures with no hard upper bound on size (in particular, digital structures with no hard upper bound on size (in particular, digital
certificates), and IKEv2 itself does not have a mechanism for certificates), and IKEv2 itself does not have a mechanism for
fragmenting large messages. IP defines a mechanism for fragmentation fragmenting large messages. IP defines a mechanism for fragmentation
of oversized UDP messages, but implementations vary in the maximum of oversized UDP messages, but implementations vary in the maximum
message size supported. Furthermore, use of IP fragmentation opens message size supported. Furthermore, use of IP fragmentation opens
an implementation to denial of service (DoS) attacks [DOSUDPPROT]. an implementation to denial-of-service (DoS) attacks [DOSUDPPROT].
Finally, some NAT and/or firewall implementations may block IP Finally, some NAT and/or firewall implementations may block IP
fragments. fragments.
All IKEv2 implementations MUST be able to send, receive, and process All IKEv2 implementations MUST be able to send, receive, and process
IKE messages that are up to 1280 octets long, and they SHOULD be able IKE messages that are up to 1280 octets long, and they SHOULD be able
to send, receive, and process messages that are up to 3000 octets to send, receive, and process messages that are up to 3000 octets
long. IKEv2 implementations need to be aware of the maximum UDP long. IKEv2 implementations need to be aware of the maximum UDP
message size supported and MAY shorten messages by leaving out some message size supported and MAY shorten messages by leaving out some
certificates or cryptographic suite proposals if that will keep certificates or cryptographic suite proposals if that will keep
messages below the maximum. Use of the "Hash and URL" formats rather messages below the maximum. Use of the "Hash and URL" formats rather
skipping to change at line 1081 skipping to change at page 23, line 32
technique from working. technique from working.
The UDP payload of all packets containing IKE messages sent on port The UDP payload of all packets containing IKE messages sent on port
4500 MUST begin with the prefix of four zeros; otherwise, the 4500 MUST begin with the prefix of four zeros; otherwise, the
receiver won't know how to handle them. receiver won't know how to handle them.
2.1. Use of Retransmission Timers 2.1. Use of Retransmission Timers
All messages in IKE exist in pairs: a request and a response. The All messages in IKE exist in pairs: a request and a response. The
setup of an IKE SA normally consists of two exchanges. Once the IKE setup of an IKE SA normally consists of two exchanges. Once the IKE
SA is set up, either end of the security association may initiate SA is set up, either end of the Security Association may initiate
requests at any time, and there can be many requests and responses requests at any time, and there can be many requests and responses
"in flight" at any given moment. But each message is labeled as "in flight" at any given moment. But each message is labeled as
either a request or a response, and for each exchange, one end of the either a request or a response, and for each exchange, one end of the
security association is the initiator and the other is the responder. Security Association is the initiator and the other is the responder.
For every pair of IKE messages, the initiator is responsible for For every pair of IKE messages, the initiator is responsible for
retransmission in the event of a timeout. The responder MUST never retransmission in the event of a timeout. The responder MUST never
retransmit a response unless it receives a retransmission of the retransmit a response unless it receives a retransmission of the
request. In that event, the responder MUST ignore the retransmitted request. In that event, the responder MUST ignore the retransmitted
request except insofar as it causes a retransmission of the response. request except insofar as it causes a retransmission of the response.
The initiator MUST remember each request until it receives the The initiator MUST remember each request until it receives the
corresponding response. The responder MUST remember each response corresponding response. The responder MUST remember each response
until it receives a request whose sequence number is larger than or until it receives a request whose sequence number is larger than or
equal to the sequence number in the response plus its window size equal to the sequence number in the response plus its window size
(see Section 2.3). In order to allow saving memory, responders are (see Section 2.3). In order to allow saving memory, responders are
allowed to forget the response after a timeout of several minutes. allowed to forget the response after a timeout of several minutes.
If the responder receives a retransmitted request for which it has If the responder receives a retransmitted request for which it has
already forgotten the response, it MUST ignore the request (and not, already forgotten the response, it MUST ignore the request (and not,
for example, attempt constructing a new response). for example, attempt constructing a new response).
IKE is a reliable protocol: the initiator MUST retransmit a request IKE is a reliable protocol: the initiator MUST retransmit a request
until either it receives a corresponding response, or until it deems until it either receives a corresponding response or deems the IKE SA
the IKE SA to have failed. In the latter case, the initiator to have failed. In the latter case, the initiator discards all state
discards all state associated with the IKE SA and any Child SAs that associated with the IKE SA and any Child SAs that were negotiated
were negotiated using that IKE SA. A retransmission from the using that IKE SA. A retransmission from the initiator MUST be
initiator MUST be bitwise identical to the original request. That bitwise identical to the original request. That is, everything
is, everything starting from the IKE Header (the IKE SA initiator's starting from the IKE header (the IKE SA initiator's SPI onwards)
SPI onwards) must be bitwise identical; items before it (such as the must be bitwise identical; items before it (such as the IP and UDP
IP and UDP headers) do not have to be identical. headers) do not have to be identical.
Retransmissions of the IKE_SA_INIT request require some special Retransmissions of the IKE_SA_INIT request require some special
handling. When a responder receives an IKE_SA_INIT request, it has handling. When a responder receives an IKE_SA_INIT request, it has
to determine whether the packet is a retransmission belonging to an to determine whether the packet is a retransmission belonging to an
existing "half-open" IKE SA (in which case the responder retransmits existing "half-open" IKE SA (in which case the responder retransmits
the same response), or a new request (in which case the responder the same response), or a new request (in which case the responder
creates a new IKE SA and sends a fresh response), or it belongs to an creates a new IKE SA and sends a fresh response), or it belongs to an
existing IKE SA where the IKE_AUTH request has been already received existing IKE SA where the IKE_AUTH request has been already received
(in which case the responder ignores it). (in which case the responder ignores it).
skipping to change at line 1138 skipping to change at page 24, line 41
from that for regular messages. Because no acknowledgement is ever from that for regular messages. Because no acknowledgement is ever
sent, there is no reason to gratuitously retransmit one-way messages. sent, there is no reason to gratuitously retransmit one-way messages.
Given that all these messages are errors, it makes sense to send them Given that all these messages are errors, it makes sense to send them
only once per "offending" packet, and only retransmit if further only once per "offending" packet, and only retransmit if further
offending packets are received. Still, it also makes sense to limit offending packets are received. Still, it also makes sense to limit
retransmissions of such error messages. retransmissions of such error messages.
2.2. Use of Sequence Numbers for Message ID 2.2. Use of Sequence Numbers for Message ID
Every IKE message contains a Message ID as part of its fixed header. Every IKE message contains a Message ID as part of its fixed header.
This Message ID is used to match up requests and responses, and to This Message ID is used to match up requests and responses and to
identify retransmissions of messages. Retransmission of a message identify retransmissions of messages. Retransmission of a message
MUST use the same Message ID as the original message. MUST use the same Message ID as the original message.
The Message ID is a 32-bit quantity, which is zero for the The Message ID is a 32-bit quantity, which is zero for the
IKE_SA_INIT messages (including retries of the message due to IKE_SA_INIT messages (including retries of the message due to
responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for
each subsequent exchange. Thus, the first pair of IKE_AUTH messages each subsequent exchange. Thus, the first pair of IKE_AUTH messages
will have ID of 1, the second (when EAP is used) will be 2, and so will have an ID of 1, the second (when EAP is used) will be 2, and so
on. The Message ID is reset to zero in the new IKE SA after the IKE on. The Message ID is reset to zero in the new IKE SA after the IKE
SA is rekeyed. SA is rekeyed.
Each endpoint in the IKE Security Association maintains two "current" Each endpoint in the IKE Security Association maintains two "current"
Message IDs: the next one to be used for a request it initiates and Message IDs: the next one to be used for a request it initiates and
the next one it expects to see in a request from the other end. the next one it expects to see in a request from the other end.
These counters increment as requests are generated and received. These counters increment as requests are generated and received.
Responses always contain the same message ID as the corresponding Responses always contain the same Message ID as the corresponding
request. That means that after the initial exchange, each integer n request. That means that after the initial exchange, each integer n
may appear as the message ID in four distinct messages: the nth may appear as the Message ID in four distinct messages: the nth
request from the original IKE initiator, the corresponding response, request from the original IKE initiator, the corresponding response,
the nth request from the original IKE responder, and the the nth request from the original IKE responder, and the
corresponding response. If the two ends make very different numbers corresponding response. If the two ends make a very different number
of requests, the Message IDs in the two directions can be very of requests, the Message IDs in the two directions can be very
different. There is no ambiguity in the messages, however, because different. There is no ambiguity in the messages, however, because
the Initiator and Response flags in the message header specify which the Initiator and Response flags in the message header specify which
of the four messages a particular one is. of the four messages a particular one is.
Throughout this document, "initiator" refers to the party who Throughout this document, "initiator" refers to the party who
initiated the exchange being described. The "original initiator" initiated the exchange being described. The "original initiator"
always refers to the party who initiated the exchange which resulted always refers to the party who initiated the exchange that resulted
in the current IKE SA. In other words, if the "original responder" in the current IKE SA. In other words, if the "original responder"
starts rekeying the IKE SA, that party becomes the "original starts rekeying the IKE SA, that party becomes the "original
initiator" of the new IKE SA. initiator" of the new IKE SA.
Note that Message IDs are cryptographically protected and provide Note that Message IDs are cryptographically protected and provide
protection against message replays. In the unlikely event that protection against message replays. In the unlikely event that
Message IDs grow too large to fit in 32 bits, the IKE SA MUST be Message IDs grow too large to fit in 32 bits, the IKE SA MUST be
closed or rekeyed. closed or rekeyed.
2.3. Window Size for Overlapping Requests 2.3. Window Size for Overlapping Requests
skipping to change at line 1219 skipping to change at page 26, line 25
able to regenerate exactly) the number of previous responses equal to able to regenerate exactly) the number of previous responses equal to
its declared window size in case its response was lost and the its declared window size in case its response was lost and the
initiator requests its retransmission by retransmitting the request. initiator requests its retransmission by retransmitting the request.
An IKE endpoint supporting a window size greater than one ought to be An IKE endpoint supporting a window size greater than one ought to be
capable of processing incoming requests out of order to maximize capable of processing incoming requests out of order to maximize
performance in the event of network failures or packet reordering. performance in the event of network failures or packet reordering.
The window size is normally a (possibly configurable) property of a The window size is normally a (possibly configurable) property of a
particular implementation, and is not related to congestion control particular implementation, and is not related to congestion control
(unlike the window size in TCP, for example). In particular, it is (unlike the window size in TCP, for example). In particular, what
not defined what the responder should do when it receives a the responder should do when it receives a SET_WINDOW_SIZE
SET_WINDOW_SIZE notification containing a smaller value than is notification containing a smaller value than is currently in effect
currently in effect. Thus, there is currently no way to reduce the is not defined. Thus, there is currently no way to reduce the window
window size of an existing IKE SA; you can only increase it. When size of an existing IKE SA; you can only increase it. When rekeying
rekeying an IKE SA, the new IKE SA starts with window size 1 until it an IKE SA, the new IKE SA starts with window size 1 until it is
is explicitly increased by sending a new SET_WINDOW_SIZE explicitly increased by sending a new SET_WINDOW_SIZE notification.
notification.
The INVALID_MESSAGE_ID notification is sent when an IKE message ID The INVALID_MESSAGE_ID notification is sent when an IKE Message ID
outside the supported window is received. This Notify message MUST outside the supported window is received. This Notify message MUST
NOT be sent in a response; the invalid request MUST NOT be NOT be sent in a response; the invalid request MUST NOT be
acknowledged. Instead, inform the other side by initiating an acknowledged. Instead, inform the other side by initiating an
INFORMATIONAL exchange with Notification data containing the four INFORMATIONAL exchange with Notification data containing the four-
octet invalid message ID. Sending this notification is OPTIONAL, and octet invalid Message ID. Sending this notification is OPTIONAL, and
notifications of this type MUST be rate limited. notifications of this type MUST be rate limited.
2.4. State Synchronization and Connection Timeouts 2.4. State Synchronization and Connection Timeouts
An IKE endpoint is allowed to forget all of its state associated with An IKE endpoint is allowed to forget all of its state associated with
an IKE SA and the collection of corresponding Child SAs at any time. an IKE SA and the collection of corresponding Child SAs at any time.
This is the anticipated behavior in the event of an endpoint crash This is the anticipated behavior in the event of an endpoint crash
and restart. It is important when an endpoint either fails or and restart. It is important when an endpoint either fails or
reinitializes its state that the other endpoint detect those reinitializes its state that the other endpoint detect those
conditions and not continue to waste network bandwidth by sending conditions and not continue to waste network bandwidth by sending
skipping to change at line 1275 skipping to change at page 27, line 34
contact it have gone unanswered for a timeout period or when a contact it have gone unanswered for a timeout period or when a
cryptographically protected INITIAL_CONTACT notification is received cryptographically protected INITIAL_CONTACT notification is received
on a different IKE SA to the same authenticated identity. An on a different IKE SA to the same authenticated identity. An
endpoint should suspect that the other endpoint has failed based on endpoint should suspect that the other endpoint has failed based on
routing information and initiate a request to see whether the other routing information and initiate a request to see whether the other
endpoint is alive. To check whether the other side is alive, IKE endpoint is alive. To check whether the other side is alive, IKE
specifies an empty INFORMATIONAL message that (like all IKE requests) specifies an empty INFORMATIONAL message that (like all IKE requests)
requires an acknowledgement (note that within the context of an IKE requires an acknowledgement (note that within the context of an IKE
SA, an "empty" message consists of an IKE header followed by an SA, an "empty" message consists of an IKE header followed by an
Encrypted payload that contains no payloads). If a cryptographically Encrypted payload that contains no payloads). If a cryptographically
protected (fresh, i.e. not retransmitted) message has been received protected (fresh, i.e., not retransmitted) message has been received
from the other side recently, unprotected Notify messages MAY be from the other side recently, unprotected Notify messages MAY be
ignored. Implementations MUST limit the rate at which they take ignored. Implementations MUST limit the rate at which they take
actions based on unprotected messages. actions based on unprotected messages.
Numbers of retries and lengths of timeouts are not covered in this The number of retries and length of timeouts are not covered in this
specification because they do not affect interoperability. It is specification because they do not affect interoperability. It is
suggested that messages be retransmitted at least a dozen times over suggested that messages be retransmitted at least a dozen times over
a period of at least several minutes before giving up on an SA, but a period of at least several minutes before giving up on an SA, but
different environments may require different rules. To be a good different environments may require different rules. To be a good
network citizen, retransmission times MUST increase exponentially to network citizen, retransmission times MUST increase exponentially to
avoid flooding the network and making an existing congestion avoid flooding the network and making an existing congestion
situation worse. If there has only been outgoing traffic on all of situation worse. If there has only been outgoing traffic on all of
the SAs associated with an IKE SA, it is essential to confirm the SAs associated with an IKE SA, it is essential to confirm
liveness of the other endpoint to avoid black holes. If no liveness of the other endpoint to avoid black holes. If no
cryptographically protected messages have been received on an IKE SA cryptographically protected messages have been received on an IKE SA
or any of its Child SAs recently, the system needs to perform a or any of its Child SAs recently, the system needs to perform a
liveness check in order to prevent sending messages to a dead peer. liveness check in order to prevent sending messages to a dead peer.
(This is sometimes called "dead peer detection" or "DPD", although it (This is sometimes called "dead peer detection" or "DPD", although it
is really detecting live peers, not dead ones.) Receipt of a fresh is really detecting live peers, not dead ones.) Receipt of a fresh
cryptographically protected message on an IKE SA or any of its Child cryptographically protected message on an IKE SA or any of its Child
SAs ensures liveness of the IKE SA and all of its Child SAs. Note SAs ensures liveness of the IKE SA and all of its Child SAs. Note
that this places requirements on the failure modes of an IKE that this places requirements on the failure modes of an IKE
endpoint. An implementation needs to stop sending on any SA if some endpoint. An implementation needs to stop sending over any SA if
failure prevents it from receiving on all of the associated SAs. If some failure prevents it from receiving on all of the associated SAs.
a system creates Child SAs that can fail independently from one If a system creates Child SAs that can fail independently from one
another without the associated IKE SA being able to send a delete another without the associated IKE SA being able to send a delete
message, then the system MUST negotiate such Child SAs using separate message, then the system MUST negotiate such Child SAs using separate
IKE SAs. IKE SAs.
There is a DoS attack on the initiator of an IKE SA that can be There is a DoS attack on the initiator of an IKE SA that can be
avoided if the initiator takes the proper care. Since the first two avoided if the initiator takes the proper care. Since the first two
messages of an SA setup are not cryptographically protected, an messages of an SA setup are not cryptographically protected, an
attacker could respond to the initiator's message before the genuine attacker could respond to the initiator's message before the genuine
responder and poison the connection setup attempt. To prevent this, responder and poison the connection setup attempt. To prevent this,
the initiator MAY be willing to accept multiple responses to its the initiator MAY be willing to accept multiple responses to its
skipping to change at line 1382 skipping to change at page 29, line 47
sending error messages) negotiate to version n, then both will notice sending error messages) negotiate to version n, then both will notice
that the other side can support a higher version number, and they that the other side can support a higher version number, and they
MUST break the connection and reconnect using version n+1. MUST break the connection and reconnect using version n+1.
Note that IKEv1 does not follow these rules, because there is no way Note that IKEv1 does not follow these rules, because there is no way
in v1 of noting that you are capable of speaking a higher version in v1 of noting that you are capable of speaking a higher version
number. So an active attacker can trick two v2-capable nodes into number. So an active attacker can trick two v2-capable nodes into
speaking v1. When a v2-capable node negotiates down to v1, it should speaking v1. When a v2-capable node negotiates down to v1, it should
note that fact in its logs. note that fact in its logs.
Also for forward compatibility, all fields marked RESERVED MUST be Also, for forward compatibility, all fields marked RESERVED MUST be
set to zero by an implementation running version 2.0, and their set to zero by an implementation running version 2.0, and their
content MUST be ignored by an implementation running version 2.0 ("Be content MUST be ignored by an implementation running version 2.0 ("Be
conservative in what you send and liberal in what you receive"). In conservative in what you send and liberal in what you receive" [IP]).
this way, future versions of the protocol can use those fields in a In this way, future versions of the protocol can use those fields in
way that is guaranteed to be ignored by implementations that do not a way that is guaranteed to be ignored by implementations that do not
understand them. Similarly, payload types that are not defined are understand them. Similarly, payload types that are not defined are
reserved for future use; implementations of a version where they are reserved for future use; implementations of a version where they are
undefined MUST skip over those payloads and ignore their contents. undefined MUST skip over those payloads and ignore their contents.
IKEv2 adds a "critical" flag to each payload header for further IKEv2 adds a "critical" flag to each payload header for further
flexibility for forward compatibility. If the critical flag is set flexibility for forward compatibility. If the critical flag is set
and the payload type is unrecognized, the message MUST be rejected and the payload type is unrecognized, the message MUST be rejected
and the response to the IKE request containing that payload MUST and the response to the IKE request containing that payload MUST
include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
unsupported critical payload was included. In that Notify payload, unsupported critical payload was included. In that Notify payload,
the notification data contains the one-octet payload type. If the the notification data contains the one-octet payload type. If the
critical flag is not set and the payload type is unsupported, that critical flag is not set and the payload type is unsupported, that
payload MUST be ignored. Payloads sent in IKE response messages MUST payload MUST be ignored. Payloads sent in IKE response messages MUST
NOT have the critical flag set. Note that the critical flag applies NOT have the critical flag set. Note that the critical flag applies
only to the payload type, not the contents. If the payload type is only to the payload type, not the contents. If the payload type is
recognized, but the payload contains something which is not (such as recognized, but the payload contains something that is not (such as
an unknown transform inside an SA payload, or an unknown Notify an unknown transform inside an SA payload, or an unknown Notify
Message Type inside a Notify payload), the critical flag is ignored. Message Type inside a Notify payload), the critical flag is ignored.
Although new payload types may be added in the future and may appear Although new payload types may be added in the future and may appear
interleaved with the fields defined in this specification, interleaved with the fields defined in this specification,
implementations SHOULD send the payloads defined in this implementations SHOULD send the payloads defined in this
specification in the order shown in the figures in Sections 1 and 2; specification in the order shown in the figures in Sections 1 and 2;
implementations MUST NOT reject as invalid a message with those implementations MUST NOT reject as invalid a message with those
payloads in any other order. payloads in any other order.
skipping to change at line 1445 skipping to change at page 31, line 16
not know the responder's SPI value and will therefore set that field not know the responder's SPI value and will therefore set that field
to zero. When the IKE_SA_INIT exchange does not result in the to zero. When the IKE_SA_INIT exchange does not result in the
creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN,
or COOKIE (see Section 2.6), the responder's SPI will be zero also in or COOKIE (see Section 2.6), the responder's SPI will be zero also in
the response message. However, if the responder sends a non-zero the response message. However, if the responder sends a non-zero
responder SPI, the initiator should not reject the response for only responder SPI, the initiator should not reject the response for only
that reason. that reason.
Two expected attacks against IKE are state and CPU exhaustion, where Two expected attacks against IKE are state and CPU exhaustion, where
the target is flooded with session initiation requests from forged IP the target is flooded with session initiation requests from forged IP
addresses. These attack can be made less effective if a responder addresses. These attacks can be made less effective if a responder
uses minimal CPU and commits no state to an SA until it knows the uses minimal CPU and commits no state to an SA until it knows the
initiator can receive packets at the address from which it claims to initiator can receive packets at the address from which it claims to
be sending them. be sending them.
When a responder detects a large number of half-open IKE SAs, it When a responder detects a large number of half-open IKE SAs, it
SHOULD reply to IKE_SA_INIT requests with a response containing the SHOULD reply to IKE_SA_INIT requests with a response containing the
COOKIE notification. The data associated with this notification MUST COOKIE notification. The data associated with this notification MUST
be between 1 and 64 octets in length (inclusive), and its generation be between 1 and 64 octets in length (inclusive), and its generation
is described later in this section. If the IKE_SA_INIT response is described later in this section. If the IKE_SA_INIT response
includes the COOKIE notification, the initiator MUST then retry the includes the COOKIE notification, the initiator MUST then retry the
skipping to change at line 1509 skipping to change at page 32, line 33
generated since the last change to <secret> and that IPi must be the generated since the last change to <secret> and that IPi must be the
same as the source address it saw the first time. Incorporating SPIi same as the source address it saw the first time. Incorporating SPIi
into the calculation ensures that if multiple IKE SAs are being set into the calculation ensures that if multiple IKE SAs are being set
up in parallel they will all get different cookies (assuming the up in parallel they will all get different cookies (assuming the
initiator chooses unique SPIi's). Incorporating Ni in the hash initiator chooses unique SPIi's). Incorporating Ni in the hash
ensures that an attacker who sees only message 2 can't successfully ensures that an attacker who sees only message 2 can't successfully
forge a message 3. Also, incorporating SPIi in the hash prevents an forge a message 3. Also, incorporating SPIi in the hash prevents an
attacker from fetching one cookie from the other end, and then attacker from fetching one cookie from the other end, and then
initiating many IKE_SA_INIT exchanges all with different initiator initiating many IKE_SA_INIT exchanges all with different initiator
SPIs (and perhaps port numbers) so that the responder thinks that SPIs (and perhaps port numbers) so that the responder thinks that
there are lots of machines behind one NAT box who are all trying to there are a lot of machines behind one NAT box that are all trying to
connect. connect.
If a new value for <secret> is chosen while there are connections in If a new value for <secret> is chosen while there are connections in
the process of being initialized, an IKE_SA_INIT might be returned the process of being initialized, an IKE_SA_INIT might be returned
with other than the current <VersionIDofSecret>. The responder in with other than the current <VersionIDofSecret>. The responder in
that case MAY reject the message by sending another response with a that case MAY reject the message by sending another response with a
new cookie or it MAY keep the old value of <secret> around for a new cookie or it MAY keep the old value of <secret> around for a
short time and accept cookies computed from either one. The short time and accept cookies computed from either one. The
responder should not accept cookies indefinitely after <secret> is responder should not accept cookies indefinitely after <secret> is
changed, since that would defeat part of the DoS protection. The changed, since that would defeat part of the DoS protection. The
skipping to change at line 1555 skipping to change at page 33, line 30
There are two common reasons why the initiator may have to retry the There are two common reasons why the initiator may have to retry the
IKE_SA_INIT exchange: the responder requests a cookie or wants a IKE_SA_INIT exchange: the responder requests a cookie or wants a
different Diffie-Hellman group than was included in the KEi payload. different Diffie-Hellman group than was included in the KEi payload.
If the initiator receives a cookie from the responder, the initiator If the initiator receives a cookie from the responder, the initiator
needs to decide whether or not to include the cookie in only the next needs to decide whether or not to include the cookie in only the next
retry of the IKE_SA_INIT request, or in all subsequent retries as retry of the IKE_SA_INIT request, or in all subsequent retries as
well. well.
If the initiator includes the cookie only in the next retry, one If the initiator includes the cookie only in the next retry, one
additional roundtrip may be needed in some cases. An additional additional round trip may be needed in some cases. An additional
roundtrip is needed also if the initiator includes the cookie in all round trip is needed also if the initiator includes the cookie in all
retries, but the responder does not support this. For instance, if retries, but the responder does not support this. For instance, if
the responder includes the KEi payloads in cookie calculation, it the responder includes the KEi payloads in cookie calculation, it
will reject the request by sending a new cookie. will reject the request by sending a new cookie.
If both peers support including the cookie in all retries, a slightly If both peers support including the cookie in all retries, a slightly
shorter exchange can happen. shorter exchange can happen.
Initiator Responder Initiator Responder
----------------------------------------------------------- -----------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni --> HDR(A,0), SAi1, KEi, Ni -->
skipping to change at line 1586 skipping to change at page 34, line 15
2.7. Cryptographic Algorithm Negotiation 2.7. Cryptographic Algorithm Negotiation
The payload type known as "SA" indicates a proposal for a set of The payload type known as "SA" indicates a proposal for a set of
choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as
cryptographic algorithms associated with each protocol. cryptographic algorithms associated with each protocol.
An SA payload consists of one or more proposals. Each proposal An SA payload consists of one or more proposals. Each proposal
includes one protocol. Each protocol contains one or more transforms includes one protocol. Each protocol contains one or more transforms
-- each specifying a cryptographic algorithm. Each transform -- each specifying a cryptographic algorithm. Each transform
contains zero or more attributes (attributes are needed only if the contains zero or more attributes (attributes are needed only if the
transform identifier does not completely specify the cryptographic Transform ID does not completely specify the cryptographic
algorithm). algorithm).
This hierarchical structure was designed to efficiently encode This hierarchical structure was designed to efficiently encode
proposals for cryptographic suites when the number of supported proposals for cryptographic suites when the number of supported
suites is large because multiple values are acceptable for multiple suites is large because multiple values are acceptable for multiple
transforms. The responder MUST choose a single suite, which may be transforms. The responder MUST choose a single suite, which may be
any subset of the SA proposal following the rules below: any subset of the SA proposal following the rules below.
Each proposal contains one protocol. If a proposal is accepted, the Each proposal contains one protocol. If a proposal is accepted, the
SA response MUST contain the same protocol. The responder MUST SA response MUST contain the same protocol. The responder MUST
accept a single proposal or reject them all and return an error. The accept a single proposal or reject them all and return an error. The
error is given in a notification of type NO_PROPOSAL_CHOSEN. error is given in a notification of type NO_PROPOSAL_CHOSEN.
Each IPsec protocol proposal contains one or more transforms. Each Each IPsec protocol proposal contains one or more transforms. Each
transform contains a transform type. The accepted cryptographic transform contains a Transform Type. The accepted cryptographic
suite MUST contain exactly one transform of each type included in the suite MUST contain exactly one transform of each type included in the
proposal. For example: if an ESP proposal includes transforms proposal. For example: if an ESP proposal includes transforms
ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six
combinations are acceptable. combinations are acceptable.
If an initiator proposes both normal ciphers with integrity If an initiator proposes both normal ciphers with integrity
protection as well as combined-mode ciphers, then two proposals are protection as well as combined-mode ciphers, then two proposals are
needed. One of the proposals includes the normal ciphers with the needed. One of the proposals includes the normal ciphers with the
integrity algoritms for them, and the other proposal includes all the integrity algorithms for them, and the other proposal includes all
combined mode ciphers without the integrity algorithms (because the combined-mode ciphers without the integrity algorithms (because
combined mode ciphers are not allowed to have any integrity algorithm combined-mode ciphers are not allowed to have any integrity algorithm
other than "none"). other than "none").
2.8. Rekeying 2.8. Rekeying
IKE, ESP, and AH security associations use secret keys that should be IKE, ESP, and AH Security Associations use secret keys that should be
used only for a limited amount of time and to protect a limited used only for a limited amount of time and to protect a limited
amount of data. This limits the lifetime of the entire security amount of data. This limits the lifetime of the entire Security
association. When the lifetime of a security association expires, Association. When the lifetime of a Security Association expires,
the security association MUST NOT be used. If there is demand, new the Security Association MUST NOT be used. If there is demand, new
security associations MAY be established. Reestablishment of Security Associations MAY be established. Reestablishment of
security associations to take the place of ones that expire is Security Associations to take the place of ones that expire is
referred to as "rekeying". referred to as "rekeying".
To allow for minimal IPsec implementations, the ability to rekey SAs To allow for minimal IPsec implementations, the ability to rekey SAs
without restarting the entire IKE SA is optional. An implementation without restarting the entire IKE SA is optional. An implementation
MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA
has expired or is about to expire and rekeying attempts using the has expired or is about to expire and rekeying attempts using the
mechanisms described here fail, an implementation MUST close the IKE mechanisms described here fail, an implementation MUST close the IKE
SA and any associated Child SAs and then MAY start new ones. SA and any associated Child SAs and then MAY start new ones.
Implementations may wish to support in-place rekeying of SAs, since Implementations may wish to support in-place rekeying of SAs, since
doing so offers better performance and is likely to reduce the number doing so offers better performance and is likely to reduce the number
of packets lost during the transition. of packets lost during the transition.
To rekey a Child SA within an existing IKE SA, create a new, To rekey a Child SA within an existing IKE SA, create a new,
equivalent SA (see Section 2.17 below), and when the new one is equivalent SA (see Section 2.17 below), and when the new one is
established, delete the old one. Note that, when rekeying, the new established, delete the old one. Note that, when rekeying, the new
Child SA SHOULD NOT have different traffic selectors and algorithms Child SA SHOULD NOT have different Traffic Selectors and algorithms
than the old one. than the old one.
To rekey an IKE SA, establish a new equivalent IKE SA (see To rekey an IKE SA, establish a new equivalent IKE SA (see
Section 2.18 below) with the peer to whom the old IKE SA is shared Section 2.18 below) with the peer to whom the old IKE SA is shared
using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so
created inherits all of the original IKE SA's Child SAs, and the new created inherits all of the original IKE SA's Child SAs, and the new
IKE SA is used for all control messages needed to maintain those IKE SA is used for all control messages needed to maintain those
Child SAs. After the new equivalent IKE SA is created, the initiator Child SAs. After the new equivalent IKE SA is created, the initiator
deletes the old IKE SA, and the Delete payload to delete itself MUST deletes the old IKE SA, and the Delete payload to delete itself MUST
be the last request sent over the old IKE SA. be the last request sent over the old IKE SA.
skipping to change at line 1671 skipping to change at page 36, line 6
enforcing its own lifetime policy on the SA and rekeying the SA when enforcing its own lifetime policy on the SA and rekeying the SA when
necessary. If the two ends have different lifetime policies, the end necessary. If the two ends have different lifetime policies, the end
with the shorter lifetime will end up always being the one to request with the shorter lifetime will end up always being the one to request
the rekeying. If an SA has been inactive for a long time and if an the rekeying. If an SA has been inactive for a long time and if an
endpoint would not initiate the SA in the absence of traffic, the endpoint would not initiate the SA in the absence of traffic, the
endpoint MAY choose to close the SA instead of rekeying it when its endpoint MAY choose to close the SA instead of rekeying it when its
lifetime expires. It can also do so if there has been no traffic lifetime expires. It can also do so if there has been no traffic
since the last time the SA was rekeyed. since the last time the SA was rekeyed.
Note that IKEv2 deliberately allows parallel SAs with the same Note that IKEv2 deliberately allows parallel SAs with the same
traffic selectors between common endpoints. One of the purposes of Traffic Selectors between common endpoints. One of the purposes of
this is to support traffic quality of service (QoS) differences among this is to support traffic quality of service (QoS) differences among
the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of
[DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints
and the traffic selectors may not uniquely identify an SA between and the Traffic Selectors may not uniquely identify an SA between
those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
the basis of duplicate traffic selectors SHOULD NOT be used. the basis of duplicate Traffic Selectors SHOULD NOT be used.
There are timing windows -- particularly in the presence of lost There are timing windows -- particularly in the presence of lost
packets -- where endpoints may not agree on the state of an SA. The packets -- where endpoints may not agree on the state of an SA. The
responder to a CREATE_CHILD_SA MUST be prepared to accept messages on responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
an SA before sending its response to the creation request, so there an SA before sending its response to the creation request, so there
is no ambiguity for the initiator. The initiator MAY begin sending is no ambiguity for the initiator. The initiator MAY begin sending
on an SA as soon as it processes the response. The initiator, on an SA as soon as it processes the response. The initiator,
however, cannot receive on a newly created SA until it receives and however, cannot receive on a newly created SA until it receives and
processes the response to its CREATE_CHILD_SA request. How, then, is processes the response to its CREATE_CHILD_SA request. How, then, is
the responder to know when it is OK to send on the newly created SA? the responder to know when it is OK to send on the newly created SA?
skipping to change at line 1710 skipping to change at page 36, line 45
continues to send traffic on the old SA until one of those events continues to send traffic on the old SA until one of those events
occurs. When establishing a new SA, the responder MAY defer sending occurs. When establishing a new SA, the responder MAY defer sending
messages on a new SA until either it receives one or a timeout has messages on a new SA until either it receives one or a timeout has
occurred. If an initiator receives a message on an SA for which it occurred. If an initiator receives a message on an SA for which it
has not received a response to its CREATE_CHILD_SA request, it has not received a response to its CREATE_CHILD_SA request, it
interprets that as a likely packet loss and retransmits the interprets that as a likely packet loss and retransmits the
CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message
on a newly created ESP SA if it has no messages queued in order to on a newly created ESP SA if it has no messages queued in order to
assure the responder that the initiator is ready to receive messages. assure the responder that the initiator is ready to receive messages.
2.8.1. Simultaneous Child SA rekeying 2.8.1. Simultaneous Child SA Rekeying
If the two ends have the same lifetime policies, it is possible that If the two ends have the same lifetime policies, it is possible that
both will initiate a rekeying at the same time (which will result in both will initiate a rekeying at the same time (which will result in
redundant SAs). To reduce the probability of this happening, the redundant SAs). To reduce the probability of this happening, the
timing of rekeying requests SHOULD be jittered (delayed by a random timing of rekeying requests SHOULD be jittered (delayed by a random
amount of time after the need for rekeying is noticed). amount of time after the need for rekeying is noticed).
This form of rekeying may temporarily result in multiple similar SAs This form of rekeying may temporarily result in multiple similar SAs
between the same pairs of nodes. When there are two SAs eligible to between the same pairs of nodes. When there are two SAs eligible to
receive packets, a node MUST accept incoming packets through either receive packets, a node MUST accept incoming packets through either
skipping to change at line 1744 skipping to change at page 37, line 31
time: time:
Host A Host B Host A Host B
------------------------------------------------------------------- -------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1), send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. --> SA(..,SPIa2,..),Ni1,.. -->
<-- send req2: N(REKEY_SA,SPIb1), <-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2 SA(..,SPIb2,..),Ni2
recv req2 <-- recv req2 <--
At this point, A knows there is a simultaneous rekeying going on. At this point, A knows there is a simultaneous rekeying happening.
However, it cannot yet know which of the exchanges will have the However, it cannot yet know which of the exchanges will have the
lowest nonce, so it will just note the situation and respond as lowest nonce, so it will just note the situation and respond as
usual. usual.
send resp2: SA(..,SPIa3,..), send resp2: SA(..,SPIa3,..),
Nr1,.. --> Nr1,.. -->
--> recv req1 --> recv req1
Now B also knows that simultaneous rekeying is going on. It responds Now B also knows that simultaneous rekeying is going on. It responds
as usual. as usual.
skipping to change at line 1826 skipping to change at page 39, line 16
Probably the most complex case occurs when both peers try to rekey Probably the most complex case occurs when both peers try to rekey
the IKE_SA at the same time. Basically, the text in Section 2.8 the IKE_SA at the same time. Basically, the text in Section 2.8
applies to this case as well; however, it is important to ensure that applies to this case as well; however, it is important to ensure that
the Child SAs are inherited by the correct IKE_SA. the Child SAs are inherited by the correct IKE_SA.
The case where both endpoints notice the simultaneous rekeying works The case where both endpoints notice the simultaneous rekeying works
the same way as with Child SAs. After the CREATE_CHILD_SA exchanges, the same way as with Child SAs. After the CREATE_CHILD_SA exchanges,
three IKE SAs exist between A and B: the old IKE SA and two new IKE three IKE SAs exist between A and B: the old IKE SA and two new IKE
SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by
the node that created it, and the other suriving new IKE SA MUST the node that created it, and the other surviving new IKE SA MUST
inherit all the Child SAs. inherit all the Child SAs.
In addition to normal simultaneous rekeying cases, there is a special In addition to normal simultaneous rekeying cases, there is a special
case where one peer finishes its rekey before it even notices that case where one peer finishes its rekey before it even notices that
other peer is doing a rekey. If only one peer detects a simultaneous other peer is doing a rekey. If only one peer detects a simultaneous
rekey, redundant SAs are not created. In this case, when the peer rekey, redundant SAs are not created. In this case, when the peer
that did not notice the simultaneous rekey gets the request to rekey that did not notice the simultaneous rekey gets the request to rekey
the IKE SA that it has already successfully rekeyed, it SHOULD return the IKE SA that it has already successfully rekeyed, it SHOULD return
TEMPORARY_FAILURE because it is an IKE SA that it is currently trying TEMPORARY_FAILURE because it is an IKE SA that it is currently trying
to close (whether or not it has already sent the delete notification to close (whether or not it has already sent the delete notification
skipping to change at line 1863 skipping to change at page 40, line 4
At this point, host B sees a request to close the IKE_SA. There's At this point, host B sees a request to close the IKE_SA. There's
not much more to do than to reply as usual. However, at this point not much more to do than to reply as usual. However, at this point
host B should stop retransmitting req2, since once host A receives host B should stop retransmitting req2, since once host A receives
resp3, it will delete all the state associated with the old IKE_SA resp3, it will delete all the state associated with the old IKE_SA
and will not be able to reply to it. and will not be able to reply to it.
<-- send resp3: () <-- send resp3: ()
The TEMPORARY_FAILURE notification was not included in RFC 4306, and The TEMPORARY_FAILURE notification was not included in RFC 4306, and
support of the TEMPORARY_FAILURE notification is not negotiated. support of the TEMPORARY_FAILURE notification is not negotiated.
Thus, older peers that implement RFC 4306 but not this document may Thus, older peers that implement RFC 4306 but not this document may
receive these notifications. In that case, they will treat it the receive these notifications. In that case, they will treat it the
same as any other unknown error notification, and will stop the same as any other unknown error notification, and will stop the
exchange. Because the other peer has already rekeyed the exchange, exchange. Because the other peer has already rekeyed the exchange,
doing so does not have any ill effects. doing so does not have any ill effects.
2.8.3. Rekeying the IKE SA Versus Reauthentication 2.8.3. Rekeying the IKE SA versus Reauthentication
Rekeying the IKE SA and reauthentication are different concepts in Rekeying the IKE SA and reauthentication are different concepts in
IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and
resets the Message ID counters, but it does not authenticate the resets the Message ID counters, but it does not authenticate the
parties again (no AUTH or EAP payloads are involved). parties again (no AUTH or EAP payloads are involved).
Although rekeying the IKE SA may be important in some environments, Although rekeying the IKE SA may be important in some environments,
reauthentication (the verification that the parties still have access reauthentication (the verification that the parties still have access
to the long-term credentials) is often more important. to the long-term credentials) is often more important.
IKEv2 does not have any special support for reauthentication. IKEv2 does not have any special support for reauthentication.
Reauthentication is done by creating a new IKE SA from scratch (using Reauthentication is done by creating a new IKE SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify
payloads), creating new Child SAs within the new IKE SA (without payloads), creating new Child SAs within the new IKE SA (without
REKEY_SA Notify payloads), and finally deleting the old IKE SA (which REKEY_SA Notify payloads), and finally deleting the old IKE SA (which
deletes the old Child SAs as well). deletes the old Child SAs as well).
This means that reauthentication also establishes new keys for the This means that reauthentication also establishes new keys for the
IKE SA and Child SAs. Therefore, while rekeying can be performed IKE SA and Child SAs. Therefore, while rekeying can be performed
more often than reauthentication, the situation where "authentication more often than reauthentication, the situation where "authentication
lifetime" is shorter than "key lifetime" does not make sense. lifetime" is shorter than "key lifetime" does not make sense.
While creation of a new IKE SA can be initiated by either party While creation of a new IKE SA can be initiated by either party
(initiator or responder in the original IKE SA), the use of EAP (initiator or responder in the original IKE SA), the use of EAP
authentication and/or configuration payloads means in practice that and/or Configuration payloads means in practice that reauthentication
reauthentication has to be initiated by the same party as the has to be initiated by the same party as the original IKE SA. IKEv2
original IKE SA. IKEv2 does not currently allow the responder to does not currently allow the responder to request reauthentication in
request reauthentication in this case; however, there are extensions this case; however, there are extensions that add this functionality
that add this functionality such as [REAUTH]. such as [REAUTH].
2.9. Traffic Selector Negotiation 2.9. Traffic Selector Negotiation
When an RFC4301-compliant IPsec subsystem receives an IP packet that When an RFC4301-compliant IPsec subsystem receives an IP packet that
matches a "protect" selector in its Security Policy Database (SPD), matches a "protect" selector in its Security Policy Database (SPD),
the subsystem protects that packet with IPsec. When no SA exists the subsystem protects that packet with IPsec. When no SA exists
yet, it is the task of IKE to create it. Maintenance of a system's yet, it is the task of IKE to create it. Maintenance of a system's
SPD is outside the scope of IKE, although some implementations might SPD is outside the scope of IKE, although some implementations might
update their SPD in connection with the running of IKE (for an update their SPD in connection with the running of IKE (for an
example scenario, see Section 1.1.3). example scenario, see Section 1.1.3).
skipping to change at line 1921 skipping to change at page 41, line 16
the information from their SPD to their peers. These must be the information from their SPD to their peers. These must be
communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY] communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY]
uses the SADB_ACQUIRE message). TS payloads specify the selection uses the SADB_ACQUIRE message). TS payloads specify the selection
criteria for packets that will be forwarded over the newly set up SA. criteria for packets that will be forwarded over the newly set up SA.
This can serve as a consistency check in some scenarios to assure This can serve as a consistency check in some scenarios to assure
that the SPDs are consistent. In others, it guides the dynamic that the SPDs are consistent. In others, it guides the dynamic
update of the SPD. update of the SPD.
Two TS payloads appear in each of the messages in the exchange that Two TS payloads appear in each of the messages in the exchange that
creates a Child SA pair. Each TS payload contains one or more creates a Child SA pair. Each TS payload contains one or more
Traffic Selectors. Each traffic selector consists of an address Traffic Selectors. Each Traffic Selector consists of an address
range (IPv4 or IPv6), a port range, and an IP protocol ID. range (IPv4 or IPv6), a port range, and an IP protocol ID.
The first of the two TS payloads is known as TSi (Traffic Selector- The first of the two TS payloads is known as TSi (Traffic Selector-
initiator). The second is known as TSr (Traffic Selector-responder). initiator). The second is known as TSr (Traffic Selector-responder).
TSi specifies the source address of traffic forwarded from (or the TSi specifies the source address of traffic forwarded from (or the
destination address of traffic forwarded to) the initiator of the destination address of traffic forwarded to) the initiator of the
Child SA pair. TSr specifies the destination address of the traffic Child SA pair. TSr specifies the destination address of the traffic
forwarded to (or the source address of the traffic forwarded from) forwarded to (or the source address of the traffic forwarded from)
the responder of the Child SA pair. For example, if the original the responder of the Child SA pair. For example, if the original
initiator requests the creation of a Child SA pair, and wishes to initiator requests the creation of a Child SA pair, and wishes to
tunnel all traffic from subnet 198.51.100.* on the initiator's side tunnel all traffic from subnet 198.51.100.* on the initiator's side
to subnet 192.0.2.* on the responder's side, the initiator would to subnet 192.0.2.* on the responder's side, the initiator would
include a single traffic selector in each TS payload. TSi would include a single Traffic Selector in each TS payload. TSi would
specify the address range (198.51.100.0 - 198.51.100.255) and TSr specify the address range (198.51.100.0 - 198.51.100.255) and TSr
would specify the address range (192.0.2.0 - 192.0.2.255). Assuming would specify the address range (192.0.2.0 - 192.0.2.255). Assuming
that proposal was acceptable to the responder, it would send that proposal was acceptable to the responder, it would send
identical TS payloads back. identical TS payloads back.
IKEv2 allows the responder to choose a subset of the traffic proposed IKEv2 allows the responder to choose a subset of the traffic proposed
by the initiator. This could happen when the configurations of the by the initiator. This could happen when the configurations of the
two endpoints are being updated but only one end has received the new two endpoints are being updated but only one end has received the new
information. Since the two endpoints may be configured by different information. Since the two endpoints may be configured by different
people, the incompatibility may persist for an extended period even people, the incompatibility may persist for an extended period even
in the absence of errors. It also allows for intentionally different in the absence of errors. It also allows for intentionally different
configurations, as when one end is configured to tunnel all addresses configurations, as when one end is configured to tunnel all addresses
and depends on the other end to have the up-to-date list. and depends on the other end to have the up-to-date list.
When the responder chooses a subset of the traffic proposed by the When the responder chooses a subset of the traffic proposed by the
initiator, it narrows the traffic selectors to some subset of the initiator, it narrows the Traffic Selectors to some subset of the
initiator's proposal (provided the set does not become the null set). initiator's proposal (provided the set does not become the null set).
If the type of traffic selector proposed is unknown, the responder If the type of Traffic Selector proposed is unknown, the responder
ignores that traffic selector, so that the unknown type is not ignores that Traffic Selector, so that the unknown type is not
returned in the narrowed set. returned in the narrowed set.
To enable the responder to choose the appropriate range in this case, To enable the responder to choose the appropriate range in this case,
if the initiator has requested the SA due to a data packet, the if the initiator has requested the SA due to a data packet, the
initiator SHOULD include as the first traffic selector in each of TSi initiator SHOULD include as the first Traffic Selector in each of TSi
and TSr a very specific traffic selector including the addresses in and TSr a very specific Traffic Selector including the addresses in
the packet triggering the request. In the example, the initiator the packet triggering the request. In the example, the initiator
would include in TSi two traffic selectors: the first containing the would include in TSi two Traffic Selectors: the first containing the
address range (198.51.100.43 - 198.51.100.43) and the source port and address range (198.51.100.43 - 198.51.100.43) and the source port and
IP protocol from the packet and the second containing (198.51.100.0 - IP protocol from the packet and the second containing (198.51.100.0 -
198.51.100.255) with all ports and IP protocols. The initiator would 198.51.100.255) with all ports and IP protocols. The initiator would
similarly include two traffic selectors in TSr. If the initiator similarly include two Traffic Selectors in TSr. If the initiator
creates the Child SA pair not in response to an arriving packet, but creates the Child SA pair not in response to an arriving packet, but
rather, say, upon startup, then there may be no specific addresses rather, say, upon startup, then there may be no specific addresses
the initiator prefers for the initial tunnel over any other. In that the initiator prefers for the initial tunnel over any other. In that
case, the first values in TSi and TSr can be ranges rather than case, the first values in TSi and TSr can be ranges rather than
specific values. specific values.
The responder performs the narrowing as follows: The responder performs the narrowing as follows:
o If the responder's policy does not allow it to accept any part of o If the responder's policy does not allow it to accept any part of
the proposed traffic selectors, it responds with a TS_UNACCEPTABLE the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE
Notify message. Notify message.
o If the responder's policy allows the entire set of traffic covered o If the responder's policy allows the entire set of traffic covered
by TSi and TSr, no narrowing is necessary, and the responder can by TSi and TSr, no narrowing is necessary, and the responder can
return the same TSi and TSr values. return the same TSi and TSr values.
o If the responder's policy allows it to accept the first selector o If the responder's policy allows it to accept the first selector
of TSi and TSr, then the responder MUST narrow the traffic of TSi and TSr, then the responder MUST narrow the Traffic
selectors to a subset that includes the initiator's first choices. Selectors to a subset that includes the initiator's first choices.
In this example above, the responder might respond with TSi being In this example above, the responder might respond with TSi being
(198.51.100.43 - 198.51.100.43) with all ports and IP protocols. (198.51.100.43 - 198.51.100.43) with all ports and IP protocols.
o If the responder's policy does not allow it to accept the first o If the responder's policy does not allow it to accept the first
selector of TSi and TSr, the responder narrows to an acceptable selector of TSi and TSr, the responder narrows to an acceptable
subset of TSi and TSr. subset of TSi and TSr.
When narrowing is done, there may be several subsets that are When narrowing is done, there may be several subsets that are
acceptable but their union is not. In this case, the responder acceptable but their union is not. In this case, the responder
arbitrarily chooses one of them, and MAY include an arbitrarily chooses one of them, and MAY include an
ADDITIONAL_TS_POSSIBLE notification in the response. The ADDITIONAL_TS_POSSIBLE notification in the response. The
ADDITIONAL_TS_POSSIBLE notification asserts that the responder ADDITIONAL_TS_POSSIBLE notification asserts that the responder
narrowed the proposed traffic selectors but that other traffic narrowed the proposed Traffic Selectors but that other Traffic
selectors would also have been acceptable, though only in a separate Selectors would also have been acceptable, though only in a separate
SA. There is no data associated with this Notify type. This case SA. There is no data associated with this Notify type. This case
will occur only when the initiator and responder are configured will occur only when the initiator and responder are configured
differently from one another. If the initiator and responder agree differently from one another. If the initiator and responder agree
on the granularity of tunnels, the initiator will never request a on the granularity of tunnels, the initiator will never request a
tunnel wider than the responder will accept. tunnel wider than the responder will accept.
It is possible for the responder's policy to contain multiple smaller It is possible for the responder's policy to contain multiple smaller
ranges, all encompassed by the initiator's traffic selector, and with ranges, all encompassed by the initiator's Traffic Selector, and with
the responder's policy being that each of those ranges should be sent the responder's policy being that each of those ranges should be sent
over a different SA. Continuing the example above, the responder over a different SA. Continuing the example above, the responder
might have a policy of being willing to tunnel those addresses to and might have a policy of being willing to tunnel those addresses to and
from the initiator, but might require that each address pair be on a from the initiator, but might require that each address pair be on a
separately negotiated Child SA. If the initiator didn't generate its separately negotiated Child SA. If the initiator didn't generate its
request based on the packet, but (for example) upon startup, there request based on the packet, but (for example) upon startup, there
would not be the very specific first traffic selectors helping the would not be the very specific first Traffic Selectors helping the
responder to select the correct range. There would be no way for the responder to select the correct range. There would be no way for the
responder to determine which pair of addresses should be included in responder to determine which pair of addresses should be included in
this tunnel, and it would have to make a guess or reject the request this tunnel, and it would have to make a guess or reject the request
with a SINGLE_PAIR_REQUIRED Notify message. with a SINGLE_PAIR_REQUIRED Notify message.
The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA
request is unacceptable because its sender is only willing to accept request is unacceptable because its sender is only willing to accept
traffic selectors specifying a single pair of addresses. The Traffic Selectors specifying a single pair of addresses. The
requestor is expected to respond by requesting an SA for only the requestor is expected to respond by requesting an SA for only the
specific traffic it is trying to forward. specific traffic it is trying to forward.
Few implementations will have policies that require separate SAs for Few implementations will have policies that require separate SAs for
each address pair. Because of this, if only some parts of the TSi each address pair. Because of this, if only some parts of the TSi
and TSr proposed by the initiator are acceptable to the responder, and TSr proposed by the initiator are acceptable to the responder,
responders SHOULD narrow the selectors to an acceptable subset rather responders SHOULD narrow the selectors to an acceptable subset rather
than use SINGLE_PAIR_REQUIRED. than use SINGLE_PAIR_REQUIRED.
2.9.1. Traffic Selectors Violating Own Policy 2.9.1. Traffic Selectors Violating Own Policy
When creating a new SA, the initiator needs to avoid proposing When creating a new SA, the initiator needs to avoid proposing
traffic selectors that violate its own policy. If this rule is not Traffic Selectors that violate its own policy. If this rule is not
followed, valid traffic may be dropped. If you use decorrelated followed, valid traffic may be dropped. If you use decorrelated
policies from [IPSECARCH], this kind of policy violations cannot policies from [IPSECARCH], this kind of policy violations cannot
happen. happen.
This is best illustrated by an example. Suppose that host A has a This is best illustrated by an example. Suppose that host A has a
policy whose effect is that traffic to 198.51.100.66 is sent via host policy whose effect is that traffic to 198.51.100.66 is sent via host
B encrypted using AES, and traffic to all other hosts in B encrypted using AES, and traffic to all other hosts in
198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also
that host B accepts any combination of AES and 3DES. that host B accepts any combination of AES and 3DES.
If host A now proposes an SA that uses 3DES, and includes TSr If host A now proposes an SA that uses 3DES, and includes TSr
containing (198.51.100.0-198.51.100.255), this will be accepted by containing (198.51.100.0-198.51.100.255), this will be accepted by
host B. Now, host B can also use this SA to send traffic from host B. Now, host B can also use this SA to send traffic from
198.51.100.66, but those packets will be dropped by A since it 198.51.100.66, but those packets will be dropped by A since it
requires the use of AES for this traffic. Even if host A creates a requires the use of AES for this traffic. Even if host A creates a
new SA only for 198.51.100.66 that uses AES, host B may freely new SA only for 198.51.100.66 that uses AES, host B may freely
continue to use the first SA for the traffic. In this situation, continue to use the first SA for the traffic. In this situation,
when proposing the SA, host A should have followed its own policy, when proposing the SA, host A should have followed its own policy,
and included a TSr containing ((198.51.100.0- and included a TSr containing ((198.51.100.0-
198.51.100.65),(198.51.100.67-198.51.100.255)) instead. 198.51.100.65),(198.51.100.67-198.51.100.255)) instead.
In general, if (1) the initiator makes a proposal "for traffic X In general, if (1) the initiator makes a proposal "for traffic X
(TSi/TSr), do SA", and (2) for some subset X' of X, the initiator (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
skipping to change at line 2069 skipping to change at page 44, line 21
would be willing to accept traffic X' with some SA' (!=SA), valid would be willing to accept traffic X' with some SA' (!=SA), valid
traffic can be unnecessarily dropped since the responder can apply traffic can be unnecessarily dropped since the responder can apply
either SA or SA' to traffic X'. either SA or SA' to traffic X'.
2.10. Nonces 2.10. Nonces
The IKE_SA_INIT messages each contain a nonce. These nonces are used The IKE_SA_INIT messages each contain a nonce. These nonces are used
as inputs to cryptographic functions. The CREATE_CHILD_SA request as inputs to cryptographic functions. The CREATE_CHILD_SA request
and the CREATE_CHILD_SA response also contain nonces. These nonces and the CREATE_CHILD_SA response also contain nonces. These nonces
are used to add freshness to the key derivation technique used to are used to add freshness to the key derivation technique used to
obtain keys for Child SA, and to ensure creation of strong pseudo- obtain keys for Child SA, and to ensure creation of strong
random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2
be randomly chosen, MUST be at least 128 bits in size, and MUST be at MUST be randomly chosen, MUST be at least 128 bits in size, and MUST
least half the key size of the negotiated pseudo-random function be at least half the key size of the negotiated pseudorandom function
(PRF). However, the initiator chooses the nonce before the outcome (PRF). However, the initiator chooses the nonce before the outcome
of the negotiation is known. Because of that, the nonce has to be of the negotiation is known. Because of that, the nonce has to be
long enough for all the PRFs being proposed. If the same random long enough for all the PRFs being proposed. If the same random
number source is used for both keys and nonces, care must be taken to number source is used for both keys and nonces, care must be taken to
ensure that the latter use does not compromise the former. ensure that the latter use does not compromise the former.
2.11. Address and Port Agility 2.11. Address and Port Agility
IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
AH associations for the same IP addresses it runs over. The IP AH associations for the same IP addresses over which it runs. The IP
addresses and ports in the outer header are, however, not themselves addresses and ports in the outer header are, however, not themselves
cryptographically protected, and IKE is designed to work even through cryptographically protected, and IKE is designed to work even through
Network Address Translation (NAT) boxes. An implementation MUST Network Address Translation (NAT) boxes. An implementation MUST
accept incoming requests even if the source port is not 500 or 4500, accept incoming requests even if the source port is not 500 or 4500,
and MUST respond to the address and port from which the request was and MUST respond to the address and port from which the request was
received. It MUST specify the address and port at which the request received. It MUST specify the address and port at which the request
was received as the source address and port in the response. IKE was received as the source address and port in the response. IKE
functions identically over IPv4 or IPv6. functions identically over IPv4 or IPv6.
2.12. Reuse of Diffie-Hellman Exponentials 2.12. Reuse of Diffie-Hellman Exponentials
skipping to change at line 2133 skipping to change at page 45, line 38
An implementation that reuses exponentials MAY choose to remember the An implementation that reuses exponentials MAY choose to remember the
exponential used by the other endpoint on past exchanges and if one exponential used by the other endpoint on past exchanges and if one
is reused to avoid the second half of the calculation. See [REUSE] is reused to avoid the second half of the calculation. See [REUSE]
for a security analysis of this practice and for additional security for a security analysis of this practice and for additional security
considerations when reusing ephemeral Diffie-Hellman keys. considerations when reusing ephemeral Diffie-Hellman keys.
2.13. Generating Keying Material 2.13. Generating Keying Material
In the context of the IKE SA, four cryptographic algorithms are In the context of the IKE SA, four cryptographic algorithms are
negotiated: an encryption algorithm, an integrity protection negotiated: an encryption algorithm, an integrity protection
algorithm, a Diffie-Hellman group, and a pseudo-random function algorithm, a Diffie-Hellman group, and a pseudorandom function (PRF).
(PRF). The PRF is used for the construction of keying material for The PRF is used for the construction of keying material for all of
all of the cryptographic algorithms used in both the IKE SA and the the cryptographic algorithms used in both the IKE SA and the Child
Child SAs. SAs.
We assume that each encryption algorithm and integrity protection We assume that each encryption algorithm and integrity protection
algorithm uses a fixed-size key and that any randomly chosen value of algorithm uses a fixed-size key and that any randomly chosen value of
that fixed size can serve as an appropriate key. For algorithms that that fixed size can serve as an appropriate key. For algorithms that
accept a variable length key, a fixed key size MUST be specified as accept a variable-length key, a fixed key size MUST be specified as
part of the cryptographic transform negotiated (see Section 3.3.5 for part of the cryptographic transform negotiated (see Section 3.3.5 for
the definition of the Key Length transform attribute). For the definition of the Key Length transform attribute). For
algorithms for which not all values are valid keys (such as DES or algorithms for which not all values are valid keys (such as DES or
3DES with key parity), the algorithm by which keys are derived from 3DES with key parity), the algorithm by which keys are derived from
arbitrary values MUST be specified by the cryptographic transform. arbitrary values MUST be specified by the cryptographic transform.
For integrity protection functions based on Hashed Message For integrity protection functions based on Hashed Message
Authentication Code (HMAC), the fixed key size is the size of the Authentication Code (HMAC), the fixed key size is the size of the
output of the underlying hash function. output of the underlying hash function.
It is assumed that PRFs accept keys of any length, but have a It is assumed that PRFs accept keys of any length, but have a
preferred key size. The preferred key size MUST be used as the preferred key size. The preferred key size MUST be used as the
length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based
on the HMAC construction, the preferred key size is equal to the on the HMAC construction, the preferred key size is equal to the
length of the output of the underlying hash function. Other types of length of the output of the underlying hash function. Other types of
PRFs MUST specify their preferred key size. PRFs MUST specify their preferred key size.
skipping to change at line 2162 skipping to change at page 46, line 20
preferred key size. The preferred key size MUST be used as the preferred key size. The preferred key size MUST be used as the
length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based
on the HMAC construction, the preferred key size is equal to the on the HMAC construction, the preferred key size is equal to the
length of the output of the underlying hash function. Other types of length of the output of the underlying hash function. Other types of
PRFs MUST specify their preferred key size. PRFs MUST specify their preferred key size.
Keying material will always be derived as the output of the Keying material will always be derived as the output of the
negotiated PRF algorithm. Since the amount of keying material needed negotiated PRF algorithm. Since the amount of keying material needed
may be greater than the size of the output of the PRF, the PRF is may be greater than the size of the output of the PRF, the PRF is
used iteratively. The term "prf+" describes a function that outputs used iteratively. The term "prf+" describes a function that outputs
a pseudo-random stream based on the inputs to a pseudo-random a pseudorandom stream based on the inputs to a pseudorandom function
function called "prf". called "prf".
In the following, | indicates concatenation. prf+ is defined as: In the following, | indicates concatenation. prf+ is defined as:
prf+ (K,S) = T1 | T2 | T3 | T4 | ... prf+ (K,S) = T1 | T2 | T3 | T4 | ...
where: where:
T1 = prf (K, S | 0x01) T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02) T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03) T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04) T4 = prf (K, T3 | S | 0x04)
skipping to change at line 2200 skipping to change at page 47, line 9
The shared keys are computed as follows. A quantity called SKEYSEED The shared keys are computed as follows. A quantity called SKEYSEED
is calculated from the nonces exchanged during the IKE_SA_INIT is calculated from the nonces exchanged during the IKE_SA_INIT
exchange and the Diffie-Hellman shared secret established during that exchange and the Diffie-Hellman shared secret established during that
exchange. SKEYSEED is used to calculate seven other secrets: SK_d exchange. SKEYSEED is used to calculate seven other secrets: SK_d
used for deriving new keys for the Child SAs established with this used for deriving new keys for the Child SAs established with this
IKE SA; SK_ai and SK_ar used as a key to the integrity protection IKE SA; SK_ai and SK_ar used as a key to the integrity protection
algorithm for authenticating the component messages of subsequent algorithm for authenticating the component messages of subsequent
exchanges; SK_ei and SK_er used for encrypting (and of course exchanges; SK_ei and SK_er used for encrypting (and of course
decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
used when generating an AUTH payload. The lengths of SK_d, SK_pi, used when generating an AUTH payload. The lengths of SK_d, SK_pi,
and SK_pr MUST be the preferred key length of the agreed-to PRF. and SK_pr MUST be the preferred key length of the PRF agreed upon.
SKEYSEED and its derivatives are computed as follows: SKEYSEED and its derivatives are computed as follows:
SKEYSEED = prf(Ni | Nr, g^ir) SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, and SK_pr are taken in order from the generated bits of the SK_pi, and SK_pr are taken in order from the generated bits of the
prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
exchange. g^ir is represented as a string of octets in big endian exchange. g^ir is represented as a string of octets in big endian
order padded with zeros if necessary to make it the length of the order padded with zeros if necessary to make it the length of the
modulus. Ni and Nr are the nonces, stripped of any headers. For modulus. Ni and Nr are the nonces, stripped of any headers. For
historical backwards-compatibility reasons, there are two PRFs that historical backward-compatibility reasons, there are two PRFs that
are treated specially in this calculation. If the negotiated PRF is are treated specially in this calculation. If the negotiated PRF is
AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128], AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128],
only the first 64 bits of Ni and the first 64 bits of Nr are used in only the first 64 bits of Ni and the first 64 bits of Nr are used in
calculating SKEYSEED, but all the bits are used for input to the prf+ calculating SKEYSEED, but all the bits are used for input to the prf+
function. function.
The two directions of traffic flow use different keys. The keys used The two directions of traffic flow use different keys. The keys used
to protect messages from the original initiator are SK_ai and SK_ei. to protect messages from the original initiator are SK_ai and SK_ei.
The keys used to protect messages in the other direction are SK_ar The keys used to protect messages in the other direction are SK_ar
and SK_er. and SK_er.
skipping to change at line 2237 skipping to change at page 47, line 46
2.15. Authentication of the IKE SA 2.15. Authentication of the IKE SA
When not using extensible authentication (see Section 2.16), the When not using extensible authentication (see Section 2.16), the
peers are authenticated by having each sign (or MAC using a padded peers are authenticated by having each sign (or MAC using a padded
shared secret as the key, as described later in this section) a block shared secret as the key, as described later in this section) a block
of data. In these calculations, IDi' and IDr' are the entire ID of data. In these calculations, IDi' and IDr' are the entire ID
payloads excluding the fixed header. For the responder, the octets payloads excluding the fixed header. For the responder, the octets
to be signed start with the first octet of the first SPI in the to be signed start with the first octet of the first SPI in the
header of the second message (IKE_SA_INIT response) and end with the header of the second message (IKE_SA_INIT response) and end with the
last octet of the last payload in the second message. Appended to last octet of the last payload in the second message. Appended to
this (for purposes of computing the signature) are the initiator's this (for the purposes of computing the signature) are the
nonce Ni (just the value, not the payload containing it), and the initiator's nonce Ni (just the value, not the payload containing it),
value prf(SK_pr, IDr'). Note that neither the nonce Ni nor the value and the value prf(SK_pr, IDr'). Note that neither the nonce Ni nor
prf(SK_pr, IDr') are transmitted. Similarly, the initiator signs the the value prf(SK_pr, IDr') are transmitted. Similarly, the initiator
first message (IKE_SA_INIT request), starting with the first octet of signs the first message (IKE_SA_INIT request), starting with the
the first SPI in the header and ending with the last octet of the first octet of the first SPI in the header and ending with the last
last payload. Appended to this (for purposes of computing the octet of the last payload. Appended to this (for purposes of
signature) are the responder's nonce Nr, and the value prf(SK_pi, computing the signature) are the responder's nonce Nr, and the value
IDi'). It is critical to the security of the exchange that each side prf(SK_pi, IDi'). It is critical to the security of the exchange
sign the other side's nonce. that each side sign the other side's nonce.
The initiator's signed octets can be described as: The initiator's signed octets can be described as:
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1 RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData RestOfInitIDPayload = IDType | RESERVED | InitIDData
skipping to change at line 2287 skipping to change at page 48, line 48
certificate chain providing evidence that the key used to compute a certificate chain providing evidence that the key used to compute a
digital signature belongs to the name in the ID payload. The digital signature belongs to the name in the ID payload. The
signature or MAC will be computed using algorithms dictated by the signature or MAC will be computed using algorithms dictated by the
type of key used by the signer, and specified by the Auth Method type of key used by the signer, and specified by the Auth Method
field in the Authentication payload. There is no requirement that field in the Authentication payload. There is no requirement that
the initiator and responder sign with the same cryptographic the initiator and responder sign with the same cryptographic
algorithms. The choice of cryptographic algorithms depends on the algorithms. The choice of cryptographic algorithms depends on the
type of key each has. In particular, the initiator may be using a type of key each has. In particular, the initiator may be using a
shared key while the responder may have a public signature key and shared key while the responder may have a public signature key and
certificate. It will commonly be the case (but it is not required) certificate. It will commonly be the case (but it is not required)
that if a shared secret is used for authentication that the same key that, if a shared secret is used for authentication, the same key is
is used in both directions. used in both directions.
Note that it is a common but typically insecure practice to have a Note that it is a common but typically insecure practice to have a
shared key derived solely from a user-chosen password without shared key derived solely from a user-chosen password without
incorporating another source of randomness. This is typically incorporating another source of randomness. This is typically
insecure because user-chosen passwords are unlikely to have insecure because user-chosen passwords are unlikely to have
sufficient unpredictability to resist dictionary attacks and these sufficient unpredictability to resist dictionary attacks and these
attacks are not prevented in this authentication method. attacks are not prevented in this authentication method.
(Applications using password-based authentication for bootstrapping (Applications using password-based authentication for bootstrapping
and IKE SA should use the authentication method in Section 2.16, and IKE SA should use the authentication method in Section 2.16,
which is designed to prevent off-line dictionary attacks.) The pre- which is designed to prevent off-line dictionary attacks.) The pre-
skipping to change at line 2319 skipping to change at page 49, line 34
where the string "Key Pad for IKEv2" is 17 ASCII characters without where the string "Key Pad for IKEv2" is 17 ASCII characters without
null termination. The shared secret can be variable length. The pad null termination. The shared secret can be variable length. The pad
string is added so that if the shared secret is derived from a string is added so that if the shared secret is derived from a
password, the IKE implementation need not store the password in password, the IKE implementation need not store the password in
cleartext, but rather can store the value prf(Shared Secret,"Key Pad cleartext, but rather can store the value prf(Shared Secret,"Key Pad
for IKEv2"), which could not be used as a password equivalent for for IKEv2"), which could not be used as a password equivalent for
protocols other than IKEv2. As noted above, deriving the shared protocols other than IKEv2. As noted above, deriving the shared
secret from a password is not secure. This construction is used secret from a password is not secure. This construction is used
because it is anticipated that people will do it anyway. The because it is anticipated that people will do it anyway. The
management interface by which the Shared Secret is provided MUST management interface by which the shared secret is provided MUST
accept ASCII strings of at least 64 octets and MUST NOT add a null accept ASCII strings of at least 64 octets and MUST NOT add a null
terminator before using them as shared secrets. It MUST also accept terminator before using them as shared secrets. It MUST also accept
a hex encoding of the Shared Secret. The management interface MAY a hex encoding of the shared secret. The management interface MAY
accept other encodings if the algorithm for translating the encoding accept other encodings if the algorithm for translating the encoding
to a binary string is specified. to a binary string is specified.
There are two types of EAP authentication (described in There are two types of EAP authentication (described in
Section 2.16), and each type uses different values in the AUTH Section 2.16), and each type uses different values in the AUTH
computations shown above. If the EAP method is key-generating, computations shown above. If the EAP method is key-generating,
substitute MSK for the Shared Secret in the computation. For non- substitute master session key (MSK) for the shared secret in the
key-generating methods, substitute SK_pi and SK_pr, respectively, for computation. For non-key-generating methods, substitute SK_pi and
the Shared Secret in the two AUTH computations. SK_pr, respectively, for the shared secret in the two AUTH
computations.
2.16. Extensible Authentication Protocol Methods 2.16. Extensible Authentication Protocol Methods
In addition to authentication using public key signatures and shared In addition to authentication using public key signatures and shared
secrets, IKE supports authentication using methods defined in RFC secrets, IKE supports authentication using methods defined in RFC
3748 [EAP]. Typically, these methods are asymmetric (designed for a 3748 [EAP]. Typically, these methods are asymmetric (designed for a
user authenticating to a server), and they may not be mutual. For user authenticating to a server), and they may not be mutual. For
this reason, these protocols are typically used to authenticate the this reason, these protocols are typically used to authenticate the
initiator to the responder and MUST be used in conjunction with a initiator to the responder and MUST be used in conjunction with a
public key signature based authentication of the responder to the public-key-signature-based authentication of the responder to the
initiator. These methods are often associated with mechanisms initiator. These methods are often associated with mechanisms
referred to as "Legacy Authentication" mechanisms. referred to as "Legacy Authentication" mechanisms.
While this document references [EAP] with the intent that new methods While this document references [EAP] with the intent that new methods
can be added in the future without updating this specification, some can be added in the future without updating this specification, some
simpler variations are documented here. [EAP] defines an simpler variations are documented here. [EAP] defines an
authentication protocol requiring a variable number of messages. authentication protocol requiring a variable number of messages.
Extensible Authentication is implemented in IKE as additional Extensible Authentication is implemented in IKE as additional
IKE_AUTH exchanges that MUST be completed in order to initialize the IKE_AUTH exchanges that MUST be completed in order to initialize the
IKE SA. IKE SA.
An initiator indicates a desire to use extensible authentication by An initiator indicates a desire to use EAP by leaving out the AUTH
leaving out the AUTH payload from the first message in the IKE_AUTH payload from the first message in the IKE_AUTH exchange. (Note that
exchange. (Note that the AUTH payload is required for non-EAP the AUTH payload is required for non-EAP authentication, and is thus
authentication, and is thus not marked as optional in the rest of not marked as optional in the rest of this document.) By including
this document.) By including an IDi payload but not an AUTH payload, an IDi payload but not an AUTH payload, the initiator has declared an
the initiator has declared an identity but has not proven it. If the identity but has not proven it. If the responder is willing to use
responder is willing to use an extensible authentication method, it an EAP method, it will place an Extensible Authentication Protocol
will place an Extensible Authentication Protocol (EAP) payload in the (EAP) payload in the response of the IKE_AUTH exchange and defer
response of the IKE_AUTH exchange and defer sending SAr2, TSi, and sending SAr2, TSi, and TSr until initiator authentication is complete
TSr until initiator authentication is complete in a subsequent in a subsequent IKE_AUTH exchange. In the case of a minimal EAP
IKE_AUTH exchange. In the case of a minimal extensible method, the initial SA establishment will appear as follows:
authentication, the initial SA establishment will appear as follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] HDR, SK {IDi, [CERTREQ,]
[IDr,] SAi2, [IDr,] SAi2,
TSi, TSr} --> TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
EAP } EAP }
skipping to change at line 2417 skipping to change at page 51, line 42
Similarly, if the authentication method has failed, the responder Similarly, if the authentication method has failed, the responder
MUST send an EAP payload containing the Failure message. The MUST send an EAP payload containing the Failure message. The
responder MAY at any time terminate the IKE exchange by sending an responder MAY at any time terminate the IKE exchange by sending an
EAP payload containing the Failure message. EAP payload containing the Failure message.
Following such an extended exchange, the EAP AUTH payloads MUST be Following such an extended exchange, the EAP AUTH payloads MUST be
included in the two messages following the one containing the EAP included in the two messages following the one containing the EAP
Success message. Success message.
When the initiator authentication uses EAP, it is possible that the When the initiator authentication uses EAP, it is possible that the
contents of the IDi payload is used only for AAA routing purposes and contents of the IDi payload is used only for Authentication,
selecting which EAP method to use. This value may be different from Authorization, and Accounting (AAA) routing purposes and selecting
the identity authenticated by the EAP method. It is important that which EAP method to use. This value may be different from the
identity authenticated by the EAP method. It is important that
policy lookups and access control decisions use the actual policy lookups and access control decisions use the actual
authenticated identity. Often the EAP server is implemented in a authenticated identity. Often the EAP server is implemented in a
separate AAA server that communicates with the IKEv2 responder. In separate AAA server that communicates with the IKEv2 responder. In
this case, the authenticated identity, if different from that in the this case, the authenticated identity, if different from that in the
IDi payload, has to be sent from the AAA server to the IKEv2 IDi payload, has to be sent from the AAA server to the IKEv2
responder. responder.
2.17. Generating Keying Material for Child SAs 2.17. Generating Keying Material for Child SAs
A single Child SA is created by the IKE_AUTH exchange, and additional A single Child SA is created by the IKE_AUTH exchange, and additional
skipping to change at line 2449 skipping to change at page 52, line 27
For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
exchange, the keying material is defined as: exchange, the keying material is defined as:
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
where g^ir (new) is the shared secret from the ephemeral Diffie- where g^ir (new) is the shared secret from the ephemeral Diffie-
Hellman exchange of this CREATE_CHILD_SA exchange (represented as an Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
octet string in big endian order padded with zeros in the high-order octet string in big endian order padded with zeros in the high-order
bits if necessary to make it the length of the modulus). bits if necessary to make it the length of the modulus).
A single CHILD_SA negotiation may result in multiple security A single CHILD_SA negotiation may result in multiple Security
associations. ESP and AH SAs exist in pairs (one in each direction), Associations. ESP and AH SAs exist in pairs (one in each direction),
so two SAs are created in a single Child SA negotiation for them. so two SAs are created in a single Child SA negotiation for them.
Furthermore, Child SA negotiation may include some future IPsec Furthermore, Child SA negotiation may include some future IPsec
protocol(s) in addition to, or instead of, ESP or AH (for example, protocol(s) in addition to, or instead of, ESP or AH (for example,
ROHC_INTEG as described in [ROHCV2]). In any case, keying material ROHC_INTEG as described in [ROHCV2]). In any case, keying material
for each child SA MUST be taken from the expanded KEYMAT using the for each Child SA MUST be taken from the expanded KEYMAT using the
following rules: following rules:
o All keys for SAs carrying data from the initiator to the responder o All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator. are taken before SAs going from the responder to the initiator.
o If multiple IPsec protocols are negotiated, keying material for o If multiple IPsec protocols are negotiated, keying material for
each Child SA is taken in the order in which the protocol headers each Child SA is taken in the order in which the protocol headers
will appear in the encapsulated packet. will appear in the encapsulated packet.
o If an IPsec protocol requires multiple keys, the order in which o If an IPsec protocol requires multiple keys, the order in which
skipping to change at line 2481 skipping to change at page 53, line 14
Each cryptographic algorithm takes a fixed number of bits of keying Each cryptographic algorithm takes a fixed number of bits of keying
material specified as part of the algorithm, or negotiated in SA material specified as part of the algorithm, or negotiated in SA
payloads (see Section 2.13 for description of key lengths, and payloads (see Section 2.13 for description of key lengths, and
Section 3.3.5 for the definition of the Key Length transform Section 3.3.5 for the definition of the Key Length transform
attribute). attribute).
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA
(see Section 1.3.2 and Section 2.8). New initiator and responder (see Sections 1.3.2 and 2.8). New initiator and responder SPIs are
SPIs are supplied in the SPI fields in the Proposal structures inside supplied in the SPI fields in the Proposal structures inside the
the Security Association (SA) payloads (not the SPI fields in the IKE Security Association (SA) payloads (not the SPI fields in the IKE
header). The TS payloads are omitted when rekeying an IKE SA. header). The TS payloads are omitted when rekeying an IKE SA.
SKEYSEED for the new IKE SA is computed using SK_d from the existing SKEYSEED for the new IKE SA is computed using SK_d from the existing
IKE SA as follows: IKE SA as follows:
SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)
where g^ir (new) is the shared secret from the ephemeral Diffie- where g^ir (new) is the shared secret from the ephemeral Diffie-
Hellman exchange of this CREATE_CHILD_SA exchange (represented as an Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
octet string in big endian order padded with zeros if necessary to octet string in big endian order padded with zeros if necessary to
make it the length of the modulus) and Ni and Nr are the two nonces make it the length of the modulus) and Ni and Nr are the two nonces
skipping to change at line 2532 skipping to change at page 54, line 16
message 3) by including a CP payload. Note, however, it is usual to message 3) by including a CP payload. Note, however, it is usual to
only assign one IP address during the IKE_AUTH exchange. That only assign one IP address during the IKE_AUTH exchange. That
address persists at least until the deletion of the IKE SA. address persists at least until the deletion of the IKE SA.
This function provides address allocation to an IPsec Remote Access This function provides address allocation to an IPsec Remote Access
Client (IRAC) trying to tunnel into a network protected by an IPsec Client (IRAC) trying to tunnel into a network protected by an IPsec
Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled
address (and optionally other information concerning the protected address (and optionally other information concerning the protected
network) in the IKE_AUTH exchange. The IRAS may procure an address network) in the IKE_AUTH exchange. The IRAS may procure an address
for the IRAC from any number of sources such as a DHCP/BOOTP server for the IRAC from any number of sources such as a DHCP/BOOTP
or its own address pool. (Bootstrap Protocol) server or its own address pool.
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {IDi, [CERT,] HDR, SK {IDi, [CERT,]
[CERTREQ,] [IDr,] AUTH, [CERTREQ,] [IDr,] AUTH,
CP(CFG_REQUEST), SAi2, CP(CFG_REQUEST), SAi2,
TSi, TSr} --> TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
CP(CFG_REPLY), SAr2, CP(CFG_REPLY), SAr2,
TSi, TSr} TSi, TSr}
skipping to change at line 2561 skipping to change at page 55, line 12
(either IPv4 or IPv6) but MAY contain any number of additional (either IPv4 or IPv6) but MAY contain any number of additional
attributes the initiator wants returned in the response. attributes the initiator wants returned in the response.
For example, message from initiator to responder: For example, message from initiator to responder:
CP(CFG_REQUEST)= CP(CFG_REQUEST)=
INTERNAL_ADDRESS() INTERNAL_ADDRESS()
TSi = (0, 0-65535,0.0.0.0-255.255.255.255) TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
TSr = (0, 0-65535,0.0.0.0-255.255.255.255) TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
NOTE: Traffic selectors contain (protocol, port range, address NOTE: Traffic Selectors contain (protocol, port range, address
range). range).
Message from responder to initiator: Message from responder to initiator:
CP(CFG_REPLY)= CP(CFG_REPLY)=
INTERNAL_ADDRESS(192.0.2.202) INTERNAL_ADDRESS(192.0.2.202)
INTERNAL_NETMASK(255.255.255.0) INTERNAL_NETMASK(255.255.255.0)
INTERNAL_SUBNET(192.0.2.0/255.255.255.0) INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
TSr = (0, 0-65535,192.0.2.0-192.0.2.255) TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
skipping to change at line 2589 skipping to change at page 55, line 40
a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
to perform an unnecessary configuration lookup if the IRAC cannot to perform an unnecessary configuration lookup if the IRAC cannot
process the REPLY. process the REPLY.
In the case where the IRAS's configuration requires that CP be used In the case where the IRAS's configuration requires that CP be used
for a given identity IDi, but IRAC has failed to send a for a given identity IDi, but IRAC has failed to send a
CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child
SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED
is not fatal to the IKE SA; it simply causes the Child SA creation to is not fatal to the IKE SA; it simply causes the Child SA creation to
fail. The initiator can fix this by later starting a new fail. The initiator can fix this by later starting a new
configuration payload request. There is no associated data in the Configuration payload request. There is no associated data in the
FAILED_CP_REQUIRED error. FAILED_CP_REQUIRED error.
2.20. Requesting the Peer's Version 2.20. Requesting the Peer's Version
An IKE peer wishing to inquire about the other peer's IKE software An IKE peer wishing to inquire about the other peer's IKE software
version information MAY use the method below. This is an example of version information MAY use the method below. This is an example of
a configuration request within an INFORMATIONAL exchange, after the a configuration request within an INFORMATIONAL exchange, after the
IKE SA and first Child SA have been created. IKE SA and first Child SA have been created.
An IKE implementation MAY decline to give out version information An IKE implementation MAY decline to give out version information
skipping to change at line 2630 skipping to change at page 56, line 36
formatted, or unacceptable for reasons of policy (such as no matching formatted, or unacceptable for reasons of policy (such as no matching
cryptographic algorithms), the response contains a Notify payload cryptographic algorithms), the response contains a Notify payload
indicating the error. The decision whether or not to send such a indicating the error. The decision whether or not to send such a
response depends whether or not there is an authenticated IKE SA. response depends whether or not there is an authenticated IKE SA.
If there is an error parsing or processing a response packet, the If there is an error parsing or processing a response packet, the
general rule is to not send back any error message because responses general rule is to not send back any error message because responses
should not generate new requests (and a new request would be the only should not generate new requests (and a new request would be the only
way to send back an error message). Such errors in parsing or way to send back an error message). Such errors in parsing or
processing response packets should still cause the recipient to clean processing response packets should still cause the recipient to clean
up the IKE state (for example, by sending a DELETE for a bad SA). up the IKE state (for example, by sending a Delete for a bad SA).
Only authentication failures (AUTHENTICATION_FAILED and EAP failure) Only authentication failures (AUTHENTICATION_FAILED and EAP failure)
and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE
SA without requiring an explicit INFORMATIONAL exchange carrying a SA without requiring an explicit INFORMATIONAL exchange carrying a
DELETE payload. Other error conditions MAY require such an exchange Delete payload. Other error conditions MAY require such an exchange
if policy dictates that this is needed. If the exchange is if policy dictates that this is needed. If the exchange is
terminated with EAP Failure, an AUTHENTICATION_FAILED notification is terminated with EAP Failure, an AUTHENTICATION_FAILED notification is
not sent. not sent.
2.21.1. Error Handling in IKE_SA_INIT 2.21.1. Error Handling in IKE_SA_INIT
Errors that occur before a cryptographically protected IKE SA is Errors that occur before a cryptographically protected IKE SA is
established need to be handled very carefully. There is a trade-off established need to be handled very carefully. There is a trade-off
between wanting to help the peer to diagnose a problem and thus between wanting to help the peer to diagnose a problem and thus
responding to the error, and wanting to avoid being part of a DoS responding to the error and wanting to avoid being part of a DoS
attack based on forged messages. attack based on forged messages.
In an IKE_SA_INIT exchange, any error notification causes the In an IKE_SA_INIT exchange, any error notification causes the
exchange to fail. Note that some error notifications such as COOKIE, exchange to fail. Note that some error notifications such as COOKIE,
INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent
successful exchange. Because all error notifications are completely successful exchange. Because all error notifications are completely
unauthenticated, the recipient should continue trying for some time unauthenticated, the recipient should continue trying for some time
before giving up. The recipient should not immediately act based on before giving up. The recipient should not immediately act based on
the error notification unless corrective actions are defined in this the error notification unless corrective actions are defined in this
specification, such as for COOKIE, INVALID_KE_PAYLOAD, and specification, such as for COOKIE, INVALID_KE_PAYLOAD, and
skipping to change at line 2688 skipping to change at page 57, line 45
than just bad payload contents), MUST be rejected in their entirety, than just bad payload contents), MUST be rejected in their entirety,
and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or
INVALID_SYNTAX Notification sent as a response. The receiver should INVALID_SYNTAX Notification sent as a response. The receiver should
not verify the payloads related to authentication in this case. not verify the payloads related to authentication in this case.
If authentication has succeeded in the IKE_AUTH exchange, the IKE SA If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
is established; however, establishing the Child SA or requesting is established; however, establishing the Child SA or requesting
configuration information may still fail. This failure does not configuration information may still fail. This failure does not
automatically cause the IKE SA to be deleted. Specifically, a automatically cause the IKE SA to be deleted. Specifically, a
responder may include all the payloads associated with authentication responder may include all the payloads associated with authentication
(IDr, Cert and AUTH) while sending error notifications for the (IDr, CERT, and AUTH) while sending error notifications for the
piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so
on), and the initiator MUST NOT fail the authentication because of on), and the initiator MUST NOT fail the authentication because of
this. The initiator MAY, of course, for reasons of policy later this. The initiator MAY, of course, for reasons of policy later
delete such an IKE SA. delete such an IKE SA.
In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
following it (in case an error happened when processing a response to following it (in case an error happened when processing a response to
IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
AUTHENTICATION_FAILED notifications are the only ones to cause the AUTHENTICATION_FAILED notifications are the only ones to cause the
IKE SA to be deleted or not created, without a DELETE payload. IKE SA to be deleted or not created, without a Delete payload.
Extension documents may define new error notifications with these Extension documents may define new error notifications with these
semantics, but MUST NOT use them unless the peer has been shown to semantics, but MUST NOT use them unless the peer has been shown to
understand them, such as by using the Vendor ID payload. understand them, such as by using the Vendor ID payload.
2.21.3. Error Handling after IKE SA is Authenticated 2.21.3. Error Handling after IKE SA is Authenticated
After the IKE SA is authenticated all requests having errors MUST After the IKE SA is authenticated, all requests having errors MUST
result in a response notifying about the error. result in a response notifying about the error.
In normal situations, there should not be cases where a valid In normal situations, there should not be cases where a valid
response from one peer results in an error situation in the other response from one peer results in an error situation in the other
peer, so there should not be any reason for a peer to send error peer, so there should not be any reason for a peer to send error
messages to the other end except as a response. Because sending such messages to the other end except as a response. Because sending such
error messages as an INFORMATIONAL exchange might lead to further error messages as an INFORMATIONAL exchange might lead to further
errors that could cause loops, such errors SHOULD NOT be sent. If errors that could cause loops, such errors SHOULD NOT be sent. If
errors are seen that indicate that the peers do not have the same errors are seen that indicate that the peers do not have the same
state, it might be good to delete the IKE SA to clean up state and state, it might be good to delete the IKE SA to clean up state and
start over. start over.
If a peer parsing a request notices that it is badly formatted (after If a peer parsing a request notices that it is badly formatted (after
it has passed the message authentication code checks and window it has passed the message authentication code checks and window
checks) and it returns an INVALID_SYNTAX notification, then this checks) and it returns an INVALID_SYNTAX notification, then this
error notification is considered fatal in both peers, meaning that error notification is considered fatal in both peers, meaning that
the IKE SA is deleted without needing an explicit DELETE payload. the IKE SA is deleted without needing an explicit Delete payload.
2.21.4. Error Handling Outside IKE SA 2.21.4. Error Handling Outside IKE SA
A node needs to limit the rate at which it will send messages in A node needs to limit the rate at which it will send messages in
response to unprotected messages. response to unprotected messages.
If a node receives a message on UDP port 500 or 4500 outside the If a node receives a message on UDP port 500 or 4500 outside the
context of an IKE SA known to it (and the message is not a request to context of an IKE SA known to it (and the message is not a request to
start an IKE SA), this may be the result of a recent crash of the start an IKE SA), this may be the result of a recent crash of the
node. If the message is marked as a response, the node can audit the node. If the message is marked as a response, the node can audit the
skipping to change at line 2766 skipping to change at page 59, line 28
the problem. the problem.
A node receiving a suspicious message from an IP address (and port, A node receiving a suspicious message from an IP address (and port,
if NAT traversal is used) with which it has an IKE SA SHOULD send an if NAT traversal is used) with which it has an IKE SA SHOULD send an
IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. IKE Notify payload in an IKE INFORMATIONAL exchange over that SA.
The recipient MUST NOT change the state of any SAs as a result, but The recipient MUST NOT change the state of any SAs as a result, but
may wish to audit the event to aid in diagnosing malfunctions. may wish to audit the event to aid in diagnosing malfunctions.
2.22. IPComp 2.22. IPComp
Use of IP compression [IP-COMP] can be negotiated as part of the Use of IP Compression [IP-COMP] can be negotiated as part of the
setup of a Child SA. While IP compression involves an extra header setup of a Child SA. While IP Compression involves an extra header
in each packet and a compression parameter index (CPI), the virtual in each packet and a compression parameter index (CPI), the virtual
"compression association" has no life outside the ESP or AH SA that "compression association" has no life outside the ESP or AH SA that
contains it. Compression associations disappear when the contains it. Compression associations disappear when the
corresponding ESP or AH SA goes away. It is not explicitly mentioned corresponding ESP or AH SA goes away. It is not explicitly mentioned
in any DELETE payload. in any Delete payload.
Negotiation of IP compression is separate from the negotiation of Negotiation of IP Compression is separate from the negotiation of
cryptographic parameters associated with a Child SA. A node cryptographic parameters associated with a Child SA. A node
requesting a Child SA MAY advertise its support for one or more requesting a Child SA MAY advertise its support for one or more
compression algorithms through one or more Notify payloads of type compression algorithms through one or more Notify payloads of type
IPCOMP_SUPPORTED. This Notify message may be included only in a IPCOMP_SUPPORTED. This Notify message may be included only in a
message containing an SA payload negotiating a Child SA and indicates message containing an SA payload negotiating a Child SA and indicates
a willingness by its sender to use IPComp on this SA. The response a willingness by its sender to use IPComp on this SA. The response
MAY indicate acceptance of a single compression algorithm with a MAY indicate acceptance of a single compression algorithm with a
Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT
occur in messages that do not contain SA payloads. occur in messages that do not contain SA payloads.
The data associated with this Notify message includes a two-octet The data associated with this Notify message includes a two-octet
IPComp CPI followed by a one-octet transform ID optionally followed IPComp CPI followed by a one-octet Transform ID optionally followed
by attributes whose length and format are defined by that transform by attributes whose length and format are defined by that Transform
ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED
notifications to indicate multiple supported algorithms. A message notifications to indicate multiple supported algorithms. A message
accepting an SA may contain at most one. accepting an SA may contain at most one.
The transform IDs are listed here. The values in the following table The Transform IDs are listed here. The values in the following table
are only current as of the publication date of RFC 4306. Other are only current as of the publication date of RFC 4306. Other
values may have been added since then or will be added after the values may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA] publication of this document. Readers should refer to [IKEV2IANA]
for the latest values. for the latest values.
Name Number Defined In Name Number Defined In
------------------------------------- -------------------------------------
IPCOMP_OUI 1 IPCOMP_OUI 1
IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_DEFLATE 2 RFC 2394
IPCOMP_LZS 3 RFC 2395 IPCOMP_LZS 3 RFC 2395
skipping to change at line 2815 skipping to change at page 60, line 28
Although there has been discussion of allowing multiple compression Although there has been discussion of allowing multiple compression
algorithms to be accepted and to have different compression algorithms to be accepted and to have different compression
algorithms available for the two directions of a Child SA, algorithms available for the two directions of a Child SA,
implementations of this specification MUST NOT accept an IPComp implementations of this specification MUST NOT accept an IPComp
algorithm that was not proposed, MUST NOT accept more than one, and algorithm that was not proposed, MUST NOT accept more than one, and
MUST NOT compress using an algorithm other than one proposed and MUST NOT compress using an algorithm other than one proposed and
accepted in the setup of the Child SA. accepted in the setup of the Child SA.
A side effect of separating the negotiation of IPComp from A side effect of separating the negotiation of IPComp from
cryptographic parameters is that it is not possible to propose cryptographic parameters is that it is not possible to propose
multiple cryptographic suites and propose IP compression with some of multiple cryptographic suites and propose IP Compression with some of
them but not others. them but not others.
In some cases, Robust Header Compression (ROHC) may be more In some cases, Robust Header Compression (ROHC) may be more
appropriate than IP Compression. [ROHCV2] defines the use of ROHC appropriate than IP Compression. [ROHCV2] defines the use of ROHC
with IKEv2 and IPsec. with IKEv2 and IPsec.
2.23. NAT Traversal 2.23. NAT Traversal
Network Address Translation (NAT) gateways are a controversial Network Address Translation (NAT) gateways are a controversial
subject. This section briefly describes what they are and how they subject. This section briefly describes what they are and how they
skipping to change at line 2871 skipping to change at page 61, line 35
requires special logic in the NAT and that logic is heuristic and requires special logic in the NAT and that logic is heuristic and
unreliable in nature. For that reason, IKEv2 will use UDP unreliable in nature. For that reason, IKEv2 will use UDP
encapsulation of IKE and ESP packets. This encoding is slightly less encapsulation of IKE and ESP packets. This encoding is slightly less
efficient but is easier for NATs to process. In addition, firewalls efficient but is easier for NATs to process. In addition, firewalls
may be configured to pass UDP-encapsulated IPsec traffic but not may be configured to pass UDP-encapsulated IPsec traffic but not
plain, unencapsulated ESP/AH or vice versa. plain, unencapsulated ESP/AH or vice versa.
It is a common practice of NATs to translate TCP and UDP port numbers It is a common practice of NATs to translate TCP and UDP port numbers
as well as addresses and use the port numbers of inbound packets to as well as addresses and use the port numbers of inbound packets to
decide which internal node should get a given packet. For this decide which internal node should get a given packet. For this
reason, even though IKE packets MUST be sent from and to UDP port 500 reason, even though IKE packets MUST be sent to and from UDP port 500
or 4500, they MUST be accepted coming from any port and responses or 4500, they MUST be accepted coming from any port and responses
MUST be sent to the port from whence they came. This is because the MUST be sent to the port from whence they came. This is because the
ports may be modified as the packets pass through NATs. Similarly, ports may be modified as the packets pass through NATs. Similarly,
IP addresses of the IKE endpoints are generally not included in the IP addresses of the IKE endpoints are generally not included in the
IKE payloads because the payloads are cryptographically protected and IKE payloads because the payloads are cryptographically protected and
could not be transparently modified by NATs. could not be transparently modified by NATs.
Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec
endpoint that discovers a NAT between it and its correspondent (as endpoint that discovers a NAT between it and its correspondent (as
described below) MUST send all subsequent traffic from port 4500, described below) MUST send all subsequent traffic from port 4500,
which NATs should not treat specially (as they might with port 500). which NATs should not treat specially (as they might with port 500).
An initiator can use port 4500 for both IKE and ESP, regardless of An initiator can use port 4500 for both IKE and ESP, regardless of
whether or not there is a NAT, even at the beginning of IKE. When whether or not there is a NAT, even at the beginning of IKE. When
either side is using port 4500, sending ESP with UDP encapsulation is either side is using port 4500, sending ESP with UDP encapsulation is
not required, but understanding received UDP encapsulated ESP packets not required, but understanding received UDP-encapsulated ESP packets
is required. UDP encapsulation MUST NOT be done on port 500. If is required. UDP encapsulation MUST NOT be done on port 500. If
NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were Network Address Translation Traversal (NAT-T) is supported (that is,
exchanged during IKE_SA_INIT), all devices MUST be able to receive if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT),
and process both UDP encapsulated ESP and non-UDP encapsulated ESP all devices MUST be able to receive and process both UDP-encapsulated
packets at any time. Either side can decide whether or not to use ESP and non-UDP-encapsulated ESP packets at any time. Either side
UDP encapsulation for ESP irrespective of the choice made by the can decide whether or not to use UDP encapsulation for ESP
other side. However, if a NAT is detected, both devices MUST use UDP irrespective of the choice made by the other side. However, if a NAT
encapsulation for ESP. is detected, both devices MUST use UDP encapsulation for ESP.
The specific requirements for supporting NAT traversal [NATREQ] are The specific requirements for supporting NAT traversal [NATREQ] are
listed below. Support for NAT traversal is optional. In this listed below. Support for NAT traversal is optional. In this
section only, requirements listed as MUST apply only to section only, requirements listed as MUST apply only to
implementations supporting NAT traversal. implementations supporting NAT traversal.
o Both IKE initiator and responder MUST include in their IKE_SA_INIT o Both the IKE initiator and responder MUST include in their
packets Notify payloads of type NAT_DETECTION_SOURCE_IP and IKE_SA_INIT packets Notify payloads of type
NAT_DETECTION_DESTINATION_IP. Those payloads can be used to NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those
detect if there is NAT between the hosts, and which end is behind payloads can be used to detect if there is NAT between the hosts,
the NAT. The location of the payloads in the IKE_SA_INIT packets and which end is behind the NAT. The location of the payloads in
is just after the Ni and Nr payloads (before the optional CERTREQ the IKE_SA_INIT packets is just after the Ni and Nr payloads
payload). (before the optional CERTREQ payload).
o The data associated with the NAT_DETECTION_SOURCE_IP notification o The data associated with the NAT_DETECTION_SOURCE_IP notification
is a SHA-1 digest of the SPIs (in the order they appear in the is a SHA-1 digest of the SPIs (in the order they appear in the
header), IP address, and port from which this packet was sent. header), IP address, and port from which this packet was sent.
There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a
message if the sender does not know which of several network message if the sender does not know which of several network
attachments will be used to send the packet. attachments will be used to send the packet.
o The data associated with the NAT_DETECTION_DESTINATION_IP o The data associated with the NAT_DETECTION_DESTINATION_IP
notification is a SHA-1 digest of the SPIs (in the order they notification is a SHA-1 digest of the SPIs (in the order they
appear in the header), IP address, and port to which this packet appear in the header), IP address, and port to which this packet
was sent. was sent.
o The recipient of either the NAT_DETECTION_SOURCE_IP or o The recipient of either the NAT_DETECTION_SOURCE_IP or
NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
value to a SHA-1 hash of the SPIs, source or recipient IP address value to a SHA-1 hash of the SPIs, source or recipient IP address
(respectively), address, and port, and if they don't match it (respectively), address, and port, and if they don't match, it
SHOULD enable NAT traversal. In the case there is a mismatch of SHOULD enable NAT traversal. In the case there is a mismatch of
the NAT_DETECTION_SOURCE_IP hash with all of the the NAT_DETECTION_SOURCE_IP hash with all of the
NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY
reject the connection attempt if NAT traversal is not supported. reject the connection attempt if NAT traversal is not supported.
In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it
means that the system receiving the NAT_DETECTION_DESTINATION_IP means that the system receiving the NAT_DETECTION_DESTINATION_IP
payload is behind a NAT and that system SHOULD start sending payload is behind a NAT and that system SHOULD start sending
keepalive packets as defined in [UDPENCAPS]; alternately, it MAY keepalive packets as defined in [UDPENCAPS]; alternately, it MAY
reject the connection attempt if NAT traversal is not supported. reject the connection attempt if NAT traversal is not supported.
o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
the expected value of the source IP and port found from the IP the expected value of the source IP and port found from the IP
header of the packet containing the payload, it means that the header of the packet containing the payload, it means that the
system sending those payloads is behind NAT (i.e., someone along system sending those payloads is behind a NAT (i.e., someone along
the route changed the source address of the original packet to the route changed the source address of the original packet to
match the address of the NAT box). In this case, the system match the address of the NAT box). In this case, the system
receiving the payloads should allow dynamic update of the other receiving the payloads should allow dynamic updates of the other
systems' IP address, as described later. systems' IP address, as described later.
o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or
NAT_DETECTION_DESTINATION_IP payloads if present and if they do NAT_DETECTION_DESTINATION_IP payloads if present, and if they do
not match the addresses in the outer packet MUST tunnel all future not match the addresses in the outer packet, MUST tunnel all
IKE and ESP packets associated with this IKE SA over UDP port future IKE and ESP packets associated with this IKE SA over UDP
4500. port 4500.
o To tunnel IKE packets over UDP port 4500, the IKE header has four o To tunnel IKE packets over UDP port 4500, the IKE header has four
octets of zero prepended and the result immediately follows the octets of zero prepended and the result immediately follows the
UDP header. To tunnel ESP packets over UDP port 4500, the ESP UDP header. To tunnel ESP packets over UDP port 4500, the ESP
header immediately follows the UDP header. Since the first four header immediately follows the UDP header. Since the first four
octets of the ESP header contain the SPI, and the SPI cannot octets of the ESP header contain the SPI, and the SPI cannot
validly be zero, it is always possible to distinguish ESP and IKE validly be zero, it is always possible to distinguish ESP and IKE
messages. messages.
o Implementations MUST process received UDP-encapsulated ESP packets o Implementations MUST process received UDP-encapsulated ESP packets
even when no NAT was detected. even when no NAT was detected.
o The original source and destination IP address required for the o The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
are obtained from the traffic selectors associated with the are obtained from the Traffic Selectors associated with the
exchange. In the case of transport mode NAT traversal, the exchange. In the case of transport mode NAT traversal, the
traffic selectors MUST contain exactly one IP address, which is Traffic Selectors MUST contain exactly one IP address, which is
then used as the original IP address. This is covered in greater then used as the original IP address. This is covered in greater
detail in Section 2.23.1. detail in Section 2.23.1.
o There are cases where a NAT box decides to remove mappings that o There are cases where a NAT box decides to remove mappings that
are still alive (for example, the keepalive interval is too long, are still alive (for example, the keepalive interval is too long,
or the NAT box is rebooted). This will be apparent to a host if or the NAT box is rebooted). This will be apparent to a host if
it receives a packet whose integrity protection validates, but has it receives a packet whose integrity protection validates, but has
a different port, address, or both from the one that was a different port, address, or both from the one that was
associated with the SA in the validated packet. When such a associated with the SA in the validated packet. When such a
validated packet is found, a host that does not support other validated packet is found, a host that does not support other
methods of recovery such as MOBIKE [MOBIKE], and that is not methods of recovery such as IKEv2 Mobility and Multihoming
behind a NAT, SHOULD send all packets (including retransmission (MOBIKE) [MOBIKE], and that is not behind a NAT, SHOULD send all
packets) to the IP address and port in the validated packet, and packets (including retransmission packets) to the IP address and
SHOULD store this as the new address and port combination for the port in the validated packet, and SHOULD store this as the new
SA (that is, they SHOULD dynamically update the address). A host address and port combination for the SA (that is, they SHOULD
behind a NAT SHOULD NOT do this type of dynamic address update if dynamically update the address). A host behind a NAT SHOULD NOT
a validated packet has different port and/or address values do this type of dynamic address update if a validated packet has
because it opens a possible DoS attack (such as allowing an different port and/or address values because it opens a possible
attacker to break the connection with a single packet). Also, DoS attack (such as allowing an attacker to break the connection
dynamic address update should only be done in response to a new with a single packet). Also, dynamic address update should only
packet; otherwise, an attacker can revert the addresses with old be done in response to a new packet; otherwise, an attacker can
replayed packets. Because of this, dynamic update can only be revert the addresses with old replayed packets. Because of this,
done safely if replay protection is enabled. When IKEv2 is used dynamic updates can only be done safely if replay protection is
with MOBIKE, dynamically updating the addresses described above enabled. When IKEv2 is used with MOBIKE, dynamically updating the
interferes with MOBIKE's way of recovering from the same addresses described above interferes with MOBIKE's way of
situation. See Section 3.8 of [MOBIKE] for more information. recovering from the same situation. See Section 3.8 of [MOBIKE]
for more information.
2.23.1. Transport Mode NAT Traversal 2.23.1. Transport Mode NAT Traversal
Transport mode used with NAT Traversal requires special handling of Transport mode used with NAT Traversal requires special handling of
the traffic selectors used in the IKEv2. The complete scenario looks the Traffic Selectors used in the IKEv2. The complete scenario looks
like: like:
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
|Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server|
|node |<------>| A |<---------->| B |<------->| | |node |<------>| A |<---------->| B |<------->| |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
(Other scenarios are simplifications of this complex case, so this (Other scenarios are simplifications of this complex case, so this
discussion uses the complete scenario.) discussion uses the complete scenario.)
In this scenario, there are two address translating NATs: NAT A and In this scenario, there are two address translating NATs: NAT A and
NAT B. NAT A is dynamic NAT that maps the clients source address IP1 NAT B. NAT A is a dynamic NAT that maps the client's source address
to IPN1. NAT B is static NAT configured so that connections coming IP1 to IPN1. NAT B is a static NAT configured so that connections
to IPN2 address are mapped to the gateways address IP2, that is, IPN2 coming to IPN2 address are mapped to the gateway's address IP2, that
destination address is mapped to IP2. This allows the client to is, IPN2 destination address is mapped to IP2. This allows the
connect to a server by connecting to the IPN2. NAT B does not client to connect to a server by connecting to the IPN2. NAT B does
necessarily need to be a static NAT, but the client needs to know how not necessarily need to be a static NAT, but the client needs to know
to connect to the server, and it can only do that if it somehow knows how to connect to the server, and it can only do that if it somehow
the outer address of the NAT B, that is, the IPN2 address. If NAT B knows the outer address of the NAT B, that is, the IPN2 address. If
is a static NAT, then its address can be configured to the client's NAT B is a static NAT, then its address can be configured to the
configuration. Other options would be find it using some other client's configuration. Another option would be to find it using
protocol (like DNS), but those are outside of scope of IKEv2. some other protocol (like DNS), but that is outside of scope of
IKEv2.
In this scenario, both client and server are configured to use In this scenario, both the client and server are configured to use
transport mode for the traffic originating from the client node and transport mode for the traffic originating from the client node and
destined to the server. destined to the server.
When the client starts creating the IKEv2 SA and Child SA for sending When the client starts creating the IKEv2 SA and Child SA for sending
traffic to the server, it may have a triggering packet with source IP traffic to the server, it may have a triggering packet with source IP
address of IP1, and a destination IP address of IPN2. Its PAD and address of IP1, and a destination IP address of IPN2. Its Peer
SPD needs to have configuration matching those addresses (or wildcard Authorization Database (PAD) and SPD needs to have a configuration
entries covering them). Because this is transport mode, it uses matching those addresses (or wildcard entries covering them).
exactly same addresses as the traffic selectors and outer IP address
of the IKE packets. For transport mode, it MUST use exactly one IP Because this is transport mode, it uses exactly same addresses as the
address in the TSi and TSr payloads. It can have multiple traffic Traffic Selectors and outer IP address of the IKE packets. For
selectors if it has, for example, multiple port ranges that it wants transport mode, it MUST use exactly one IP address in the TSi and TSr
to negotiate, but all TSi entries must use IP1-IP1 range as the IP payloads. It can have multiple Traffic Selectors if it has, for
addresses, and all TSr entries must have the IPN2-IPN2 range as IP example, multiple port ranges that it wants to negotiate, but all TSi
addresses. The first traffic selector of TSi and TSr SHOULD have entries must use the IP1-IP1 range as the IP addresses, and all TSr
very specific traffic selectors including protocol and port numbers, entries must have the IPN2-IPN2 range as IP addresses. The first
such as from the packet triggering the request. Traffic Selector of TSi and TSr SHOULD have very specific Traffic
Selectors including protocol and port numbers, such as from the
packet triggering the request.
NAT A will then replace the source address of the IKE packet from IP1 NAT A will then replace the source address of the IKE packet from IP1
to IPN1, and NAT B will replace the destination address of the IKE to IPN1, and NAT B will replace the destination address of the IKE
packet from IPN2 to IP2, so when the packet arrives to the server it packet from IPN2 to IP2, so when the packet arrives to the server it
will still have the exactly same traffic selectors which were sent by will still have the exactly same Traffic Selectors that were sent by
the client, but the IP address of the IKE packet has been replaced to the client, but the IP address of the IKE packet has been replaced by
IPN1 and IP2. IPN1 and IP2.
When the server receives this packet, it normally looks in the Peer When the server receives this packet, it normally looks in the Peer
Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based
on the ID and then searches the SPD based on the traffic selectors. on the ID and then searches the SPD based on the Traffic Selectors.
Because IP1 does not really mean anything to the server (it is the Because IP1 does not really mean anything to the server (it is the
address client has behind the NAT), it is useless to do a lookup address client has behind the NAT), it is useless to do a lookup
based on that if transport mode is used. On the other hand, the based on that if transport mode is used. On the other hand, the
server cannot know whether transport mode is allowed by its policy server cannot know whether transport mode is allowed by its policy
before it finds the matching SPD entry. before it finds the matching SPD entry.
In this case, the server should first check that the initiator In this case, the server should first check that the initiator
requested transport mode, and then do address substitution on the requested transport mode, and then do address substitution on the
traffic selectors. It needs to first store the old traffic selector Traffic Selectors. It needs to first store the old Traffic Selector
IP addresses to be used later for the incremental checksum fixup (the IP addresses to be used later for the incremental checksum fixup (the
IP address in the TSi can be stored as the original source address IP address in the TSi can be stored as the original source address
and the IP address in the TSr can be stored as the original and the IP address in the TSr can be stored as the original
destination address). After that, if the other end was detected as destination address). After that, if the other end was detected as
being behind a NAT, the server replaces the IP address in TSi being behind a NAT, the server replaces the IP address in TSi
payloads with the IP address obtained from the source address of the payloads with the IP address obtained from the source address of the
IKE packet received (that is, it replaces IP1 in TSi with IPN1). If IKE packet received (that is, it replaces IP1 in TSi with IPN1). If
the server's end was detected to be behind NAT, it replaces the IP the server's end was detected to be behind NAT, it replaces the IP
address in the TSr payloads with the IP address obtained from the address in the TSr payloads with the IP address obtained from the
destination address of the IKE packet received (that is, it replaces destination address of the IKE packet received (that is, it replaces
IPN2 in TSr with IP2). IPN2 in TSr with IP2).
After this address substitution, both the traffic selectors and the After this address substitution, both the Traffic Selectors and the
IKE UDP source/destination addresses look the same, and the server IKE UDP source/destination addresses look the same, and the server
does SPD lookup based on those new traffic selectors. If an entry is does SPD lookup based on those new Traffic Selectors. If an entry is
found and it allows transport mode, then that entry is used. If an found and it allows transport mode, then that entry is used. If an
entry is found but it does not allow transport mode, then the server entry is found but it does not allow transport mode, then the server
MAY undo the address substitution and redo the SPD lookup using the MAY undo the address substitution and redo the SPD lookup using the
original traffic selectors. If the second lookup succeeds, the original Traffic Selectors. If the second lookup succeeds, the
server will create an SA in tunnel mode using real traffic selectors server will create an SA in tunnel mode using real Traffic Selectors
sent by the other end. sent by the other end.
This address substitution in transport mode is needed because the SPD This address substitution in transport mode is needed because the SPD
is looked up using the addresses that will be seen by the local host. is looked up using the addresses that will be seen by the local host.
This also will make sure the SAD entries for the tunnel exit checks This also will make sure the Security Association Database (SAD)
and return packets is added using the addresses as seen by the local entries for the tunnel exit checks and return packets is added using
operating system stack. the addresses as seen by the local operating system stack.
The most common case is that the server's SPD will contain wildcard The most common case is that the server's SPD will contain wildcard
entries matching any addresses, but this allows also making different entries matching any addresses, but this also allows making different
SPD entries, for example, for different known NATs' outer addresses. SPD entries, for example, for different known NATs' outer addresses.
After the SPD lookup, the server will do traffic selector narrowing After the SPD lookup, the server will do Traffic Selector narrowing
based on the SPD entry it found. It will again use the already- based on the SPD entry it found. It will again use the already
substituted traffic selectors, and it will thus send back traffic substituted Traffic Selectors, and it will thus send back Traffic
selectors having IPN1 and IP2 as their IP addresses; it can still Selectors having IPN1 and IP2 as their IP addresses; it can still
narrow down the protocol number or port ranges used by the traffic narrow down the protocol number or port ranges used by the Traffic
selectors. The SAD entry created for the Child SA will have the Selectors. The SAD entry created for the Child SA will have the
addresses as seen by the server, namely IPN1 and IP2. addresses as seen by the server, namely IPN1 and IP2.
When the client receives the server's response to the Child SA, it When the client receives the server's response to the Child SA, it
will do similar processing. If the transport mode SA was created, will do similar processing. If the transport mode SA was created,
the client can store the original returned traffic selectors as the client can store the original returned Traffic Selectors as
original source and destination addresses. It will replace the IP original source and destination addresses. It will replace the IP
addresses in the traffic selectors with the ones from the IP header addresses in the Traffic Selectors with the ones from the IP header
of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2. of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2.
Then it will use those traffic selectors when verifying the SA Then, it will use those Traffic Selectors when verifying the SA
against sent traffic selectors, and when installing the SAD entry. against sent Traffic Selectors, and when installing the SAD entry.
A summary of the rules for NAT-traversal in transport mode is: A summary of the rules for NAT traversal in transport mode is:
For the client proposing transport mode: For the client proposing transport mode:
- The TSi entries MUST have exactly one IP address, and that MUST - The TSi entries MUST have exactly one IP address, and that MUST
match the source address of the IKE SA. match the source address of the IKE SA.
- The TSr entries MUST have exactly one IP address, and that MUST - The TSr entries MUST have exactly one IP address, and that MUST
match the destination address of the IKE SA. match the destination address of the IKE SA.
- The first TSi and TSr traffic selectors SHOULD have very specific - The first TSi and TSr Traffic Selectors SHOULD have very specific
traffic selectors including protocol and port numbers, such as Traffic Selectors including protocol and port numbers, such as
from the packet triggering the request. from the packet triggering the request.
- There MAY be multiple TSi and TSr entries. - There MAY be multiple TSi and TSr entries.
- If transport mode for the SA was selected (that is, if the server - If transport mode for the SA was selected (that is, if the server
included USE_TRANSPORT_MODE notification in its response): included USE_TRANSPORT_MODE notification in its response):
- Store the original traffic selectors as the received source and - Store the original Traffic Selectors as the received source and
destination address. destination address.
- If the server is behind a NAT, substitute the IP address in the - If the server is behind a NAT, substitute the IP address in the
TSr entries with the remote address of the IKE SA. TSr entries with the remote address of the IKE SA.
- If the client is behind a NAT, substitute the IP address in the - If the client is behind a NAT, substitute the IP address in the
TSi entries with the local address of the IKE SA. TSi entries with the local address of the IKE SA.
- Do address substitution before using those traffic selectors - Do address substitution before using those Traffic Selectors
for anything else other than storing original content of them. for anything other than storing original content of them.
This includes verification that traffic selectors were narrowed This includes verification that Traffic Selectors were narrowed
correctly by other end, creation of the SAD entry, and so on. correctly by the other end, creation of the SAD entry, and so on.
For the responder, when transport mode is proposed by client: For the responder, when transport mode is proposed by client:
- Store the original traffic selector IP addresses as received source - Store the original Traffic Selector IP addresses as received source
and destination address, both in case we need to undo address and destination address, in case undo address
substitution, and to use as the "real source and destination substitution is needed, to use as the "real source and destination
address" specified by [UDPENCAPS], and for TCP/UDP checksum fixup. address" specified by [UDPENCAPS], and for TCP/UDP checksum fixup.
- If the client is behind a NAT, substitute the IP address in the - If the client is behind a NAT, substitute the IP address in the
TSi entries with the remote address of the IKE SA. TSi entries with the remote address of the IKE SA.
- If the server is behind a NAT substitute the IP address in the - If the server is behind a NAT, substitute the IP address in the
TSr entries with the local address of the IKE SA. TSr entries with the local address of the IKE SA.
- Do PAD and SPD lookup using the ID and substituted traffic - Do PAD and SPD lookup using the ID and substituted Traffic
selectors. Selectors.
- If no SPD entry was found, or if found SPD entry does not - If no SPD entry was found, or if found SPD entry does not
allow transport mode, undo the traffic selector substitutions. allow transport mode, undo the Traffic Selector substitutions.
Do PAD and SPD lookup again using the ID and original traffic Do PAD and SPD lookup again using the ID and original Traffic
selectors, but also searching for tunnel mode SPD entry (that Selectors, but also searching for tunnel mode SPD entry (that
is, fall back to tunnel mode). is, fall back to tunnel mode).
- However, if a transport mode SPD entry was found, do normal - However, if a transport mode SPD entry was found, do normal
traffic selection narrowing based on the substituted traffic traffic selection narrowing based on the substituted Traffic
selectors and SPD entry. Use the resulting traffic selectors when Selectors and SPD entry. Use the resulting Traffic Selectors when
creating SAD entries, and when sending traffic selectors back to creating SAD entries, and when sending Traffic Selectors back to
the client. the client.
2.24. Explicit Congestion Notification (ECN) 2.24. Explicit Congestion Notification (ECN)
When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
ECN usage is not appropriate for the outer IP headers because tunnel ECN usage is not appropriate for the outer IP headers because tunnel
decapsulation processing discards ECN congestion indications to the decapsulation processing discards ECN congestion indications to the
detriment of the network. ECN support for IPsec tunnels for IKEv1- detriment of the network. ECN support for IPsec tunnels for IKEv1-
based IPsec requires multiple operating modes and negotiation (see based IPsec requires multiple operating modes and negotiation (see
[ECN]). IKEv2 simplifies this situation by requiring that ECN be [ECN]). IKEv2 simplifies this situation by requiring that ECN be
usable in the outer IP headers of all tunnel-mode Child SAs created usable in the outer IP headers of all tunnel mode Child SAs created
by IKEv2. Specifically, tunnel encapsulators and decapsulators for by IKEv2. Specifically, tunnel encapsulators and decapsulators for
all tunnel-mode SAs created by IKEv2 MUST support the ECN full- all tunnel mode SAs created by IKEv2 MUST support the ECN full-
functionality option for tunnels specified in [ECN] and MUST functionality option for tunnels specified in [ECN] and MUST
implement the tunnel encapsulation and decapsulation processing implement the tunnel encapsulation and decapsulation processing
specified in [IPSECARCH] to prevent discarding of ECN congestion specified in [IPSECARCH] to prevent discarding of ECN congestion
indications. indications.
2.25. Exchange Collisions 2.25. Exchange Collisions
Because IKEv2 exchanges can be initiated by either peer, it is Because IKEv2 exchanges can be initiated by either peer, it is
possible that two exchanges affecting the same SA partly overlap. possible that two exchanges affecting the same SA partly overlap.
This can lead to a situation where the SA state information is This can lead to a situation where the SA state information is
skipping to change at line 3206 skipping to change at page 68, line 42
size of 1, and recommends solutions. size of 1, and recommends solutions.
A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives
a request that cannot be completed due to a temporary condition such a request that cannot be completed due to a temporary condition such
as a rekeying operation. When a peer receives a TEMPORARY_FAILURE as a rekeying operation. When a peer receives a TEMPORARY_FAILURE
notification, it MUST NOT immediately retry the operation; it MUST notification, it MUST NOT immediately retry the operation; it MUST
wait so that the sender may complete whatever operation caused the wait so that the sender may complete whatever operation caused the
temporary condition. The recipient MAY retry the request one or more temporary condition. The recipient MAY retry the request one or more
times over a period of several minutes. If a peer continues to times over a period of several minutes. If a peer continues to
receive TEMPORARY_FAILURE on the same IKE SA after several minutes, receive TEMPORARY_FAILURE on the same IKE SA after several minutes,
it SHOULD conclude that the state information is out-of-sync and it SHOULD conclude that the state information is out of sync and
close the IKE SA. close the IKE SA.
A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
a request to rekey a Child SA that does not exist. The SA that the a request to rekey a Child SA that does not exist. The SA that the
initiator attempted to rekey is indicated by the SPI field in the initiator attempted to rekey is indicated by the SPI field in the
Notify Payload, which is copied from the SPI field in the REKEY_SA Notify payload, which is copied from the SPI field in the REKEY_SA
notification. A peer that receives a CHILD_SA_NOT_FOUND notification notification. A peer that receives a CHILD_SA_NOT_FOUND notification
SHOULD silently delete the Child SA (if it still exists) and send a SHOULD silently delete the Child SA (if it still exists) and send a
request to create a new Child SA from scratch (if the Child SA does request to create a new Child SA from scratch (if the Child SA does
not yet exist). not yet exist).
2.25.1. Collisions While Rekeying or Closing Child SAs 2.25.1. Collisions while Rekeying or Closing Child SAs
If a peer receives a request to rekey a Child SA that it is currently If a peer receives a request to rekey a Child SA that it is currently
trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer
receives a request to rekey a Child SA that it is currently rekeying, receives a request to rekey a Child SA that it is currently rekeying,
it SHOULD reply as usual, and SHOULD prepare to close redundant SAs it SHOULD reply as usual, and SHOULD prepare to close redundant SAs
later based on the nonces (see Section 2.8.1). If a peer receives a later based on the nonces (see Section 2.8.1). If a peer receives a
request to rekey a Child SA that does not exist, it SHOULD reply with request to rekey a Child SA that does not exist, it SHOULD reply with
CHILD_SA_NOT_FOUND. CHILD_SA_NOT_FOUND.
If a peer receives a request to close a Child SA that it is currently If a peer receives a request to close a Child SA that it is currently
trying to close, it SHOULD reply without Delete payloads (see trying to close, it SHOULD reply without a Delete payload (see
Section 1.4.1). If a peer receives a request to close a Child SA Section 1.4.1). If a peer receives a request to close a Child SA
that it is currently rekeying, it SHOULD reply as usual, with a that it is currently rekeying, it SHOULD reply as usual, with a
Delete payload. If a peer receives a request to close a Child SA Delete payload. If a peer receives a request to close a Child SA
that does not exist, it SHOULD reply without Delete payloads. that does not exist, it SHOULD reply without a Delete payload.
If a peer receives a request to rekey the IKE SA, and it is currently If a peer receives a request to rekey the IKE SA, and it is currently
creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD
reply with TEMPORARY_FAILURE. reply with TEMPORARY_FAILURE.
2.25.2. Collisions While Rekeying or Closing IKE SAs 2.25.2. Collisions while Rekeying or Closing IKE SAs
If a peer receives a request to rekey an IKE SA that it is currently If a peer receives a request to rekey an IKE SA that it is currently
rekeying, it SHOULD reply as usual, and SHOULD prepare to close rekeying, it SHOULD reply as usual, and SHOULD prepare to close
redundant SAs and move inherited Child SAs later based on the nonces redundant SAs and move inherited Child SAs later based on the nonces
(see Section 2.8.2). If a peer receives a request to rekey an IKE SA (see Section 2.8.2). If a peer receives a request to rekey an IKE SA
that it is currently trying to close, it SHOULD reply with that it is currently trying to close, it SHOULD reply with
TEMPORARY_FAILURE. TEMPORARY_FAILURE.
If a peer receives a request to close an IKE SA that it is currently If a peer receives a request to close an IKE SA that it is currently
rekeying, it SHOULD reply as usual, and forget about its own rekeying rekeying, it SHOULD reply as usual, and forget about its own rekeying
skipping to change at line 3278 skipping to change at page 70, line 16
"UNSPECIFIED" in implementations that are meant to be interoperable. "UNSPECIFIED" in implementations that are meant to be interoperable.
3.1. The IKE Header 3.1. The IKE Header
IKE messages use UDP ports 500 and/or 4500, with one IKE message per IKE messages use UDP ports 500 and/or 4500, with one IKE message per
UDP datagram. Information from the beginning of the packet through UDP datagram. Information from the beginning of the packet through
the UDP header is largely ignored except that the IP addresses and the UDP header is largely ignored except that the IP addresses and
UDP ports from the headers are reversed and used for return packets. UDP ports from the headers are reversed and used for return packets.
When sent on UDP port 500, IKE messages begin immediately following When sent on UDP port 500, IKE messages begin immediately following
the UDP header. When sent on UDP port 4500, IKE messages have the UDP header. When sent on UDP port 4500, IKE messages have
prepended four octets of zero. These four octets of zero are not prepended four octets of zero. These four octets of zeros are not
part of the IKE message and are not included in any of the length part of the IKE message and are not included in any of the length
fields or checksums defined by IKE. Each IKE message begins with the fields or checksums defined by IKE. Each IKE message begins with the
IKE header, denoted HDR in this document. Following the header are IKE header, denoted HDR in this document. Following the header are
one or more IKE payloads each identified by a "Next Payload" field in one or more IKE payloads each identified by a "Next Payload" field in
the preceding payload. Payloads are identified in the order in which the preceding payload. Payloads are identified in the order in which
they appear in an IKE message by looking in the "Next Payload" field they appear in an IKE message by looking in the "Next Payload" field
in the IKE header, and subsequently according to the "Next Payload" in the IKE header, and subsequently according to the "Next Payload"
field in the IKE payload itself until a "Next Payload" field of zero field in the IKE payload itself until a "Next Payload" field of zero
indicates that no payloads follow. If a payload of type "Encrypted" indicates that no payloads follow. If a payload of type "Encrypted"
is found, that payload is decrypted and its contents parsed as is found, that payload is decrypted and its contents parsed as
additional payloads. An Encrypted payload MUST be the last payload additional payloads. An Encrypted payload MUST be the last payload
in a packet and an Encrypted payload MUST NOT contain another in a packet and an Encrypted payload MUST NOT contain another
Encrypted payload. Encrypted payload.
The responder's SPI in the header identifies an instance of an IKE The responder's SPI in the header identifies an instance of an IKE
security association. It is therefore possible for a single instance Security Association. It is therefore possible for a single instance
of IKE to multiplex distinct sessions with multiple peers, including of IKE to multiplex distinct sessions with multiple peers, including
multiple sessions per peer. multiple sessions per peer.
All multi-octet fields representing integers are laid out in big All multi-octet fields representing integers are laid out in big
endian order (also known as "most significant byte first", or endian order (also known as "most significant byte first", or
"network byte order"). "network byte order").
The format of the IKE header is shown in Figure 4. The format of the IKE header is shown in Figure 4.
1 2 3 1 2 3
skipping to change at line 3323 skipping to change at page 71, line 26
| Next Payload | MjVer | MnVer | Exchange Type | Flags | | Next Payload | MjVer | MnVer | Exchange Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IKE Header Format Figure 4: IKE Header Format
o Initiator's SPI (8 octets) - A value chosen by the initiator to o Initiator's SPI (8 octets) - A value chosen by the initiator to
identify a unique IKE security association. This value MUST NOT identify a unique IKE Security Association. This value MUST NOT
be zero. be zero.
o Responder's SPI (8 octets) - A value chosen by the responder to o Responder's SPI (8 octets) - A value chosen by the responder to
identify a unique IKE security association. This value MUST be identify a unique IKE Security Association. This value MUST be
zero in the first message of an IKE Initial Exchange (including zero in the first message of an IKE initial exchange (including
repeats of that message including a cookie). repeats of that message including a cookie).
o Next Payload (1 octet) - Indicates the type of payload that o Next Payload (1 octet) - Indicates the type of payload that
immediately follows the header. The format and value of each immediately follows the header. The format and value of each
payload are defined below. payload are defined below.
o Major Version (4 bits) - Indicates the major version of the IKE o Major Version (4 bits) - Indicates the major version of the IKE
protocol in use. Implementations based on this version of IKE protocol in use. Implementations based on this version of IKE
MUST set the Major Version to 2. Implementations based on MUST set the major version to 2. Implementations based on
previous versions of IKE and ISAKMP MUST set the Major Version to previous versions of IKE and ISAKMP MUST set the major version to
1. Implementations based on this version of IKE MUST reject or 1. Implementations based on this version of IKE MUST reject or
ignore messages containing a version number greater than 2 with an ignore messages containing a version number greater than 2 with an
INVALID_MAJOR_VERSION notification message as described in Section INVALID_MAJOR_VERSION notification message as described in Section
2.5. 2.5.
o Minor Version (4 bits) - Indicates the minor version of the IKE o Minor Version (4 bits) - Indicates the minor version of the IKE
protocol in use. Implementations based on this version of IKE protocol in use. Implementations based on this version of IKE
MUST set the Minor Version to 0. They MUST ignore the minor MUST set the minor version to 0. They MUST ignore the minor
version number of received messages. version number of received messages.
o Exchange Type (1 octet) - Indicates the type of exchange being o Exchange Type (1 octet) - Indicates the type of exchange being
used. This constrains the payloads sent in each message in an used. This constrains the payloads sent in each message in an
exchange. The values in the following table are only current as exchange. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest document. Readers should refer to [IKEV2IANA] for the latest
values. values.
skipping to change at line 3372 skipping to change at page 72, line 28
INFORMATIONAL 37 INFORMATIONAL 37
o Flags (1 octet) - Indicates specific options that are set for the o Flags (1 octet) - Indicates specific options that are set for the
message. Presence of options is indicated by the appropriate bit message. Presence of options is indicated by the appropriate bit
in the flags field being set. The bits are as follows: in the flags field being set. The bits are as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X| |X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
In the description below, a bit being 'set' means its value is In the description below, a bit being 'set' means its value is '1',
'1', while 'cleared' means its value is '0'. "X" bits MUST be while 'cleared' means its value is '0'. 'X' bits MUST be cleared
cleared when sending and MUST be ignored on receipt. when sending and MUST be ignored on receipt.
* R (Response) - This bit indicates that this message is a * R (Response) - This bit indicates that this message is a
response to a message containing the same message ID. This bit response to a message containing the same Message ID. This bit
MUST be cleared in all request messages and MUST be set in all MUST be cleared in all request messages and MUST be set in all
responses. An IKE endpoint MUST NOT generate a response to a responses. An IKE endpoint MUST NOT generate a response to a
message that is marked as being a response (with one exception; message that is marked as being a response (with one exception;
see Section 2.21.2). see Section 2.21.2).
* V (Version) - This bit indicates that the transmitter is * V (Version) - This bit indicates that the transmitter is
capable of speaking a higher major version number of the capable of speaking a higher major version number of the
protocol than the one indicated in the major version number protocol than the one indicated in the major version number
field. Implementations of IKEv2 MUST clear this bit when field. Implementations of IKEv2 MUST clear this bit when
sending and MUST ignore it in incoming messages. sending and MUST ignore it in incoming messages.
skipping to change at line 3400 skipping to change at page 73, line 9
original initiator of the IKE SA and MUST be cleared in original initiator of the IKE SA and MUST be cleared in
messages sent by the original responder. It is used by the messages sent by the original responder. It is used by the
recipient to determine which eight octets of the SPI were recipient to determine which eight octets of the SPI were
generated by the recipient. This bit changes to reflect who generated by the recipient. This bit changes to reflect who
initiated the last rekey of the IKE SA. initiated the last rekey of the IKE SA.
o Message ID (4 octets, unsigned integer) - Message identifier used o Message ID (4 octets, unsigned integer) - Message identifier used
to control retransmission of lost packets and matching of requests to control retransmission of lost packets and matching of requests
and responses. It is essential to the security of the protocol and responses. It is essential to the security of the protocol
because it is used to prevent message replay attacks. See because it is used to prevent message replay attacks. See
Section 2.1 and Section 2.2. Sections 2.1 and 2.2.
o Length (4 octets, unsigned integer) - Length of total message o Length (4 octets, unsigned integer) - Length of the total message
(header + payloads) in octets. (header + payloads) in octets.
3.2. Generic Payload Header 3.2. Generic Payload Header
Each IKE payload defined in Section 3.3 through Section 3.16 begins Each IKE payload defined in Sections 3.3 through 3.16 begins with a
with a generic payload header, shown in Figure 5. Figures for each generic payload header, shown in Figure 5. Figures for each payload
payload below will include the generic payload header, but for below will include the generic payload header, but for brevity, the
brevity the description of each field will be omitted. description of each field will be omitted.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Generic Payload Header Figure 5: Generic Payload Header
The Generic Payload Header fields are defined as follows: The Generic Payload Header fields are defined as follows:
skipping to change at line 3477 skipping to change at page 74, line 41
payload type code in the Next Payload field of the previous payload type code in the Next Payload field of the previous
payload. MUST be set to one if the sender wants the recipient to payload. MUST be set to one if the sender wants the recipient to
reject this entire message if it does not understand the payload reject this entire message if it does not understand the payload
type. MUST be ignored by the recipient if the recipient type. MUST be ignored by the recipient if the recipient
understands the payload type code. MUST be set to zero for understands the payload type code. MUST be set to zero for
payload types defined in this document. Note that the critical payload types defined in this document. Note that the critical
bit applies to the current payload rather than the "next" payload bit applies to the current payload rather than the "next" payload
whose type code appears in the first octet. The reasoning behind whose type code appears in the first octet. The reasoning behind
not setting the critical bit for payloads defined in this document not setting the critical bit for payloads defined in this document
is that all implementations MUST understand all payload types is that all implementations MUST understand all payload types
defined in this document and therefore must ignore the Critical defined in this document and therefore must ignore the critical
bit's value. Skipped payloads are expected to have valid Next bit's value. Skipped payloads are expected to have valid Next
Payload and Payload Length fields. See Section 2.5 for more Payload and Payload Length fields. See Section 2.5 for more
information on this bit. information on this bit.
o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
receipt. receipt.
o Payload Length (2 octets, unsigned integer) - Length in octets of o Payload Length (2 octets, unsigned integer) - Length in octets of
the current payload, including the generic payload header. the current payload, including the generic payload header.
Many payloads contain fields marked as "RESERVED". Some payloads in Many payloads contain fields marked as "RESERVED". Some payloads in
IKEv2 (and historically in IKEv1) are not aligned to 4-octet IKEv2 (and historically in IKEv1) are not aligned to 4-octet
boundaries. boundaries.
3.3. Security Association Payload 3.3. Security Association Payload
The Security Association Payload, denoted SA in this document, is The Security Association payload, denoted SA in this document, is
used to negotiate attributes of a security association. Assembly of used to negotiate attributes of a Security Association. Assembly of
Security Association Payloads requires great peace of mind. An SA Security Association payloads requires great peace of mind. An SA
payload MAY contain multiple proposals. If there is more than one, payload MAY contain multiple proposals. If there is more than one,
they MUST be ordered from most preferred to least preferred. Each they MUST be ordered from most preferred to least preferred. Each
proposal contains a single IPsec protocol (where a protocol is IKE, proposal contains a single IPsec protocol (where a protocol is IKE,
ESP, or AH), each protocol MAY contain multiple transforms, and each ESP, or AH), each protocol MAY contain multiple transforms, and each
transform MAY contain multiple attributes. When parsing an SA, an transform MAY contain multiple attributes. When parsing an SA, an
implementation MUST check that the total Payload Length is consistent implementation MUST check that the total Payload Length is consistent
with the payload's internal lengths and counts. Proposals, with the payload's internal lengths and counts. Proposals,
Transforms, and Attributes each have their own variable length Transforms, and Attributes each have their own variable-length
encodings. They are nested such that the Payload Length of an SA encodings. They are nested such that the Payload Length of an SA
includes the combined contents of the SA, Proposal, Transform, and includes the combined contents of the SA, Proposal, Transform, and
Attribute information. The length of a Proposal includes the lengths Attribute information. The length of a Proposal includes the lengths
of all Transforms and Attributes it contains. The length of a of all Transforms and Attributes it contains. The length of a
Transform includes the lengths of all Attributes it contains. Transform includes the lengths of all Attributes it contains.
The syntax of Security Associations, Proposals, Transforms, and The syntax of Security Associations, Proposals, Transforms, and
Attributes is based on ISAKMP; however the semantics are somewhat Attributes is based on ISAKMP; however, the semantics are somewhat
different. The reason for the complexity and the hierarchy is to different. The reason for the complexity and the hierarchy is to
allow for multiple possible combinations of algorithms to be encoded allow for multiple possible combinations of algorithms to be encoded
in a single SA. Sometimes there is a choice of multiple algorithms, in a single SA. Sometimes there is a choice of multiple algorithms,
whereas other times there is a combination of algorithms. For whereas other times there is a combination of algorithms. For
example, an initiator might want to propose using ESP with either example, an initiator might want to propose using ESP with either
(3DES and HMAC_MD5) or (AES and HMAC_SHA1). (3DES and HMAC_MD5) or (AES and HMAC_SHA1).
One of the reasons the semantics of the SA payload has changed from One of the reasons the semantics of the SA payload have changed from
ISAKMP and IKEv1 is to make the encodings more compact in common ISAKMP and IKEv1 is to make the encodings more compact in common
cases. cases.
The Proposal structure contains within it a Proposal Num and an IPsec The Proposal structure contains within it a Proposal Num and an IPsec
protocol ID. Each structure MUST have a proposal number one (1) protocol ID. Each structure MUST have a proposal number one (1)
greater than the previous structure. The first Proposal in the greater than the previous structure. The first Proposal in the
initiator's SA payload MUST have a Proposal Num of one (1). One initiator's SA payload MUST have a Proposal Num of one (1). One
reason to use multiple proposals is to propose both standard crypto reason to use multiple proposals is to propose both standard crypto
ciphers and combined-mode ciphers. Combined-mode ciphers include ciphers and combined-mode ciphers. Combined-mode ciphers include
both integrity and encryption in a single encryption algorithm, and both integrity and encryption in a single encryption algorithm, and
MUST either offer no integrity algorithm or a single integrity MUST either offer no integrity algorithm or a single integrity
algorithm of "none", with no integrity algorithm being the algorithm of "none", with no integrity algorithm being the
RECOMMENDED method. If an initiator wants to propose both combined- RECOMMENDED method. If an initiator wants to propose both combined-
mode ciphers and normal ciphers, it must include two proposals: one mode ciphers and normal ciphers, it must include two proposals: one
will have all the combined-mode ciphers, and the other will have all will have all the combined-mode ciphers, and the other will have all
the normal ciphers with the integrity algorithms. For example, one the normal ciphers with the integrity algorithms. For example, one
such proposal would have two proposal structures. Proposal 1 is ESP such proposal would have two proposal structures. Proposal 1 is ESP
with AES-128, AES-192, and AES-256 bits in CBC mode, with either with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining
HMAC-SHA1-96 or XCBC-96 as the integrity algorithm; Proposal 2 is (CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity
AES-128 or AES-256 in GCM mode with an 8-octet ICV. Both proposals algorithm; Proposal 2 is AES-128 or AES-256 in GCM mode with an
allow but do not require the use of ESN (extended sequence numbers). 8-octet Integrity Check Value (ICV). Both proposals allow but do not
This can be illustrated as: require the use of ESNs (Extended Sequence Numbers). This can be
illustrated as:
SA Payload SA Payload
| |
+--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
| | 7 transforms, SPI = 0x052357bb ) | | 7 transforms, SPI = 0x052357bb )
| | | |
| +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 128 ) | | +-- Attribute ( Key Length = 128 )
| | | |
| +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Transform ENCR ( Name = ENCR_AES_CBC )
skipping to change at line 3578 skipping to change at page 76, line 47
| |
+-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
| +-- Attribute ( Key Length = 256 ) | +-- Attribute ( Key Length = 256 )
| |
+-- Transform ESN ( Name = ESNs ) +-- Transform ESN ( Name = ESNs )
+-- Transform ESN ( Name = No ESNs ) +-- Transform ESN ( Name = No ESNs )
Each Proposal/Protocol structure is followed by one or more transform Each Proposal/Protocol structure is followed by one or more transform
structures. The number of different transforms is generally structures. The number of different transforms is generally
determined by the Protocol. AH generally has two transforms: determined by the Protocol. AH generally has two transforms:
Extended Sequence Numbers (ESN) and an integrity check algorithm. Extended Sequence Numbers (ESNs) and an integrity check algorithm.
ESP generally has three: ESN, an encryption algorithm and an ESP generally has three: ESN, an encryption algorithm, and an
integrity check algorithm. IKE generally has four transforms: a integrity check algorithm. IKE generally has four transforms: a
Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, Diffie-Hellman group, an integrity check algorithm, a PRF algorithm,
and an encryption algorithm. For each Protocol, the set of and an encryption algorithm. For each Protocol, the set of
permissible transforms is assigned transform ID numbers, which appear permissible transforms is assigned Transform ID numbers, which appear
in the header of each transform. in the header of each transform.
If there are multiple transforms with the same Transform Type, the If there are multiple transforms with the same Transform Type, the
proposal is an OR of those transforms. If there are multiple proposal is an OR of those transforms. If there are multiple
Transforms with different Transform Types, the proposal is an AND of transforms with different Transform Types, the proposal is an AND of
the different groups. For example, to propose ESP with (3DES or AES- the different groups. For example, to propose ESP with (3DES or AES-
CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two
Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and
two Transform Type 3 candidates (one for HMAC_MD5 and one for two Transform Type 3 candidates (one for HMAC_MD5 and one for
HMAC_SHA). This effectively proposes four combinations of HMAC_SHA). This effectively proposes four combinations of
algorithms. If the initiator wanted to propose only a subset of algorithms. If the initiator wanted to propose only a subset of
those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there
is no way to encode that as multiple transforms within a single is no way to encode that as multiple transforms within a single
Proposal. Instead, the initiator would have to construct two Proposal. Instead, the initiator would have to construct two
different Proposals, each with two transforms. different Proposals, each with two transforms.
A given transform MAY have one or more Attributes. Attributes are A given transform MAY have one or more Attributes. Attributes are
necessary when the transform can be used in more than one way, as necessary when the transform can be used in more than one way, as
when an encryption algorithm has a variable key size. The transform when an encryption algorithm has a variable key size. The transform
would specify the algorithm and the attribute would specify the key would specify the algorithm and the attribute would specify the key
size. Most transforms do not have attributes. A transform MUST NOT size. Most transforms do not have attributes. A transform MUST NOT
have multiple attributes of the same type. To propose alternate have multiple attributes of the same type. To propose alternate
values for an attribute (for example, multiple key sizes for the AES values for an attribute (for example, multiple key sizes for the AES
encryption algorithm), an implementation MUST include multiple encryption algorithm), an implementation MUST include multiple
Transforms with the same Transform Type each with a single Attribute. transforms with the same Transform Type each with a single Attribute.
Note that the semantics of Transforms and Attributes are quite Note that the semantics of Transforms and Attributes are quite
different from those in IKEv1. In IKEv1, a single Transform carried different from those in IKEv1. In IKEv1, a single Transform carried
multiple algorithms for a protocol with one carried in the Transform multiple algorithms for a protocol with one carried in the Transform
and the others carried in the Attributes. and the others carried in the Attributes.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Proposals> ~ ~ <Proposals> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Security Association Payload Figure 6: Security Association Payload
o Proposals (variable) - One or more proposal substructures. o Proposals (variable) - One or more proposal substructures.
The payload type for the Security Association Payload is thirty three The payload type for the Security Association payload is thirty-three
(33). (33).
3.3.1. Proposal Substructure 3.3.1. Proposal Substructure
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 2 | RESERVED | Proposal Length | | 0 (last) or 2 | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size |Num Transforms| | Proposal Num | Protocol ID | SPI Size |Num Transforms|
skipping to change at line 3654 skipping to change at page 78, line 30
~ <Transforms> ~ ~ <Transforms> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Proposal Substructure Figure 7: Proposal Substructure
o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the
last Proposal Substructure in the SA. This syntax is inherited last Proposal Substructure in the SA. This syntax is inherited
from ISAKMP, but is unnecessary because the last Proposal could be from ISAKMP, but is unnecessary because the last Proposal could be
identified from the length of the SA. The value (2) corresponds identified from the length of the SA. The value (2) corresponds
to a Payload Type of Proposal in IKEv1, and the first four octets to a payload type of Proposal in IKEv1, and the first four octets
of the Proposal structure are designed to look somewhat like the of the Proposal structure are designed to look somewhat like the
header of a Payload. header of a payload.
o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
receipt. receipt.
o Proposal Length (2 octets, unsigned integer) - Length of this o Proposal Length (2 octets, unsigned integer) - Length of this
proposal, including all transforms and attributes that follow. proposal, including all transforms and attributes that follow.
o Proposal Num (1 octet) - When a proposal is made, the first o Proposal Num (1 octet) - When a proposal is made, the first
proposal in an SA payload MUST be 1, and subsequent proposals MUST proposal in an SA payload MUST be 1, and subsequent proposals MUST
be one more than the previous proposal (indicating an OR of the be one more than the previous proposal (indicating an OR of the
skipping to change at line 3720 skipping to change at page 79, line 47
~ Transform Attributes ~ ~ Transform Attributes ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Transform Substructure Figure 8: Transform Substructure
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
last Transform Substructure in the Proposal. This syntax is last Transform Substructure in the Proposal. This syntax is
inherited from ISAKMP, but is unnecessary because the last inherited from ISAKMP, but is unnecessary because the last
transform could be identified from the length of the proposal. transform could be identified from the length of the proposal.
The value (3) corresponds to a Payload Type of Transform in IKEv1, The value (3) corresponds to a payload type of Transform in IKEv1,
and the first four octets of the Transform structure are designed and the first four octets of the Transform structure are designed
to look somewhat like the header of a Payload. to look somewhat like the header of a payload.
o RESERVED - MUST be sent as zero; MUST be ignored on receipt. o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o Transform Length - The length (in octets) of the Transform o Transform Length - The length (in octets) of the Transform
Substructure including Header and Attributes. Substructure including Header and Attributes.
o Transform Type (1 octet) - The type of transform being specified o Transform Type (1 octet) - The type of transform being specified
in this transform. Different protocols support different in this transform. Different protocols support different
transform types. For some protocols, some of the transforms may Transform Types. For some protocols, some of the transforms may
be optional. If a transform is optional and the initiator wishes be optional. If a transform is optional and the initiator wishes
to propose that the transform be omitted, no transform of the to propose that the transform be omitted, no transform of the
given type is included in the proposal. If the initiator wishes given type is included in the proposal. If the initiator wishes
to make use of the transform optional to the responder, it to make use of the transform optional to the responder, it
includes a transform substructure with transform ID = 0 as one of includes a transform substructure with Transform ID = 0 as one of
the options. the options.
o Transform ID (2 octets) - The specific instance of the transform o Transform ID (2 octets) - The specific instance of the Transform
type being proposed. Type being proposed.
The transform type values are listed below. The values in the The Transform Type values are listed below. The values in the
following table are only current as of the publication date of RFC following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be added 4306. Other values may have been added since then or will be added
after the publication of this document. Readers should refer to after the publication of this document. Readers should refer to
[IKEV2IANA] for the latest values. [IKEV2IANA] for the latest values.
Description Trans. Used In Description Trans. Used In
Type Type
------------------------------------------------------------------ ------------------------------------------------------------------
Encryption Algorithm (ENCR) 1 IKE and ESP Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudo-random Function (PRF) 2 IKE Pseudorandom Function (PRF) 2 IKE
Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP
Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP
Extended Sequence Numbers (ESN) 5 AH and ESP Extended Sequence Numbers (ESN) 5 AH and ESP
(*) Negotiating an integrity algorithm is mandatory for the (*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. For example, Encrypted payload format specified in this document. For example,
[AEAD] specifies additional formats based on authenticated [AEAD] specifies additional formats based on authenticated
encryption, in which a separate integrity algorithm is not encryption, in which a separate integrity algorithm is not
negotiated. negotiated.
For Transform Type 1 (Encryption Algorithm), the Transform IDs are For Transform Type 1 (Encryption Algorithm), the Transform IDs are
listed below. The values in the following table are only current as listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values. document. Readers should refer to [IKEV2IANA] for the latest values.
skipping to change at line 3784 skipping to change at page 81, line 20
ENCR_RC5 4 (RFC2451) ENCR_RC5 4 (RFC2451)
ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_IDEA 5 (RFC2451), [IDEA]
ENCR_CAST 6 (RFC2451) ENCR_CAST 6 (RFC2451)
ENCR_BLOWFISH 7 (RFC2451) ENCR_BLOWFISH 7 (RFC2451)
ENCR_3IDEA 8 (UNSPECIFIED) ENCR_3IDEA 8 (UNSPECIFIED)
ENCR_DES_IV32 9 (UNSPECIFIED) ENCR_DES_IV32 9 (UNSPECIFIED)
ENCR_NULL 11 (RFC2410) ENCR_NULL 11 (RFC2410)
ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CBC 12 (RFC3602)
ENCR_AES_CTR 13 (RFC3686) ENCR_AES_CTR 13 (RFC3686)
For Transform Type 2 (Pseudo-random Function), the Transform IDs are For Transform Type 2 (Pseudorandom Function), the Transform IDs are
listed below. The values in the following table are only current as listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values. document. Readers should refer to [IKEV2IANA] for the latest values.
Name Number Defined In Name Number Defined In
------------------------------------------------------ ------------------------------------------------------
PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_MD5 1 (RFC2104), [MD5]
PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_SHA1 2 (RFC2104), [SHA]
PRF_HMAC_TIGER 3 (UNSPECIFIED) PRF_HMAC_TIGER 3 (UNSPECIFIED)
skipping to change at line 3811 skipping to change at page 81, line 47
Name Number Defined In Name Number Defined In
---------------------------------------- ----------------------------------------
NONE 0 NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_HMAC_SHA1_96 2 (RFC2404)
AUTH_DES_MAC 3 (UNSPECIFIED) AUTH_DES_MAC 3 (UNSPECIFIED)
AUTH_KPDK_MD5 4 (UNSPECIFIED) AUTH_KPDK_MD5 4 (UNSPECIFIED)
AUTH_AES_XCBC_96 5 (RFC3566) AUTH_AES_XCBC_96 5 (RFC3566)
For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs For Transform Type 4 (Diffie-Hellman group), defined Transform IDs
are listed below. The values in the following table are only current are listed below. The values in the following table are only current
as of the publication date of RFC 4306. Other values may have been as of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values. document. Readers should refer to [IKEV2IANA] for the latest values.
Name Number Defined in Name Number Defined In
---------------------------------------- ----------------------------------------
NONE 0 NONE 0
768 Bit MODP 1 Appendix B 768-bit MODP 1 Appendix B
1024 Bit MODP 2 Appendix B 1024-bit MODP 2 Appendix B
1536-bit MODP 5 [ADDGROUP] 1536-bit MODP 5 [ADDGROUP]
2048-bit MODP 14 [ADDGROUP] 2048-bit MODP 14 [ADDGROUP]
3072-bit MODP 15 [ADDGROUP] 3072-bit MODP 15 [ADDGROUP]
4096-bit MODP 16 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP]
6144-bit MODP 17 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP]
8192-bit MODP 18 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP]
Although ESP and AH do not directly include a Diffie-Hellman Although ESP and AH do not directly include a Diffie-Hellman
exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
skipping to change at line 3852 skipping to change at page 82, line 40
Name Number Name Number
-------------------------------------------- --------------------------------------------
No Extended Sequence Numbers 0 No Extended Sequence Numbers 0
Extended Sequence Numbers 1 Extended Sequence Numbers 1
Note that an initiator who supports ESNs will usually include two ESN Note that an initiator who supports ESNs will usually include two ESN
transforms, with values "0" and "1", in its proposals. A proposal transforms, with values "0" and "1", in its proposals. A proposal
containing a single ESN transform with value "1" means that using containing a single ESN transform with value "1" means that using
normal (non-extended) sequence numbers is not acceptable. normal (non-extended) sequence numbers is not acceptable.
Numerous additional transform types have been defined since the Numerous additional Transform Types have been defined since the
publication of RFC 4306. Please refer to the IANA IKEv2 registry for publication of RFC 4306. Please refer to the IANA IKEv2 registry for
details. details.
3.3.3. Valid Transform Types by Protocol 3.3.3. Valid Transform Types by Protocol
The number and type of transforms that accompany an SA payload are The number and type of transforms that accompany an SA payload are
dependent on the protocol in the SA itself. An SA payload proposing dependent on the protocol in the SA itself. An SA payload proposing
the establishment of an SA has the following mandatory and optional the establishment of an SA has the following mandatory and optional
transform types. A compliant implementation MUST understand all Transform Types. A compliant implementation MUST understand all
mandatory and optional types for each protocol it supports (though it mandatory and optional types for each protocol it supports (though it
need not accept proposals with unacceptable suites). A proposal MAY need not accept proposals with unacceptable suites). A proposal MAY
omit the optional types if the only value for them it will accept is omit the optional types if the only value for them it will accept is
NONE. NONE.
Protocol Mandatory Types Optional Types Protocol Mandatory Types Optional Types
--------------------------------------------------- ---------------------------------------------------
IKE ENCR, PRF, INTEG*, D-H IKE ENCR, PRF, INTEG*, D-H
ESP ENCR, ESN INTEG, D-H ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H AH INTEG, ESN D-H
(*) Negotiating an integrity algorithm is mandatory for the (*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. For example, Encrypted payload format specified in this document. For example,
[AEAD] specifies additional formats based on authenticated [AEAD] specifies additional formats based on authenticated
encryption, in which a separate integrity algorithm is not encryption, in which a separate integrity algorithm is not
negotiated. negotiated.
3.3.4. Mandatory Transform IDs 3.3.4. Mandatory Transform IDs
The specification of suites that MUST and SHOULD be supported for The specification of suites that MUST and SHOULD be supported for
interoperability has been removed from this document because they are interoperability has been removed from this document because they are
likely to change more rapidly than this document evolves. At the likely to change more rapidly than this document evolves. At the
time of publication of this document, [RFC4307] specifies these time of publication of this document, [RFC4307] specifies these
skipping to change at line 3901 skipping to change at page 83, line 42
It is likely that IANA will add additional transforms in the future, It is likely that IANA will add additional transforms in the future,
and some users may want to use private suites, especially for IKE and some users may want to use private suites, especially for IKE
where implementations should be capable of supporting different where implementations should be capable of supporting different
parameters, up to certain size limits. In support of this goal, all parameters, up to certain size limits. In support of this goal, all
implementations of IKEv2 SHOULD include a management facility that implementations of IKEv2 SHOULD include a management facility that
allows specification (by a user or system administrator) of Diffie- allows specification (by a user or system administrator) of Diffie-
Hellman parameters (the generator, modulus, and exponent lengths and Hellman parameters (the generator, modulus, and exponent lengths and
values) for new Diffie-Hellman groups. Implementations SHOULD values) for new Diffie-Hellman groups. Implementations SHOULD
provide a management interface through which these parameters and the provide a management interface through which these parameters and the
associated transform IDs may be entered (by a user or system associated Transform IDs may be entered (by a user or system
administrator), to enable negotiating such groups. administrator), to enable negotiating such groups.
All implementations of IKEv2 MUST include a management facility that All implementations of IKEv2 MUST include a management facility that
enables a user or system administrator to specify the suites that are enables a user or system administrator to specify the suites that are
acceptable for use with IKE. Upon receipt of a payload with a set of acceptable for use with IKE. Upon receipt of a payload with a set of
transform IDs, the implementation MUST compare the transmitted Transform IDs, the implementation MUST compare the transmitted
transform IDs against those locally configured via the management Transform IDs against those locally configured via the management
controls, to verify that the proposed suite is acceptable based on controls, to verify that the proposed suite is acceptable based on
local policy. The implementation MUST reject SA proposals that are local policy. The implementation MUST reject SA proposals that are
not authorized by these IKE suite controls. Note that cryptographic not authorized by these IKE suite controls. Note that cryptographic
suites that MUST be implemented need not be configured as acceptable suites that MUST be implemented need not be configured as acceptable
to local policy. to local policy.
3.3.5. Transform Attributes 3.3.5. Transform Attributes
Each transform in a Security Association payload may include Each transform in a Security Association payload may include
attributes that modify or complete the specification of the attributes that modify or complete the specification of the
skipping to change at line 3950 skipping to change at page 84, line 43
o Attribute Format (AF) (1 bit) - Indicates whether the data o Attribute Format (AF) (1 bit) - Indicates whether the data
attribute follows the Type/Length/Value (TLV) format or a attribute follows the Type/Length/Value (TLV) format or a
shortened Type/Value (TV) format. If the AF bit is zero (0), then shortened Type/Value (TV) format. If the AF bit is zero (0), then
the attribute uses TLV format; if the AF bit is one (1), the TV the attribute uses TLV format; if the AF bit is one (1), the TV
format (with two-byte value) is used. format (with two-byte value) is used.
o Attribute Type (15 bits) - Unique identifier for each type of o Attribute Type (15 bits) - Unique identifier for each type of
attribute (see below). attribute (see below).
o Attribute Value (variable length) - Value of the Attribute o Attribute Value (variable length) - Value of the attribute
associated with the Attribute Type. If the AF bit is a zero (0), associated with the attribute type. If the AF bit is a zero (0),
this field has a variable length defined by the Attribute Length this field has a variable length defined by the Attribute Length
field. If the AF bit is a one (1), the Attribute Value has a field. If the AF bit is a one (1), the Attribute Value has a
length of 2 octets. length of 2 octets.
The only currently defined attribute type (Key Length) is fixed The only currently defined attribute type (Key Length) is fixed
length; the variable-length encoding specification is included only length; the variable-length encoding specification is included only
for future extensions. Attributes described as fixed length MUST NOT for future extensions. Attributes described as fixed length MUST NOT
be encoded using the variable-length encoding unless that length be encoded using the variable-length encoding unless that length
exceeds two bytes. Variable-length attributes MUST NOT be encoded as exceeds two bytes. Variable-length attributes MUST NOT be encoded as
fixed-length even if their value can fit into two octets. NOTE: This fixed-length even if their value can fit into two octets. Note: This
is a change from IKEv1, where increased flexibility may have is a change from IKEv1, where increased flexibility may have
simplified the composer of messages but certainly complicated the simplified the composer of messages but certainly complicated the
parser. parser.
The values in the following table are only current as of the The values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added since publication date of RFC 4306. Other values may have been added since
then or will be added after the publication of this document. then or will be added after the publication of this document.
Readers should refer to [IKEV2IANA] for the latest values. Readers should refer to [IKEV2IANA] for the latest values.
Attribute Type Value Attribute Format Attribute Type Value Attribute Format
------------------------------------------------------------ ------------------------------------------------------------
Key Length (in bits) 14 TV Key Length (in bits) 14 TV
Values 0-13 and 15-17 were used in a similar context in IKEv1, and Values 0-13 and 15-17 were used in a similar context in IKEv1, and
should not be assigned except to matching values. should not be assigned except to matching values.
The Key Length attribute specifies the key length in bits (MUST use The Key Length attribute specifies the key length in bits (MUST use
network byte order) for certain transforms as follows: network byte order) for certain transforms as follows:
o The Key Length attribute MUST NOT be used with transforms that use o The Key Length attribute MUST NOT be used with transforms that use
a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and a fixed-length key. For example, this includes ENCR_DES,
all the Type 2 (Pseudo-random function) and Type 3 (Integrity ENCR_IDEA, and all the Type 2 (Pseudorandom function) and Type 3
Algorithm) transforms specified in this document. It is (Integrity Algorithm) transforms specified in this document. It
recommended that future Type 2 or 3 transforms do not use this is recommended that future Type 2 or 3 transforms do not use this
attribute. attribute.
o Some transforms specify that the Key Length attribute MUST be o Some transforms specify that the Key Length attribute MUST be
always included (omitting the attribute is not allowed, and always included (omitting the attribute is not allowed, and
proposals not containing it MUST be rejected). This includes, proposals not containing it MUST be rejected). For example, this
e.g., ENCR_AES_CBC and ENCR_AES_CTR. includes ENCR_AES_CBC and ENCR_AES_CTR.
o Some transforms allow variable-length keys, but also specify a o Some transforms allow variable-length keys, but also specify a
default key length if the attribute is not included. These default key length if the attribute is not included. For example,
transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. these transforms include ENCR_RC5 and ENCR_BLOWFISH.
Implementation note: To further interoperability and to support Implementation note: To further interoperability and to support
upgrading endpoints independently, implementers of this protocol upgrading endpoints independently, implementers of this protocol
SHOULD accept values that they deem to supply greater security. For SHOULD accept values that they deem to supply greater security. For
instance, if a peer is configured to accept a variable-length cipher instance, if a peer is configured to accept a variable-length cipher
with a key length of X bits and is offered that cipher with a larger with a key length of X bits and is offered that cipher with a larger
key length, the implementation SHOULD accept the offer if it supports key length, the implementation SHOULD accept the offer if it supports
use of the longer key. use of the longer key.
Support of this capability allows a responder to express a concept of Support for this capability allows a responder to express a concept
"at least" a certain level of security -- "a key length of _at least_ of "at least" a certain level of security -- "a key length of _at
X bits for cipher Y". However, as the attribute is always returned least_ X bits for cipher Y". However, as the attribute is always
unchanged (see the next section), an initiator willing to accept returned unchanged (see the next section), an initiator willing to
multiple key lengths has to include multiple transforms with the same accept multiple key lengths has to include multiple transforms with
Transform Type, each with a different Key Length attribute. the same Transform Type, each with a different Key Length attribute.
3.3.6. Attribute Negotiation 3.3.6. Attribute Negotiation
During security association negotiation initiators present offers to During Security Association negotiation initiators present offers to
responders. Responders MUST select a single complete set of responders. Responders MUST select a single complete set of
parameters from the offers (or reject all offers if none are parameters from the offers (or reject all offers if none are
acceptable). If there are multiple proposals, the responder MUST acceptable). If there are multiple proposals, the responder MUST
choose a single proposal. If the selected proposal has multiple choose a single proposal. If the selected proposal has multiple
Transforms with the same type, the responder MUST choose a single transforms with the same type, the responder MUST choose a single
one. Any attributes of a selected transform MUST be returned one. Any attributes of a selected transform MUST be returned
unmodified. The initiator of an exchange MUST check that the unmodified. The initiator of an exchange MUST check that the
accepted offer is consistent with one of its proposals, and if not accepted offer is consistent with one of its proposals, and if not
MUST terminate the exchange. MUST terminate the exchange.
If the responder receives a proposal that contains a Transform Type If the responder receives a proposal that contains a Transform Type
it does not understand, or a proposal that is missing a mandatory it does not understand, or a proposal that is missing a mandatory
Transform Type, it MUST consider this proposal unacceptable; however, Transform Type, it MUST consider this proposal unacceptable; however,
other proposals in the same SA payload are processed as usual. other proposals in the same SA payload are processed as usual.
Similarly, if the responder receives a transform that it does not Similarly, if the responder receives a transform that it does not
skipping to change at line 4054 skipping to change at page 87, line 7
initiator SHOULD pick an element of that group for its KE value when initiator SHOULD pick an element of that group for its KE value when
retrying the first message. It SHOULD, however, continue to propose retrying the first message. It SHOULD, however, continue to propose
its full supported set of groups in order to prevent a man-in-the- its full supported set of groups in order to prevent a man-in-the-
middle downgrade attack. If one of the proposals offered is for the middle downgrade attack. If one of the proposals offered is for the
Diffie-Hellman group of NONE, and the responder selects that Diffie- Diffie-Hellman group of NONE, and the responder selects that Diffie-
Hellman group, then it MUST ignore the initiator's KE payload and Hellman group, then it MUST ignore the initiator's KE payload and
omit the KE payload from the response. omit the KE payload from the response.
3.4. Key Exchange Payload 3.4. Key Exchange Payload
The Key Exchange Payload, denoted KE in this document, is used to The Key Exchange payload, denoted KE in this document, is used to
exchange Diffie-Hellman public numbers as part of a Diffie-Hellman exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
key exchange. The Key Exchange Payload consists of the IKE generic key exchange. The Key Exchange payload consists of the IKE generic
payload header followed by the Diffie-Hellman public value itself. payload header followed by the Diffie-Hellman public value itself.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num | RESERVED | | Diffie-Hellman Group Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Key Exchange Data ~ ~ Key Exchange Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Key Exchange Payload Format Figure 10: Key Exchange Payload Format
A key exchange payload is constructed by copying one's Diffie-Hellman A Key Exchange payload is constructed by copying one's Diffie-Hellman
public value into the "Key Exchange Data" portion of the payload. public value into the "Key Exchange Data" portion of the payload.
The length of the Diffie-Hellman public value for MODP groups MUST be The length of the Diffie-Hellman public value for modular
equal to the length of the prime modulus over which the exponentiation group (MODP) groups MUST be equal to the length of the
exponentiation was performed, prepending zero bits to the value if prime modulus over which the exponentiation was performed, prepending
necessary. zero bits to the value if necessary.
The Diffie-Hellman Group Num identifies the Diffie-Hellman group in The Diffie-Hellman Group Num identifies the Diffie-Hellman group in
which the Key Exchange Data was computed (see Section 3.3.2). This which the Key Exchange Data was computed (see Section 3.3.2). This
Diffie-Hellman Group Num MUST match a Diffie-Hellman Group specified Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified
in a proposal in the SA payload that is sent in the same message, and in a proposal in the SA payload that is sent in the same message, and
SHOULD match the Diffie-Hellman group in the first group in the first SHOULD match the Diffie-Hellman group in the first group in the first
proposal, if such exists. If none of the proposals in that SA proposal, if such exists. If none of the proposals in that SA
payload specifies a Diffie-Hellman Group, the KE payload MUST NOT be payload specifies a Diffie-Hellman group, the KE payload MUST NOT be
present. If the selected proposal uses a different Diffie-Hellman present. If the selected proposal uses a different Diffie-Hellman
group (other than NONE), the message MUST be rejected with a Notify group (other than NONE), the message MUST be rejected with a Notify
payload of type INVALID_KE_PAYLOAD. See also Section 1.2 and payload of type INVALID_KE_PAYLOAD. See also Sections 1.2 and 2.7.
Section 2.7.
The payload type for the Key Exchange payload is thirty four (34). The payload type for the Key Exchange payload is thirty-four (34).
3.5. Identification Payloads 3.5. Identification Payloads
The Identification Payloads, denoted IDi and IDr in this document, The Identification payloads, denoted IDi and IDr in this document,
allow peers to assert an identity to one another. This identity may allow peers to assert an identity to one another. This identity may
be used for policy lookup, but does not necessarily have to match be used for policy lookup, but does not necessarily have to match
anything in the CERT payload; both fields may be used by an anything in the CERT payload; both fields may be used by an
implementation to perform access control decisions. When using the implementation to perform access control decisions. When using the
ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
does not require this address to match the address in the IP header does not require this address to match the address in the IP header
of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IKEv2 packets, or anything in the TSi/TSr payloads. The contents
of IDi/IDr is used purely to fetch the policy and authentication data of IDi/IDr are used purely to fetch the policy and authentication
related to the other party. data related to the other party.
NOTE: In IKEv1, two ID payloads were used in each direction to hold NOTE: In IKEv1, two ID payloads were used in each direction to hold
Traffic Selector (TS) information for data passing over the SA. In Traffic Selector (TS) information for data passing over the SA. In
IKEv2, this information is carried in TS payloads (see Section 3.13). IKEv2, this information is carried in TS payloads (see Section 3.13).
The Peer Authorization Database (PAD) as described in RFC 4301 The Peer Authorization Database (PAD) as described in RFC 4301
[IPSECARCH] describes the use of the ID payload in IKEv2 and provides [IPSECARCH] describes the use of the ID payload in IKEv2 and provides
a formal model for the binding of identity to policy in addition to a formal model for the binding of identity to policy in addition to
providing services that deal more specifically with the details of providing services that deal more specifically with the details of
policy enforcement. The PAD is intended to provide a link between policy enforcement. The PAD is intended to provide a link between
the SPD and the IKE security association management. See Section the SPD and the IKE Security Association management. See Section
4.4.3 of RFC 4301 for more details. 4.4.3 of RFC 4301 for more details.
The Identification Payload consists of the IKE generic payload header The Identification payload consists of the IKE generic payload header
followed by identification fields as follows: followed by identification fields as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | RESERVED | | ID Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at line 4145 skipping to change at page 88, line 48
o ID Type (1 octet) - Specifies the type of Identification being o ID Type (1 octet) - Specifies the type of Identification being
used. used.
o RESERVED - MUST be sent as zero; MUST be ignored on receipt. o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o Identification Data (variable length) - Value, as indicated by the o Identification Data (variable length) - Value, as indicated by the
Identification Type. The length of the Identification Data is Identification Type. The length of the Identification Data is
computed from the size in the ID payload header. computed from the size in the ID payload header.
The payload types for the Identification Payload are thirty five (35) The payload types for the Identification payload are thirty-five (35)
for IDi and thirty six (36) for IDr. for IDi and thirty-six (36) for IDr.
The following table lists the assigned semantics for the The following table lists the assigned semantics for the
Identification Type field. The values in the following table are Identification Type field. The values in the following table are
only current as of the publication date of RFC 4306. Other values only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the publication may have been added since then or will be added after the publication
of this document. Readers should refer to [IKEV2IANA] for the latest of this document. Readers should refer to [IKEV2IANA] for the latest
values. values.
ID Type Value ID Type Value
------------------------------------------------------------------- -------------------------------------------------------------------
ID_IPV4_ADDR 1 ID_IPV4_ADDR 1
A single four (4) octet IPv4 address. A single four (4) octet IPv4 address.
ID_FQDN 2 ID_FQDN 2
A fully-qualified domain name string. An example of a ID_FQDN A fully-qualified domain name string. An example of an ID_FQDN
is, "example.com". The string MUST NOT contain any terminators is "example.com". The string MUST NOT contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined for an "internationalized domain name", the syntax is as defined
in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net".
ID_RFC822_ADDR 3 ID_RFC822_ADDR 3
A fully-qualified RFC822 email address string, An example of a A fully-qualified RFC 822 email address string. An example of a
ID_RFC822_ADDR is, "jsmith@example.com". The string MUST NOT ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT
contain any terminators. Because of [EAI], implementations would contain any terminators. Because of [EAI], implementations would
be wise to treat this field as UTF-8 encoded text, not as be wise to treat this field as UTF-8 encoded text, not as
pure ASCII. pure ASCII.
ID_IPV6_ADDR 5 ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address. A single sixteen (16) octet IPv6 address.
ID_DER_ASN1_DN 9 ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [PKIX]. ASN.1 X.500 Distinguished Name [PKIX].
ID_DER_ASN1_GN 10 ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX]. The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX].
ID_KEY_ID 11 ID_KEY_ID 11
An opaque octet stream which may be used to pass vendor- An opaque octet stream that may be used to pass vendor-
specific information necessary to do certain proprietary specific information necessary to do certain proprietary
types of identification. types of identification.
Two implementations will interoperate only if each can generate a Two implementations will interoperate only if each can generate a
type of ID acceptable to the other. To assure maximum type of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be configurable to send at interoperability, implementations MUST be configurable to send at
least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these four types. MUST be configurable to accept all of these four types.
Implementations SHOULD be capable of generating and accepting all of Implementations SHOULD be capable of generating and accepting all of
these types. IPv6-capable implementations MUST additionally be these types. IPv6-capable implementations MUST additionally be
skipping to change at line 4214 skipping to change at page 90, line 22
same as the syntax of email address in [MAILFORMAT]. For those NAIs same as the syntax of email address in [MAILFORMAT]. For those NAIs
that include the realm component, the ID_RFC822_ADDR identification that include the realm component, the ID_RFC822_ADDR identification
type SHOULD be used. Responder implementations should not attempt to type SHOULD be used. Responder implementations should not attempt to
verify that the contents actually conform to the exact syntax given verify that the contents actually conform to the exact syntax given
in [MAILFORMAT], but instead should accept any reasonable-looking in [MAILFORMAT], but instead should accept any reasonable-looking
NAI. For NAIs that do not include the realm component, the ID_KEY_ID NAI. For NAIs that do not include the realm component, the ID_KEY_ID
identification type SHOULD be used. identification type SHOULD be used.
3.6. Certificate Payload 3.6. Certificate Payload
The Certificate Payload, denoted CERT in this document, provides a The Certificate payload, denoted CERT in this document, provides a
means to transport certificates or other authentication-related means to transport certificates or other authentication-related
information via IKE. Certificate payloads SHOULD be included in an information via IKE. Certificate payloads SHOULD be included in an
exchange if certificates are available to the sender. The Hash and exchange if certificates are available to the sender. The Hash and
URL formats of the Certificate payloads should be used in case the URL formats of the Certificate payloads should be used in case the
peer has indicated an ability to retrieve this information from peer has indicated an ability to retrieve this information from
elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note
that the term "Certificate Payload" is somewhat misleading, because that the term "Certificate payload" is somewhat misleading, because
not all authentication mechanisms use certificates and data other not all authentication mechanisms use certificates and data other
than certificates may be passed in this payload. than certificates may be passed in this payload.
The Certificate Payload is defined as follows: The Certificate payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ Certificate Data ~ ~ Certificate Data ~
| | | |
skipping to change at line 4267 skipping to change at page 91, line 27
SPKI Certificate 9 UNSPECIFIED SPKI Certificate 9 UNSPECIFIED
X.509 Certificate - Attribute 10 UNSPECIFIED X.509 Certificate - Attribute 10 UNSPECIFIED
Raw RSA Key 11 Raw RSA Key 11
Hash and URL of X.509 certificate 12 Hash and URL of X.509 certificate 12
Hash and URL of X.509 bundle 13 Hash and URL of X.509 bundle 13
o Certificate Data (variable length) - Actual encoding of o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated by the certificate data. The type of certificate is indicated by the
Certificate Encoding field. Certificate Encoding field.
The payload type for the Certificate Payload is thirty seven (37). The payload type for the Certificate payload is thirty-seven (37).
Specific syntax for some of the certificate type codes above is not Specific syntax for some of the certificate type codes above is not
defined in this document. The types whose syntax is defined in this defined in this document. The types whose syntax is defined in this
document are: document are:
o "X.509 Certificate - Signature" contains a DER encoded X.509 o "X.509 Certificate - Signature" contains a DER-encoded X.509
certificate whose public key is used to validate the sender's AUTH certificate whose public key is used to validate the sender's AUTH
payload. Note that with this encoding, if a chain of certificates payload. Note that with this encoding, if a chain of certificates
needs to be sent, multiple CERT payloads are used, only the first needs to be sent, multiple CERT payloads are used, only the first
of which holds the public key used to validate the sender's AUTH of which holds the public key used to validate the sender's AUTH
payload. payload.
o "Certificate Revocation List" contains a DER encoded X.509 o "Certificate Revocation List" contains a DER-encoded X.509
certificate revocation list. certificate revocation list.
o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER- o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-
encoded RSAPublicKey structure (see [RSA] and [PKCS1]). encoded RSAPublicKey structure (see [RSA] and [PKCS1]).
o Hash and URL encodings allow IKE messages to remain short by o Hash and URL encodings allow IKE messages to remain short by
replacing long data structures with a 20 octet SHA-1 hash (see replacing long data structures with a 20-octet SHA-1 hash (see
[SHA]) of the replaced value followed by a variable-length URL [SHA]) of the replaced value followed by a variable-length URL
that resolves to the DER encoded data structure itself. This that resolves to the DER-encoded data structure itself. This
improves efficiency when the endpoints have certificate data improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to DoS attacks that become cached and makes IKE less subject to DoS attacks that become
easier to mount when IKE messages are large enough to require IP easier to mount when IKE messages are large enough to require IP
fragmentation [DOSUDPPROT]. fragmentation [DOSUDPPROT].
The "Hash and URL of a bundle" type uses the following ASN.1 The "Hash and URL of a bundle" type uses the following ASN.1
definition for the X.509 bundle: definition for the X.509 bundle:
CertBundle CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
skipping to change at line 4337 skipping to change at page 93, line 7
the public key used to sign the AUTH payload. The other certificates the public key used to sign the AUTH payload. The other certificates
may be sent in any order. may be sent in any order.
Implementations MUST support the HTTP [HTTP] method for hash-and-URL Implementations MUST support the HTTP [HTTP] method for hash-and-URL
lookup. The behavior of other URL methods [URLS] is not currently lookup. The behavior of other URL methods [URLS] is not currently
specified, and such methods SHOULD NOT be used in the absence of a specified, and such methods SHOULD NOT be used in the absence of a
document specifying them. document specifying them.
3.7. Certificate Request Payload 3.7. Certificate Request Payload
The Certificate Request Payload, denoted CERTREQ in this document, The Certificate Request payload, denoted CERTREQ in this document,
provides a means to request preferred certificates via IKE and can provides a means to request preferred certificates via IKE and can
appear in the IKE_INIT_SA response and/or the IKE_AUTH request. appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
Certificate Request payloads MAY be included in an exchange when the Certificate Request payloads MAY be included in an exchange when the
sender needs to get the certificate of the receiver. sender needs to get the certificate of the receiver.
The Certificate Request Payload is defined as follows: The Certificate Request payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ Certification Authority ~ ~ Certification Authority ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 4366 skipping to change at page 93, line 35
Figure 13: Certificate Request Payload Format Figure 13: Certificate Request Payload Format
o Certificate Encoding (1 octet) - Contains an encoding of the type o Certificate Encoding (1 octet) - Contains an encoding of the type
or format of certificate requested. Values are listed in or format of certificate requested. Values are listed in
Section 3.6. Section 3.6.
o Certification Authority (variable length) - Contains an encoding o Certification Authority (variable length) - Contains an encoding
of an acceptable certification authority for the type of of an acceptable certification authority for the type of
certificate requested. certificate requested.
The payload type for the Certificate Request Payload is thirty eight The payload type for the Certificate Request payload is thirty-eight
(38). (38).
The Certificate Encoding field has the same values as those defined The Certificate Encoding field has the same values as those defined
in Section 3.6. The Certification Authority field contains an in Section 3.6. The Certification Authority field contains an
indicator of trusted authorities for this certificate type. The indicator of trusted authorities for this certificate type. The
Certification Authority value is a concatenated list of SHA-1 hashes Certification Authority value is a concatenated list of SHA-1 hashes
of the public keys of trusted Certification Authorities (CAs). Each of the public keys of trusted Certification Authorities (CAs). Each
is encoded as the SHA-1 hash of the Subject Public Key Info element is encoded as the SHA-1 hash of the Subject Public Key Info element
(see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate.
The twenty-octet hashes are concatenated and included with no other The 20-octet hashes are concatenated and included with no other
formatting. formatting.
The contents of the "Certification Authority" field are defined only The contents of the "Certification Authority" field are defined only
for X.509 certificates, which are types 4, 12, and 13. Other values for X.509 certificates, which are types 4, 12, and 13. Other values
SHOULD NOT be used until standards-track specifications that specify SHOULD NOT be used until Standards-Track specifications that specify
their use are published. their use are published.
Note that the term "Certificate Request" is somewhat misleading, in Note that the term "Certificate Request" is somewhat misleading, in
that values other than certificates are defined in a "Certificate" that values other than certificates are defined in a "Certificate"
payload and requests for those values can be present in a Certificate payload and requests for those values can be present in a Certificate
Request Payload. The syntax of the Certificate Request payload in Request payload. The syntax of the Certificate Request payload in
such cases is not defined in this document. such cases is not defined in this document.
The Certificate Request Payload is processed by inspecting the "Cert The Certificate Request payload is processed by inspecting the "Cert
Encoding" field to determine whether the processor has any Encoding" field to determine whether the processor has any
certificates of this type. If so, the "Certification Authority" certificates of this type. If so, the "Certification Authority"
field is inspected to determine if the processor has any certificates field is inspected to determine if the processor has any certificates
that can be validated up to one of the specified certification that can be validated up to one of the specified certification
authorities. This can be a chain of certificates. authorities. This can be a chain of certificates.
If an end-entity certificate exists that satisfies the criteria If an end-entity certificate exists that satisfies the criteria
specified in the CERTREQ, a certificate or certificate chain SHOULD specified in the CERTREQ, a certificate or certificate chain SHOULD
be sent back to the certificate requestor if the recipient of the be sent back to the certificate requestor if the recipient of the
CERTREQ: CERTREQ:
o is configured to use certificate authentication, o is configured to use certificate authentication,
o is allowed to send a CERT payload, o is allowed to send a CERT payload,
o has matching CA trust policy governing the current negotiation, o has matching CA trust policy governing the current negotiation,
and and
o has at least one time-wise and usage appropriate end-entity o has at least one time-wise and usage-appropriate end-entity
certificate chaining to a CA provided in the CERTREQ. certificate chaining to a CA provided in the CERTREQ.
Certificate revocation checking must be considered during the Certificate revocation checking must be considered during the
chaining process used to select a certificate. Note that even if two chaining process used to select a certificate. Note that even if two
peers are configured to use two different CAs, cross-certification peers are configured to use two different CAs, cross-certification
relationships should be supported by appropriate selection logic. relationships should be supported by appropriate selection logic.
The intent is not to prevent communication through the strict The intent is not to prevent communication through the strict
adherence of selection of a certificate based on CERTREQ, when an adherence of selection of a certificate based on CERTREQ, when an
alternate certificate could be selected by the sender that would alternate certificate could be selected by the sender that would
skipping to change at line 4437 skipping to change at page 95, line 13
acceptable (perhaps after prompting a human operator). acceptable (perhaps after prompting a human operator).
The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any
message that can include a CERTREQ payload and indicates that the message that can include a CERTREQ payload and indicates that the
sender is capable of looking up certificates based on an HTTP-based sender is capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive certificate URL (and hence presumably would prefer to receive certificate
specifications in that format). specifications in that format).
3.8. Authentication Payload 3.8. Authentication Payload
The Authentication Payload, denoted AUTH in this document, contains The Authentication payload, denoted AUTH in this document, contains
data used for authentication purposes. The syntax of the data used for authentication purposes. The syntax of the
Authentication data varies according to the Auth Method as specified Authentication data varies according to the Auth Method as specified
below. below.
The Authentication Payload is defined as follows: The Authentication payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED | | Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Authentication Data ~ ~ Authentication Data ~
skipping to change at line 4470 skipping to change at page 95, line 46
following table are only current as of the publication date of RFC following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be 4306. Other values may have been added since then or will be
added after the publication of this document. Readers should added after the publication of this document. Readers should
refer to [IKEV2IANA] for the latest values. refer to [IKEV2IANA] for the latest values.
Mechanism Value Mechanism Value
----------------------------------------------------------------- -----------------------------------------------------------------
RSA Digital Signature 1 RSA Digital Signature 1
Computed as specified in Section 2.15 using an RSA private key Computed as specified in Section 2.15 using an RSA private key
with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1] with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1]
(implementors should note that IKEv1 used a different method for (implementers should note that IKEv1 used a different method for
RSA signatures). To promote interoperability, implementations RSA signatures). To promote interoperability, implementations
that support this type SHOULD support signatures that use SHA-1 that support this type SHOULD support signatures that use SHA-1
as the hash function and SHOULD use SHA-1 as the default hash as the hash function and SHOULD use SHA-1 as the default hash
function when generating signatures. Implementations can use the function when generating signatures. Implementations can use the
certificates received from a given peer as a hint for selecting a certificates received from a given peer as a hint for selecting a
mutually-understood hash function for the AUTH payload signature. mutually understood hash function for the AUTH payload signature.
Note, however, that the hash algorithm used in the AUTH payload Note, however, that the hash algorithm used in the AUTH payload
signature doesn't have to be the same as any hash algorithm(s) signature doesn't have to be the same as any hash algorithm(s)
used in the certificate(s). used in the certificate(s).
Shared Key Message Integrity Code 2 Shared Key Message Integrity Code 2
Computed as specified in Section 2.15 using the shared key Computed as specified in Section 2.15 using the shared key
associated with the identity in the ID payload and the negotiated associated with the identity in the ID payload and the negotiated
PRF. PRF.
DSS Digital Signature 3 DSS Digital Signature 3
Computed as specified in Section 2.15 using a DSS private key Computed as specified in Section 2.15 using a DSS private key
(see [DSS]) over a SHA-1 hash. (see [DSS]) over a SHA-1 hash.
o Authentication Data (variable length) - see Section 2.15. o Authentication Data (variable length) - see Section 2.15.
The payload type for the Authentication Payload is thirty nine (39). The payload type for the Authentication payload is thirty-nine (39).
3.9. Nonce Payload 3.9. Nonce Payload
The Nonce Payload, denoted Ni and Nr in this document for the The Nonce payload, denoted as Ni and Nr in this document for the
initiator's and responder's nonce respectively, contains random data initiator's and responder's nonce, respectively, contains random data
used to guarantee liveness during an exchange and protect against used to guarantee liveness during an exchange and protect against
replay attacks. replay attacks.
The Nonce Payload is defined as follows: The Nonce payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Nonce Data ~ ~ Nonce Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Nonce Payload Format Figure 15: Nonce Payload Format
o Nonce Data (variable length) - Contains the random data generated o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity. by the transmitting entity.
The payload type for the Nonce Payload is forty (40). The payload type for the Nonce payload is forty (40).
The size of the Nonce Data MUST be between 16 and 256 octets The size of the Nonce Data MUST be between 16 and 256 octets,
inclusive. Nonce values MUST NOT be reused. inclusive. Nonce values MUST NOT be reused.
3.10. Notify Payload 3.10. Notify Payload
The Notify Payload, denoted N in this document, is used to transmit The Notify payload, denoted N in this document, is used to transmit
informational data, such as error conditions and state transitions, informational data, such as error conditions and state transitions,
to an IKE peer. A Notify Payload may appear in a response message to an IKE peer. A Notify payload may appear in a response message
(usually specifying why a request was rejected), in an INFORMATIONAL (usually specifying why a request was rejected), in an INFORMATIONAL
Exchange (to report an error not in an IKE request), or in any other Exchange (to report an error not in an IKE request), or in any other
message to indicate sender capabilities or to modify the meaning of message to indicate sender capabilities or to modify the meaning of
the request. the request.
The Notify Payload is defined as follows: The Notify payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type | | Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security Parameter Index (SPI) ~ ~ Security Parameter Index (SPI) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Notification Data ~ ~ Notification Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Notify Payload Format Figure 16: Notify Payload Format
o Protocol ID (1 octet) - If this notification concerns an existing o Protocol ID (1 octet) - If this notification concerns an existing
SA whose SPI is given in the SPI field, this field indicates the SA whose SPI is given in the SPI field, this field indicates the
type of that SA. For notifications concerning Child SAs this type of that SA. For notifications concerning Child SAs, this
field MUST contain either (2) to indicate AH or (3) to indicate field MUST contain either (2) to indicate AH or (3) to indicate
ESP. Of the notifications defined in this document, the SPI is ESP. Of the notifications defined in this document, the SPI is
included only with INVALID_SELECTORS and REKEY_SA. If the SPI included only with INVALID_SELECTORS and REKEY_SA. If the SPI
field is empty, this field MUST be sent as zero and MUST be field is empty, this field MUST be sent as zero and MUST be
ignored on receipt. ignored on receipt.
o SPI Size (1 octet) - Length in octets of the SPI as defined by the o SPI Size (1 octet) - Length in octets of the SPI as defined by the
IPsec protocol ID or zero if no SPI is applicable. For a IPsec protocol ID or zero if no SPI is applicable. For a
notification concerning the IKE SA, the SPI Size MUST be zero and notification concerning the IKE SA, the SPI Size MUST be zero and
the field must be empty. the field must be empty.
o Notify Message Type (2 octets) - Specifies the type of o Notify Message Type (2 octets) - Specifies the type of
notification message. notification message.
o SPI (variable length) - Security Parameter Index. o SPI (variable length) - Security Parameter Index.
o Notification Data (variable length) - Status or error data o Notification Data (variable length) - Status or error data
transmitted in addition to the Notify Message Type. Values for transmitted in addition to the Notify Message Type. Values for
this field are type specific (see below). this field are type specific (see below).
The payload type for the Notify Payload is forty one (41). The payload type for the Notify payload is forty-one (41).
3.10.1. Notify Message Types 3.10.1. Notify Message Types
Notification information can be error messages specifying why an SA Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process. managing an SA database wishes to communicate with a peer process.
The table below lists the Notification messages and their The table below lists the Notification messages and their
corresponding values. The number of different error statuses was corresponding values. The number of different error statuses was
greatly reduced from IKEv1 both for simplification and to avoid greatly reduced from IKEv1 both for simplification and to avoid
giving configuration information to probers. giving configuration information to probers.
Types in the range 0 - 16383 are intended for reporting errors. An Types in the range 0 - 16383 are intended for reporting errors. An
implementation receiving a Notify payload with one of these types implementation receiving a Notify payload with one of these types
that it does not recognize in a response MUST assume that the that it does not recognize in a response MUST assume that the
corresponding request has failed entirely. Unrecognized error types corresponding request has failed entirely. Unrecognized error types
in a request and status types in a request or response MUST be in a request and status types in a request or response MUST be
skipping to change at line 4597 skipping to change at page 98, line 31
Types in the range 0 - 16383 are intended for reporting errors. An Types in the range 0 - 16383 are intended for reporting errors. An
implementation receiving a Notify payload with one of these types implementation receiving a Notify payload with one of these types
that it does not recognize in a response MUST assume that the that it does not recognize in a response MUST assume that the
corresponding request has failed entirely. Unrecognized error types corresponding request has failed entirely. Unrecognized error types
in a request and status types in a request or response MUST be in a request and status types in a request or response MUST be
ignored, and they should be logged. ignored, and they should be logged.
Notify payloads with status types MAY be added to any message and Notify payloads with status types MAY be added to any message and
MUST be ignored if not recognized. They are intended to indicate MUST be ignored if not recognized. They are intended to indicate
capabilities, and as part of SA negotiation are used to negotiate capabilities, and as part of SA negotiation, are used to negotiate
non-cryptographic parameters. non-cryptographic parameters.
More information on error handling can be found in Section 2.21. More information on error handling can be found in Section 2.21.
The values in the following table are only current as of the The values in the following table are only current as of the
publication date of RFC 4306, plus two error types added in this publication date of RFC 4306, plus two error types added in this
document. Other values may have been added since then or will be document. Other values may have been added since then or will be
added after the publication of this document. Readers should refer added after the publication of this document. Readers should refer
to [IKEV2IANA] for the latest values. to [IKEV2IANA] for the latest values.
NOTIFY messages: error types Value NOTIFY messages: error types Value
------------------------------------------------------------------- -------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1 UNSUPPORTED_CRITICAL_PAYLOAD 1
See Section 2.5. See Section 2.5.
INVALID_IKE_SPI 4 INVALID_IKE_SPI 4
See Section 2.21. See Section 2.21.
INVALID_MAJOR_VERSION 5 INVALID_MAJOR_VERSION 5
See Section 2.5. See Section 2.5.
INVALID_SYNTAX 7 INVALID_SYNTAX 7
Indicates the IKE message that was received was invalid because Indicates the IKE message that was received was invalid because
some type, length, or value was out of range or because the some type, length, or value was out of range or because the
request was rejected for policy reasons. To avoid a DoS request was rejected for policy reasons. To avoid a DoS
attack using forged messages, this status may only be attack using forged messages, this status may only be
returned for and in an encrypted packet if the message ID and returned for and in an encrypted packet if the Message ID and
cryptographic checksum were valid. To avoid leaking information cryptographic checksum were valid. To avoid leaking information
to someone probing a node, this status MUST be sent in response to someone probing a node, this status MUST be sent in response
to any error not covered by one of the other status types. to any error not covered by one of the other status types.
To aid debugging, more detailed error information should be To aid debugging, more detailed error information should be
written to a console or log. written to a console or log.
INVALID_MESSAGE_ID 9 INVALID_MESSAGE_ID 9
See Section 2.3. See Section 2.3.
INVALID_SPI 11 INVALID_SPI 11
See Section 1.5. See Section 1.5.
NO_PROPOSAL_CHOSEN 14 NO_PROPOSAL_CHOSEN 14
None of the proposed crypto suites was acceptable. This can be None of the proposed crypto suites was acceptable. This can be
sent in any case where the offered proposals (including but not sent in any case where the offered proposals (including but not
limited to SA payload values, USE_TRANSPORT_MODE notify, limited to SA payload values, USE_TRANSPORT_MODE notify,
IPCOMP_SUPPORTED notify) are not acceptable for the responder. IPCOMP_SUPPORTED notify) are not acceptable for the responder.
This can also be used as "generic" Child SA error when Child SA This can also be used as "generic" Child SA error when Child SA
cannot be created for some other reason. See also Section 2.7. cannot be created for some other reason. See also Section 2.7.
INVALID_KE_PAYLOAD 17 INVALID_KE_PAYLOAD 17
See Section 1.2 and 1.3. See Sections 1.2 and 1.3.
AUTHENTICATION_FAILED 24 AUTHENTICATION_FAILED 24
Sent in the response to an IKE_AUTH message when for some reason Sent in the response to an IKE_AUTH message when, for some reason,
the authentication failed. There is no associated data. See also the authentication failed. There is no associated data. See also
Section 2.21.2. Section 2.21.2.
SINGLE_PAIR_REQUIRED 34 SINGLE_PAIR_REQUIRED 34
See Section 2.9. See Section 2.9.
NO_ADDITIONAL_SAS 35 NO_ADDITIONAL_SAS 35
See Section 1.3. See Section 1.3.
INTERNAL_ADDRESS_FAILURE 36 INTERNAL_ADDRESS_FAILURE 36
See Section 3.15.4. See Section 3.15.4.
FAILED_CP_REQUIRED 37 FAILED_CP_REQUIRED 37
See Section 2.19. See Section 2.19.
TS_UNACCEPTABLE 38 TS_UNACCEPTABLE 38
See Section 2.9. See Section 2.9.
INVALID_SELECTORS 39 INVALID_SELECTORS 39
MAY be sent in an IKE INFORMATIONAL exchange when a node receives MAY be sent in an IKE INFORMATIONAL exchange when a node receives
an ESP or AH packet whose selectors do not match those of the SA an ESP or AH packet whose selectors do not match those of the SA
on which it was delivered (and that caused the packet to be on which it was delivered (and that caused the packet to be
dropped). The Notification Data contains the start of the dropped). The Notification Data contains the start of the
offending packet (as in ICMP messages) and the SPI field of the offending packet (as in ICMP messages) and the SPI field of the
notification is set to match the SPI of the Child SA. notification is set to match the SPI of the Child SA.
TEMPORARY_FAILURE {TBA1} TEMPORARY_FAILURE 43
See section 2.25. See section 2.25.
CHILD_SA_NOT_FOUND {TBA2} CHILD_SA_NOT_FOUND 44
See section 2.25. See section 2.25.
NOTIFY messages: status types Value NOTIFY messages: status types Value
------------------------------------------------------------------- -------------------------------------------------------------------
INITIAL_CONTACT 16384 INITIAL_CONTACT 16384
See Section 2.4. See Section 2.4.
SET_WINDOW_SIZE 16385 SET_WINDOW_SIZE 16385
See Section 2.3. See Section 2.3.
ADDITIONAL_TS_POSSIBLE 16386 ADDITIONAL_TS_POSSIBLE 16386
skipping to change at line 4722 skipping to change at page 101, line 13
See Section 1.3.3. See Section 1.3.3.
ESP_TFC_PADDING_NOT_SUPPORTED 16394 ESP_TFC_PADDING_NOT_SUPPORTED 16394
See Section 1.3.1. See Section 1.3.1.
NON_FIRST_FRAGMENTS_ALSO 16395 NON_FIRST_FRAGMENTS_ALSO 16395
See Section 1.3.1. See Section 1.3.1.
3.11. Delete Payload 3.11. Delete Payload
The Delete Payload, denoted D in this document, contains a protocol The Delete payload, denoted D in this document, contains a protocol-
specific security association identifier that the sender has removed specific Security Association identifier that the sender has removed
from its security association database and is, therefore, no longer from its Security Association database and is, therefore, no longer
valid. Figure 17 shows the format of the Delete Payload. It is valid. Figure 17 shows the format of the Delete payload. It is
possible to send multiple SPIs in a Delete payload; however, each SPI possible to send multiple SPIs in a Delete payload; however, each SPI
MUST be for the same protocol. Mixing of protocol identifiers MUST MUST be for the same protocol. Mixing of protocol identifiers MUST
NOT be performed in the Delete payload. It is permitted, however, to NOT be performed in the Delete payload. It is permitted, however, to
include multiple Delete payloads in a single INFORMATIONAL exchange include multiple Delete payloads in a single INFORMATIONAL exchange
where each Delete payload lists SPIs for a different protocol. where each Delete payload lists SPIs for a different protocol.
Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but
no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the
IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI
is the SPI the sending endpoint would expect in inbound ESP or AH is the SPI the sending endpoint would expect in inbound ESP or AH
packets. packets.
The Delete Payload is defined as follows: The Delete payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Num of SPIs | | Protocol ID | SPI Size | Num of SPIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security Parameter Index(es) (SPI) ~ ~ Security Parameter Index(es) (SPI) ~
skipping to change at line 4766 skipping to change at page 102, line 10
o SPI Size (1 octet) - Length in octets of the SPI as defined by the o SPI Size (1 octet) - Length in octets of the SPI as defined by the
protocol ID. It MUST be zero for IKE (SPI is in message header) protocol ID. It MUST be zero for IKE (SPI is in message header)
or four for AH and ESP. or four for AH and ESP.
o Num of SPIs (2 octets, unsigned integer) - The number of SPIs o Num of SPIs (2 octets, unsigned integer) - The number of SPIs
contained in the Delete payload. The size of each SPI is defined contained in the Delete payload. The size of each SPI is defined
by the SPI Size field. by the SPI Size field.
o Security Parameter Index(es) (variable length) - Identifies the o Security Parameter Index(es) (variable length) - Identifies the
specific security association(s) to delete. The length of this specific Security Association(s) to delete. The length of this
field is determined by the SPI Size and Num of SPIs fields. field is determined by the SPI Size and Num of SPIs fields.
The payload type for the Delete Payload is forty two (42). The payload type for the Delete payload is forty-two (42).
3.12. Vendor ID Payload 3.12. Vendor ID Payload
The Vendor ID Payload, denoted V in this document, contains a vendor The Vendor ID payload, denoted V in this document, contains a vendor-
defined constant. The constant is used by vendors to identify and defined constant. The constant is used by vendors to identify and
recognize remote instances of their implementations. This mechanism recognize remote instances of their implementations. This mechanism
allows a vendor to experiment with new features while maintaining allows a vendor to experiment with new features while maintaining
backward compatibility. backward compatibility.
A Vendor ID payload MAY announce that the sender is capable of A Vendor ID payload MAY announce that the sender is capable of
accepting certain extensions to the protocol, or it MAY simply accepting certain extensions to the protocol, or it MAY simply
identify the implementation as an aid in debugging. A Vendor ID identify the implementation as an aid in debugging. A Vendor ID
payload MUST NOT change the interpretation of any information defined payload MUST NOT change the interpretation of any information defined
in this specification (i.e., the critical bit MUST be set to 0). in this specification (i.e., the critical bit MUST be set to 0).
Multiple Vendor ID payloads MAY be sent. An implementation is not Multiple Vendor ID payloads MAY be sent. An implementation is not
required to send any Vendor ID payload at all. required to send any Vendor ID payload at all.
A Vendor ID payload may be sent as part of any message. Reception of A Vendor ID payload may be sent as part of any message. Reception of
a familiar Vendor ID payload allows an implementation to make use of a familiar Vendor ID payload allows an implementation to make use of
private use numbers described throughout this document, such as private use numbers described throughout this document, such as
private payloads, private exchanges, private notifications, etc. private payloads, private exchanges, private notifications, etc.
Unfamiliar Vendor IDs MUST be ignored. Unfamiliar Vendor IDs MUST be ignored.
Writers of Internet-Drafts who wish to extend this protocol MUST Writers of documents who wish to extend this protocol MUST define a
define a Vendor ID payload to announce the ability to implement the Vendor ID payload to announce the ability to implement the extension
extension in the Internet-Draft. It is expected that Internet-Drafts in the document. It is expected that documents that gain acceptance
that gain acceptance and are standardized will be given "magic and are standardized will be given "magic numbers" out of the Future
numbers" out of the Future Use range by IANA, and the requirement to Use range by IANA, and the requirement to use a Vendor ID will go
use a Vendor ID will go away. away.
The Vendor ID Payload fields are defined as follows: The Vendor ID payload fields are defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Vendor ID (VID) ~ ~ Vendor ID (VID) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Vendor ID Payload Format Figure 18: Vendor ID Payload Format
o Vendor ID (variable length) - It is the responsibility of the o Vendor ID (variable length) - It is the responsibility of the
person choosing the Vendor ID to assure its uniqueness in spite of person choosing the Vendor ID to assure its uniqueness in spite of
the absence of any central registry for IDs. Good practice is to the absence of any central registry for IDs. Good practice is to
include a company name, a person name, or some such. If you want include a company name, a person name, or some such information.
to show off, you might include the latitude and longitude and time If you want to show off, you might include the latitude and
where you were when you chose the ID and some random input. A longitude and time where you were when you chose the ID and some
message digest of a long unique string is preferable to the long random input. A message digest of a long unique string is
unique string itself. preferable to the long unique string itself.
The payload type for the Vendor ID Payload is forty three (43). The payload type for the Vendor ID payload is forty-three (43).
3.13. Traffic Selector Payload 3.13. Traffic Selector Payload
The Traffic Selector Payload, denoted TS in this document, allows The Traffic Selector payload, denoted TS in this document, allows
peers to identify packet flows for processing by IPsec security peers to identify packet flows for processing by IPsec security
services. The Traffic Selector Payload consists of the IKE generic services. The Traffic Selector payload consists of the IKE generic
payload header followed by individual traffic selectors as follows: payload header followed by individual Traffic Selectors as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | RESERVED | | Number of TSs | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Traffic Selectors> ~ ~ <Traffic Selectors> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Traffic Selectors Payload Format Figure 19: Traffic Selectors Payload Format
o Number of TSs (1 octet) - Number of traffic selectors being o Number of TSs (1 octet) - Number of Traffic Selectors being
provided. provided.
o RESERVED - This field MUST be sent as zero and MUST be ignored on o RESERVED - This field MUST be sent as zero and MUST be ignored on
receipt. receipt.
o Traffic Selectors (variable length) - One or more individual o Traffic Selectors (variable length) - One or more individual
traffic selectors. Traffic Selectors.
The length of the Traffic Selector payload includes the TS header and The length of the Traffic Selector payload includes the TS header and
all the traffic selectors. all the Traffic Selectors.
The payload type for the Traffic Selector payload is forty four (44) The payload type for the Traffic Selector payload is forty-four (44)
for addresses at the initiator's end of the SA and forty five (45) for addresses at the initiator's end of the SA and forty-five (45)
for addresses at the responder's end. for addresses at the responder's end.
There is no requirement that TSi and TSr contain the same number of There is no requirement that TSi and TSr contain the same number of
individual traffic selectors. Thus, they are interpreted as follows: individual Traffic Selectors. Thus, they are interpreted as follows:
a packet matches a given TSi/TSr if it matches at least one of the a packet matches a given TSi/TSr if it matches at least one of the
individual selectors in TSi, and at least one of the individual individual selectors in TSi, and at least one of the individual
selectors in TSr. selectors in TSr.
For instance, the following traffic selectors: For instance, the following Traffic Selectors:
TSi = ((17, 100, 198.51.100.66-198.51.100.66), TSi = ((17, 100, 198.51.100.66-198.51.100.66),
(17, 200, 198.51.100.66-198.51.100.66)) (17, 200, 198.51.100.66-198.51.100.66))
TSr = ((17, 300, 0.0.0.0-255.255.255.255), TSr = ((17, 300, 0.0.0.0-255.255.255.255),
(17, 400, 0.0.0.0-255.255.255.255)) (17, 400, 0.0.0.0-255.255.255.255))
would match UDP packets from 198.51.100.66 to anywhere, with any of would match UDP packets from 198.51.100.66 to anywhere, with any of
the four combinations of source/destination ports (100,300), the four combinations of source/destination ports (100,300),
(100,400), (200,300), and (200, 400). (100,400), (200,300), and (200, 400).
skipping to change at line 4908 skipping to change at page 105, line 29
~ Ending Address* ~ ~ Ending Address* ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Traffic Selector Figure 20: Traffic Selector
*Note: All fields other than TS Type and Selector Length depend on *Note: All fields other than TS Type and Selector Length depend on
the TS Type. The fields shown are for TS Types 7 and 8, the only two the TS Type. The fields shown are for TS Types 7 and 8, the only two
values currently defined. values currently defined.
o TS Type (one octet) - Specifies the type of traffic selector. o TS Type (one octet) - Specifies the type of Traffic Selector.
o IP protocol ID (1 octet) - Value specifying an associated IP o IP protocol ID (1 octet) - Value specifying an associated IP
protocol ID (such as UDP, TCP, and ICMP). A value of zero means protocol ID (such as UDP, TCP, and ICMP). A value of zero means
that the protocol ID is not relevant to this traffic selector-- that the protocol ID is not relevant to this Traffic Selector --
the SA can carry all protocols. the SA can carry all protocols.
o Selector Length - Specifies the length of this Traffic Selector o Selector Length - Specifies the length of this Traffic Selector
substructure including the header. substructure including the header.
o Start Port (2 octets, unsigned integer) - Value specifying the o Start Port (2 octets, unsigned integer) - Value specifying the
smallest port number allowed by this traffic selector. For smallest port number allowed by this Traffic Selector. For
protocols for which port is undefined (including protocol 0), or protocols for which port is undefined (including protocol 0), or
if all ports are allowed, this field MUST be zero. ICMP and if all ports are allowed, this field MUST be zero. ICMP and
ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are ICMPv6 Type and Code values, as well as Mobile IP version 6
represented in this field as specified in Section 4.4.1.1 of (MIPv6) mobility header (MH) Type values, are represented in this
[IPSECARCH]. ICMP Type and Code values are treated as a single field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type
16-bit integer port number, with Type in the most significant and Code values are treated as a single 16-bit integer port
eight bits and Code in the least significant eight bits. MIPv6 MH number, with Type in the most significant eight bits and Code in
Type values are treated as a single 16-bit integer port number, the least significant eight bits. MIPv6 MH Type values are
with Type in the most significant eight bits and the least treated as a single 16-bit integer port number, with Type in the
significant eight bits set to zero. most significant eight bits and the least significant eight bits
set to zero.
o End Port (2 octets, unsigned integer) - Value specifying the o End Port (2 octets, unsigned integer) - Value specifying the
largest port number allowed by this traffic selector. For largest port number allowed by this Traffic Selector. For
protocols for which port is undefined (including protocol 0), or protocols for which port is undefined (including protocol 0), or
if all ports are allowed, this field MUST be 65535. ICMP and if all ports are allowed, this field MUST be 65535. ICMP and
ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
represented in this field as specified in Section 4.4.1.1 of represented in this field as specified in Section 4.4.1.1 of
[IPSECARCH]. ICMP Type and Code values are treated as a single [IPSECARCH]. ICMP Type and Code values are treated as a single
16-bit integer port number, with Type in the most significant 16-bit integer port number, with Type in the most significant
eight bits and Code in the least significant eight bits. MIPv6 MH eight bits and Code in the least significant eight bits. MIPv6 MH
Type values are treated as a single 16-bit integer port number, Type values are treated as a single 16-bit integer port number,
with Type in the most significant eight bits and the least with Type in the most significant eight bits and the least
significant eight bits set to zero. significant eight bits set to zero.
o Starting Address - The smallest address included in this Traffic o Starting Address - The smallest address included in this Traffic
Selector (length determined by TS type). Selector (length determined by TS Type).
o Ending Address - The largest address included in this Traffic o Ending Address - The largest address included in this Traffic
Selector (length determined by TS type). Selector (length determined by TS Type).
Systems that are complying with [IPSECARCH] that wish to indicate Systems that are complying with [IPSECARCH] that wish to indicate
"ANY" ports MUST set the start port to 0 and the end port to 65535; "ANY" ports MUST set the start port to 0 and the end port to 65535;
note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems
working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but
not "ANY" ports, MUST set the start port to 65535 and the end port to not "ANY" ports, MUST set the start port to 65535 and the end port to
0. 0.
The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6 The Traffic Selector types 7 and 8 can also refer to ICMP or ICMPv6
type and code fields, as well as MH Type fields for the IPv6 mobility type and code fields, as well as MH Type fields for the IPv6 mobility
header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets
have separate source and destination fields. The method for have separate source and destination fields. The method for
specifying the traffic selectors for ICMP and MIPv6 is shown by specifying the Traffic Selectors for ICMP and MIPv6 is shown by
example in Section 4.4.1.3 of [IPSECARCH]. example in Section 4.4.1.3 of [IPSECARCH].
The following table lists values for the Traffic Selector Type field The following table lists values for the Traffic Selector Type field
and the corresponding Address Selector Data. The values in the and the corresponding Address Selector Data. The values in the
following table are only current as of the publication date of RFC following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be added 4306. Other values may have been added since then or will be added
after the publication of this document. Readers should refer to after the publication of this document. Readers should refer to
[IKEV2IANA] for the latest values. [IKEV2IANA] for the latest values.
TS Type Value TS Type Value
skipping to change at line 4974 skipping to change at page 107, line 4
The following table lists values for the Traffic Selector Type field The following table lists values for the Traffic Selector Type field
and the corresponding Address Selector Data. The values in the and the corresponding Address Selector Data. The values in the
following table are only current as of the publication date of RFC following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be added 4306. Other values may have been added since then or will be added
after the publication of this document. Readers should refer to after the publication of this document. Readers should refer to
[IKEV2IANA] for the latest values. [IKEV2IANA] for the latest values.
TS Type Value TS Type Value
------------------------------------------------------------------- -------------------------------------------------------------------
TS_IPV4_ADDR_RANGE 7 TS_IPV4_ADDR_RANGE 7
A range of IPv4 addresses, represented by two four-octet A range of IPv4 addresses, represented by two four-octet
values. The first value is the beginning IPv4 address values. The first value is the beginning IPv4 address
(inclusive) and the second value is the ending IPv4 address (inclusive) and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified (inclusive). All addresses falling between the two specified
addresses are considered to be within the list. addresses are considered to be within the list.
TS_IPV6_ADDR_RANGE 8 TS_IPV6_ADDR_RANGE 8
A range of IPv6 addresses, represented by two sixteen-octet A range of IPv6 addresses, represented by two sixteen-octet
values. The first value is the beginning IPv6 address values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address (inclusive) and the second value is the ending IPv6 address
(inclusive). All addresses falling between the two specified (inclusive). All addresses falling between the two specified
addresses are considered to be within the list. addresses are considered to be within the list.
3.14. Encrypted Payload 3.14. Encrypted Payload
The Encrypted Payload, denoted SK{...} in this document, contains The Encrypted payload, denoted SK{...} in this document, contains
other payloads in encrypted form. The Encrypted Payload, if present other payloads in encrypted form. The Encrypted payload, if present
in a message, MUST be the last payload in the message. Often, it is in a message, MUST be the last payload in the message. Often, it is
the only payload in the message. This payload is also called the the only payload in the message. This payload is also called the
"Encrypted and Authenticated" payload. "Encrypted and Authenticated" payload.
The algorithms for encryption and integrity protection are negotiated The algorithms for encryption and integrity protection are negotiated
during IKE SA setup, and the keys are computed as specified in during IKE SA setup, and the keys are computed as specified in
Section 2.14 and Section 2.18. Sections 2.14 and 2.18.
This document specifies the cryptographic processing of Encrypted This document specifies the cryptographic processing of Encrypted
payloads using a block cipher in CBC mode and an integrity check payloads using a block cipher in CBC mode and an integrity check
algorithm that computes a fixed-length checksum over a variable size algorithm that computes a fixed-length checksum over a variable size
message. The design is modeled after the ESP algorithms described in message. The design is modeled after the ESP algorithms described in
RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
completely specifies the cryptographic processing of IKE data, but completely specifies the cryptographic processing of IKE data, but
those documents should be consulted for design rationale. Future those documents should be consulted for design rationale. Future
documents may specify the processing of Encrypted payloads for other documents may specify the processing of Encrypted payloads for other
types of transforms, such as counter mode encryption and types of transforms, such as counter mode encryption and
authenticated encryption algorithms. Peers MUST NOT negotiate authenticated encryption algorithms. Peers MUST NOT negotiate
transforms for which no such specification exists. transforms for which no such specification exists.
When an authenticated encryption algorithm is used to protect the IKE When an authenticated encryption algorithm is used to protect the IKE
SA, the construction of the encrypted payload is different than what SA, the construction of the Encrypted payload is different than what
is described here. See [AEAD] for more information on authenticated is described here. See [AEAD] for more information on authenticated
encryption algorithms and their use in ESP. encryption algorithms and their use in ESP.
The payload type for an Encrypted payload is forty six (46). The The payload type for an Encrypted payload is forty-six (46). The
Encrypted Payload consists of the IKE generic payload header followed Encrypted payload consists of the IKE generic payload header followed
by individual fields as follows: by individual fields as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector | | Initialization Vector |
| (length is block size for encryption algorithm) | | (length is block size for encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 5049 skipping to change at page 108, line 32
Figure 21: Encrypted Payload Format Figure 21: Encrypted Payload Format
o Next Payload - The payload type of the first embedded payload. o Next Payload - The payload type of the first embedded payload.
Note that this is an exception in the standard header format, Note that this is an exception in the standard header format,
since the Encrypted payload is the last payload in the message and since the Encrypted payload is the last payload in the message and
therefore the Next Payload field would normally be zero. But therefore the Next Payload field would normally be zero. But
because the content of this payload is embedded payloads and there because the content of this payload is embedded payloads and there
was no natural place to put the type of the first one, that type was no natural place to put the type of the first one, that type
is placed here. is placed here.
o Payload Length - Includes the lengths of the header, IV, Encrypted o Payload Length - Includes the lengths of the header,
IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. initialization vector (IV), Encrypted IKE payloads, Padding, Pad
Length, and Integrity Checksum Data.
o Initialization Vector - For CBC mode ciphers, the length of the o Initialization Vector - For CBC mode ciphers, the length of the
initialization vector (IV) is equal to the block length of the initialization vector (IV) is equal to the block length of the
underlying encryption algorithm. Senders MUST select a new underlying encryption algorithm. Senders MUST select a new
unpredictable IV for every message; recipients MUST accept any unpredictable IV for every message; recipients MUST accept any
value. The reader is encouraged to consult [MODES] for advice on value. The reader is encouraged to consult [MODES] for advice on
IV generation. In particular, using the final ciphertext block of IV generation. In particular, using the final ciphertext block of
the previous message is not considered unpredictable. For modes the previous message is not considered unpredictable. For modes
other than CBC, the IV format and processing is specified in the other than CBC, the IV format and processing is specified in the
document specifying the encryption algorithm and mode. document specifying the encryption algorithm and mode.
o IKE Payloads are as specified earlier in this section. This field o IKE payloads are as specified earlier in this section. This field
is encrypted with the negotiated cipher. is encrypted with the negotiated cipher.
o Padding MAY contain any value chosen by the sender, and MUST have o Padding MAY contain any value chosen by the sender, and MUST have
a length that makes the combination of the Payloads, the Padding, a length that makes the combination of the payloads, the Padding,
and the Pad Length to be a multiple of the encryption block size. and the Pad Length to be a multiple of the encryption block size.
This field is encrypted with the negotiated cipher. This field is encrypted with the negotiated cipher.
o Pad Length is the length of the Padding field. The sender SHOULD o Pad Length is the length of the Padding field. The sender SHOULD
set the Pad Length to the minimum value that makes the combination set the Pad Length to the minimum value that makes the combination
of the Payloads, the Padding, and the Pad Length a multiple of the of the payloads, the Padding, and the Pad Length a multiple of the
block size, but the recipient MUST accept any length that results block size, but the recipient MUST accept any length that results
in proper alignment. This field is encrypted with the negotiated in proper alignment. This field is encrypted with the negotiated
cipher. cipher.
o Integrity Checksum Data is the cryptographic checksum of the o Integrity Checksum Data is the cryptographic checksum of the
entire message starting with the Fixed IKE Header through the Pad entire message starting with the Fixed IKE header through the Pad
Length. The checksum MUST be computed over the encrypted message. Length. The checksum MUST be computed over the encrypted message.
Its length is determined by the integrity algorithm negotiated. Its length is determined by the integrity algorithm negotiated.
3.15. Configuration Payload 3.15. Configuration Payload
The Configuration payload, denoted CP in this document, is used to The Configuration payload, denoted CP in this document, is used to
exchange configuration information between IKE peers. The exchange exchange configuration information between IKE peers. The exchange
is for an IRAC to request an internal IP address from an IRAS and to is for an IRAC to request an internal IP address from an IRAS and to
exchange other information of the sort that one would acquire with exchange other information of the sort that one would acquire with
Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly
connected to a LAN. connected to a LAN.
The Configuration Payload is defined as follows: The Configuration payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CFG Type | RESERVED | | CFG Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Configuration Attributes ~ ~ Configuration Attributes ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Configuration Payload Format Figure 22: Configuration Payload Format
The payload type for the Configuration Payload is forty seven (47). The payload type for the Configuration payload is forty-seven (47).
o CFG Type (1 octet) - The type of exchange represented by the o CFG Type (1 octet) - The type of exchange represented by the
Configuration Attributes. The values in the following table are Configuration Attributes. The values in the following table are
only current as of the publication date of RFC 4306. Other values only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA] publication of this document. Readers should refer to [IKEV2IANA]
for the latest values. for the latest values.
CFG Type Value CFG Type Value
-------------------------- --------------------------