TOC 
Network Working GroupG. Kalyani
Internet-DraftCisco
Intended status: Standards TrackJune 25, 2010
Expires: December 27, 2010 


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




 TOC 

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.

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.



 TOC 

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].



 TOC 

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}



 TOC 

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

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.



 TOC 

5.  Notify Types

Below are the three notify types that are newly defined



 TOC 

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.



 TOC 

7.  Security Considerations

There can be two types of DOS attacks.



 TOC 

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.



 TOC 

9.  Acknowledgements

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



 TOC 

10. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4306] Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” RFC 4306, December 2005 (TXT, HTML, XML).
[RFC4718] Eronen, P. and P. Hoffman, “IKEv2 Clarifications and Implementation Guidelines,” RFC 4306, October 2006 (TXT, HTML, XML).


 TOC 

Author's Address

  Kalyani Garigipati
  Cisco Systems, Inc.
  SEZ Unit, Cessna Business Park
  Bangalore, Karnataka 560025
  India
Phone:  +91 80 4426 4831
Email:  kagarigi@cisco.com