idnits 2.17.00 (12 Aug 2021) /tmp/idnits58838/draft-ikev2-windowssync-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 14, 2010) is 4359 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4718' is defined on line 262, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Duplicate reference: RFC4306, mentioned in 'RFC4718', was also mentioned in 'RFC4306'. ** Obsolete normative reference: RFC 4306 (ref. 'RFC4718') (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Kalyani 3 Internet-Draft Cisco 4 Intended status: Standards Track June 14, 2010 5 Expires: December 16, 2010 7 IKEv2 window synchronisation among peers 8 draft-ikev2-windowssync-00 10 Abstract 12 This document describes an extension to the IKEv2 protocol that 13 allows the synchronisation of ikev2 windows between the peers. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on December 16, 2010. 32 Copyright Notice 34 Copyright (c) 2010 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Description of the solution . . . . . . . . . . . . . . . . . . 4 52 4. Details of implementation . . . . . . . . . . . . . . . . . . . 4 53 5. Notify Types . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 55 7. VID Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 57 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 58 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 IKEv2 RFC states that "An IKE endpoint MUST NOT exceed the peer's 64 stated window size for transmitted IKE requests". 66 As per the protocol , all IKEv2 packets must follow a request- 67 response paradigm. The initiator of an IKEv2 request MUST retransmit 68 the request, until it has received a response from the peer. IKEv2 69 introduces a windowing mechanism that allows multiple requests to be 70 outstanding at a given point of time, but mandates that the sender 71 window does not move until the oldest message sent from one peer to 72 another is acknowledged. Loss of even a single packet leads to 73 repeated retransmissions followed by an IKEv2 SA teardown if the 74 retransmissions are unacknowledged. 76 HA for IKEv2 is required to ensure that in case of crash of active 77 device , the stand-by device becomes active immediately. The 78 stand-by device is expected to have the exact values of message id 79 fields of active device when it crashed. Even with the best efforts 80 to update the message Id values from active to stand-by device, the 81 values at standby device can be stale due to following reasons. 82 o standby device does not have a retransmission buffer corresponding 83 to that of old active SA . 84 o standby device is unaware of the last message that was received 85 and acknowledged by the older active device as failover could have 86 happened before the standby could be updated. 88 When a stand-by device takes over as the active device, it would 89 start the message id ranges from previously updated values. This 90 would make it reject requests from the peer , since the values would 91 be stale. As a sender, the stand-by device may end up reusing a 92 stale message-id which will cause the peer to drop the request. 93 Eventually there is a high probability of the IKEv2 and corresponding 94 IPsec SAs getting torn down simply because of a transitory message-id 95 mismatch. This is not a desirable feature of HA. 97 Hence a mechanism is required in HA to ensure that the stand-by 98 device has correct values of message Id values, so that sessions are 99 not torn down just because of window ranges. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 o stand-by device : The device which will take control , when the 108 active device crashes. 109 o active device : This is the primary device in the cluster. The 110 stand-by and active device form a cluster. 111 o peer device: This is the device with which any device in the 112 cluster , would establish an IKEv2 session. 113 o WINDOW_SYNC : A new type of exchange that is used to update the 114 window at stand-by device. 115 o SYNC_EXCH_MESSAGE_ID : This is the message Id sent as payload data 116 in the WINDOW_SYNC exchange. 118 3. Description of the solution 120 After the stand-by device takes control over the active device, the 121 stand-by device would request the peer to send its values of message 122 Id fields. 124 The stand-by device would then update its values of message Id fields 125 and then start sending/receiving the requests. 127 4. Details of implementation 129 A new exchange called WINDOW_SYNC exchange is required which is used 130 to exchange the message Id information among stand-by and peer 131 device. These exchanges are rate limited per IKEv2 SA. 133 Device which receives the messages of type WINDOWS_SYNC exchange MUST 134 ignore the message Id field and MUST NOT validate the message Id in 135 the header with the current window. 137 The stand-by device can initiate this Exchange 138 o when it has to send/receive the request. 139 o It has just got the control from active device and want to update 140 the values before-hand, so that it need not start this exchange at 141 the time of sending/receiving the request. 143 Since there can be many sessions at Stand-by device, and sending 144 exchanges from all of the sessions can cause throttling, the stand-by 145 device can chose to initiate the exchange when it has to send or 146 receive the request. Thus the trigger to initiate this exchange 147 depends on the requirement/discretion of the stand-by device. 149 Upon configuration the active device would announce its capability of 150 participating in window sync exchange by sending a VID payload in the 151 INIT exchange. This capability is updated at the stand-by device so 152 that is aware that it can participate in WINDOW_SYNC exchange. 154 The device which has received this VID payload can participate in the 155 WINDOW_SYNC exchange. A device MUST NOT send this exchange if it did 156 not receive this VID payload. 158 If a device gets this type of exchange even though it did not send 159 the VID payload, then it MUST drop this packet with error 160 INVALID_SYNTAX. 162 If responder of this exchange does not reply to this exchange, even 163 though responder has announced its capability in VID payload, then 164 the initiator SHOULD retransmit. The responder MUST retransmit the 165 SET_MESSAGE_ID_INFO notify only for the earlier received 166 GET_MESSAGE_ID_INFO. 168 5. Notify Types 170 Below are the two notify types that are newly defined 171 o GET_MESSAGE_ID_INFO : This notify would be similar to that any 172 other simple notify with the notify type being 173 GET_MESSAGE_ID_INFO. The value of SYNC_EXCH_MESSAGE_ID should be 174 sent as data in this. 175 * SYNC_EXCH_MESSAGE_ID : This MUST be started with zero and 176 incremented for every consequent GET_MESSAGE_ID_INFO notify 177 sent over an IKEv2 SA. 179 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Next Payload |C| RESERVED | Payload Length | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | SYNC_EXCH_MESSAGE_ID | 187 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 189 GET_MESSAGE_ID_INFO 191 o SET_MESSAGE_ID_INFO : This notify would be similar to that of 192 GET_MESSAGE_ID_INFO but with Notify message type being 193 SET_MESSAGE_ID_INFO.Additionally it contains the following data. 194 * SYNC_EXCH_MESSAGE_ID : This value should be filled with the 195 value received in GET_MESSAGE_ID_INFO notify. 196 * EXPECTED_SEND_REQ_MESSAGE_ID : This field is used by the sender 197 of this notify, to indicate the message Id it will use in the 198 next request, that it will send to the peer. 200 * EXPECTED_RECV_REQ_MESSAGE_ID : This field is used by the sender 201 of this notify, to indicate the message Id it can accept in the 202 next request, received from the peer. 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Next Payload |C| RESERVED | Payload Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Protocol ID | SPI Size | Notify Message Type | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | SYNC_EXCH_MESSAGE_ID | 210 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 211 | EXPECTED_SEND_REQ_MESSAGE_ID | 212 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 213 | EXPECTED_RECV_REQ_MESSAGE_ID | 214 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 216 SET_MESSAGE_ID_INFO 218 6. Security Considerations 220 In order to avoid getting replays of the same Notify of 221 GET_MESSAGE_ID_INFO and SET_MESSAGE_ID_INFO, SYNC_EXCH_MESSAGE_ID is 222 used as payload data. 224 The window size for this exchange is always 1, which means that the 225 sender cannot send the GET_MESSAGE_ID_INFO with different 226 SYNC_EXCH_MESSAGE_ID value. This value MUST be started with zero. 227 The number of times responder can retransmit the SET_MESSAGE_ID_INFO 228 can be rate limited to avoid the DOS attacks. 230 7. VID Payload 232 The VID payload is as described in [RFC4306] with a 16-octets data 233 field as follows: 235 ae3303f2ddd9ced6a903ce8a152429b7 237 This value was obtained by hashing the string "sync message Id 238 information" using the MD5 algorithms. 240 8. IANA Considerations 242 This document defines a new exchange and two new IKEv2 Notification 243 Message types as described in Section 5.The new Notify Message Types 244 must be assigned values between 16396 and 40959. 245 o WINDOW_SYNC_EXCHANGE 246 o GET_MESSAGE_ID_INFO 247 o SET_MESSAGE_ID_INFO 249 9. Acknowledgements 251 I would like to thank Pratima Sethi and Frederic Detienne for their 252 valuable reviews and suggestions. 254 10. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 260 RFC 4306, December 2005. 262 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 263 Implementation Guidelines", RFC 4306, October 2006. 265 Author's Address 267 Kalyani Garigipati 268 Cisco Systems, Inc. 269 SEZ Unit, Cessna Business Park 270 Bangalore, Karnataka 560025 271 India 273 Phone: +91 80 4426 4831 274 Email: kagarigi@cisco.com