IKEv2 window synchronisation among peers
draft-kagarigi-ipsecme-ikev2-windowsync-01

Abstract

This document describes an extension to the IKEv2 protocol that allows the synchronisation of ikev2 windows between the peers.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on December 27, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Description of the solution
4.  Details of implementation
5.  Notify Types
6.  Actions on the Peer Device
7.  Security Considerations
8.  IANA Considerations
9.  Acknowledgements
10.  Normative References
§  Author's Address

1.  Introduction

IKEv2 RFC states that "An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests".

As per the protocol , all IKEv2 packets must follow a request-response paradigm. The initiator of an IKEv2 request MUST retransmit the request, until it has received a response from the peer. IKEv2 introduces a windowing mechanism that allows multiple requests to be outstanding at a given point of time, but mandates that the sender window does not move until the oldest message sent from one peer to another is acknowledged. Loss of even a single packet leads to repeated retransmissions followed by an IKEv2 SA teardown if the retransmissions are unacknowledged.

HA for IKEv2 is required to ensure that in case of crash of active device , the stand-by device becomes active immediately. The stand-by device is expected to have the exact values of message id fields of active device when it crashed. Even with the best efforts to update the message Id values from active to stand-by device, the values at standby device can be stale due to following reasons.

• standby device does not have a retransmission buffer corresponding to that of old active SA .
• standby device is unaware of the last message that was received and acknowledged by the older active device as failover could have happened before the standby could be updated.

When a stand-by device takes over as the active device, it would start the message id ranges from previously updated values. This would make it reject requests from the peer , since the values would be stale. As a sender, the stand-by device may end up reusing a stale message-id which will cause the peer to drop the request. Eventually there is a high probability of the IKEv2 and corresponding IPsec SAs getting torn down simply because of a transitory message-id mismatch. This is not a desirable feature of HA.

Hence a mechanism is required in HA to ensure that the stand-by device has correct values of message Id values, so that sessions are not torn down just because of window ranges.

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

• stand-by device : The device which will take control , when the active device crashes.
• active device : This is the primary device in the cluster. The stand-by and active device form a cluster.
• peer device: This is the device with which any device in the cluster , would establish an IKEv2 session.
• Message SYNC Request : The information exchange with notify GET_MESSAGE_ID_INFO.
• Message SYNC Response : The informational exchange with notify SET_MESSAGE_ID_INFO.

3.  Description of the solution

After the stand-by device takes control over the active device, the stand-by device would request the peer to send its values of message Id fields.

The stand-by device would then update its values of message Id fields and then start sending/receiving the requests.

The ability of a device to participate in syncing the message Id MUST be announced using the notify SYNC_MESSAGE_ID_INFO in AUTH exchange. After the peer device responds with this capability, the active device MUST sync this to the stand-by device so that stand-by device is aware of the capability and can use it when it takes control over the active device.

   Active Device                          Peer Device
   ===========                               ===========
   HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                  AUTH, SAi2, TSi, TSr,
                  N[SYNC_MESSAGE_ID_INFO]}  ===>

             ====  HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                                 AUTH, SAi2, TSi, TSr,
                                 N[SYNC_MESSAGE_ID_INFO]}

when the stand-by device takes control over the active device, it has to request the peer for the message Id values. Stand-by device would initiate the Message SYNC Request with an INFORMATIONAL exchange containing the notify GET_MESSAGE_ID_INFO . Nonce payload MUST be sent in Message SYNC Request.

Peer device would respond back with the notify SET_MESSAGE_ID_INFO. The Nonce payload received in request MUST be sent back same by peer device in the reponse. This is done to counter the replay of Message SYNC response.

   Stand by Device                          Peer Device
   ===========                                      ===========
   HDR, SK {N[GET_MESSAGE_ID_INFO], N}  ===>

             ===  HDR, SK {N[SET_MESSAGE_ID_INFO], N}

4.  Details of implementation

The message Id used in this exchange MUST be zero so that it is not vaildated upon receipt. Message Id zero MUST be permitted only for informational exchange that would have NOTIFY of type GET_MESSAGE_ID_INFO or SET_MESSAGE_ID_INFO. If any packet uses the message Id Zero, without having this Notify along with the Nonce payload, then such packets MUST be discarded upon decryption.

The stand-by device can initiate this Exchange

• when it has to send/receive the request.
• It has just got the control from active device and want to update the values before-hand, so that it need not start this exchange at the time of sending/receiving the request.

Since there can be many sessions at Stand-by device, and sending exchanges from all of the sessions can cause throttling, the stand-by device can chose to initiate the exchange when it has to send or receive the request. Thus the trigger to initiate this exchange depends on the requirement/discretion of the stand-by device.

The device which has not announced its capability MUST NOT send the notify GET_MESSAGE_ID_INFO and MUST NOT receive SET_MESSAGE_ID_INFO.

If a device gets this type of exchange even though it did not announce its capability, then it MUST drop this packet with error INVALID_SYNTAX.

If responder of this exchange does not reply to this exchange, even though responder has announced its capability in VID payload, then the initiator SHOULD retransmit. The responder MUST retransmit the SET_MESSAGE_ID_INFO notify only if gets a retransmitted request..

If responder of this exchange does not reply to this exchange, even though responder has announced its capability in VID payload, then the initiator SHOULD retransmit. The responder MUST retransmit the SET_MESSAGE_ID_INFO notify only for the earlier received GET_MESSAGE_ID_INFO.

5.  Notify Types

Below are the three notify types that are newly defined

• SYNC_MESSAGE_ID_INFO : This notify would be similar to that any other simple notify with the notify type being SYNC_MESSAGE_ID_INFO.
  

  ---

                            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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Payload  |C|  RESERVED   |         Payload Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  

  SYNC_MESSAGE_ID_INFO

  ---

• GET_MESSAGE_ID_INFO : This notify would be similar to that any other simple notify with the notify type being GET_MESSAGE_ID_INFO.
  

  ---

                            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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Payload  |C|  RESERVED   |         Payload Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  
  

  GET_MESSAGE_ID_INFO

  ---

• SET_MESSAGE_ID_INFO : This notify would be similar to that of GET_MESSAGE_ID_INFO but with Notify message type being SET_MESSAGE_ID_INFO.Additionally it contains the following data.
  • EXPECTED_SEND_REQ_MESSAGE_ID : This field is used by the sender of this notify, to indicate the message Id it will use in the next request, that it will send to the peer.
  • EXPECTED_RECV_REQ_MESSAGE_ID : This field is used by the sender of this notify, to indicate the message Id it can accept in the next request, received from the peer.
  
  

  ---

                        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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Payload  |C|  RESERVED   |         Payload Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |EXPECTED_SEND_REQ_MESSAGE_ID                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |EXPECTED_RECV_REQ_MESSAGE_ID                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  

  SET_MESSAGE_ID_INFO

  ---

6.  Actions on the Peer Device

The Peer MUST start the window from higher value and MUST NOT wait for any pending requests. For example, If the Peer device is expecting the next request with message Id K, then it should send the EXPECTED_SEND_REQ_MESSAGE_ID as K. If it has received some request through K-P but not P , then it should send the EXPECTED_SEND_REQ_MESSAGE_ID as P.

7.  Security Considerations

There can be two types of DOS attacks.

• Replay of Message SYNC Request. This can be countered by rate limiting the number of such requests a peer device can receive. The rate limiting can be done either by number or the time delay between which GET_MESSAGE_ID_INFO can be received or both These options are configurable.
• Replay of Message SYNC Response. This can be countered by sending the NONCE payload along with the GET_MESSAGE_ID_INFO notify. The payload has to be returned same in response. Thus the stand-by device can accept the reply only for the current request. After it receives the response, it MUST not accept the same response again and MUST drop the response.

8.  IANA Considerations

This document three new IKEv2 Notification Message types as described in Section 5.The new Notify Message Types must be assigned values between 16396 and 40959.

• SYNC_MESSAGE_ID_INFO
• GET_MESSAGE_ID_INFO
• SET_MESSAGE_ID_INFO

9.  Acknowledgements

I would like to thank Pratima Sethi, Frederic Detienne and HA Design team for their valuable reviews and suggestions.

10. Normative References

Author's Address