draft-ietf-ipsecme-ikev2bis-06.txt   draft-ietf-ipsecme-ikev2bis-07.txt 
Network Working Group C. Kaufman Network Working Group C. Kaufman
Internet-Draft Microsoft Internet-Draft Microsoft
Obsoletes: 4306, 4718 P. Hoffman Obsoletes: 4306, 4718 P. Hoffman
(if approved) VPN Consortium (if approved) VPN Consortium
Intended status: Standards Track Y. Nir Intended status: Standards Track Y. Nir
Expires: June 12, 2010 Check Point Expires: July 24, 2010 Check Point
P. Eronen P. Eronen
Nokia Nokia
December 9, 2009 January 20, 2010
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-ietf-ipsecme-ikev2bis-06 draft-ietf-ipsecme-ikev2bis-07
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). It replaces and updates RFC 4306, and includes all of the (SAs). This document replaces and updates RFC 4306, and includes all
clarifications from RFC 4718. of the clarifications from RFC 4718.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 12, 2010. This Internet-Draft will expire on July 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 24 skipping to change at page 3, line 24
1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 13 Exchange . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 15 Exchange . . . . . . . . . . . . . . . . . . . . . . 15
1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16
1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17
1.5. Informational Messages outside of an IKE SA . . . . . . . 18 1.5. Informational Messages outside of an IKE SA . . . . . . . 18
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19
1.7. Differences Between RFC 4306 and This Document . . . . . 19 1.7. Significant Differences Between RFC 4306 and This
2. IKE Protocol Details and Variations . . . . . . . . . . . . . 20 Document . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 21 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21
2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 22 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 22
2.3. Window Size for Overlapping Requests . . . . . . . . . . 23 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23
2.4. State Synchronization and Connection Timeouts . . . . . . 24 2.3. Window Size for Overlapping Requests . . . . . . . . . . 24
2.5. Version Numbers and Forward Compatibility . . . . . . . . 26 2.4. State Synchronization and Connection Timeouts . . . . . . 25
2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 28 2.5. Version Numbers and Forward Compatibility . . . . . . . . 27
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 30 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 29
2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 31 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 31
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 32 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32
2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 34 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 36 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 35
2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 37 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 38
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 38 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 38
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 41 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 42
2.11. Address and Port Agility . . . . . . . . . . . . . . . . 42 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 42 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 43
2.13. Generating Keying Material . . . . . . . . . . . . . . . 43 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43
2.14. Generating Keying Material for the IKE SA . . . . . . . . 44 2.13. Generating Keying Material . . . . . . . . . . . . . . . 44
2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 45 2.14. Generating Keying Material for the IKE SA . . . . . . . . 45
2.16. Extensible Authentication Protocol Methods . . . . . . . 47 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46
2.17. Generating Keying Material for Child SAs . . . . . . . . 49 2.16. Extensible Authentication Protocol Methods . . . . . . . 48
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 50 2.17. Generating Keying Material for Child SAs . . . . . . . . 50
2.19. Requesting an Internal Address on a Remote Network . . . 51 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 51
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 52 2.19. Requesting an Internal Address on a Remote Network . . . 52
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53
2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 53 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 54
2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 54 2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 54
2.21.3. Error Handling after IKE SA is Authenticated . . . . 55 2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 55
2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 55 2.21.3. Error Handling after IKE SA is Authenticated . . . . 56
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 56
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 61 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58
2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 62
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 65 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 65
2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 65 2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 65
2.25.1. Collisions While Rekeying or Closing Child SAs . . . 66 2.25.1. Collisions While Rekeying or Closing Child SAs . . . 66
2.25.2. Collisions While Rekeying or Closing IKE SAs . . . . 67 2.25.2. Collisions While Rekeying or Closing IKE SAs . . . . 67
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 67 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 67
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 67 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 67
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 70 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 70
3.3. Security Association Payload . . . . . . . . . . . . . . 72 3.3. Security Association Payload . . . . . . . . . . . . . . 72
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 74 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 74
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 76 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 76
skipping to change at page 4, line 33 skipping to change at page 4, line 34
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 82 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 82
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 83 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 83
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 84 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 84
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 87 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 87
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 89 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 89
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 91 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 91
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 93 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 93
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 93 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 93
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 94 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 94
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 97 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 97
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 98 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 99
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 100 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 100
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 101 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 101
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 103 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 103
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 105 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 105
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 106 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 106
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 109 3.15.2. Meaning of INTERNAL_IP4_SUBNET and
INTERNAL_IP6_SUBNET . . . . . . . . . . . . . . . . . 109
3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 111 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 111
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 112 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 112
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 112 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 113
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 114 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 114
5. Security Considerations . . . . . . . . . . . . . . . . . . . 116 5. Security Considerations . . . . . . . . . . . . . . . . . . . 116
5.1. Traffic selector authorization . . . . . . . . . . . . . 119 5.1. Traffic selector authorization . . . . . . . . . . . . . 119
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 121 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 121
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 121 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 122
8.1. Normative References . . . . . . . . . . . . . . . . . . 121 8.1. Normative References . . . . . . . . . . . . . . . . . . 122
8.2. Informative References . . . . . . . . . . . . . . . . . 122 8.2. Informative References . . . . . . . . . . . . . . . . . 123
Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 127 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 127
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 128 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 128
B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 128 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 128
B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 128 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 129
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 129 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 129
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 129 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 129
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 130 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 130
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 131 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 131
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 132 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 132
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 132 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 132
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 132 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 132
Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 132 Appendix D. Changes Between Internet Draft Versions . . . . . . 132
Appendix E. Changes Between Internet Draft Versions . . . . . . 133 D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 133
E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 133 D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 133
E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 133 D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 135
E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 135 D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 136
E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 136 D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 137
E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 137 D.6. Changes from draft -03 to
E.6. Changes from draft -03 to
draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 138 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 138
E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 139 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 139
E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 143 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 143
E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 145 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 145
E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to
draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 146 draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 146
E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to
draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 146 draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 146
E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to
draft-ietf-ipsecme-ikev2bis-05 . . . . . . . . . . . . . 147 draft-ietf-ipsecme-ikev2bis-05 . . . . . . . . . . . . . 147
E.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to
draft-ietf-ipsecme-ikev2bis-06 . . . . . . . . . . . . . 149 draft-ietf-ipsecme-ikev2bis-06 . . . . . . . . . . . . . 149
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151 D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to
draft-ietf-ipsecme-ikev2bis-07 . . . . . . . . . . . . . 151
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157
1. Introduction 1. Introduction
[[ An introduction to the differences between RFC 4306 [IKEV2] and
this document is given at the end of Section 1. It is put there
(instead of here) to preserve the section numbering of RFC 4306. ]]
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.
Establishing this shared state in a manual fashion does not scale Establishing this shared state in a manual fashion does not scale
well. Therefore, a protocol to establish this state dynamically is well. Therefore, a protocol to establish this state dynamically is
needed. This memo describes such a protocol -- the Internet Key needed. This document describes such a protocol -- the Internet Key
Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI],
2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs.
IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif]
(RFC 4718). This document replaces and updates RFC 4306 and RFC (RFC 4718). This document replaces and updates RFC 4306 and RFC
4718. IKEv2 was a change to the IKE protocol that was not backward 4718. IKEv2 was a change to the IKE protocol that was not backward
compatible. In contrast, the current document not only provides a compatible. In contrast, the current document not only provides a
clarification of IKEv2, but makes minimum changes to the IKE clarification of IKEv2, but makes minimum changes to the IKE
protocol. protocol. A list of the significant differences between RFC 4306 and
this document is given in Section 1.7.
IKE performs mutual authentication between two parties and IKE performs mutual authentication between two parties and
establishes an IKE security association (SA) that includes shared establishes an IKE security association (SA) that includes shared
secret information that can be used to efficiently establish SAs for secret information that can be used to efficiently establish SAs for
Encapsulating Security Payload (ESP) [ESP] or Authentication Header Encapsulating Security Payload (ESP) [ESP] or Authentication Header
(AH) [AH] and a set of cryptographic algorithms to be used by the SAs (AH) [AH] and a set of cryptographic algorithms to be used by the SAs
to protect the traffic that they carry. In this document, the term to protect the traffic that they carry. In this document, the term
"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
skipping to change at page 7, line 13 skipping to change at page 7, line 10
there may be more than one of each of these exchanges. In all cases, there may be more than one of each of these exchanges. In all cases,
all IKE_SA_INIT exchanges MUST complete before any other exchange all IKE_SA_INIT exchanges MUST complete before any other exchange
type, then all IKE_AUTH exchanges MUST complete, and following that type, then all IKE_AUTH exchanges MUST complete, and following that
any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
in any order. In some scenarios, only a single Child SA is needed in any order. In some scenarios, only a single Child SA is needed
between the IPsec endpoints, and therefore there would be no between the IPsec endpoints, and therefore there would be no
additional exchanges. Subsequent exchanges MAY be used to establish additional exchanges. Subsequent exchanges MAY be used to establish
additional Child SAs between the same authenticated pair of endpoints additional Child SAs between the same authenticated pair of endpoints
and to perform housekeeping functions. and to perform housekeeping functions.
IKE message flow always consists of a request followed by a response. An IKE message flow always consists of a request followed by a
It is the responsibility of the requester to ensure reliability. If response. It is the responsibility of the requester to ensure
the response is not received within a timeout interval, the requester reliability. If the response is not received within a timeout
needs to retransmit the request (or abandon the connection). interval, the requester needs to retransmit the request (or abandon
the connection).
The first request/response of an IKE session (IKE_SA_INIT) negotiates The first request/response of an IKE session (IKE_SA_INIT) negotiates
security parameters for the IKE SA, sends nonces, and sends Diffie- security parameters for the IKE SA, sends nonces, and sends Diffie-
Hellman values. Hellman values.
The second request/response (IKE_AUTH) transmits identities, proves The second request/response (IKE_AUTH) transmits identities, proves
knowledge of the secrets corresponding to the two identities, and knowledge of the secrets corresponding to the two identities, and
sets up an SA for the first (and often only) AH or ESP Child SA sets up an SA for the first (and often only) AH or ESP Child SA
(unless there is failure setting up the AH or ESP Child SA, in which (unless there is failure setting up the AH or ESP Child SA, in which
case the IKE SA is still established without the IPsec SA). case the IKE SA is still established without the Child SA).
The types of subsequent exchanges are CREATE_CHILD_SA (which creates The types of subsequent exchanges are CREATE_CHILD_SA (which creates
a Child SA) and INFORMATIONAL (which deletes an SA, reports error a Child SA) and INFORMATIONAL (which deletes an SA, reports error
conditions, or does other housekeeping). Every request requires a conditions, or does other housekeeping). Every request requires a
response. An INFORMATIONAL request with no payloads (other than the response. An INFORMATIONAL request with no payloads (other than the
empty Encrypted payload required by the syntax) is commonly used as a empty Encrypted payload required by the syntax) is commonly used as a
check for liveness. These subsequent exchanges cannot be used until check for liveness. These subsequent exchanges cannot be used until
the initial exchanges have completed. the initial exchanges have completed.
In the description that follows, we assume that no errors occur. In the description that follows, we assume that no errors occur.
skipping to change at page 10, line 34 skipping to change at page 10, line 34
response pairs. We'll describe the base exchange first, followed by response pairs. We'll describe the base exchange first, followed by
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.) how the encryption keys are generated. (A man-in-the-middle who
cannot complete the IKE_AUTH exchange can nonetheless see the
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
IKE_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.
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
E Encrypted
EAP Extensible Authentication EAP Extensible Authentication
HDR IKE Header 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
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], indicate that optionally a certificate request such as [CERTREQ]; this indicates that a certificate request payload
payload can 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
cryptographic algorithms the initiator supports for the IKE SA. The cryptographic algorithms the initiator supports for the IKE SA. The
skipping to change at page 14, line 26 skipping to change at page 14, line 26
exchange, and the Diffie-Hellman value (if KE payloads are included exchange, and the Diffie-Hellman value (if KE payloads are included
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 Notification payload. There are two octets of the INVALID_KE_PAYLOAD Notify payload. There are two octets of data
data associated with this notification: the accepted D-H Group number associated with this notification: the accepted D-H Group number in
in big endian order. In the case of such a rejection, the 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. the responder gave in the INVALID_KE_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. Some minimal unwilling to accept any more Child SAs on this IKE SA. Some minimal
implementations may only accept a single Child SA setup in the implementations may only accept a single Child SA setup in the
context of an initial IKE exchange and reject any subsequent attempts context of an initial IKE exchange and reject any subsequent attempts
to add more. to add more.
skipping to change at page 15, line 48 skipping to change at page 15, line 48
The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation
control. See [IPSECARCH] for a fuller explanation. Both parties control. See [IPSECARCH] for a fuller explanation. Both parties
need to agree to sending non-first fragments before either party does need to agree to sending non-first fragments before either party does
so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is
included in both the request proposing an SA and the response included in both the request proposing an SA and the response
accepting it. If the responder does not want to send or receive non- accepting it. If the responder does not want to send or receive non-
first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification
from its response, but does not reject the whole Child SA creation. from its response, but does not reject the whole Child SA creation.
An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also
be included in the request/response pair.
Failure of an attempt to create a Child SA SHOULD NOT tear down the Failure of an attempt to create a Child SA SHOULD NOT tear down the
IKE SA: there is no reason to lose the work done to set up the IKE IKE SA: there is no reason to lose the work done to set up the IKE
SA. When an IKE SA is not created, the error message return SHOULD SA. See Section 2.21 for a list of error messages that might occur
NOT be encrypted because the other party will not be able to if creating a Child SA fails.
authenticate that message. See Section 2.21 for a list of error
messages that might occur if creating a Child SA fails.
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying an IKE SA is: The CREATE_CHILD_SA request for rekeying an IKE SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {SA, Ni, KEi} --> HDR, SK {SA, Ni, KEi} -->
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, and a Diffie-Hellman value in the KEi payload. The KEi payload, and a Diffie-Hellman value in the KEi payload. The KEi
payload MUST be included. New initiator and responder SPIs are payload MUST be included. A new initiator SPI is supplied in the SPI
supplied in the SPI fields of the SA payload. Once a peer receives a field of the SA payload. Once a peer receives a request to rekey an
request to rekey an IKE SA or sends a request to rekey an IKE SA, it IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any
SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA that new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed.
is being rekeyed.
The CREATE_CHILD_SA response for rekeying an IKE SA is: The CREATE_CHILD_SA response for rekeying an IKE SA is:
<-- 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.
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.
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, 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 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
skipping to change at page 17, line 35 skipping to change at page 17, line 36
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. Section 2.21 also covers error messages in the negotiated keys. Note that some informational messages, not
great detail. exchanges, can be sent outside the context of an IKE SA. Section
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 which 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 (else the an INFORMATIONAL exchange request MUST send some response; otherwise,
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 a message with no payloads. retransmit it. That response MAY be an empty message. The request
The request message in an INFORMATIONAL exchange MAY also contain no message in an INFORMATIONAL exchange MAY also contain no payloads.
payloads. This is the expected way an endpoint can ask the other This is the expected way an endpoint can ask the other endpoint to
endpoint to verify that it is alive. verify that it is alive.
The INFORMATIONAL exchange is defined as: The INFORMATIONAL exchange is defined as:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {[N,] [D,] HDR, SK {[N,] [D,]
[CP,] ...} --> [CP,] ...} -->
<-- HDR, SK {[N,] [D,] <-- HDR, SK {[N,] [D,]
[CP], ...} [CP], ...}
skipping to change at page 18, line 27 skipping to change at page 18, line 30
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 your Informational exchange. half of each SA pair in the INFORMATIONAL exchange.
Normally, the reply in the INFORMATIONAL exchange will contain delete Normally, the response in the INFORMATIONAL exchange will contain
payloads for the paired SAs going in the other direction. There is delete payloads for the paired SAs going in the other direction.
one exception. If by chance both ends of a set of SAs independently There is one exception. If by chance both ends of a set of SAs
decide to close them, each may send a delete payload and the two independently decide to close them, each may send a delete payload
requests may cross in the network. If a node receives a delete and the two requests may cross in the network. If a node receives a
request for SAs for which it has already issued a delete request, it delete request for SAs for which it has already issued a delete
MUST delete the outgoing SAs while processing the request and the request, it MUST delete the outgoing SAs while processing the request
incoming SAs while processing the response. In that case, the and the incoming SAs while processing the response. In that case,
responses MUST NOT include delete payloads for the deleted SAs, since the responses MUST NOT include delete payloads for the deleted SAs,
that would result in duplicate deletion and could in theory delete since that would result in duplicate deletion and could in theory
the wrong SA. delete the wrong SA.
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
persist. Note that this specification nowhere specifies time persist. Note that this specification nowhere specifies time
periods, so it is up to individual endpoints to decide how long to periods, so it is up to individual endpoints to decide how long to
wait. A node MAY refuse to accept incoming data on half-closed wait. A node MAY refuse to accept incoming data on half-closed
connections but MUST NOT unilaterally close them and reuse the SPIs. connections but MUST NOT unilaterally close them and reuse the SPIs.
If connection state becomes sufficiently messed up, a node MAY close If connection state becomes sufficiently messed up, a node MAY close
the IKE SA; doing so will implicitly close all SAs negotiated under the IKE SA; doing so will implicitly close all SAs negotiated under
it. It can then rebuild the SAs it needs on a clean base under a new it. It can then rebuild the SAs it needs on a clean base under a new
IKE SA. The response to a request that deletes the IKE SA is an IKE SA. The response to a request that deletes the IKE SA is an
empty Informational response. empty INFORMATIONAL response.
1.5. Informational Messages outside of an IKE SA 1.5. Informational Messages outside of an IKE SA
If an encrypted IKE request packet arrives on port 500 or 4500 with If an encrypted IKE request packet arrives on port 500 or 4500 with
an unrecognized SPI, it could be because the receiving node has an unrecognized SPI, it could be because the receiving node has
recently crashed and lost state or because of some other system recently crashed and lost state or because of some other system
malfunction or attack. If the receiving node has an active IKE SA to malfunction or attack. If the receiving node does not have an active
the IP address from whence the packet came, it MAY send a IKE SA to the IP address from whence the packet came, it MAY send a
notification of the wayward packet over that IKE SA in an notification of the wayward packet with a Notify payload without
INFORMATIONAL exchange. If it does not have such an IKE SA, it MAY cryptographic protection to the source IP address. Such a message is
send an Informational message without cryptographic protection to the not part of an INFORMATIONAL exchange, and the receiving node MUST
source IP address. Such a message is not part of an informational NOT respond to it. Doing so could cause a message loop.
exchange, and the receiving node MUST NOT respond to it. Doing so
could cause a message loop.
The INVALID_SPI notification MAY be sent in an IKE INFORMATIONAL The INVALID_SPI notification MAY be sent in an IKE INFORMATIONAL
exchange when a node receives an ESP or AH packet with an invalid exchange when a node receives an ESP or AH packet with an invalid
SPI. The Notification Data contains the SPI of the invalid packet. SPI. The Notification Data contains the SPI of the invalid packet.
This usually indicates a node has rebooted and forgotten an SA. If This usually indicates a node has rebooted and forgotten an SA. If
this Informational Message is sent outside the context of an IKE SA, this Notify payload is sent outside the context of an IKE SA, it
it should only be used by the recipient as a "hint" that something should only be used by the recipient as a "hint" that something might
might be wrong (because it could easily be forged). The recipient of be wrong (because it could easily be forged). The recipient of this
this notification cannot tell whether the SPI is for AH or ESP, but notification cannot tell whether the SPI is for AH or ESP, but this
this is not important because the SPIs are supposed to be different is not important because the SPIs are supposed to be different for
for the two. the two.
There are two cases when a one-way message is sent: INVALID_IKE_SPI There are two cases when a one-way message is sent: INVALID_IKE_SPI
and INVALID_SPI. These messages are sent outside of an IKE SA. Note and INVALID_SPI. These messages are sent outside of an IKE SA. Note
that such messages are explicitly not Informational exchanges; these that such messages are explicitly not INFORMATIONAL exchanges; these
are one-way messages that must not be responded to. are one-way messages that must not be responded to.
(INVALID_MAJOR_VERSION is also a one-way message which is sent (INVALID_MAJOR_VERSION is also a one-way message which is sent
outside of an IKE SA, although it is sent as a response to the outside of an IKE SA, although it is sent as a response to the
incoming IKE SA creation.) incoming IKE SA creation.)
In case of INVALID_IKE_SPI, the message sent is a response message, In case of INVALID_IKE_SPI, the message sent is a response message,
and thus it is sent to the IP address and port from whence it came and thus it is sent to the IP address and port from whence it came
with the same IKE SPIs and the Message ID is copied. The Response with the same IKE SPIs and the Message ID is copied. The Response
bit is set to 1, and the version flags are set in the normal fashion. bit is set to 1, and the version flags are set in the normal fashion.
For a one-way INVALID_IKE_SPI notification for an unrecognized SPI, For a one-way INVALID_IKE_SPI notification for an unrecognized SPI,
skipping to change at page 20, line 12 skipping to change at page 20, line 12
is set, the Response bit is set to 0, and the version flags are set is set, the Response bit is set to 0, and the version flags are set
in the normal fashion. in the normal fashion.
1.6. Requirements Terminology 1.6. Requirements Terminology
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.
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"MAY" that appear in this document are to be interpreted as described "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
in [MUSTSHOULD]. document are to be interpreted as described in [MUSTSHOULD].
1.7. 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]. The clarifications are mostly based on [Clarif]. The [IKEV2]. The clarifications are mostly 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
version number (2) and minor version number (0) as was used in RFC version number (2) and minor version number (0) as was used in RFC
4306. That is, the version number is *not* changed from RFC 4306. 4306. That is, the version number is *not* changed from RFC 4306.
This document makes the figures and references a bit more regular This document makes the figures and references a bit more regular
than in [IKEV2]. than in [IKEV2].
IKEv2 developers have noted that the SHOULD-level requirements are IKEv2 developers have noted that the SHOULD-level requirements in RFC
often unclear in that they don't say when it is OK to not obey the 4306 are often unclear in that they don't say when it is OK to not
requirements. They also have noted that there are MUST-level obey the requirements. They also have noted that there are MUST-
requirements that are not related to interoperability. This document level requirements that are not related to interoperability. This
has more explanation of some of these requirements. All non- document has more explanation of some of these requirements. All
capitalized uses of the words SHOULD and MUST now mean their normal non-capitalized uses of the words SHOULD and MUST now mean their
English sense, not the interoperability sense of [MUSTSHOULD]. normal English sense, not the interoperability sense of [MUSTSHOULD].
IKEv2 (and IKEv1) developers have noted that there is a great deal of IKEv2 (and IKEv1) developers have noted that there is a great deal of
material in the tables of codes in Section 3.10.1. This leads to material in the tables of codes in Section 3.10.1 in RFC 4306. This
implementers not having all the needed information in the main body leads to implementers not having all the needed information in the
of the document. Much of the material from those tables has been main body of the document. Much of the material from those tables
moved into the associated parts of the main body of the document. has been moved into the associated parts of the main body of the
document.
This document removes discussion of nesting AH and ESP. This was a This document removes discussion of nesting AH and ESP. This was a
mistake in RFC 4306 caused by the lag between finishing RFC 4306 and mistake in RFC 4306 caused by the lag between finishing RFC 4306 and
RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not
include "SA bundles" that were part of RFC 2401. While a single include "SA bundles" that were part of RFC 2401. While a single
packet can go through IPsec processing multiple times, each of these packet can go through IPsec processing multiple times, each of these
passes uses a separate SA, and the passes are coordinated by the passes uses a separate SA, and the passes are coordinated by the
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. value for INTERNAL_ADDRESS_EXPIRY. This document also removed
INTERNAL_IP6_NBNS as a configuration attribute.
This document adds the restriction in Section 2.13 that all PRFs used This document removes the allowance for rejecting messages where the
with IKEv2 MUST take variable-sized keys. This should not affect any payloads were not in the "right" order; now implementations MUST NOT
implementations because there were no standardized PRFs that have reject them. This is due to the lack of clarity where the orders for
fixed-size keys. the payloads are described.
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
4306. Also, many of those lists are now preceded with the very
important instruction to developers that they really should look at
the IANA registry at the time of development because new items have
been added since RFC 4306.
This document adds clarification on when notifications are and are
not sent encrypted, depending on the state of the negotiation at the
time.
This document discusses more about how to negotiate combined-mode
ciphers such as GCM and GMAC.
In section 1.3.2, changed "The KEi payload SHOULD be included" to be
"The KEi payload MUST be included". This also lead to changes in
section 2.18.
In Section 2.3, there is new material covering how the initiator's
SPI and/or IP is used to differentiate if this is a "half-open" IKE
SA or a new request.
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
different traffic selectors and algorithms than the old one" to "Note
that, when rekeying, the new Child SA SHOULD NOT 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.9.2 covers traffic selectors in rekeying.
This document adds the restriction in Section 2.13 that all pseudo-
random functions (PRFs) used with IKEv2 MUST take variable-sized
keys. This should not affect any implementations because there were
no standardized PRFs that have fixed-size keys.
Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie-
Hellman exchange was optional, but this was not useful (or
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.
Added Section 2.23.1 to describe NAT traversal when transport mode is
requested.
All of Section 2.25 was added to explain how to act when there are All of Section 2.25 was added to explain how to act when there are
timing collisions when deleting and/or rekeying SAs. timing collisions when deleting and/or rekeying SAs, and two new
error notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were
defined.
In Section 3.6, added "Implementations MUST support the HTTP method
for hash-and-URL lookup. The behavior of other URL methods is not
currently specified, and such methods SHOULD NOT be used in the
absence of a document specifying them."
In Section 3.15.3, added a pointer to a new document that is related
to configuration of IPv6 addresses.
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.
IKE is designed to function so long as (1) at least one of a series IKE is designed to function so long as (1) at least one of a series
of retransmitted packets reaches its destination before timing out; of retransmitted packets reaches its destination before timing out;
skipping to change at page 21, line 45 skipping to change at page 23, line 9
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, X.509 structures with no hard upper bound on size (in particular, X.509
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 oversize UDP messages, but implementations vary in the maximum of oversize 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 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
than including certificates in exchanges where possible can avoid than including certificates in exchanges where possible can avoid
most problems. Implementations and configuration need to keep in most problems. Implementations and configuration need to keep in
mind, however, that if the URL lookups are possible only after the mind, however, that if the URL lookups are possible only after the
IPsec SA is established, recursion issues could prevent this Child SA is established, recursion issues could prevent this
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 request/response pairs. setup of an IKE SA normally consists of two request/response pairs.
skipping to change at page 22, line 40 skipping to change at page 23, line 51
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 triggers a retransmission of the request except insofar as it triggers a retransmission of the
response. The initiator MUST remember each request until it receives response. The initiator MUST remember each request until it receives
the corresponding response. The responder MUST remember each the corresponding response. The responder MUST remember each
response until it receives a request whose sequence number is larger response until it receives a request whose sequence number is larger
than or equal to the sequence number in the response plus its window than or equal to the sequence number in the response plus its window
size (see Section 2.3). In order to allow saving memory, responders size (see Section 2.3). In order to allow saving memory, responders
are allowed to forget response after a timeout of several minutes. are allowed to forget the response after a timeout of several
If the responder receives a retransmitted request for which it has minutes. If the responder receives a retransmitted request for which
already forgotten the response, it MUST ignore the request (and not, it has already forgotten the response, it MUST ignore the request
for example, attempt constructing a new response). (and not, for example, attempt constructing a new response).
IKE is a reliable protocol, in the sense that the initiator MUST IKE is a reliable protocol: the initiator MUST retransmit a request
retransmit a request until either it receives a corresponding reply until either it receives a corresponding response, or until it deems
OR it deems the IKE security association to have failed and it the IKE SA to have failed. In the latter case, the initiator
discards all state associated with the IKE SA and any Child SAs discards all state associated with the IKE SA and any Child SAs that
negotiated using that IKE SA. A retransmission from the initiator were negotiated using that IKE SA. A retransmission from the
MUST be bitwise identical to the original request. That is, initiator MUST be bitwise identical to the original request. That
everything starting from the IKE Header (the IKE SA Initiator's SPI is, everything starting from the IKE Header (the IKE SA initiator's
onwards) must be bitwise identical; items before it (such as the IP SPI onwards) must be bitwise identical; items before it (such as the
and UDP headers, and the zero non-ESP marker) do not have to be IP and UDP headers) do not have to be identical.
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 page 23, line 32 skipping to change at page 24, line 42
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. identify retransmissions of messages.
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. The Message ID is reset to zero in the new each subsequent exchange. Thus, the first pair of IKE_AUTH messages
IKE SA after the IKE SA is rekeyed. Rekeying an IKE SA resets the will have ID of 1, the second (when EAP is used) will be 2, and so
sequence numbers. Thus, the first pair of IKE_AUTH messages will on. The Message ID is reset to zero in the new IKE SA after the IKE
have ID of 1, the second (when EAP is used) will be 2, and so on. 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 very different numbers
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 (I)nitiator and (R)esponse bits in the message header specify the (I)nitiator and (R)esponse bits in the message header specify
which of the four messages a particular one is. which 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, and "original initiator" initiated the exchange being described. The "original initiator"
refers to the party who initiated the whole IKE SA. The "original always refers to the party who initiated the exchange which resulted
initiator" always refers to the party who initiated the exchange in the current IKE SA. In other words, if the "original responder"
which resulted in the current IKE SA. In other words, if the starts rekeying the IKE SA, that party becomes the "original
"original responder" starts rekeying the IKE SA, that party becomes initiator" of the new IKE SA.
the "original 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
The SET_WINDOW_SIZE notification asserts that the sending endpoint is The SET_WINDOW_SIZE notification asserts that the sending endpoint is
capable of keeping state for multiple outstanding exchanges, capable of keeping state for multiple outstanding exchanges,
skipping to change at page 25, line 43 skipping to change at page 27, line 4
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
packets over discarded SAs and having them fall into a black hole. packets over discarded SAs and having them fall into a black hole.
The INITIAL_CONTACT notification asserts that this IKE SA is the only The INITIAL_CONTACT notification asserts that this IKE SA is the only
IKE SA currently active between the authenticated identities. It MAY IKE SA currently active between the authenticated identities. It MAY
be sent when an IKE SA is established after a crash, and the be sent when an IKE SA is established after a crash, and the
recipient MAY use this information to delete any other IKE SAs it has recipient MAY use this information to delete any other IKE SAs it has
to the same authenticated identity without waiting for a timeout. to the same authenticated identity without waiting for a timeout.
This notification MUST NOT be sent by an entity that may be This notification MUST NOT be sent by an entity that may be
replicated (e.g., a roaming user's credentials where the user is replicated (e.g., a roaming user's credentials where the user is
allowed to connect to the corporate firewall from two remote systems allowed to connect to the corporate firewall from two remote systems
at the same time). The INITIAL_CONTACT notification, if sent, MUST at the same time). The INITIAL_CONTACT notification, if sent, MUST
be in the first IKE_AUTH request or response, not as a separate be in the first IKE_AUTH request or response, not as a separate
exchange afterwards; however, receiving parties MAY ignore it in exchange afterwards; receiving parties MAY ignore it in other
other messages. messages.
Since IKE is designed to operate in spite of Denial of Service (DoS) Since IKE is designed to operate in spite of denial of service
attacks from the network, an endpoint MUST NOT conclude that the attacks from the network, an endpoint MUST NOT conclude that the
other endpoint has failed based on any routing information (e.g., other endpoint has failed based on any routing information (e.g.,
ICMP messages) or IKE messages that arrive without cryptographic ICMP messages) or IKE messages that arrive without cryptographic
protection (e.g., Notify messages complaining about unknown SPIs). protection (e.g., Notify messages complaining about unknown SPIs).
An endpoint MUST conclude that the other endpoint has failed only An endpoint MUST conclude that the other endpoint has failed only
when repeated attempts to contact it have gone unanswered for a when repeated attempts to contact it have gone unanswered for a
timeout period or when a cryptographically protected INITIAL_CONTACT timeout period or when a cryptographically protected INITIAL_CONTACT
notification is received on a different IKE SA to the same notification is received on a different IKE SA to the same
authenticated identity. An endpoint should suspect that the other authenticated identity. An endpoint should suspect that the other
endpoint has failed based on routing information and initiate a endpoint has failed based on routing information and initiate a
skipping to change at page 26, line 29 skipping to change at page 27, line 40
retransmitted) message has been received from the other side retransmitted) message has been received from the other side
recently, unprotected notifications MAY be ignored. Implementations recently, unprotected notifications MAY be ignored. Implementations
MUST limit the rate at which they take actions based on unprotected MUST limit the rate at which they take actions based on unprotected
messages. messages.
Numbers of retries and lengths of timeouts are not covered in this Numbers of retries and lengths 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, retranmission 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 MUST NOT continue sending on any SA if endpoint. An implementation MUST NOT continue sending on any SA if
some failure prevents it from receiving on all of the associated SAs. some failure prevents it from receiving on all of the associated SAs.
If Child SAs can fail independently from one another without the If Child SAs can fail independently from one another without the
associated IKE SA being able to send a delete message, then they MUST associated IKE SA being able to send a delete message, then they MUST
be negotiated by separate IKE SAs. be negotiated by separate IKE SAs.
There is a Denial of Service attack on the initiator of an IKE SA There is a denial of service attack on the initiator of an IKE SA
that can be avoided if the initiator takes the proper care. Since that can be avoided if the initiator takes the proper care. Since
the first two messages of an SA setup are not cryptographically the first two messages of an SA setup are not cryptographically
protected, an attacker could respond to the initiator's message protected, an attacker could respond to the initiator's message
before the genuine responder and poison the connection setup attempt. before the genuine responder and poison the connection setup attempt.
To prevent this, the initiator MAY be willing to accept multiple To prevent this, the initiator MAY be willing to accept multiple
responses to its first message, treat each as potentially legitimate, responses to its first message, treat each as potentially legitimate,
respond to it, and then discard all the invalid half-open connections respond to it, and then discard all the invalid half-open connections
when it receives a valid cryptographically protected response to any when it receives a valid cryptographically protected response to any
one of its requests. Once a cryptographically valid response is one of its requests. Once a cryptographically valid response is
received, all subsequent responses should be ignored whether or not received, all subsequent responses should be ignored whether or not
skipping to change at page 29, line 9 skipping to change at page 30, line 19
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 which 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 Section 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.
2.6. IKE SA SPIs and Cookies 2.6. IKE SA SPIs and Cookies
The term "cookies" originates with Karn and Simpson [PHOTURIS] in The term "cookies" originates with Karn and Simpson [PHOTURIS] in
Photuris, an early proposal for key management with IPsec, and it has Photuris, an early proposal for key management with IPsec, and it has
persisted. The Internet Security Association and Key Management persisted. The Internet Security Association and Key Management
Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-
octet fields titled "cookies", and that syntax is used by both IKEv1 octet fields titled "cookies", and that syntax is used by both IKEv1
skipping to change at page 30, line 36 skipping to change at page 31, line 46
The first two messages do not affect any initiator or responder state The first two messages do not affect any initiator or responder state
except for communicating the cookie. In particular, the message except for communicating the cookie. In particular, the message
sequence numbers in the first four messages will all be zero and the sequence numbers in the first four messages will all be zero and the
message sequence numbers in the last two messages will be one. 'A' message sequence numbers in the last two messages will be one. 'A'
is the SPI assigned by the initiator, while 'B' is the SPI assigned is the SPI assigned by the initiator, while 'B' is the SPI assigned
by the responder. by the responder.
An IKE implementation can implement its responder cookie generation An IKE implementation can implement its responder cookie generation
in such a way as to not require any saved state to recognize its in such a way as to not require any saved state to recognize its
valid cookie when the second IKE_SA_INIT message arrives. The exact valid cookie when the second IKE_SA_INIT message arrives. The exact
algorithms and syntax they use to generate cookies do not affect algorithms and syntax used to generate cookies do not affect
interoperability and hence are not specified here. The following is interoperability and hence are not specified here. The following is
an example of how an endpoint could use cookies to implement limited an example of how an endpoint could use cookies to implement limited
DOS protection. DOS protection.
A good way to do this is to set the responder cookie to be: A good way to do this is to set the responder cookie to be:
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>) Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
where <secret> is a randomly generated secret known only to the where <secret> is a randomly generated secret known only to the
responder and periodically changed and | indicates concatenation. responder and periodically changed and | indicates concatenation.
<VersionIDofSecret> should be changed whenever <secret> is <VersionIDofSecret> should be changed whenever <secret> is
regenerated. The cookie can be recomputed when the IKE_SA_INIT regenerated. The cookie can be recomputed when the IKE_SA_INIT
arrives the second time and compared to the cookie in the received arrives the second time and compared to the cookie in the received
message. If it matches, the responder knows that the cookie was message. If it matches, the responder knows that the cookie was
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 Ni in the hash prevents an forge a message 3. Also, incorporating SPi 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 lots of machines behind one NAT box who 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 denial of service changed, since that would defeat part of the denial of service
protection. The responder should change the value of <secret> protection. The responder should change the value of <secret>
frequently, especially if under attack. frequently, especially if under attack.
In addition to cookies, there are several cases where the IKE_SA_INIT
exchange does not result in the creation of an IKE SA (such as
INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a case, sending a
zero value for the Responder's SPI is correct. If the responder
sends a non-zero responder SPI, the initiator should not reject the
response for only that reason.
When one party receives an IKE_SA_INIT request containing a cookie When one party receives an IKE_SA_INIT request containing a cookie
whose contents do not match the value expected, that party MUST whose contents do not match the value expected, that party MUST
ignore the cookie and process the message as if no cookie had been ignore the cookie and process the message as if no cookie had been
included; usually this means sending a response containing a new included; usually this means sending a response containing a new
cookie. The initiator should limit the number of cookie exchanges it cookie. The initiator should limit the number of cookie exchanges it
tries before giving up. An attacker can forge multiple cookie tries before giving up. An attacker can forge multiple cookie
responses to the initiator's IKE_SA_INIT message, and each of those responses to the initiator's IKE_SA_INIT message, and each of those
forged cookie replies will trigger two packets: one packet from the forged cookie replies will trigger two packets: one packet from the
initiator to the responder (which will reject those cookies), and one initiator to the responder (which will reject those cookies), and one
reply from responder to initiator that includes the correct cookie. response from responder to initiator that includes the correct
cookie.
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
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.
skipping to change at page 34, line 14 skipping to change at page 35, line 18
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. established, delete the old one. Note that, when rekeying, the new
Child SA SHOULD NOT have different traffic selectors and algorithms
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. Note that, when be the last request sent over the old IKE SA.
rekeying, the new Child SA SHOULD NOT have different traffic
selectors and algorithms than the old one.
SAs should be rekeyed proactively, i.e., the new SA should be SAs should be rekeyed proactively, i.e., the new SA should be
established before the old one expires and becomes unusable. Enough established before the old one expires and becomes unusable. Enough
time should elapse between the time the new SA is established and the time should elapse between the time the new SA is established and the
old one becomes unusable so that traffic can be switched over to the old one becomes unusable so that traffic can be switched over to the
new SA. new SA.
A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the SA is responsible for were negotiated. In IKEv2, each end of the SA is responsible for
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 should do so if there has been no traffic since lifetime expires. It can also do so if there has been no traffic
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.
The node that initiated the surviving rekeyed SA should delete the
replaced SA after the new one is established.
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 page 36, line 8 skipping to change at page 37, line 10
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
SA. If redundant SAs are created though such a collision, the SA SA. If redundant SAs are created though such a collision, the SA
created with the lowest of the four nonces used in the two exchanges created with the lowest of the four nonces used in the two exchanges
SHOULD be closed by the endpoint that created it. "Lowest" means an SHOULD be closed by the endpoint that created it. "Lowest" means an
octet-by-octet, lexicographical comparison (instead of, for instance, octet-by-octet, lexicographical comparison (instead of, for instance,
comparing the nonces as large integers). In other words, start by comparing the nonces as large integers). In other words, start by
comparing the first octet; if they're equal, move to the next octet, comparing the first octet; if they're equal, move to the next octet,
and so on. If you reach the end of one nonce, that nonce is the and so on. If you reach the end of one nonce, that nonce is the
lower one. lower one. The node that initiated the surviving rekeyed SA should
delete the replaced SA after the new one is established.
The following is an explanation on the impact this has on The following is an explanation on the impact this has on
implementations. Assume that hosts A and B have an existing IPsec SA implementations. Assume that hosts A and B have an existing Child SA
pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
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 <--
skipping to change at page 37, line 37 skipping to change at page 38, line 45
From B's point of view, the rekeying is now completed, and since it From B's point of view, the rekeying is now completed, and since it
has not yet received A's req1, it does not even know that there was has not yet received A's req1, it does not even know that there was
simultaneous rekeying. However, A will continue retransmitting the simultaneous rekeying. However, A will continue retransmitting the
message, and eventually it will reach B. message, and eventually it will reach B.
resend req1 --> resend req1 -->
--> recv req1 --> recv req1
To B, it looks like A is trying to rekey an SA that no longer exists; To B, it looks like A is trying to rekey an SA that no longer exists;
thus, B responds to the request with something non-fatal such as thus, B responds to the request with something non-fatal such as
NO_PROPOSAL_CHOSEN. CHILD_SA_NOT_FOUND.
<-- send resp1: N(NO_PROPOSAL_CHOSEN) <-- send resp1: N(CHILD_SA_NOT_FOUND)
recv resp1 <-- recv resp1 <--
When A receives this error, it already knows there was simultaneous When A receives this error, it already knows there was simultaneous
rekeying, so it can ignore the error message. rekeying, so it can ignore the error message.
2.8.2. Simultaneous IKE SA Rekeying 2.8.2. Simultaneous IKE SA Rekeying
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 right IKE_SA. the CHILD_SAs are inherited by the right 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 inherits the Child SAs. The new IKE SA containing the lowest nonce inherits the Child
SAs. If only one peer detects a simultaneous rekey, redundant SAs SAs.
are not created. In this case, when the peer that did not notice the
If only one peer detects a simultaneous rekey, redundant SAs are not
created. In this case, when the peer that did not notice the
simultaneous rekey gets the request to rekey the IKE SA that it has simultaneous rekey gets the request to rekey the IKE SA that it has
already successfully rekeyed, it MUST return TEMPORARY_FAILURE already successfully rekeyed, it SHOULD return TEMPORARY_FAILURE
because it is an IKE SA that it is currently trying to close (whether because it is an IKE SA that it is currently trying to close (whether
or not it has already sent the delete notification for the SA). If or not it has already sent the delete notification for the SA). If
the peer that did notice the simultaneous rekey gets the delete the peer that did notice the simultaneous rekey gets the delete
request from the other peer for the old IKE SA, it knows that the request from the other peer for the old IKE SA, it knows that the
other peer did not detect the simultaneous rekey, and the first peer other peer did not detect the simultaneous rekey, and the first peer
can forget its own rekey attempt. can forget its own rekey attempt.
However, there is a twist to the other case where one rekeying
finishes first:
Host A Host B Host A Host B
------------------------------------------------------------------- -------------------------------------------------------------------
send req1: send req1:
SA(..,SPIa1,..),Ni1,.. --> SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,.. <-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1 --> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,.. <-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <-- recv resp1 <--
send req3: D() --> send req3: D() -->
--> recv req3 --> recv req3
skipping to change at page 40, line 7 skipping to change at page 41, line 13
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 192.0.1.* on the initiator's side to tunnel all traffic from subnet 198.51.100.* on the initiator's side
subnet 192.0.2.* on the responder's side, the initiator would include to subnet 192.0.2.* on the responder's side, the initiator would
a single traffic selector in each TS payload. TSi would specify the include a single traffic selector in each TS payload. TSi would
address range (192.0.1.0 - 192.0.1.255) and TSr would specify the specify the address range (198.51.100.0 - 198.51.100.255) and TSr
address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was would specify the address range (192.0.2.0 - 192.0.2.255). Assuming
acceptable to the responder, it would send identical TS payloads that proposal was acceptable to the responder, it would send
back. (Note: The IP address range 192.0.2.* has been reserved for identical TS payloads back.
use in examples in RFCs and similar documents. This document needed
two such ranges, and so also used 192.0.1.*. This should not be
confused with any actual address.)
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 be ignores that traffic selector, so that the unknown type is not be
returned in the narrowed set. returned in the narrowed set.
To enable the responder to choose the appropriate range in this case, If the initiator requests an SA because it wants to send a data
if the initiator has requested the SA due to a data packet, the packet, including the specific addresses in the packet triggering the
initiator SHOULD include as the first traffic selector in each of TSi request in the first traffic selector in both TSi and TSr enables the
and TSr a very specific traffic selector including the addresses in responder to choose the appropriate range. In the example, the
the packet triggering the request. In the example, the initiator initiator would include in TSi two traffic selectors: the first
would include in TSi two traffic selectors: the first containing the containing the address range (198.51.100.43 - 198.51.100.43) and the
address range (192.0.1.43 - 192.0.1.43) and the source port and IP source port and IP protocol from the packet and the second containing
protocol from the packet and the second containing (192.0.1.0 - (198.51.100.0 - 198.51.100.255) with all ports and IP protocols. The
192.0.1.255) with all ports and IP protocols. The initiator would initiator would similarly include two traffic selectors in TSr. If
similarly include two traffic selectors in TSr. If the initiator the initiator creates the Child SA pair not in response to an
creates the Child SA pair not in response to an arriving packet, but arriving packet, but rather, say, upon startup, then there may be no
rather, say, upon startup, then there may be no specific addresses specific addresses the initiator prefers for the initial tunnel over
the initiator prefers for the initial tunnel over any other. In that any other. In that case, the first values in TSi and TSr can be
case, the first values in TSi and TSr can be ranges rather than 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 TS_UNACCEPTABLE. the proposed traffic selectors, it responds with TS_UNACCEPTABLE.
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
(192.0.1.43 - 192.0.1.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. Such misconfigurations tunnel wider than the responder will accept.
should be recorded in error logs.
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 generated its separately negotiated Child SA. If the initiator didn't generate its
request in response to an incoming packet from 192.0.1.43 to request based on the packet, but (for example) upon startup, there
192.0.2.123, there would be no way for the responder to determine would not be the very specific first traffic selectors helping the
which pair of addresses should be included in this tunnel, and it responder to select the correct range. There would be no way for the
would have to make a guess or reject the request with a status of responder to determine which pair of addresses should be included in
SINGLE_PAIR_REQUIRED. this tunnel, and it would have to make a guess or reject the request
with a status of SINGLE_PAIR_REQUIRED.
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,
skipping to change at page 42, line 21 skipping to change at page 43, line 21
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 192.0.1.66 is sent via host B policy whose effect is that traffic to 198.51.100.66 is sent via host
encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 B encrypted using AES, and traffic to all other hosts in
is also sent via B, but must use 3DES. Suppose also that host B 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also
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 (192.0.1.0-192.0.1.255), this will be accepted by host B. containing (198.51.100.0-198.51.100.255), this will be accepted by
Now, host B can also use this SA to send traffic from 192.0.1.66, but host B. Now, host B can also use this SA to send traffic from
those packets will be dropped by A since it requires the use of AES 198.51.100.66, but those packets will be dropped by A since it
for those traffic. Even if host A creates a new SA only for requires the use of AES for this traffic. Even if host A creates a
192.0.1.66 that uses AES, host B may freely continue to use the first new SA only for 198.51.100.66 that uses AES, host B may freely
SA for the traffic. In this situation, when proposing the SA, host A continue to use the first SA for the traffic. In this situation,
should have followed its own policy, and included a TSr containing when proposing the SA, host A should have followed its own policy,
((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. and included a TSr containing ((198.51.100.0-
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
does not actually accept traffic X' with SA, and (3) the initiator does not actually accept traffic X' with SA, and (3) the initiator
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 pseudo-
random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST
be randomly chosen, MUST be at least 128 bits in size, and MUST be at be randomly chosen, MUST be at least 128 bits in size, and MUST be at
least half the key size of the negotiated prf. ("prf" refers to least half the key size of the negotiated pseudo-random function
"pseudo-random function", one of the cryptographic algorithms (PRF). However, the initiator chooses the nonce before the outcome
negotiated in the IKE exchange.) However, the initiator chooses the of the negotiation is known. Because of that, the nonce has to be
nonce before the outcome of the negotiation is known. Because of long enough for all the PRFs being proposed. If the same random
that, the nonce has to be long enough for all the PRFs being number source is used for both keys and nonces, care must be taken to
proposed. If the same random number source is used for both keys and ensure that the latter use does not compromise the former.
nonces, care must be taken to 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 it runs over. 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
skipping to change at page 44, line 7 skipping to change at page 45, line 6
reasonable strategies for doing this. An endpoint could choose a new reasonable strategies for doing this. An endpoint could choose a new
exponential only periodically though this could result in less-than- exponential only periodically though this could result in less-than-
perfect forward secrecy if some connection lasts for less than the perfect forward secrecy if some connection lasts for less than the
lifetime of the exponential. Or it could keep track of which lifetime of the exponential. Or it could keep track of which
exponential was used for each connection and delete the information exponential was used for each connection and delete the information
associated with the exponential only when some corresponding associated with the exponential only when some corresponding
connection was closed. This would allow the exponential to be reused connection was closed. This would allow the exponential to be reused
without losing perfect forward secrecy at the cost of maintaining without losing perfect forward secrecy at the cost of maintaining
more state. more state.
Decisions as to whether and when to reuse Diffie-Hellman exponentials Whether and when to reuse Diffie-Hellman exponentials are private
is a private decision in the sense that it will not affect decisions in the sense that they will not affect interoperability.
interoperability. An implementation that reuses exponentials MAY An implementation that reuses exponentials MAY choose to remember the
choose to remember the exponential used by the other endpoint on past exponential used by the other endpoint on past exchanges and if one
exchanges and if one is reused to avoid the second half of the is reused to avoid the second half of the calculation. See [REUSE]
calculation. See [REUSE] for a security analysis of this practice for a security analysis of this practice and for additional security
and for additional security considerations when reusing ephemeral DH considerations when reusing ephemeral DH keys.
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 pseudo-random function
(prf). The pseudo-random function is used for the construction of (PRF). The PRF is used for the construction of keying material for
keying material for all of the cryptographic algorithms used in both all of the cryptographic algorithms used in both the IKE SA and the
the IKE SA and the Child SAs. Child 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 defintion of the Key Length transform attribute). For algorithms the definition of the Key Length transform attribute). For
for which not all values are valid keys (such as DES or 3DES with key algorithms for which not all values are valid keys (such as DES or
parity), the algorithm by which keys are derived from arbitrary 3DES with key parity), the algorithm by which keys are derived from
values MUST be specified by the cryptographic transform. For arbitrary values MUST be specified by the cryptographic transform.
integrity protection functions based on Hashed Message Authentication For integrity protection functions based on Hashed Message
Code (HMAC), the fixed key size is the size of the output of the Authentication Code (HMAC), the fixed key size is the size of the
underlying hash function. output of the underlying hash function.
It is assumed that pseudo-random functions (PRFs) accept keys of any It is assumed that PRFs accept keys of any length, but have a
length, but have a preferred key size. The preferred key size is preferred key size. The preferred key size is used as the length of
used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based on the
PRFs based on the HMAC construction, the preferred key size is equal HMAC construction, the preferred key size is equal to the length of
to the length of the output of the underlying hash function. Other the output of the underlying hash function. Other types of PRFs MUST
types of PRFs MUST specify their preferred key size. 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 algorithm, we may be greater than the size of the output of the PRF, the PRF is
will use the prf iteratively. We will use the terminology prf+ to used iteratively. The term "prf+" describes a function that outputs
describe the function that outputs a pseudo-random stream based on a pseudo-random stream based on the inputs to a pseudo-random
the inputs to a prf as follows: (where | indicates concatenation) function called "prf".
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)
...
continuing as needed to compute all required keys. The keys are This continues until all the material needed to compute all required
taken from the output string without regard to boundaries (e.g., if keys has been output from prf+. The keys are taken from the output
the required keys are a 256-bit Advanced Encryption Standard (AES) string without regard to boundaries (e.g., if the required keys are a
key and a 160-bit HMAC key, and the prf function generates 160 bits, 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC
the AES key will come from T1 and the beginning of T2, while the HMAC key, and the prf function generates 160 bits, the AES key will come
key will come from the rest of T2 and the beginning of T3). from T1 and the beginning of T2, while the HMAC key will come from
the rest of T2 and the beginning of T3).
The constant concatenated to the end of each string feeding the prf The constant concatenated to the end of each prf function is a single
is a single octet. prf+ in this document is not defined beyond 255 octet. The prf+ function is not defined beyond 255 times the size of
times the size of the prf output. the prf function output.
2.14. Generating Keying Material for the IKE SA 2.14. Generating Keying Material for the IKE SA
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
skipping to change at page 48, line 33 skipping to change at page 49, line 33
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 memo references [EAP] with the intent that new methods can While this document references [EAP] with the intent that new methods
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 and in Section 3.16. [EAP] simpler variations are documented here. [EAP] defines an
defines an authentication protocol requiring a variable number of authentication protocol requiring a variable number of messages.
messages. Extensible Authentication is implemented in IKE as Extensible Authentication is implemented in IKE as additional
additional IKE_AUTH exchanges that MUST be completed in order to IKE_AUTH exchanges that MUST be completed in order to initialize the
initialize the IKE SA. IKE SA.
An initiator indicates a desire to use extensible authentication by An initiator indicates a desire to use extensible authentication by
leaving out the AUTH payload from message 3. By including an IDi leaving out the AUTH payload from message 3. By including an IDi
payload but not an AUTH payload, the initiator has declared an payload but not an AUTH payload, the initiator has declared an
identity but has not proven it. If the responder is willing to use identity but has not proven it. If the responder is willing to use
an extensible authentication method, it will place an Extensible an extensible authentication method, it will place an Extensible
Authentication Protocol (EAP) payload in message 4 and defer sending Authentication Protocol (EAP) payload in message 4 and defer sending
SAr2, TSi, and TSr until initiator authentication is complete in a SAr2, TSi, and TSr until initiator authentication is complete in a
subsequent IKE_AUTH exchange. In the case of a minimal extensible subsequent IKE_AUTH exchange. In the case of a minimal extensible
authentication, the initial SA establishment will appear as follows: authentication, the initial SA establishment will appear as follows:
skipping to change at page 51, line 34 skipping to change at page 52, line 34
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
stripped of any headers. stripped of any headers.
The old and new IKE SA may have selected a different PRF. Because The old and new IKE SA may have selected a different PRF. Because
the rekeying exchange belongs to the old IKE SA, it is the old IKE the rekeying exchange belongs to the old IKE SA, it is the old IKE
SA's PRF that is used. SA's PRF that is used to generate SKEYSEED.
The main reason for rekeying the IKE SA is to ensure that the The main reason for rekeying the IKE SA is to ensure that the
compromise of old keying material does not provide information about compromise of old keying material does not provide information about
the current keys, or vice versa. Therefore, implementations MUST the current keys, or vice versa. Therefore, implementations MUST
perform a new Diffie-Hellman exchange when rekeying the IKE SA. In perform a new Diffie-Hellman exchange when rekeying the IKE SA. In
other words, an initiator MUST NOT propose the value "NONE" for the other words, an initiator MUST NOT propose the value "NONE" for the
D-H transform, and a responder MUST NOT accept such a proposal. This D-H transform, and a responder MUST NOT accept such a proposal. This
means that a succesful exchange rekeying the IKE SA always includes means that a successful exchange rekeying the IKE SA always includes
the KEi/KEr payloads. the KEi/KEr payloads.
The new IKE SA MUST reset its message counters to 0. The new IKE SA MUST reset its message counters to 0.
SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new
exchange. exchange, and using the new IKE SA's PRF.
2.19. Requesting an Internal Address on a Remote Network 2.19. Requesting an Internal Address on a Remote Network
Most commonly occurring in the endpoint-to-security-gateway scenario, Most commonly occurring in the endpoint-to-security-gateway scenario,
an endpoint may need an IP address in the network protected by the an endpoint may need an IP address in the network protected by the
security gateway and may need to have that address dynamically security gateway and may need to have that address dynamically
assigned. A request for such a temporary address can be included in assigned. A request for such a temporary address can be included in
any request to create a Child SA (including the implicit request in any request to create a Child SA (including the implicit request in
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
skipping to change at page 53, line 19 skipping to change at page 54, line 19
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)
All returned values will be implementation dependent. As can be seen All returned values will be implementation dependent. As can be seen
in the above example, the IRAS MAY also send other attributes that in the above example, the IRAS MAY also send other attributes that
were not included in CP(CFG_REQUEST) and MAY ignore the non- were not included in CP(CFG_REQUEST) and MAY ignore the non-
mandatory attributes that it does not support. mandatory attributes that it does not support.
The FAILED_CP_REQUIRED notification is sent by responder in the case
where CP(CFG_REQUEST) was expected but not received, and so is a
conflict with locally configured policy. There is no associated
data.
The responder MUST NOT send a CFG_REPLY without having first received The responder MUST NOT send a CFG_REPLY without having first received
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. In the case where the IRAS's configuration process the REPLY.
requires that CP be used for a given identity IDi, but IRAC has
failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and In the case where the IRAS's configuration requires that CP be used
terminate the IKE exchange with a FAILED_CP_REQUIRED error. The for a given identity IDi, but IRAC has failed to send a
FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child
Child SA creation fail. The initiator can fix this by later starting SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED
a new configuration payload request. is not fatal to the IKE SA; it simply causes the Child SA creation
fail. The initiator can fix this by later starting a new
configuration payload request. There is no associated data in the
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
prior to authentication or even after authentication to prevent prior to authentication or even after authentication to prevent
skipping to change at page 56, line 5 skipping to change at page 57, line 5
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 in when processing a response following it (in case an error happened in when processing a response
to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and to 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. understand them.
NOTE FOR WG DISCUSSION: Having other payloads in the message is
allowed but there are none suggested. One WG member mentioned the
possibility of adding a DELETE payload when the error is sent in a
separate INFORMATIONAL exchange. Do we want to allow such additional
payloads that have operational semantics?
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 response notifying about the error. result in response notifying about the error.
In normal situations, there should not be cases where valid response In normal situations, there should not be cases where valid response
from one peer results in an error situation in the other peer, so 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 messages to there should not be any reason for a peer to send error messages to
the other end except as a response. Because sending such error the other end except as a response. Because sending such error
messages as INFORMATIONAL exchange might lead to further errors that messages as INFORMATIONAL exchange might lead to further errors that
skipping to change at page 59, line 46 skipping to change at page 60, line 42
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 MUST endpoint that discovers a NAT between it and its correspondent MUST
send all subsequent traffic from port 4500, which NATs should not send all subsequent traffic from port 4500, which NATs should not
treat specially (as they might with port 500). treat specially (as they might with port 500).
An initiator can float to port 4500, regardless whether or not there An initiator can use port 4500, regardless whether or not there is
is NAT, even at the beginning of IKE. When either side is using port NAT, even at the beginning of IKE. When either side is using port
4500, sending with UDP encapsulation is not required, but 4500, sending with UDP encapsulation is not required, but
understanding received packets with UDP encapsulation is required. understanding received packets with UDP encapsulation is required.
UDP encapsulation MUST NOT be done on port 500. If NAT-T is UDP encapsulation MUST NOT be done on port 500. If NAT-T is
supported (that is, if NAT_DETECTION_*_IP payloads were exchanged supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
during IKE_SA_INIT), all devices MUST be able to receive and process during IKE_SA_INIT), all devices MUST be able to receive and process
both UDP encapsulated and non-UDP encapsulated packets at any time. both UDP encapsulated and non-UDP encapsulated packets at any time.
Either side can decide whether or not to use UDP encapsulation Either side can decide whether or not to use UDP encapsulation
irrespective of the choice made by the other side. However, if a NAT irrespective of the choice made by the other side. However, if a NAT
is detected, both devices MUST send UDP encapsulated packets. is detected, both devices MUST send UDP encapsulated packets.
skipping to change at page 60, line 28 skipping to change at page 61, line 24
o Both IKE initiator and responder MUST include in their IKE_SA_INIT o Both IKE initiator and responder MUST include in their IKE_SA_INIT
packets Notify payloads of type NAT_DETECTION_SOURCE_IP and packets Notify payloads of type NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP. Those payloads can be used to NAT_DETECTION_DESTINATION_IP. Those payloads can be used to
detect if there is NAT between the hosts, and which end is behind detect if there is NAT between the hosts, and which end is behind
the NAT. The location of the payloads in the IKE_SA_INIT packets the NAT. The location of the payloads in the IKE_SA_INIT packets
is just after the Ni and Nr payloads (before the optional CERTREQ is just after the Ni and Nr payloads (before the optional CERTREQ
payload). 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 on 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 IP address, and port, value to a SHA-1 hash of the SPIs, source IP address, and port,
and if they don't match it SHOULD enable NAT traversal. In the and if they don't match it SHOULD enable NAT traversal. In the
case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient case there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with
MAY reject the connection attempt if NAT traversal is not all of the NAT_DETECTION_SOURCE_IP payloads received, the
supported. In the case of a mismatching recipient MAY reject the connection attempt if NAT traversal is
not supported. In the case of a mismatching
NAT_DETECTION_DESTINATION_IP hash, it means that the system NAT_DETECTION_DESTINATION_IP hash, it means that the system
receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT
and that system SHOULD start sending keepalive packets as defined and that system SHOULD start sending keepalive packets as defined
in [UDPENCAPS]; alternately, it MAY reject the connection attempt in [UDPENCAPS]; alternately, it MAY reject the connection attempt
if NAT traversal is not supported. 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 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 update of the other
systems' IP address, as described later. systems' IP address, as described later.
o If the NAT_DETECTION_DESTINATION_IP payload received does not
match the hash of the destination IP and port found from the IP
header of the packet containing the payload, it means that the
system receiving the NAT_DETECTION_DESTINATION_IP payload is
behind a NAT. In this case, that system SHOULD start sending
keepalive packets as explained in [UDPENCAPS].
o The IKE initiator MUST check these payloads if present and if they o The IKE initiator MUST check these payloads if present and if they
do not match the addresses in the outer packet MUST tunnel all do not match the addresses in the outer packet MUST tunnel all
future IKE and ESP packets associated with this IKE SA over UDP future IKE and ESP packets associated with this IKE SA over UDP
port 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
skipping to change at page 61, line 52 skipping to change at page 62, line 40
original IP address. original IP address.
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). To recover in these cases, hosts or the NAT box is rebooted). To recover in these cases, hosts
that do not support other methods of recovery such as MOBIKE that do not support other methods of recovery such as MOBIKE
[MOBIKE], and that are not behind a NAT, SHOULD send all packets [MOBIKE], and that are not behind a NAT, SHOULD send all packets
(including retransmission packets) to the IP address and port from (including retransmission packets) to the IP address and port from
the last valid authenticated packet from the other end (that is, the last valid authenticated packet from the other end (that is,
they should dynamically update the address). A host behind a NAT they should dynamically update the address). A host behind a NAT
SHOULD NOT do this because it opens a possible denial-of-service SHOULD NOT do this because it opens a possible denial of service
attack. Any authenticated IKE packet or any authenticated UDP- attack. Any authenticated IKE packet or any authenticated UDP-
encapsulated ESP packet can be used to detect that the IP address encapsulated ESP packet can be used to detect that the IP address
or the port has changed. When IKEv2 is used with MOBIKE, or the port has changed. When IKEv2 is used with MOBIKE,
dynamically updating the addresses described above interferes with dynamically updating the addresses described above interferes with
MOBIKE's way of recovering from the same situation, so this method MOBIKE's way of recovering from the same situation. See Section
MUST NOT be used when MOBIKE is used. See Section 3.8 of [MOBIKE] 3.8 of [MOBIKE] for more information.
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 simplications 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 dynamic NAT that maps the clients source address IP1
to IPN1. NAT B is static NAT configured so that connections coming to IPN1. NAT B is static NAT configured so that connections coming
to IPN2 address are mapped to the gateways adddress IP2, that is, to IPN2 address are mapped to the gateways address IP2, that is, IPN2
IPN2 destination address is mapped to IP2. This allows the client to destination address is mapped to IP2. This allows the client to
connect to a server by connecting to the IPN2. NAT B does not connect to a server by connecting to the IPN2. NAT B does not
necessarily need to be a static NAT, but the client needs to know how necessarily need to be a static NAT, but the client needs to know how
to connect to the server, and it can only do that if it somehow knows to connect to the server, and it can only do that if it somehow knows
the outer address of the NAT B, that is, the IPN2 address. If NAT B the outer address of the NAT B, that is, the IPN2 address. If NAT B
is a static NAT, then its address can be configured to the client's is a static NAT, then its address can be configured to the client's
configuration. Other options would be find it using some other configuration. Other options would be find it using some other
protocol (like DNS), but those are outside of scope of IKEv2. protocol (like DNS), but those are outside of scope of IKEv2.
In this scenario, both client and server are configured to use In this scenario, both 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
skipping to change at page 63, line 6 skipping to change at page 63, line 47
traffic to the server, it has a triggering packet with source IP traffic to the server, it has 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 PAD and
SPD needs to have configuration matching those addresses (or wildcard SPD needs to have configuration matching those addresses (or wildcard
entries covering them). Because this is transport mode, it uses entries covering them). Because this is transport mode, it uses
exactly same addresses as the traffic selectors and outer IP address exactly same addresses as the traffic selectors and outer IP address
of the IKE packets. For transport mode, it MUST use exactly one IP of the IKE packets. For transport mode, it MUST use exactly one IP
address in the TSi and TSr payloads. It can have multiple traffic address in the TSi and TSr payloads. It can have multiple traffic
selectors if it has, for example, multiple port ranges that it wants selectors if it has, for example, multiple port ranges that it wants
to negotiate, but all TSi entries must use IP1-IP1 range as the IP to negotiate, but all TSi entries must use IP1-IP1 range as the IP
addresses, and all TSr entries must have the IPN2-IPN2 range as IP addresses, and all TSr entries must have the IPN2-IPN2 range as IP
the addresses. The first traffic selector of TSi and TSr SHOULD have addresses. The first traffic selector of TSi and TSr SHOULD have
very specific traffic selectors including protocol and port numbers very specific traffic selectors including protocol and port numbers
from the packet triggering the request. 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 which 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 to
IPN1 and IP2. IPN1 and IP2.
skipping to change at page 63, line 29 skipping to change at page 64, line 21
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 lookup based address client has behind the NAT), it is useless to do lookup based
on that if transport mode is used. On the other hand, the server on that if transport mode is used. On the other hand, the server
cannot know whether transport mode is allowed by its policy before it cannot know whether transport mode is allowed by its policy before it
finds the matching SPD entry. finds the matching SPD entry.
In this case, the server should first check that as initiator In this case, the server should first check that as initiator
requested transport mode and do address substitution on the traffic requested transport mode and do address substitution on the traffic
selectors. It needs to first store the old traffic selector IP 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 real source address and the address in the TSi can be stored as the original source address and
IP address in the TSr can be stored as the real destination address). the IP address in the TSr can be stored as the original destination
After that, if the other end was detected as being behind a NAT, the address). After that, if the other end was detected as being behind
server replaces the IP address in TSi payloads with the IP address a NAT, the server replaces the IP address in TSi payloads with the IP
obtained from the source address of the IKE packet received (that is, address obtained from the source address of the IKE packet received
it replaces IP1 in TSi with IPN1). If the server's end was detected (that is, it replaces IP1 in TSi with IPN1). If the server's end was
to be behind NAT, it replaces the IP address in the TSr payloads with detected to be behind NAT, it replaces the IP address in the TSr
the IP address obtained from the destination address of the IKE payloads with the IP address obtained from the destination address of
packet received (thta is, it replaces IPN2 in TSr with IP2). the IKE packet received (that is, it replaces 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.
skipping to change at page 64, line 19 skipping to change at page 65, line 11
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 reply to the Child SA, it will When the client receives the server's response to the Child SA, it
do similar processing. If the transport mode SA was created, the will do similar processing. If the transport mode SA was created,
client can store the original returned traffic selectors as real the client can store the original returned traffic selectors as
source and destination addresses. It will replace the IP addresses original source and destination addresses. It will replace the IP
in the traffic selectors with the ones from the IP header of the IKE addresses in the traffic selectors with the ones from the IP header
packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2.
will use those traffic selectors when verifying the SA against sent Then it will use those traffic selectors when verifying the SA
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 from the traffic selectors including protocol and port numbers from the
packet triggering the request. 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 reply): included USE_TRANSPORT_MODE notification in its response):
- Store the original traffic selectors as the real 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 else 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 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 real source - Store the original traffic selector IP addresses as received source
and destination address in case we need to undo address and destination address, both in case we need to undo address
substitution. substitution, and to use as the "real source and destination
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.
skipping to change at page 66, line 40 skipping to change at page 66, line 41
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 IPsec 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
skipping to change at page 67, line 24 skipping to change at page 67, line 26
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 state information is out-of-sync and close it SHOULD conclude that state information is out-of-sync and close
the IKE SA. 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. A peer that a request to rekey a Child SA that does not exist. The SA that the
receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the initiator attempted to rekey is indicated by the SPI field in the
Child SA and send a request to create a new Child SA from scratch. Notify Payload, which is copied from the SPI field in the REYEY_SA
notification. A peer that receives a CHILD_SA_NOT_FOUND notification
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
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. If a peer receives a request to rekey a later based on the nonces (see Section 2.8.1). If a peer receives 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. If a peer trying to close, it SHOULD reply without Delete payloads (see
receives a request to close a Child SA that it is currently rekeying, Section 1.4.1). If a peer receives a request to close a Child SA
it SHOULD reply as usual, with Delete payload. If a peer receives a that it is currently rekeying, it SHOULD reply as usual, with Delete
request to close a Child SA that does not exist, it SHOULD reply payload. If a peer receives a request to close a Child SA that does
without Delete payloads. not exist, it SHOULD reply without Delete payloads.
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
If a peer receives a request to rekey an IKE SA that it is currently (see Section 2.8.2). If a peer receives a request to rekey an IKE SA
trying to close, it SHOULD reply with TEMPORARY_FAILURE. that it is currently trying to close, it SHOULD reply with
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
request. If a peer receives a request to close an IKE SA that it is request. If a peer receives a request to close an IKE SA that it is
currently trying to close, it SHOULD reply as usual, and forget about currently trying to close, it SHOULD reply as usual, and forget about
its own close request. its own close request.
If a peer receives a request to create or rekey a Child SA when it is If a peer receives a request to create or rekey a Child SA when it is
currently rekeying the IKE SA, it SHOULD reply with currently rekeying the IKE SA, it SHOULD reply with
TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA
when it is currently rekeying the IKE SA, it SHOULD reply as usual, when it is currently rekeying the IKE SA, it SHOULD reply as usual,
with a Delete payload. with a Delete payload.
3. Header and Payload Formats 3. Header and Payload Formats
In the tables in this section, some cryptographic primitives and In the tables in this section, some cryptographic primitives and
configuation attributes are marked as "UNSPECIFIED". These are items configuration attributes are marked as "UNSPECIFIED". These are
for which there are no known specifications and therefore items for which there are no known specifications and therefore
interoperability is currently impossible. A future specification may interoperability is currently impossible. A future specification may
describe their use, but until such specification is made, describe their use, but until such specification is made,
implementations SHOULD NOT attempt to use items marked as implementations SHOULD NOT attempt to use items marked as
"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 zero 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 memo. Following the header are one IKE header, denoted HDR in this document. Following the header are
or more IKE payloads each identified by a "Next Payload" field in the one or more IKE payloads each identified by a "Next Payload" field in
preceding payload. Payloads are processed in the order in which they the preceding payload. Payloads are processed in the order in which
appear in an IKE message by invoking the appropriate processing they appear in an IKE message by invoking the appropriate processing
routine according to the "Next Payload" field in the IKE header and routine according to the "Next Payload" field in the IKE header and
subsequently according to the "Next Payload" field in the IKE payload subsequently according to the "Next Payload" field in the IKE payload
itself until a "Next Payload" field of zero indicates that no itself until a "Next Payload" field of zero indicates that no
payloads follow. If a payload of type "Encrypted" is found, that payloads follow. If a payload of type "Encrypted" is found, that
payload is decrypted and its contents parsed as additional payloads. payload is decrypted and its contents parsed as additional payloads.
An Encrypted payload MUST be the last payload in a packet and an An Encrypted payload MUST be the last payload in a packet and an
Encrypted payload MUST NOT contain another Encrypted payload. Encrypted payload MUST NOT contain another Encrypted payload.
The Recipient SPI in the header identifies an instance of an IKE The Recipient 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
skipping to change at page 70, line 36 skipping to change at page 70, line 37
Exchange Type Value Exchange Type Value
---------------------------------- ----------------------------------
IKE_SA_INIT 34 IKE_SA_INIT 34
IKE_AUTH 35 IKE_AUTH 35
CREATE_CHILD_SA 36 CREATE_CHILD_SA 36
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 defined LSB first, so in the flags field being set. The bits are as follows:
bit 0 would be the least significant bit of the Flags octet. In
the description below, a bit being 'set' means its value is '1',
while 'cleared' means its value is '0'.
* X(reserved) (bits 0-2) - These bits MUST be cleared when +-+-+-+-+-+-+-+-+
sending and MUST be ignored on receipt. |X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+
* I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages In the description below, a bit being 'set' means its value is
sent by the original initiator of the IKE SA and MUST be '1', while 'cleared' means its value is '0'. "X" bits MUST be
cleared in messages sent by the original responder. It is used cleared when sending and MUST be ignored on receipt.
by the recipient to determine which eight octets of the SPI
were generated by the recipient. This bit changes to reflect
who initiated the last rekey of the IKE SA.
* V(ersion) (bit 4 of Flags) - This bit indicates that the * I(nitiator) - This bit MUST be set in messages sent by the
transmitter is capable of speaking a higher major version original initiator of the IKE SA and MUST be cleared in
number of the protocol than the one indicated in the major messages sent by the original responder. It is used by the
version number field. Implementations of IKEv2 MUST clear this recipient to determine which eight octets of the SPI were
bit when sending and MUST ignore it in incoming messages. generated by the recipient. This bit changes to reflect who
initiated the last rekey of the IKE SA.
* R(esponse) (bit 5 of Flags) - This bit indicates that this * V(ersion) - This bit indicates that the transmitter is capable
message is a response to a message containing the same message of speaking a higher major version number of the protocol than
ID. This bit MUST be cleared in all request messages and MUST the one indicated in the major version number field.
be set in all responses. An IKE endpoint MUST NOT generate a Implementations of IKEv2 MUST clear this bit when sending and
response to a message that is marked as being a response. MUST ignore it in incoming messages.
* X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared * R(esponse) - This bit indicates that this message is a response
when sending and MUST be ignored on receipt. to a message containing the same message ID. This bit MUST be
cleared in all request messages and MUST be set in all
responses. An IKE endpoint MUST NOT generate a response to a
message that is marked as being a response.
o Message ID (4 octets) - Message identifier used to control o Message ID (4 octets) - Message identifier used to control
retransmission of lost packets and matching of requests and retransmission of lost packets and matching of requests and
responses. It is essential to the security of the protocol 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. Section 2.1 and Section 2.2.
o Length (4 octets) - Length of total message (header + payloads) in o Length (4 octets) - Length of total message (header + payloads) in
octets. octets.
skipping to change at page 72, line 5 skipping to change at page 72, line 6
o Next Payload (1 octet) - Identifier for the payload type of the o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the last next payload in the message. If the current payload is the last
in the message, then this field will be 0. This field provides a in the message, then this field will be 0. This field provides a
"chaining" capability whereby additional payloads can be added to "chaining" capability whereby additional payloads can be added to
a message by appending it to the end of the message and setting a message by appending it to the end of the message and setting
the "Next Payload" field of the preceding payload to indicate the the "Next Payload" field of the preceding payload to indicate the
new payload's type. An Encrypted payload, which must always be new payload's type. An Encrypted payload, which must always be
the last payload of a message, is an exception. It contains data the last payload of a message, is an exception. It contains data
structures in the format of additional payloads. In the header of structures in the format of additional payloads. In the header of
an Encrypted payload, the Next Payload field is set to the payload an Encrypted payload, the Next Payload field is set to the payload
type of the first contained payload (instead of 0). type of the first contained payload (instead of 0). The payload
type values are listed here. The values in the following table
o The payload type values are listed here. The values in the are only current as of the publication date of RFC 4306. Other
following table are only current as of the publication date of RFC values may have been added since then or will be added after the
4306. Other values may have been added since then or will be publication of this document. Readers should refer to [IKEV2IANA]
added after the publication of this document. Readers should for the latest values.
refer to [IKEV2IANA] for the latest values.
Next Payload Type Notation Value Next Payload Type Notation Value
-------------------------------------------------- --------------------------------------------------
No Next Payload 0 No Next Payload 0
Security Association SA 33 Security Association SA 33
Key Exchange KE 34 Key Exchange KE 34
Identification - Initiator IDi 35 Identification - Initiator IDi 35
Identification - Responder IDr 36 Identification - Responder IDr 36
Certificate CERT 37 Certificate CERT 37
Certificate Request CERTREQ 38 Certificate Request CERTREQ 38
Authentication AUTH 39 Authentication AUTH 39
Nonce Ni, Nr 40 Nonce Ni, Nr 40
Notify N 41 Notify N 41
Delete D 42 Delete D 42
Vendor ID V 43 Vendor ID V 43
Traffic Selector - Initiator TSi 44 Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45 Traffic Selector - Responder TSr 45
Encrypted E 46 Encrypted and Authenticated SK 46
Configuration CP 47 Configuration CP 47
Extensible Authentication EAP 48 Extensible Authentication EAP 48
(Payload type values 1-32 should not be assigned in the (Payload type values 1-32 should not be assigned in the
future so that there is no overlap with the code assignments future so that there is no overlap with the code assignments
for IKEv1.) for IKEv1.)
o Critical (1 bit) - MUST be set to zero if the sender wants the o Critical (1 bit) - MUST be set to zero if the sender wants the
recipient to skip this payload if it does not understand the recipient to skip this payload if it does not understand the
payload type code in the Next Payload field of the previous payload type code in the Next Payload field of the previous
skipping to change at page 72, line 51 skipping to change at page 72, line 51
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. Payload and Payload Length fields. See Section 2.5 for more
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) - Length in octets of the current o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header. 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 memo, is used to The Security Association Payload, denoted SA in this document, is
negotiate attributes of a security association. Assembly of Security used to negotiate attributes of a security association. Assembly of
Association Payloads requires great peace of mind. An SA payload MAY Security Association Payloads requires great peace of mind. An SA
contain multiple proposals. If there is more than one, they MUST be payload MAY contain multiple proposals. If there is more than one,
ordered from most preferred to least preferred. Each proposal they MUST be ordered from most preferred to least preferred. Each
contains a single IPsec protocol (where a protocol is IKE, ESP, or proposal contains a single IPsec protocol (where a protocol is IKE,
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.
skipping to change at page 74, line 4 skipping to change at page 74, line 6
One of the reasons the semantics of the SA payload has changed from One of the reasons the semantics of the SA payload has 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 # and an IPsec The Proposal structure contains within it a Proposal # 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 # of one (1). One reason initiator's SA payload MUST have a Proposal # of one (1). One reason
to use multiple proposals is to propose both standard crypto ciphers to use multiple proposals is to propose both standard crypto ciphers
and combined-mode ciphers. Combined-mode ciphers include both and combined-mode ciphers. Combined-mode ciphers include both
integrity and encryption in a single encryption algorithm, and are integrity and encryption in a single encryption algorithm, and MUST
not allowed to be offered with a separate integrity algorithm other either offer no integrity algorithm or a single integrity algorithm
than "none". If an initiator wants to propose both combined-mode of "none", with no integrity algorithm being the RECOMMENDED method.
ciphers and normal ciphers, it must include two proposals: one will If an initiator wants to propose both combined-mode ciphers and
have all the combined-mode ciphers, and the other will have all the normal ciphers, it must include two proposals: one will have all the
normal ciphers with the integrity algorithms. For example, one such combined-mode ciphers, and the other will have all the normal ciphers
proposal would have two proposal structures: ESP with ENCR_AES-CCM_8, with the integrity algorithms. For example, one such proposal would
ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with have two proposal structures: ESP with ENCR_AES-CCM_8, ENCR_AES-
CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with
ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as
Proposal #2. Proposal #2.
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 (ESN) 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. If an algorithm that combines and an encryption algorithm. For each Protocol, the set of
encryption and integrity protection is proposed, it MUST be proposed permissible transforms is assigned transform ID numbers, which appear
as an encryption algorithm and an integrity protection algorithm MUST in the header of each transform.
NOT be proposed. For each Protocol, the set of permissible
transforms is assigned transform ID numbers, which appear 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
skipping to change at page 83, line 47 skipping to change at page 83, line 47
that response MUST be rejected. that response MUST be rejected.
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 contains a Similarly, if the responder receives a transform that contains a
Transform Attribute it does not understand, it MUST consider this Transform Attribute it does not understand, it MUST consider this
transform unacceptable; other transforms with the same Transform Type transform unacceptable; other transforms with the same Transform Type
are processed as usual. This allows new Transform Types and are processed as usual. This allows new Transform Types and
Transform Attributes to be defined in the future. An exception is Transform Attributes to be defined in the future.
the case where one of the proposals offered is for the Diffie-Hellman
group of NONE. In this case, the responder MUST ignore the
initiator's KE payload and omit the KE payload from the response.
Negotiating Diffie-Hellman groups presents some special challenges. Negotiating Diffie-Hellman groups presents some special challenges.
SA offers include proposed attributes and a Diffie-Hellman public SA offers include proposed attributes and a Diffie-Hellman public
number (KE) in the same message. If in the initial exchange the number (KE) in the same message. If in the initial exchange the
initiator offers to use one of several Diffie-Hellman groups, it initiator offers to use one of several Diffie-Hellman groups, it
SHOULD pick the one the responder is most likely to accept and SHOULD pick the one the responder is most likely to accept and
include a KE corresponding to that group. If the responder selects a include a KE corresponding to that group. If the responder selects a
proposal using a different Diffie-Hellman group (other than NONE), proposal using a different Diffie-Hellman group (other than NONE),
the responder will indicate the correct group in the response and the the responder will indicate the correct group in the response and the
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. middle downgrade attack. If one of the proposals offered is for the
Diffie-Hellman group of NONE, the responder MUST ignore the
initiator's KE payload and 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 memo, 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH Group # | RESERVED | | DH Group # | RESERVED |
skipping to change at page 85, line 4 skipping to change at page 84, line 51
performed, prepending zero bits to the value if necessary. performed, prepending zero bits to the value if necessary.
The DH Group # identifies the Diffie-Hellman group in which the Key The DH Group # identifies the Diffie-Hellman group in which the Key
Exchange Data was computed (see Section 3.3.2). This Group # MUST Exchange Data was computed (see Section 3.3.2). This Group # MUST
match a DH Group specified in a proposal in the SA payload that is match a DH Group specified in a proposal in the SA payload that is
sent in the same message, and SHOULD match the DH group in the first sent in the same message, and SHOULD match the DH group in the first
group in the first proposal, if such exists. If none of the group in the first proposal, if such exists. If none of the
proposals in that SA payload specifies a DH Group, the KE payload proposals in that SA payload specifies a DH Group, the KE payload
MUST NOT be present. If the selected proposal uses a different MUST NOT be present. If the selected proposal uses a different
Diffie-Hellman group (other than NONE), the message MUST be rejected Diffie-Hellman group (other than NONE), the message MUST be rejected
with a Notify payload of type INVALID_KE_PAYLOAD. with a Notify payload of type INVALID_KE_PAYLOAD. See also
Section 1.2 and 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 memo, allow The Identification Payloads, denoted IDi and IDr in this document,
peers to assert an identity to one another. This identity may be allow peers to assert an identity to one another. This identity may
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 is used purely to fetch the policy and authentication data
related to the other party. 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
skipping to change at page 87, line 12 skipping to change at page 87, line 12
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 a 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 RFC822 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 [X.501]. ASN.1 X.500 Distinguished Name [X.501].
skipping to change at page 88, line 14 skipping to change at page 88, line 14
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 memo, provides a means The Certificate Payload, denoted CERT in this document, provides a
to transport certificates or other authentication-related information means to transport certificates or other authentication-related
via IKE. Certificate payloads SHOULD be included in an exchange if information via IKE. Certificate payloads SHOULD be included in an
exchange if certificates are available to the sender. The Hash and
URL formats of the Certificate payloads should be used in case the
peer has indicated an ability to retrieve this information from
elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.
Certificate payloads SHOULD be included in an exchange if
certificates are available to the sender unless the peer has certificates are available to the sender unless the peer has
indicated an ability to retrieve this information from elsewhere indicated an ability to retrieve this information from elsewhere
using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the
term "Certificate Payload" is somewhat misleading, because not all term "Certificate Payload" is somewhat misleading, because not all
authentication mechanisms use certificates and data other than authentication mechanisms use certificates and data other than
certificates may be passed in this payload. 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
skipping to change at page 89, line 30 skipping to change at page 89, line 30
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 denial of service attacks cached and makes IKE less subject to denial of service attacks
that become easier to mount when IKE messages are large enough to that become easier to mount when IKE messages are large enough to
require IP fragmentation [DOSUDPPROT]. require IP fragmentation [DOSUDPPROT].
skipping to change at page 90, line 44 skipping to change at page 90, line 44
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 method for hash-and-URL lookup. Implementations MUST support the HTTP method for hash-and-URL lookup.
The behavior of other URL methods is not currently specified, and The behavior of other URL methods is not currently specified, and
such methods SHOULD NOT be used in the absence of a document such methods SHOULD NOT be used in the absence of a document
specifying them. specifying them.
3.7. Certificate Request Payload 3.7. Certificate Request Payload
The Certificate Request Payload, denoted CERTREQ in this memo, 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. If multiple CAs sender needs to get the certificate of the receiver. If multiple CAs
are trusted and the certificate encoding does not allow a list, then are trusted and the certificate encoding does not allow a list, then
multiple Certificate Request payloads would need to be transmitted. multiple Certificate Request payloads would need to be transmitted.
The Certificate Request Payload is defined as follows: The Certificate Request Payload is defined as follows:
1 2 3 1 2 3
skipping to change at page 92, line 48 skipping to change at page 92, line 48
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 memo, contains data The Authentication Payload, denoted AUTH in this document, contains
used for authentication purposes. The syntax of the Authentication data used for authentication purposes. The syntax of the
data varies according to the Auth Method as specified below. Authentication data varies according to the Auth Method as specified
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 93, line 47 skipping to change at page 93, line 47
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 function. 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 memo for the initiator's The Nonce Payload, denoted Ni and Nr in this document for the
and responder's nonce respectively, contains random data used to initiator's and responder's nonce respectively, contains random data
guarantee liveness during an exchange and protect against replay used to guarantee liveness during an exchange and protect against
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 ~
skipping to change at page 95, line 25 skipping to change at page 95, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ 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 IPsec 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.
skipping to change at page 96, line 22 skipping to change at page 96, line 22
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.
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, plus two error types added in this
then or will be added after the publication of this document. document. Other values may have been added since then or will be
Readers should refer to [IKEV2IANA] for the latest values. added after the publication of this document. Readers should refer
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
skipping to change at page 96, line 47 skipping to change at page 96, line 50
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 denial of request was rejected for policy reasons. To avoid a denial of
service attack using forged messages, this status may only be service 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.
{{ Demoted the SHOULD }} To aid debugging, more detailed error To aid debugging, more detailed error information should be
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 proposal (including but not sent in any case where the offered proposal (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.3. See Section 1.3 and 2.7.
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. the authentication failed. There is no associated data. See also
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.
skipping to change at page 97, line 44 skipping to change at page 97, line 48
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 IPsec SA. notification is set to match the SPI of the Child SA.
TEMPORARY_FAILURE {TBA1}
See section 2.25.
CHILD_SA_NOT_FOUND {TBA2}
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 page 98, line 45 skipping to change at page 98, line 48
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 memo, 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
skipping to change at page 99, line 46 skipping to change at page 100, line 7
payload. The size of each SPI is defined by the SPI Size field. payload. The size of each SPI is defined 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 # of SPIs fields. field is determined by the SPI Size and # 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 memo, 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 memo-- private private use numbers described throughout this document, such as
payloads, private exchanges, private notifications, etc. Unfamiliar private payloads, private exchanges, private notifications, etc.
Vendor IDs MUST be ignored. Unfamiliar Vendor IDs MUST be ignored.
Writers of Internet-Drafts who wish to extend this protocol MUST Writers of Internet-Drafts who wish to extend this protocol MUST
define a Vendor ID payload to announce the ability to implement the define a Vendor ID payload to announce the ability to implement the
extension in the Internet-Draft. It is expected that Internet-Drafts extension in the Internet-Draft. It is expected that Internet-Drafts
that gain acceptance and are standardized will be given "magic that gain acceptance and are standardized will be given "magic
numbers" out of the Future Use range by IANA, and the requirement to numbers" out of the Future Use range by IANA, and the requirement to
use a Vendor ID will go away. use a Vendor ID will go away.
The Vendor ID Payload fields are defined as follows: The Vendor ID Payload fields are defined as follows:
skipping to change at page 101, line 7 skipping to change at page 101, line 12
include a company name, a person name, or some such. If you want include a company name, a person name, or some such. If you want
to show off, you might include the latitude and longitude and time to show off, you might include the latitude and longitude and time
where you were when you chose the ID and some random input. A where you were when you chose the ID and some random input. A
message digest of a long unique string is preferable to the long message digest of a long unique string is preferable to the long
unique string itself. 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 memo, allows peers The Traffic Selector Payload, denoted TS in this document, allows
to identify packet flows for processing by IPsec security services. peers to identify packet flows for processing by IPsec security
The Traffic Selector Payload consists of the IKE generic payload services. The Traffic Selector Payload consists of the IKE generic
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> ~
skipping to change at page 101, line 50 skipping to change at page 102, line 7
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, 192.0.1.66-192.0.1.66), TSi = ((17, 100, 198.51.100.66-198.51.100.66),
(17, 200, 192.0.1.66-192.0.1.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 192.0.1.66 to anywhere, with any of the would match UDP packets from 198.51.100.66 to anywhere, with any of
four combinations of source/destination ports (100,300), (100,400), the four combinations of source/destination ports (100,300),
(200,300), and (200, 400). (100,400), (200,300), and (200, 400).
Thus, some types of policies may require several Child SA pairs. For Thus, some types of policies may require several Child SA pairs. For
instance, a policy matching only source/destination ports (100,300) instance, a policy matching only source/destination ports (100,300)
and (200,400), but not the other two combinations, cannot be and (200,400), but not the other two combinations, cannot be
negotiated as a single Child SA pair. negotiated as a single Child SA pair.
3.13.1. Traffic Selector 3.13.1. Traffic Selector
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
skipping to change at page 102, line 42 skipping to change at page 102, line 48
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 (e.g., UDP/TCP/ICMP). A value of zero means that the protocol ID (such as UDP, TCP, and ICMP). A value of zero means
protocol ID is not relevant to this traffic selector-- the SA can that the protocol ID is not relevant to this traffic selector--
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) - Value specifying the smallest port number o Start Port (2 octets) - Value specifying the smallest port number
allowed by this Traffic Selector. For protocols for which port is allowed by this Traffic Selector. For protocols for which port is
undefined (including protocol 0), or if all ports are allowed, undefined (including protocol 0), or if all ports are allowed,
this field MUST be zero. For the ICMP protocol, the two one-octet this field MUST be zero. ICMP and ICMPv6 Type and Code values, as
fields Type and Code are treated as a single 16-bit integer (with well as MIPv6 MH Type values, are represented in this field as
specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code
values are treated as a single 16-bit integer port number, with
Type in the most significant eight bits and Code in the least Type in the most significant eight bits and Code in the least
significant eight bits) port number for the purposes of filtering significant eight bits. MIPv6 MH Type values are treated as a
based on this field. single 16-bit integer port number, with Type in the most
significant eight bits and the least significant eight bits set to
zero.
o End Port (2 octets) - Value specifying the largest port number o End Port (2 octets) - Value specifying the largest port number
allowed by this Traffic Selector. For protocols for which port is allowed by this Traffic Selector. For protocols for which port is
undefined (including protocol 0), or if all ports are allowed, undefined (including protocol 0), or if all ports are allowed,
this field MUST be 65535. For the ICMP protocol, the two one- this field MUST be 65535. ICMP and ICMPv6 Type and Code values,
octet fields Type and Code are treated as a single 16-bit integer as well as MIPv6 MH Type values, are represented in this field as
(with Type in the most significant eight bits and Code in the specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code
least significant eight bits) port number for the purposed of values are treated as a single 16-bit integer port number, with
filtering based on this field. Type in the most significant eight bits and Code in the least
significant eight bits. MIPv6 MH Type values are treated as a
single 16-bit integer port number, with Type in the most
significant eight bits and the least 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 type and The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6
code fields. Note, however, that ICMP packets do not have separate type and code fields, as well as MH Type fields for the IPv6 mobility
source and destination port fields. The method for specifying the header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets
traffic selectors for ICMP is shown by example in Section 4.4.1.3 of have separate source and destination fields. The method for
[IPSECARCH]. specifying the traffic selectors for ICMP and MIPv6 is shown by
example in Section 4.4.1.3 of [IPSECARCH].
Traffic selectors can use IP Protocol ID 135 to match the IPv6
mobility header [MIPV6]. This document does not specify how to
represent the "MH Type" field in traffic selectors, although it is
likely that a different document will specify this in the future.
Note that [IPSECARCH] says that the IPv6 mobility header (MH) message
type is placed in the most significant eight bits of the 16-bit local
port selector. The direction semantics of TSi/TSr port fields are
the same as for ICMP.
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
skipping to change at page 104, line 27 skipping to change at page 104, line 32
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{...} or E in this memo, contains The Encrypted Payload, denoted SK{...} or E in this document,
other payloads in encrypted form. The Encrypted Payload, if present contains other payloads in encrypted form. The Encrypted Payload, if
in a message, MUST be the last payload in the message. Often, it is present in a message, MUST be the last payload in the message.
the only payload in the message. Often, it is the only payload in the message.
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. Section 2.14 and Section 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
skipping to change at page 107, line 47 skipping to change at page 107, line 52
ignored on receipt. ignored on receipt.
o Attribute Type (15 bits) - A unique identifier for each of the o Attribute Type (15 bits) - A unique identifier for each of the
Configuration Attribute Types. Configuration Attribute Types.
o Length (2 octets) - Length in octets of Value. o Length (2 octets) - Length in octets of Value.
o Value (0 or more octets) - The variable-length value of this o Value (0 or more octets) - The variable-length value of this
Configuration Attribute. The following lists the attribute types. Configuration Attribute. The following lists the attribute types.
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 publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
since then or will be added after the publication of this INTERNAL_IP6_NBNS which were removed by this document). Other
document. Readers should refer to [IKEV2IANA] for the latest values may have been added since then or will be added after the
values. publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.
Attribute Type Value Valued Length Attribute Type Value Multi-Valued Length
------------------------------------------------------- ------------------------------------------------------------
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
INTERNAL_IP6_DNS 10 YES 0 or 16 octets INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 YES 17 octets INTERNAL_IP6_SUBNET 15 YES 17 octets
* These attributes may be multi-valued on return only if * These attributes may be multi-valued on return only if
multiple values were requested. multiple values were requested.
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or private internal network, sometimes called a red node address or private
address and MAY be a private address on the Internet. In a address and MAY be a private address on the Internet. In a
request message, the address specified is a requested address (or request message, the address specified is a requested address (or
a zero-length address if no specific address is requested). If a a zero-length address if no specific address is requested). If a
specific address is requested, it likely indicates that a previous specific address is requested, it likely indicates that a previous
skipping to change at page 108, line 42 skipping to change at page 108, line 46
MAY be requested by requesting multiple internal address MAY be requested by requesting multiple internal address
attributes. The responder MAY only send up to the number of attributes. The responder MAY only send up to the number of
addresses requested. The INTERNAL_IP6_ADDRESS is made up of two addresses requested. The INTERNAL_IP6_ADDRESS is made up of two
fields: the first is a 16-octet IPv6 address, and the second is a fields: the first is a 16-octet IPv6 address, and the second is a
one-octet prefix-length as defined in [ADDRIPV6]. The requested one-octet prefix-length as defined in [ADDRIPV6]. The requested
address is valid as long as this IKE SA (or its rekeyed address is valid as long as this IKE SA (or its rekeyed
successors) requesting the address is valid. This is described in successors) requesting the address is valid. This is described in
more detail in Section 3.15.3. more detail in Section 3.15.3.
o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one
netmask is allowed in the request and reply messages (e.g., netmask is allowed in the request and response messages (e.g.,
255.255.255.0), and it MUST be used only with an 255.255.255.0), and it MUST be used only with an
INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a
CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET
containing the same information ("send traffic to these addresses containing the same information ("send traffic to these addresses
through me"), but also implies a link boundary. For instance, the through me"), but also implies a link boundary. For instance, the
client could use its own address and the netmask to calculate the client could use its own address and the netmask to calculate the
broadcast address of the link. An empty INTERNAL_IP4_NETMASK broadcast address of the link. An empty INTERNAL_IP4_NETMASK
attribute can be included in a CFG_REQUEST to request this attribute can be included in a CFG_REQUEST to request this
information (although the gateway can send the information even information (although the gateway can send the information even
when not requested). Non-empty values for this attribute in a when not requested). Non-empty values for this attribute in a
skipping to change at page 109, line 44 skipping to change at page 109, line 49
response contains an attribute that contains a set of attribute response contains an attribute that contains a set of attribute
identifiers each in 2 octets. The length divided by 2 (octets) identifiers each in 2 octets. The length divided by 2 (octets)
would state the number of supported attributes contained in the would state the number of supported attributes contained in the
response. response.
o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields: the device protects. This attribute is made up of two fields: the
first is a 16-octet IPv6 address, and the second is a one-octet first is a 16-octet IPv6 address, and the second is a one-octet
prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY
be requested. The responder MAY respond with zero or more sub- be requested. The responder MAY respond with zero or more sub-
network attributes. This is discussed in more detail in Section network attributes. This is discussed in more detail in
3.15.2. Section 3.15.2.
Note that no recommendations are made in this document as to how an Note that no recommendations are made in this document as to how an
implementation actually figures out what information to send in a implementation actually figures out what information to send in a
reply. That is, we do not recommend any specific method of an IRAS response. That is, we do not recommend any specific method of an
determining which DNS server should be returned to a requesting IRAC. IRAS determining which DNS server should be returned to a requesting
IRAC.
The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
information from its peer. If an attribute in the CFG_REQUEST information from its peer. If an attribute in the CFG_REQUEST
Configuration Payload is not zero-length, it is taken as a suggestion Configuration Payload is not zero-length, it is taken as a suggestion
for that attribute. The CFG_REPLY Configuration Payload MAY return for that attribute. The CFG_REPLY Configuration Payload MAY return
that value, or a new one. It MAY also add new attributes and not that value, or a new one. It MAY also add new attributes and not
include some requested ones. Unrecognized or unsupported attributes include some requested ones. Unrecognized or unsupported attributes
MUST be ignored in both requests and responses. MUST be ignored in both requests and responses.
The CFG_SET and CFG_ACK pair allows an IKE endpoint to push The CFG_SET and CFG_ACK pair allows an IKE endpoint to push
skipping to change at page 110, line 27 skipping to change at page 110, line 33
it accepted any of the configuration data and it MUST contain the it accepted any of the configuration data and it MUST contain the
attributes that the responder accepted with zero-length data. Those attributes that the responder accepted with zero-length data. Those
attributes that it did not accept MUST NOT be in the CFG_ACK attributes that it did not accept MUST NOT be in the CFG_ACK
Configuration Payload. If no attributes were accepted, the responder Configuration Payload. If no attributes were accepted, the responder
MUST return either an empty CFG_ACK payload or a response message MUST return either an empty CFG_ACK payload or a response message
without a CFG_ACK payload. There are currently no defined uses for without a CFG_ACK payload. There are currently no defined uses for
the CFG_SET/CFG_ACK exchange, though they may be used in connection the CFG_SET/CFG_ACK exchange, though they may be used in connection
with extensions based on Vendor IDs. An implementation of this with extensions based on Vendor IDs. An implementation of this
specification MAY ignore CFG_SET payloads. specification MAY ignore CFG_SET payloads.
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET
INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets,
ones that need one or more separate SAs, that can be reached through ones that need one or more separate SAs, that can be reached through
the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET
attributes may also express the gateway's policy about what traffic attributes may also express the gateway's policy about what traffic
should be sent through the gateway; the client can choose whether should be sent through the gateway; the client can choose whether
other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is
sent through the gateway or directly to the destination. Thus, sent through the gateway or directly to the destination. Thus,
traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET
attributes should be sent through the gateway that announces the attributes should be sent through the gateway that announces the
attributes. If there are no existing IPsec SAs whose traffic attributes. If there are no existing Child SAs whose traffic
selectors cover the address in question, new SAs need to be created. selectors cover the address in question, new SAs need to be created.
For instance, if there are two subnets, 192.0.1.0/26 and For instance, if there are two subnets, 198.51.100.0/26 and
192.0.2.0/24, and the client's request contains the following: 192.0.2.0/24, and the client's request contains the following:
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS() INTERNAL_IP4_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)
then a valid response could be the following (in which TSr and then a valid response could be the following (in which TSr and
INTERNAL_IP4_SUBNET contain the same information): INTERNAL_IP4_SUBNET contain the same information):
CP(CFG_REPLY) = CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),
(0, 0-65535, 192.0.2.0-192.0.2.255)) (0, 0-65535, 192.0.2.0-192.0.2.255))
In these cases, the INTERNAL_IP4_SUBNET does not really carry any In these cases, the INTERNAL_IP4_SUBNET does not really carry any
useful information. useful information.
A different possible reply would have been this: A different possible response would have been this:
CP(CFG_REPLY) = CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
That reply would mean that the client can send all its traffic That response would mean that the client can send all its traffic
through the gateway, but the gateway does not mind if the client through the gateway, but the gateway does not mind if the client
sends traffic not included by INTERNAL_IP4_SUBNET directly to the sends traffic not included by INTERNAL_IP4_SUBNET directly to the
destination (without going through the gateway). destination (without going through the gateway).
A different situation arises if the gateway has a policy that A different situation arises if the gateway has a policy that
requires the traffic for the two subnets to be carried in separate requires the traffic for the two subnets to be carried in separate
SAs. Then a response like this would indicate to the client that if SAs. Then a response like this would indicate to the client that if
it wants access to the second subnet, it needs to create a separate it wants access to the second subnet, it needs to create a separate
SA: SA:
CP(CFG_REPLY) = CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)
INTERNAL_IP4_SUBNET can also be useful if the client's TSr included INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
only part of the address space. For instance, if the client requests only part of the address space. For instance, if the client requests
the following: the following:
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS() INTERNAL_IP4_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, 192.0.2.155-192.0.2.155) TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
then the gateway's reply might be: then the gateway's response might be:
CP(CFG_REPLY) = CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in
CFG_REQUESTs is unclear, they cannot be used reliably in CFG_REQUESTs is unclear, they cannot be used reliably in
CFG_REQUESTs. CFG_REQUESTs.
3.15.3. Configuration payloads for IPv6 3.15.3. Configuration payloads for IPv6
The configuration payloads for IPv6 are based on the corresponding The configuration payloads for IPv6 are based on the corresponding
IPv4 payloads, and do not fully follow the "normal IPv6 way of doing IPv4 payloads, and do not fully follow the "normal IPv6 way of doing
skipping to change at page 113, line 10 skipping to change at page 113, line 18
prefix; if even that fails, the gateway selects another interface prefix; if even that fails, the gateway selects another interface
identifier. identifier.
The INTERNAL_IP6_ADDRESS attribute also contains a prefix length The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
field. When used in a CFG_REPLY, this corresponds to the field. When used in a CFG_REPLY, this corresponds to the
INTERNAL_IP4_NETMASK attribute in the IPv4 case. INTERNAL_IP4_NETMASK attribute in the IPv4 case.
Although this approach to configuring IPv6 addresses is reasonably Although this approach to configuring IPv6 addresses is reasonably
simple, it has some limitations. IPsec tunnels configured using simple, it has some limitations. IPsec tunnels configured using
IKEv2 are not fully-featured "interfaces" in the IPv6 addressing IKEv2 are not fully-featured "interfaces" in the IPv6 addressing
architecture sense [IPV6ADDR]. In particular, they do not architecture sense [ADDRIPV6]. In particular, they do not
necessarily have link-local addresses, and this may complicate the necessarily have link-local addresses, and this may complicate the
use of protocols that assume them, such as [MLDV2]. use of protocols that assume them, such as [MLDV2].
3.15.4. Address Assignment Failures 3.15.4. Address Assignment Failures
If the responder encounters an error while attempting to assign an IP If the responder encounters an error while attempting to assign an IP
address to the initiator during the processing of a Configuration address to the initiator during the processing of a Configuration
Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification.
The IKE SA is still created even if the initial Child SA cannot be The IKE SA is still created even if the initial Child SA cannot be
created because of this failure. If this error is generated within created because of this failure. If this error is generated within
skipping to change at page 113, line 41 skipping to change at page 113, line 49
that the responder does not support, even though the responder that the responder does not support, even though the responder
supports configuration payloads. In this case, the responder simply supports configuration payloads. In this case, the responder simply
ignores the type of address it does not support and processes the ignores the type of address it does not support and processes the
rest of the request as usual. rest of the request as usual.
If the initiator requests multiple addresses of a type that the If the initiator requests multiple addresses of a type that the
responder supports, and some (but not all) of the requests fail, the responder supports, and some (but not all) of the requests fail, the
responder replies with the successful addresses only. The responder responder replies with the successful addresses only. The responder
sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
If the initiator does not receive the IP address(es) required by its
policy, it MAY keep the IKE SA up and retry the configuration payload
as separate INFORMATIONAL exchange after suitable timeout, or it MAY
tear down the IKE SA by sending a DELETE payload inside a separate
INFORMATIONAL exchange and later retry IKE SA from the beginning
after some timeout. Such a timeout should not be too short
(especially if the IKE SA is started from the beginning) because
these error situations may not be able to be fixed quickly; the
timeout should likely be several minutes. For example, an address
shortage problem on the responder will probably only be fixed when
more entries are returned to the address pool when other clients
disconnect or when responder is reconfigured with larger address
pool.
3.16. Extensible Authentication Protocol (EAP) Payload 3.16. Extensible Authentication Protocol (EAP) Payload
The Extensible Authentication Protocol Payload, denoted EAP in this The Extensible Authentication Protocol Payload, denoted EAP in this
memo, allows IKE SAs to be authenticated using the protocol defined document, allows IKE SAs to be authenticated using the protocol
in RFC 3748 [EAP] and subsequent extensions to that protocol. The defined in RFC 3748 [EAP] and subsequent extensions to that protocol.
full set of acceptable values for the payload is defined elsewhere, The full set of acceptable values for the payload is defined
but a short summary of RFC 3748 is included here to make this elsewhere, but a short summary of RFC 3748 is included here to make
document stand alone in the common cases. this document stand alone in the common cases.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ EAP Message ~ ~ EAP Message ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 116, line 20 skipping to change at page 116, line 34
in the payload header. If the critical bit is set in an unsupported in the payload header. If the critical bit is set in an unsupported
payload header, all implementations MUST reject the messages payload header, all implementations MUST reject the messages
containing those payloads. containing those payloads.
Every implementation MUST be capable of doing four-message Every implementation MUST be capable of doing four-message
IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
one for ESP or AH). Implementations MAY be initiate-only or respond- one for ESP or AH). Implementations MAY be initiate-only or respond-
only if appropriate for their platform. Every implementation MUST be only if appropriate for their platform. Every implementation MUST be
capable of responding to an INFORMATIONAL exchange, but a minimal capable of responding to an INFORMATIONAL exchange, but a minimal
implementation MAY respond to any INFORMATIONAL message with an empty implementation MAY respond to any INFORMATIONAL message with an empty
INFORMATIONAL reply (note that within the context of an IKE SA, an INFORMATIONAL response (note that within the context of an IKE SA, an
"empty" message consists of an IKE header followed by an Encrypted "empty" message consists of an IKE header followed by an Encrypted
payload with no payloads contained in it). A minimal implementation payload with no payloads contained in it). A minimal implementation
MAY support the CREATE_CHILD_SA exchange only in so far as to MAY support the CREATE_CHILD_SA exchange only in so far as to
recognize requests and reject them with a Notify payload of type recognize requests and reject them with a Notify payload of type
NO_ADDITIONAL_SAS. A minimal implementation need not be able to NO_ADDITIONAL_SAS. A minimal implementation need not be able to
initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
expires (based on locally configured values of either lifetime or expires (based on locally configured values of either lifetime or
octets passed), and implementation MAY either try to renew it with a octets passed), and implementation MAY either try to renew it with a
CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
create a new one. If the responder rejects the CREATE_CHILD_SA create a new one. If the responder rejects the CREATE_CHILD_SA
skipping to change at page 117, line 47 skipping to change at page 118, line 15
Use of EAP authentication changes the probing possibilities somewhat. Use of EAP authentication changes the probing possibilities somewhat.
When EAP authentication is used, the responder proves its identity When EAP authentication is used, the responder proves its identity
before the initiator does, so an initiator that knew the name of a before the initiator does, so an initiator that knew the name of a
valid initiator could probe the responder for both its name and valid initiator could probe the responder for both its name and
certificates. certificates.
Repeated rekeying using CREATE_CHILD_SA without additional Diffie- Repeated rekeying using CREATE_CHILD_SA without additional Diffie-
Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
single key or overrun of either endpoint. Implementers should take single key or overrun of either endpoint. Implementers should take
note of this fact and set a limit on CREATE_CHILD_SA exchanges note of this fact and set a limit on CREATE_CHILD_SA exchanges
between exponentiations. This memo does not prescribe such a limit. between exponentiations. This document does not prescribe such a
limit.
The strength of a key derived from a Diffie-Hellman exchange using The strength of a key derived from a Diffie-Hellman exchange using
any of the groups defined here depends on the inherent strength of any of the groups defined here depends on the inherent strength of
the group, the size of the exponent used, and the entropy provided by the group, the size of the exponent used, and the entropy provided by
the random number generator used. Due to these inputs, it is the random number generator used. Due to these inputs, it is
difficult to determine the strength of a key for any of the defined difficult to determine the strength of a key for any of the defined
groups. Diffie-Hellman group number two, when used with a strong groups. Diffie-Hellman group number two, when used with a strong
random number generator and an exponent no less than 200 bits, is random number generator and an exponent no less than 200 bits, is
common for use with 3DES. Group five provides greater security than common for use with 3DES. Group five provides greater security than
group two. Group one is for historic purposes only and does not group two. Group one is for historic purposes only and does not
provide sufficient strength except for use with DES, which is also provide sufficient strength except for use with DES, which is also
for historic use only. Implementations should make note of these for historic use only. Implementations should make note of these
estimates when establishing policy and negotiating security estimates when establishing policy and negotiating security
parameters. parameters.
Note that these limitations are on the Diffie-Hellman groups Note that these limitations are on the Diffie-Hellman groups
themselves. There is nothing in IKE that prohibits using stronger themselves. There is nothing in IKE that prohibits using stronger
groups nor is there anything that will dilute the strength obtained groups nor is there anything that will dilute the strength obtained
from stronger groups (limited by the strength of the other algorithms from stronger groups (limited by the strength of the other algorithms
negotiated including the prf function). In fact, the extensible negotiated including the PRF). In fact, the extensible framework of
framework of IKE encourages the definition of more groups; use of IKE encourages the definition of more groups; use of elliptical curve
elliptical curve groups may greatly increase strength using much groups may greatly increase strength using much smaller numbers.
smaller numbers.
It is assumed that all Diffie-Hellman exponents are erased from It is assumed that all Diffie-Hellman exponents are erased from
memory after use. memory after use.
The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator
has been authenticated. As a result, an implementation of this has been authenticated. As a result, an implementation of this
protocol needs to be completely robust when deployed on any insecure protocol needs to be completely robust when deployed on any insecure
network. Implementation vulnerabilities, particularly denial-of- network. Implementation vulnerabilities, particularly denial of
service attacks, can be exploited by unauthenticated peers. This service attacks, can be exploited by unauthenticated peers. This
issue is particularly worrisome because of the unlimited number of issue is particularly worrisome because of the unlimited number of
messages in EAP-based authentication. messages in EAP-based authentication.
The strength of all keys is limited by the size of the output of the The strength of all keys is limited by the size of the output of the
negotiated prf function. For this reason, a prf function whose negotiated PRF. For this reason, a PRF whose output is less than 128
output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with bits (e.g., 3DES-CBC) MUST NOT be used with this protocol.
this protocol.
The security of this protocol is critically dependent on the The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters. These should be randomness of the randomly chosen parameters. These should be
generated by a strong random or properly seeded pseudo-random source generated by a strong random or properly seeded pseudo-random source
(see [RANDOMNESS]). Implementers should take care to ensure that use (see [RANDOMNESS]). Implementers should take care to ensure that use
of random numbers for both keys and nonces is engineered in a fashion of random numbers for both keys and nonces is engineered in a fashion
that does not undermine the security of the keys. that does not undermine the security of the keys.
For information on the rationale of many of the cryptographic design For information on the rationale of many of the cryptographic design
choices in this protocol, see [SIGMA] and [SKEME]. Though the choices in this protocol, see [SIGMA] and [SKEME]. Though the
skipping to change at page 119, line 51 skipping to change at page 120, line 17
exchange, and use it to initiate an IKEv2 connection. For this exchange, and use it to initiate an IKEv2 connection. For this
reason, use of non-key-generating EAP methods SHOULD be avoided where reason, use of non-key-generating EAP methods SHOULD be avoided where
possible. Where they are used, it is extremely important that all possible. Where they are used, it is extremely important that all
usages of these EAP methods SHOULD utilize a protected tunnel, where usages of these EAP methods SHOULD utilize a protected tunnel, where
the initiator validates the responder's certificate before initiating the initiator validates the responder's certificate before initiating
the EAP authentication. Implementers should describe the the EAP authentication. Implementers should describe the
vulnerabilities of using non-key-generating EAP methods in the vulnerabilities of using non-key-generating EAP methods in the
documentation of their implementations so that the administrators documentation of their implementations so that the administrators
deploying IPsec solutions are aware of these dangers. deploying IPsec solutions are aware of these dangers.
An implementation using EAP MUST also use strong authentication of An implementation using EAP MUST also use a public-key-based
the server to the client before the EAP authentication begins, even authentication of the server to the client before the EAP
if the EAP method offers mutual authentication. This avoids having authentication begins, even if the EAP method offers mutual
additional IKEv2 protocol variations and protects the EAP data from authentication. This avoids having additional IKEv2 protocol
active attackers. variations and protects the EAP data from active attackers.
If the messages of IKEv2 are long enough that IP-level fragmentation If the messages of IKEv2 are long enough that IP-level fragmentation
is necessary, it is possible that attackers could prevent the is necessary, it is possible that attackers could prevent the
exchange from completing by exhausting the reassembly buffers. The exchange from completing by exhausting the reassembly buffers. The
chances of this can be minimized by using the Hash and URL encodings chances of this can be minimized by using the Hash and URL encodings
instead of sending certificates (see Section 3.6). Additional instead of sending certificates (see Section 3.6). Additional
mitigations are discussed in [DOSUDPPROT]. mitigations are discussed in [DOSUDPPROT].
Admission control is critical to the security of the protocol. For Admission control is critical to the security of the protocol. For
example, trust anchors used for identifying IKE peers should probably example, trust anchors used for identifying IKE peers should probably
be different than those used for other forms of trust, such as those be different than those used for other forms of trust, such as those
used to identify public web servers. Moreover, although IKE provides used to identify public web servers. Moreover, although IKE provides
a great deal of leeway in defining the security policy for a trusted a great deal of leeway in defining the security policy for a trusted
peer's identity, credentials, and the correlation between them, peer's identity, credentials, and the correlation between them,
having such security policy defined explicitly is essential to a having such security policy defined explicitly is essential to a
secure implementation. secure implementation.
5.1. Traffic selector authorization 5.1. Traffic selector authorization
IKEv2 relies on information in the Peer Authorization Database (PAD) IKEv2 relies on information in the Peer Authorization Database (PAD)
when determining what kind of IPsec SAs a peer is allowed to create. when determining what kind of Child SAs a peer is allowed to create.
This process is described in [IPSECARCH] Section 4.4.3. When a peer This process is described in [IPSECARCH] Section 4.4.3. When a peer
requests the creation of an IPsec SA with some traffic selectors, the requests the creation of an Child SA with some traffic selectors, the
PAD must contain "Child SA Authorization Data" linking the identity PAD must contain "Child SA Authorization Data" linking the identity
authenticated by IKEv2 and the addresses permitted for traffic authenticated by IKEv2 and the addresses permitted for traffic
selectors. selectors.
For example, the PAD might be configured so that authenticated For example, the PAD might be configured so that authenticated
identity "sgw23.example.com" is allowed to create IPsec SAs for identity "sgw23.example.com" is allowed to create Child SAs for
192.0.2.0/24, meaning this security gateway is a valid 192.0.2.0/24, meaning this security gateway is a valid
"representative" for these addresses. Host-to-host IPsec requires "representative" for these addresses. Host-to-host IPsec requires
similar entries, linking, for example, "fooserver4.example.com" with similar entries, linking, for example, "fooserver4.example.com" with
192.0.1.66/32, meaning this identity a valid "owner" or 198.51.100.66/32, meaning this identity a valid "owner" or
"representative" of the address in question. "representative" of the address in question.
As noted in [IPSECARCH], "It is necessary to impose these constraints As noted in [IPSECARCH], "It is necessary to impose these constraints
on creation of child SAs to prevent an authenticated peer from on creation of child SAs to prevent an authenticated peer from
spoofing IDs associated with other, legitimate peers." In the spoofing IDs associated with other, legitimate peers." In the
example given above, a correct configuration of the PAD prevents example given above, a correct configuration of the PAD prevents
sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents sgw23 from creating Child SAs with address 198.51.100.66, and
fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. prevents fooserver4 from creating Child SAs with addresses from
192.0.2.0/24.
It is important to note that simply sending IKEv2 packets using some It is important to note that simply sending IKEv2 packets using some
particular address does not imply a permission to create IPsec SAs particular address does not imply a permission to create Child SAs
with that address in the traffic selectors. For example, even if with that address in the traffic selectors. For example, even if
sgw23 would be able to spoof its IP address as 192.0.1.66, it could sgw23 would be able to spoof its IP address as 198.51.100.66, it
not create IPsec SAs matching fooserver4's traffic. could not create Child SAs matching fooserver4's traffic.
The IKEv2 specification does not specify how exactly IP address The IKEv2 specification does not specify how exactly IP address
assignment using configuration payloads interacts with the PAD. Our assignment using configuration payloads interacts with the PAD. Our
interpretation is that when a security gateway assigns an address interpretation is that when a security gateway assigns an address
using configuration payloads, it also creates a temporary PAD entry using configuration payloads, it also creates a temporary PAD entry
linking the authenticated peer identity and the newly allocated inner linking the authenticated peer identity and the newly allocated inner
address. address.
It has been recognized that configuring the PAD correctly may be It has been recognized that configuring the PAD correctly may be
difficult in some environments. For instance, if IPsec is used difficult in some environments. For instance, if IPsec is used
between a pair of hosts whose addresses are allocated dynamically between a pair of hosts whose addresses are allocated dynamically
using DHCP, it is extremely difficult to ensure that the PAD using DHCP, it is extremely difficult to ensure that the PAD
specifies the correct "owner" for each IP address. This would specifies the correct "owner" for each IP address. This would
require a mechanism to securely convey address assignments from the require a mechanism to securely convey address assignments from the
DHCP server, and link them to identities authenticated using IKEv2. DHCP server, and link them to identities authenticated using IKEv2.
Due to this limitation, some vendors have been known to configure Due to this limitation, some vendors have been known to configure
their PADs to allow an authenticated peer to create IPsec SAs with their PADs to allow an authenticated peer to create Child SAs with
traffic selectors containing the same address that was used for the traffic selectors containing the same address that was used for the
IKEv2 packets. In environments where IP spoofing is possible (i.e., IKEv2 packets. In environments where IP spoofing is possible (i.e.,
almost everywhere) this essentially allows any peer to create IPsec almost everywhere) this essentially allows any peer to create Child
SAs with any traffic selectors. This is not an appropriate or secure SAs with any traffic selectors. This is not an appropriate or secure
configuration in most circumstances. See [H2HIPSEC] for an extensive configuration in most circumstances. See [H2HIPSEC] for an extensive
discussion about this issue, and the limitations of host-to-host discussion about this issue, and the limitations of host-to-host
IPsec in general. IPsec in general.
6. IANA Considerations 6. IANA Considerations
[IKEV2] defined many field types and values. IANA has already [IKEV2] defined many field types and values. IANA has already
registered those types and values in [IKEV2IANA], so the are not registered those types and values in [IKEV2IANA], so the are not
listed here again. listed here again.
Two items are removed from the IKEv2 Configuration Payload Attribute
Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY.
Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR
TYPES" registry are defined here that were not defined in [IKEV2]: TYPES" registry are defined here that were not defined in [IKEV2]:
{TBA1} TEMPORARY_FAILURE {TBA1} TEMPORARY_FAILURE
{TBA2} CHILD_SA_NOT_FOUND {TBA2} CHILD_SA_NOT_FOUND
IANA should update all references to RFC 4306 to point to this IANA should update all references to RFC 4306 to point to this
document. document.
7. Acknowledgements 7. Acknowledgements
skipping to change at page 122, line 31 skipping to change at page 122, line 45
the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
each of which has its own list of authors. Hugh Daniel suggested the each of which has its own list of authors. Hugh Daniel suggested the
feature of having the initiator, in message 3, specify a name for the feature of having the initiator, in message 3, specify a name for the
responder, and gave the feature the cute name "You Tarzan, Me Jane". responder, and gave the feature the cute name "You Tarzan, Me Jane".
David Faucher and Valery Smyslov helped refine the design of the David Faucher and Valery Smyslov helped refine the design of the
traffic selector negotiation. traffic selector negotiation.
This paragraph lists references that appear only in figures. The This paragraph lists references that appear only in figures. The
section is only here to keep the 'xml2rfc' program happy, and needs section is only here to keep the 'xml2rfc' program happy, and needs
to be removed when the document is published. The RFC Editor will to be removed when the document is published. The RFC Editor will
remove it before publication. [AEAD] [EAI] [DES] [IDEA] [MD5] remove it before publication. [EAI] [DES] [IDEA] [MD5] [X.501]
[X.501] [X.509] [DSS] [X.509] [DSS]
8. References 8. References
8.1. Normative References 8.1. Normative References
[ADDGROUP] [ADDGROUP]
Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
[ADDRIPV6] [ADDRIPV6]
Hinden, R. and S. Deering, "Internet Protocol Version 6 Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 4291, February 2006. (IPv6) Addressing Architecture", RFC 4291, February 2006.
skipping to change at page 125, line 52 skipping to change at page 126, line 21
RFC 4306, December 2005. RFC 4306, December 2005.
[IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173, Payload Compression Protocol (IPComp)", RFC 3173,
September 2001. September 2001.
[IPSECARCH-OLD] [IPSECARCH-OLD]
Kent, S. and R. Atkinson, "Security Architecture for the Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[IPV6ADDR]
Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 4291, February 2006.
[IPV6CONFIG] [IPV6CONFIG]
Eronen, et. al., P., "IPv6 Configuration in IKEv2", Eronen, et. al., P., "IPv6 Configuration in IKEv2",
draft-ietf-ipsecme-ikev2-ipv6-config (work in progress), draft-ietf-ipsecme-ikev2-ipv6-config (work in progress),
August 2009. August 2009.
[ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[MAILFORMAT] [MAILFORMAT]
Resnick, P., "Internet Message Format", RFC 2822, Resnick, P., "Internet Message Format", RFC 5322,
April 2001. October 2008.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
skipping to change at page 129, line 6 skipping to change at page 129, line 23
9. To specify Traffic Selectors in their own payloads type rather 9. To specify Traffic Selectors in their own payloads type rather
than overloading ID payloads, and making more flexible the than overloading ID payloads, and making more flexible the
Traffic Selectors that may be specified; Traffic Selectors that may be specified;
10. To specify required behavior under certain error conditions or 10. To specify required behavior under certain error conditions or
when data that is not understood is received in order to make it when data that is not understood is received in order to make it
easier to make future revisions in a way that does not break easier to make future revisions in a way that does not break
backwards compatibility; backwards compatibility;
11. To simplify and clarify how shared state is maintained in the 11. To simplify and clarify how shared state is maintained in the
presence of network failures and Denial of Service attacks; and presence of network failures and denial of service attacks; and
12. To maintain existing syntax and magic numbers to the extent 12. To maintain existing syntax and magic numbers to the extent
possible to make it likely that implementations of IKEv1 can be possible to make it likely that implementations of IKEv1 can be
enhanced to support IKEv2 with minimum effort. enhanced to support IKEv2 with minimum effort.
Appendix B. Diffie-Hellman Groups Appendix B. Diffie-Hellman Groups
There are two Diffie-Hellman groups defined here for use in IKE. There are two Diffie-Hellman groups defined here for use in IKE.
These groups were generated by Richard Schroeppel at the University These groups were generated by Richard Schroeppel at the University
of Arizona. Properties of these primes are described in [OAKLEY]. of Arizona. Properties of these primes are described in [OAKLEY].
skipping to change at page 133, line 32 skipping to change at page 133, line 32
[N(ADDITIONAL_TS_POSSIBLE)] [N(ADDITIONAL_TS_POSSIBLE)]
[V+][N+] [V+][N+]
error case <-- N(error) error case <-- N(error)
different D-H <-- N(INVALID_KE_PAYLOAD), different D-H <-- N(INVALID_KE_PAYLOAD),
group wanted [V+][N+] group wanted [V+][N+]
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA
request --> SA, Ni, [KEi] request --> SA, Ni, KEi
[V+][N+] [V+][N+]
response <-- SA, Nr, [KEr] response <-- SA, Nr, KEr
[V+][N+] [V+][N+]
C.6. INFORMATIONAL Exchange C.6. INFORMATIONAL Exchange
request --> [N+], request --> [N+],
[D+], [D+],
[CP(CFG_REQUEST)] [CP(CFG_REQUEST)]
response <-- [N+], response <-- [N+],
[D+], [D+],
[CP(CFG_REPLY)] [CP(CFG_REPLY)]
Appendix D. Significant Changes from RFC 4306 Appendix D. Changes Between Internet Draft Versions
This is a placeholder that will be filled in. The WG needs to decide
what level of specificity is most useful here. For example, it might
only be changes that involve SHOULD-level or MUST-level requirements,
or it might also include additional "significant" advice that was
added.
Appendix E. Changes Between Internet Draft Versions
This section will be removed before publication as an RFC, but should This section will be removed before publication as an RFC, but should
be left intact until then so that reviewers can follow what has be left intact until then so that reviewers can follow what has
changed. changed.
E.1. Changes from IKEv2 to draft -00 D.1. Changes from IKEv2 to draft -00
There were a zillion additions from RFC 4718. These are noted with There were a zillion additions from RFC 4718. These are noted with
"{{ Clarif-nn }}". "{{ Clarif-nn }}".
Cleaned up many of the figures. Made the table headings consistent. Cleaned up many of the figures. Made the table headings consistent.
Made some tables easier to read by removing blank spaces. Removed Made some tables easier to read by removing blank spaces. Removed
the "reserved to IANA" and "private use" text wording and moved it the "reserved to IANA" and "private use" text wording and moved it
into the tables. into the tables.
Changed many SHOULD requirements to better match RFC 2119. These are Changed many SHOULD requirements to better match RFC 2119. These are
also marked with comments such as "{{ Demoted the SHOULD }}". also marked with comments such as "{{ Demoted the SHOULD }}".
In Section 2.16, changed the MUST requirement of authenticating the In Section 2.16, changed the MUST requirement of authenticating the
responder from "public key signature based" to "strong" because that responder from "public key signature based" to "strong" because that
is what most current IKEv2 implementations do, and it better matches is what most current IKEv2 implementations do, and it better matches
the actual security requirement. the actual security requirement.
E.2. Changes from draft -00 to draft -01 D.2. Changes from draft -00 to draft -01
The most significant technical change was to make KE optional but The most significant technical change was to make KE optional but
strongly recommended in Section 1.3.2. strongly recommended in Section 1.3.2.
Updated all references to the IKEv2 Clarifications document to RFC Updated all references to the IKEv2 Clarifications document to RFC
4718. 4718.
Moved a lot of the protocol description out of the long tables in Moved a lot of the protocol description out of the long tables in
Section 3.10.1 into the body of the document. These are noted with Section 3.10.1 into the body of the document. These are noted with
"{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number.
skipping to change at page 136, line 43 skipping to change at page 136, line 35
address is valid until there are no IKE SAs between the peers." address is valid until there are no IKE SAs between the peers."
In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified.
Made [ADDRIPV6] an informative reference instead of a normative Made [ADDRIPV6] an informative reference instead of a normative
reference and updated it. reference and updated it.
Made [PKCS1] a normative reference instead of an informative Made [PKCS1] a normative reference instead of an informative
reference and changed the pointer to RFC 3447. reference and changed the pointer to RFC 3447.
E.3. Changes from draft -00 to draft -01 D.3. Changes from draft -00 to draft -01
In Section 1.5, added "request" to first sentence to make it "If an In Section 1.5, added "request" to first sentence to make it "If an
encrypted IKE request packet arrives on port 500 or 4500 with an encrypted IKE request packet arrives on port 500 or 4500 with an
unrecognized SPI...". unrecognized SPI...".
In Section 3.3, fifth paragraph, upped the number of transforms for In Section 3.3, fifth paragraph, upped the number of transforms for
AH and ESP by one each to account for ESN, which is now mandatory. AH and ESP by one each to account for ESN, which is now mandatory.
In Section 2.1, added "or equal to" in "The responder MUST remember In Section 2.1, added "or equal to" in "The responder MUST remember
each response until it receives a request whose sequence number is each response until it receives a request whose sequence number is
larger than or equal to the sequence number in the response plus its larger than or equal to the sequence number in the response plus its
window size." window size."
In Section 2.18, removed " Note that this may not work if the new IKE In Section 2.18, removed " Note that this may not work if the new IKE
SA's PRF has a fixed key size because the output of the PRF may not SA's PRF has a fixed key size because the output of the PRF may not
be of the correct size." because it is no longer relevant. be of the correct size." because it is no longer relevant.
E.4. Changes from draft -01 to draft -02 D.4. Changes from draft -01 to draft -02
Many grammatical fixes. Many grammatical fixes.
In Section 1.2, reworded Clarif-4.3 to be clearer. In Section 1.2, reworded Clarif-4.3 to be clearer.
In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove
redundant text. redundant text.
In Section 2.13, replaced text about variable length keys with In Section 2.13, replaced text about variable length keys with
clearer explanation and requirement on non-HMAC PRFs. Also added clearer explanation and requirement on non-HMAC PRFs. Also added
skipping to change at page 138, line 17 skipping to change at page 138, line 9
In Section 3.10, clarified 3.10.1-16394. In Section 3.10, clarified 3.10.1-16394.
Updated Section 6 to indicate that there is nothing new for IANA in Updated Section 6 to indicate that there is nothing new for IANA in
this spec. Also removed the definition of "Expert Review" from this spec. Also removed the definition of "Expert Review" from
Section 1.6 for the same reason. Section 1.6 for the same reason.
In Appendix A, removed "and not commit any state to an exchange until In Appendix A, removed "and not commit any state to an exchange until
the initiator can be cryptographically authenticated" because that the initiator can be cryptographically authenticated" because that
was only true in an earlier version of IKEv2. was only true in an earlier version of IKEv2.
E.5. Changes from draft -02 to draft -03 D.5. Changes from draft -02 to draft -03
In Section 1.3, changed "If the responder rejects the Diffie-Hellman In Section 1.3, changed "If the responder rejects the Diffie-Hellman
group of the KEi payload, the responder MUST reject the request and group of the KEi payload, the responder MUST reject the request and
indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD
Notification payload." to "If the responder selects a proposal using Notification payload." to "If the responder selects a proposal using
a different Diffie-Hellman group (other than NONE), the responder a different Diffie-Hellman group (other than NONE), the responder
MUST reject the request and indicate its preferred Diffie-Hellman MUST reject the request and indicate its preferred Diffie-Hellman
group in the INVALID_KE_PAYLOAD Notification payload. group in the INVALID_KE_PAYLOAD Notification payload.
In Section 2.3, added the last two paragraphs covering why you In Section 2.3, added the last two paragraphs covering why you
skipping to change at page 139, line 38 skipping to change at page 139, line 30
modes, and to clarify which encryption and integrity protection we modes, and to clarify which encryption and integrity protection we
are talking about. are talking about.
Changed the "Initialization Vector" bullet in Section 3.14 to specify Changed the "Initialization Vector" bullet in Section 3.14 to specify
better what is needed for the IV. Upgraded the SHOULDs to MUSTs. better what is needed for the IV. Upgraded the SHOULDs to MUSTs.
Also added the reference for [MODES]. Also added the reference for [MODES].
In Section 5, in the second-to-last paragraph, changed "a public-key- In Section 5, in the second-to-last paragraph, changed "a public-key-
based" to "strong" to match the wording in Section 2.16. based" to "strong" to match the wording in Section 2.16.
E.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 D.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00
Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00.
Added Yoav Nir as a co-author. Added Yoav Nir as a co-author.
In many places in the document, changed "and/or" to "or" when talking In many places in the document, changed "and/or" to "or" when talking
about combinations of ESP and AH SAs. For example, in the intro, it about combinations of ESP and AH SAs. For example, in the intro, it
said "can be used to efficiently establish SAs for Encapsulating said "can be used to efficiently establish SAs for Encapsulating
Security Payload (ESP) and/or Authentication Header (AH)". This is Security Payload (ESP) and/or Authentication Header (AH)". This is
changed to "or" to indicate that you can only establish one type of changed to "or" to indicate that you can only establish one type of
SA at a time. SA at a time.
skipping to change at page 140, line 11 skipping to change at page 140, line 4
In Section 1, clarified that RFC 4306 already replaced IKEv1, and In Section 1, clarified that RFC 4306 already replaced IKEv1, and
that this document replaces RFC 4306. Also fixed Section 2.5 for that this document replaces RFC 4306. Also fixed Section 2.5 for
similar issue. Also updated the Abstract to cover this. similar issue. Also updated the Abstract to cover this.
In Section 2.15, in the responder's signed octets, changed: In Section 2.15, in the responder's signed octets, changed:
RestOfRespIDPayload = IDType | RESERVED | InitIDData RestOfRespIDPayload = IDType | RESERVED | InitIDData
to to
RestOfRespIDPayload = IDType | RESERVED | RespIDData RestOfRespIDPayload = IDType | RESERVED | RespIDData
In 2.16, changed "strong" back to "public key signature based" to In 2.16, changed "strong" back to "public key signature based" to
make it the same as 4306. make it the same as 4306.
In section 3.10, added "and the field must be empty" to make it clear In section 3.10, added "and the field must be empty" to make it clear
that a zero-length SPI is really empty. that a zero-length SPI is really empty.
E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
draft-ietf-ipsecme-ikev2bis-01 draft-ietf-ipsecme-ikev2bis-01
Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to
"Child SA" (except left "CREATE_CHILD_SA" alone). "Child SA" (except left "CREATE_CHILD_SA" alone).
Added the middle sentence in the Abstract to say what IKE actually Added the middle sentence in the Abstract to say what IKE actually
does. does.
Added in section 1 "(unless there is failure setting up the AH or ESP Added in section 1 "(unless there is failure setting up the AH or ESP
Child SA, in which case the IKE SA is still established without IPsec Child SA, in which case the IKE SA is still established without Child
SA)". SA)".
Clarified the titles of 1.1.1, 1.1.2, and 1.1.3. Clarified the titles of 1.1.1, 1.1.2, and 1.1.3.
In 1.1.2, changed "If there is an inner IP header, the inner In 1.1.2, changed "If there is an inner IP header, the inner
addresses will be the same as the outer addresses." because we are addresses will be the same as the outer addresses." because we are
talking about transport mode here. talking about transport mode here.
Added reference to section 2.14 to setion 1.2 and 1.3. Added reference to section 2.14 to setion 1.2 and 1.3.
skipping to change at page 144, line 23 skipping to change at page 144, line 11
most implementations to do so. most implementations to do so.
Updated a bunch of reference to their newer versions. Updated a bunch of reference to their newer versions.
Added "[V+]" to the end of the exchanges in C.4 and C.5. Added "[V+]" to the end of the exchanges in C.4 and C.5.
Added two more response templates to Appendix C.1. Added another Added two more response templates to Appendix C.1. Added another
response template in Appendix C.2. Added two more responses in response template in Appendix C.2. Added two more responses in
Appendix C.4. Appendix C.4.
E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 draft-ietf-ipsecme-ikev2bis-02
In section 1.3.1, added "Failure of an attempt to create a CHILD SA In section 1.3.1, added "Failure of an attempt to create a CHILD SA
SHOULD NOT tear down the IKE SA: there is no reason to lose the work SHOULD NOT tear down the IKE SA: there is no reason to lose the work
done to set up the IKE SA. When an IKE SA is not created, the error done to set up the IKE SA. When an IKE SA is not created, the error
message return SHOULD NOT be encrypted because the other party will message return SHOULD NOT be encrypted because the other party will
not be able to authenticate that message." This may be changed again not be able to authenticate that message." This may be changed again
in the future. [Issue #9] in the future. [Issue #9]
In section 1.3.2, changed "The KEi payload SHOULD be included" to be In section 1.3.2, changed "The KEi payload SHOULD be included" to be
skipping to change at page 146, line 26 skipping to change at page 146, line 13
been authenticated. As a result, an implementation of this protocol been authenticated. As a result, an implementation of this protocol
needs to be completely robust when deployed on any insecure network. needs to be completely robust when deployed on any insecure network.
Implementation vulnerabilities, particularly denial-of-service Implementation vulnerabilities, particularly denial-of-service
attacks, can be exploited by unauthenticated peers. This issue is attacks, can be exploited by unauthenticated peers. This issue is
particularly worrisome because of the unlimited number of messages in particularly worrisome because of the unlimited number of messages in
EAP-based authentication." [Issue #62] EAP-based authentication." [Issue #62]
Added new Appendix D, "Significant Changes from RFC 4306", as a Added new Appendix D, "Significant Changes from RFC 4306", as a
placeholder for now. [Issue #3] placeholder for now. [Issue #3]
E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 draft-ietf-ipsecme-ikev2bis-02
Near the end of 1.3, changed "If the guess turns out to be wrong, the Near the end of 1.3, changed "If the guess turns out to be wrong, the
responder will indicate the correct group in the response and the responder will indicate the correct group in the response and the
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." to "If the responder selects a proposal retrying the first message." to "If the responder selects a proposal
using a different Diffie-Hellman group (other than NONE), the using a different Diffie-Hellman group (other than NONE), the
responder will indicate the correct group in the response and the responder will indicate the correct group in the response and the
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." [Issue #6] retrying the first message." [Issue #6]
skipping to change at page 147, line 22 skipping to change at page 147, line 9
Changed the last bullet item in section 2.23 to discuss MOBIKE in Changed the last bullet item in section 2.23 to discuss MOBIKE in
more detail. [Issue #41] more detail. [Issue #41]
In section 3.1, the bullet about bit 4, changed "must" to "MUST". In section 3.1, the bullet about bit 4, changed "must" to "MUST".
In section 3.3.6, added two sentences at the end of the second In section 3.3.6, added two sentences at the end of the second
paragraph to indicate that there is an exception for when the paragraph to indicate that there is an exception for when the
proposal is a DH group of NONE. [Issue #6] proposal is a DH group of NONE. [Issue #6]
E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to
draft-ietf-ipsecme-ikev2bis-03 draft-ietf-ipsecme-ikev2bis-03
In section 2.4, change "The INITIAL_CONTACT notification, if sent, In section 2.4, change "The INITIAL_CONTACT notification, if sent,
MUST be in the first IKE_AUTH request, not as a separate exchange MUST be in the first IKE_AUTH request, not as a separate exchange
afterwards; however, receiving parties need to deal with it in other afterwards; however, receiving parties need to deal with it in other
requests." to "The INITIAL_CONTACT notification, if sent, MUST be in requests." to "The INITIAL_CONTACT notification, if sent, MUST be in
the first IKE_AUTH request or response, not as a separate exchange the first IKE_AUTH request or response, not as a separate exchange
afterwards; however, receiving parties MAY ignore it in other afterwards; receiving parties MAY ignore it in other messages."
messages." [Issue #53] [Issue #53]
Added to the security considerations: "Admission control is critical Added to the security considerations: "Admission control is critical
to the security of the protocol. For example, trust anchors used for to the security of the protocol. For example, trust anchors used for
identifying IKE peers should probably be different than those used identifying IKE peers should probably be different than those used
for other forms of trust, such as those used to identify public web for other forms of trust, such as those used to identify public web
servers. Moreover, although IKE provides a great deal of leeway in servers. Moreover, although IKE provides a great deal of leeway in
defining the security policy for a trusted peer's identity, defining the security policy for a trusted peer's identity,
credentials, and the correlation between them, having such security credentials, and the correlation between them, having such security
policy defined explicitly is essential to a secure implementation." policy defined explicitly is essential to a secure implementation."
[Issue #61] [Issue #61]
Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63] Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63]
E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to
draft-ietf-ipsecme-ikev2bis-04 draft-ietf-ipsecme-ikev2bis-04
Throughout, removed the marks that showed where text from the Throughout, removed the marks that showed where text from the
Clarifications RFC was inserted, or where a "SHOULD" was demoted to Clarifications RFC was inserted, or where a "SHOULD" was demoted to
weaker language. weaker language.
In section 1, added "IKEv2 was a change to the IKE protocol that was In section 1, added "IKEv2 was a change to the IKE protocol that was
not backward compatible. In contrast, the current document not only not backward compatible. In contrast, the current document not only
provides a clarification of IKEv2, but makes minimum changes to the provides a clarification of IKEv2, but makes minimum changes to the
IKE protocol." [Issue #48] IKE protocol." [Issue #48]
In 1.5, added "The recipient of this notification cannot tell whether In 1.5, added "The recipient of this notification cannot tell whether
the SPI is for AH or ESP, but this is not important because the SPIs the SPI is for AH or ESP, but this is not important because the SPIs
are supposed to be different for the two." [Issue #35] are supposed to be different for the two." [Issue #35]
In 1.5, added "(INVALID_MAJOR_VERSION is also a one-way message which In 1.5, added "(INVALID_MAJOR_VERSION is also a one-way message which
is sent outside of an IKE SA, although it is sent as a response to is sent outside of an IKE SA, although it is sent as a response to
the incoming IKE SA creation.)" [Issue #13] the incoming IKE SA creation.)" [Issue #13]
In 1.7, added "This document removes the allowance for rejecting
messages where the payloads were not in the "right" order; now
implementations MUST NOT reject them. This is due to the lack of
clarity where the orders for th payloads are described."
Added "The Message ID is reset to zero in the new IKE SA after the Added "The Message ID is reset to zero in the new IKE SA after the
IKE SA is rekeyed" in the first paragraph of 2.2. [Issue #15] IKE SA is rekeyed" in the first paragraph of 2.2. [Issue #15]
In 2.5, changed "implementations MUST send the payloads defined in In 2.5, changed "implementations MUST send the payloads defined in
this specification in the order shown in the figures in Section 2; this specification in the order shown in the figures in Section 2;
implementations are explicitly allowed to reject as invalid a message implementations are explicitly allowed to reject as invalid a message
with those payloads in any other order" to "implementations SHOULD with those payloads in any other order" to "implementations SHOULD
send the payloads defined in this specification in the order shown in send the payloads defined in this specification in the order shown in
the figures in Section 2; implementations MUST NOT reject as invalid the figures in Section 2; implementations MUST NOT reject as invalid
a message with those payloads in any other order". [Issue #16] a message with those payloads in any other order". [Issue #16]
skipping to change at page 148, line 40 skipping to change at page 148, line 30
In 2.9, added "Maintenance of a system's SPD is outside the scope of In 2.9, added "Maintenance of a system's SPD is outside the scope of
IKE (see [PFKEY] for an example programming interface, although it IKE (see [PFKEY] for an example programming interface, although it
only applies to IKEv1), though some implementations might update only applies to IKEv1), though some implementations might update
their SPD in connection with the running of IKE (for an example their SPD in connection with the running of IKE (for an example
scenario, see Section 1.1.3)." This was actually done in -03 but not scenario, see Section 1.1.3)." This was actually done in -03 but not
noted in the change notes. [Issue #64] [Issue #54] noted in the change notes. [Issue #64] [Issue #54]
In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange" In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange"
to the last sentence. to the last sentence.
In the last paragraph of 2.25, added "The SA that the initiator
attempted to rekey is indicated by the SPI field in the Notify
Payload, which is copied from the SPI field in the REYEY_SA
notification."
Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44] Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44]
Changed "The requested address is valid until there are no IKE_SAs Changed "The requested address is valid until there are no IKE_SAs
between the peers" to "The requested address is valid as long as this between the peers" to "The requested address is valid as long as this
IKE SA (or its rekeyed successors) requesting the address is valid." IKE SA (or its rekeyed successors) requesting the address is valid."
[Issue #43] [Issue #43]
E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to
draft-ietf-ipsecme-ikev2bis-05 draft-ietf-ipsecme-ikev2bis-05
Added the following near the end of 1.2: "If the failure is related Added the following near the end of 1.2: "If the failure is related
to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE
SA is not created. Note that although the IKE_AUTH messages are SA is not created. Note that although the IKE_AUTH messages are
encrypted and integrity protected, if the peer receiving this encrypted and integrity protected, if the peer receiving this
notification has not yet authenticated the other end (or if the peer notification 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 indication is known MAC verifies correctly, the sender of the error indication is known
skipping to change at page 150, line 26 skipping to change at page 150, line 22
parts of the document. [Issue #108] parts of the document. [Issue #108]
Added the following to 3.15.3: "Note that there is an additional Added the following to 3.15.3: "Note that there is an additional
document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG]. document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG].
At the present time, it is an experimental document, but there is a At the present time, it is an experimental document, but there is a
hope that with more implementation experience, it will gain the same hope that with more implementation experience, it will gain the same
standards treatment as this document." [Issue #47 and Issue #60] standards treatment as this document." [Issue #47 and Issue #60]
Reworded the acknowledgements to be more inclusive. Reworded the acknowledgements to be more inclusive.
E.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to
draft-ietf-ipsecme-ikev2bis-06 draft-ietf-ipsecme-ikev2bis-06
Many small editorial nits fixed. Many small editorial nits fixed.
Changed all the tables to only list the values that were defined in Changed all the tables to only list the values that were defined in
RFC 4306. Removed reserved and private use ranges. Also, a pointer RFC 4306. Removed reserved and private use ranges. Also, a pointer
to the IANA registry is given repeatedly. to the IANA registry is given repeatedly.
At the end of 1.3.1, added "See Section 2.21 for a list of error At the end of 1.3.1, added "See Section 2.21 for a list of error
messages that might occur if creating a Child SA fails." messages that might occur if creating a Child SA fails."
skipping to change at page 152, line 35 skipping to change at page 152, line 32
some text that was removed a few iterations ago. some text that was removed a few iterations ago.
In 4, changed "If an implementation does support issuing such In 4, changed "If an implementation does support issuing such
requests" to "If an implementation does support issuing such requests requests" to "If an implementation does support issuing such requests
and its policy requires using temporary IP addresses". and its policy requires using temporary IP addresses".
In 8 (Refereneces), changed the reference for AEAD from RFC 5116 to In 8 (Refereneces), changed the reference for AEAD from RFC 5116 to
RFC 5282. Also added IKEV2IANA as a normative reference. Also RFC 5282. Also added IKEV2IANA as a normative reference. Also
changed the FTP URLs to the RFC Editor to HTTP references. changed the FTP URLs to the RFC Editor to HTTP references.
D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to
draft-ietf-ipsecme-ikev2bis-07
These changes were made during and after WG Last Call.
Many small editorial nits fixed.
In 1.2, added "(A man-in-the-middle who cannot complete the IKE_AUTH
exchange can nonetheless see the identity of the initiator.)"
In the table in 1.2, added " (not a payload)" to "IKE Header" because
the other items are, in fact, payloads. Also changed "E Encrypted"
to "SK Encrypted and Authenticated".
Removed "When an IKE SA is not created, the error message return
SHOULD NOT be encrypted because the other party will not be able to
authenticate that message." from the end of 1.3.1. [Issue #127]
In 1.3.1, added "An IPCOMP_SUPPORTED notification, covered in
Section 2.22, can also be included in the request/response pair."
In 1.3.2, changed "New initiator and responder SPIs are supplied in
the SPI fields of the SA payload." to "A new initiator SPI is
supplied in the SPI field of the SA payload." Also added "A new
responder SPI is supplied in the SPI field of the SA payload." a few
paragraphs down.
In 1.3.3, changed the figure for the initiator from:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N, SA, Ni, [KEi],
TSi, TSr} -->
to:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(REKEY_SA), SA, Ni, [KEi],
TSi, TSr} -->
Added to 1.4: "Note that some informational messages, not exchanges,
can be sent outside the context of an IKE SA."
In 1.5, changed "it MAY send an informational message" to "it MAY
indicate this with a Notify payload". Made a similar change in the
following paragraph.
In 1.5, changed "If the receiving node has an active IKE SA to the IP
address from whence the packet came, it MAY send a notification of
the wayward packet over that IKE SA in an INFORMATIONAL exchange. If
it does not have such an IKE SA, it MAY indicate this with a Notify
payload without cryptographic protection to the source IP address."
to "If the receiving node does not have an active IKE SA to the IP
address from whence the packet came, it MAY send a notification of
the wayward packet with a Notify payload without cryptographic
protection to the source IP address."
Fixed the boilerplate wording in 1.6.
Added and clarified materila in 1.7. Also added "Significant" to the
title of the section because it cannot list all the differences.
[Issue #126]
In 2.1, changed "IKE is a reliable protocol, in the sense that the
initiator MUST retransmit a request until either it receives a
corresponding reply OR it deems the IKE security association to have
failed and it discards all state associated with the IKE SA and any
Child SAs negotiated using that IKE SA." to "IKE is a reliable
protocol: the initiator MUST retransmit a request until either it
receives a corresponding reply, or until it deems the IKE SA to have
failed. In the latter case, the initiator discards all state
associated with the IKE SA and any Child SAs that were negotiated
using that IKE SA."
In 2.1, removed ", and the zero non-ESP marker" because it was
confusing.
In 2.2, rearranged the paragraphs beginning "The Message ID is a 32-
bit.." and "Throughout this document, "initiator"...".
In 2.5, changed "implementations SHOULD send the payloads defined in
this specification in the order shown in the figures in Section 2" to
"...the figures in Sections 1 and 2".
In 2.6, changed "Also, incorporating Ni" to "Also, incorporating
SPi".
In 2.6, removed the paragraph that started "In addition to cookies"
because it was redundant with information in 2.7 that was stated
better.
In 2.8, changed "It should do so if there has been no traffic since
the last time the SA was rekeyed." to "It can also do so if ..."
In 2.8.1, changed NO_PROPOSAL_CHOSEN to CHILD_SA_NOT_FOUND in the
paragraph that starts "To B, it looks like A is trying to rekey" and
the artwork after it.
In 2.8.2, changed "In this case, when the peer that did not notice
the simultaneous rekey gets the request to rekey the IKE SA that it
has already successfully rekeyed, it MUST return
TEMPORARY_FAILURE..." to "...it SHOULD return TEMPORARY_FAILURE...".
[Issue #131]
In 2.9, changed "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 initiator SHOULD include as the first traffic
selector in each of TSi and TSr a very specific traffic selector
including the addresses in the packet triggering the request" to "If
the initiator requests an SA because it wants to sen a data packet,
including the specific addresses in the packet triggering the request
in the first traffic selector in both TSi and TSr enables the
responder to choose the appropriate range".
In 2.9, removed "Such misconfigurations should be recorded in error
logs." [Issue #125]
In 2.9, changed the end of the paragraph that starts "It is possible
for the responder's policy..." to actually match the scenario, which
is not a triggering packet.
In 2.9, changed the "192.0.1" example network to "198.51.100" and
removed the parenthetical comment about the old ones. Did the same
change in 3.15.2 and 5.1.
Rewrote parts of 2.13 to make it clearer when general functions and
specific functions were being discussed. Also cleaned up
inconsistent use of "prf" and "PRF" throughout the document.
In 2.18, added "to generate SKEYSEED" to the end of "The old and new
IKE SA...", and added "and using the new IKE SA's PRF" to the end of
the last paragraph. [Issue #121]
At the end of 2.19, removed some redundancy and split the final
paragraph into two.
In 2.21.2, removed "NOTE FOR WG DISCUSSION: Having other payloads in
the message is allowed but there are none suggested. One WG member
mentioned the possibility of adding a DELETE payload when the error
is sent in a separate INFORMATIONAL exchange. Do we want to allow
such additional payloads that have operational semantics?"
In 2.23, changed "float to" to "use".
In 2.23, changed "In the case of a mismatching
NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection
attempt if NAT traversal is not supported." to "In the case there is
a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the
NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject
the connection attempt if NAT traversal is not supported." Also
removed the bullet that started "If the NAT_DETECTION_DESTINATION_IP
payload received does not match the hash of the destination IP"
because it was already covered above.
In 2.23, removed "so this method MUST NOT be used when MOBIKE is
used" but left in the reference to section 3.8 in MOBIKE so that
readers can see what is and is not allowed.
In 2.23.1, in the first bullet for the responder in transport mode,
changed "Store the original traffic selector IP addresses as received
source and destination address in case we need to undo address
substitution." to "Store the original traffic selector IP addresses
as received source and destination address, both in case we need to
undo address substitution, and to use as the "real source and
destination address" specified by [UDPENCAPS], and for TCP/UDP
checksum fixup."
In 2.25, changed: "A peer that receives a CHILD_SA_NOT_FOUND
notification SHOULD silently delete the Child SA and send a request
to create a new Child SA from scratch." to "A peer that receives a
CHILD_SA_NOT_FOUND notification 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 not yet exist)."
In the flags description in 3.1, replaced "The bits are defined LSB
first, so bit 0 would be the least significant bit of the Flags
octet. " with "The bits are as follows:
+-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+
Also added: ""X" bits MUST be cleared when sending and MUST be
ignored on receipt." Then removed the bit positions from the
description.
In 3.1, added "See Section 2.5 for more information on this bit" to
the end of the Critical bit description.
In 3.2, changed "E Encrypted" to "SK Encrypted and Authenticated".
In 3.3, fourth paragraph, changed "Combined-mode ciphers include both
integrity and encryption in a single encryption algorithm, and are
not allowed to be offered with a separate integrity algorithm other
than "none"." to "Combined-mode ciphers include both integrity and
encryption in a single encryption algorithm, and MUST either offer no
integrity algorithm or a single integrity algorithm of "none", with
no integrity algorithm being the RECOMMENDED method." Also, removed
"If an algorithm that combines encryption and integrity protection is
proposed, it MUST be proposed as an encryption algorithm and an
integrity protection algorithm MUST NOT be proposed" from the
following paragraph. [Issue #122]
In 3.3.6, moved the last sentence from the second paragraph and moved
it to third paragraph. It now reads "If one of the proposals offered
is for the Diffie-Hellman group of NONE, the responder MUST ignore
the initiator's KE payload and omit the KE payload from the
response."
In 3.4, added "See also Section 1.2 and Section 2.7."
In 3.6, changed "Certificate payloads SHOULD be included in an
exchange if certificates are available to the sender unless the peer
has indicated an ability to retrieve this information from elsewhere
using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." to "Certificate
payloads SHOULD be included in an exchange if certificates are
available to the sender. The Hash and URL formats of the Certificate
payloads should be used in case the peer has indicated an ability to
retrieve this information from elsewhere using an
HTTP_CERT_LOOKUP_SUPPORTED Notify payload."
In 3.10.1, added "More information on error handling can be found in
Section 2.21."
Added TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND to the table in
3.10.1.
Replaced the Start Port and End Port discussions in 3.13.1 with ones
that describe the ICMP and ICMPv6 in more detail. Also replaced the
two paragraphs starting "The traffic selector types 7..." and
"Traffic selectors can use" with "he 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 header [MIPV6]. Note, however,
that neither ICMP nor MIPv6 packets have separate source and
destination fields. The method for specifying the traffic selectors
for ICMP and MIPv6 is shown by example in Section 4.4.1.3 of
[IPSECARCH]". [Issue #129]
In 3.15.1, made the table heading "Multi-Valued" instead of "Valued".
In 3.15.1, added "(except INTERNAL_ADDRESS_EXPIRY and
INTERNAL_IP6_NBNS which were removed by this document)" to the bullet
point for "Value" because those two were removed from the table.
Added new paragraph at the end of 3.15.4 to suggest what the
initiator should do if they don't get enough addresses. [Issue #124]
In 5, changed "An implementation using EAP MUST also use strong
authentication" back to "An implementation using EAP MUST also use a
public-key-based authentication" soas not to change mandatory
requirements from RFC 4306.
Added to section 6: "Two items are removed from the IKEv2
Configuration Payload Attribute Types table: INTERNAL_IP6_NBNS and
INTERNAL_ADDRESS_EXPIRY."
Removed Appendix C, "Significant Changes from RFC 4306", because this
information is actually going in section 1.7.
In C.5, changed the figure from:
request --> SA, Ni, [KEi]
[V+][N+]
response <-- SA, Nr, [KEr]
[V+][N+]
to
request --> SA, Ni, KEi
[V+][N+]
response <-- SA, Nr, KEr
[V+][N+]
Authors' Addresses Authors' Addresses
Charlie Kaufman Charlie Kaufman
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Phone: 1-425-707-3335 Phone: 1-425-707-3335
Email: charliek@microsoft.com Email: charliek@microsoft.com
 End of changes. 241 change blocks. 
650 lines changed or deleted 995 lines changed or added

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