[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
   IP Security Protocol Working Group (IPSEC)
   Internet Draft                                            S. Fanning
   Document: draft-ietf-ipsec-ike-lifetime-00.txt         Cisco Systems
   Expires: December 2001                                     July 2001


                 Responder Lifetime Notify Message for IKE


Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   This document describes how the RESPONDER-LIFETIME notify message,
   used within the ISAKMP DOI can be used to facilitate lifetime
   negotiation and rekeying.




Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   1. Introduction....................................................2
   2. Conventions used in this document...............................2
   3. Justification...................................................2
   4. The IKE Responder Lifetime Notify Message.......................3
   5. Security Considerations.........................................4
   6. Acknowledgments.................................................5
   7. References......................................................5
   8. Authors' Addresses..............................................5

             Responder Lifetime Notify Message for IKE    December 2001


1. Introduction

   Currently, IKE[RFC-2409], Phase One (Main Mode / Aggressive Mode)
   lifetimes are not negotiated. By sending a RESPONDER-LIFETIME Notify
   message over the IKE SA (ISAKMP DOI), both parties can be aware of
   the lifetime of the IKE SA thus allowing for the initiating peer to
   take whatever action required.


2. Conventions used in this document

   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


3. Justification

   In cases where the responders IKE lifetime is shorter than the one
   presented by the initiator, it is often desirable that the responder
   be able to communicate to the initiator what lifetime is preferred
   according to its local policy.

   Although the IKE and IPSec Security Associations are independent,
   there are implementations that bind the two together. Such an
   implementation is not contrary to the standard, but can result in
   interoperability problems.

   In section 4.5.4 of IPSec DOI [IPSEC], it states that there are 3
   options for handling lifetimes for QM (IPSec DOI). If we extend the
   three ways of handling lifetimes to ISAKMP, the following behavior
   will result.

   a) Fail the negotiation entirely.

   Although, a legitimate, and entirely secure response to a lifetime
   that does not match local policy, it does not promote connectivity.
   Responding this way SHOULD be a matter of local policy.

   b) Complete the negotiation but use a shorter lifetime than what was
   offered.

   Due to the fact that you can not alter the proposals presented by
   the initiator, another common solution to mismatched lifetimes is to
   accept the proposed lifetime of the initiator and delete the IKE SA
   when the shorter lifetime is exceeded.

   This however, can cause a "black hole" problem.

   Example:

   - Peer A initiates IKE to Peer B, proposing a lifetime of 1 year.
   - Peer Bs local policy says that lifetimes are acceptable only ifs
   they are 60 minutes.
   S. Fanning                                                         2

             Responder Lifetime Notify Message for IKE    December 2001

   - Peer B accepts the 1 year lifetime, but will send a DELETE
   notification when the 60 minutes is exceeded.

   However, in the case where Peer B sends a DELETE notify message and
   is not received by the Initiator (Peer A), the peer A will not
   delete its IKE SA until 1 year is up. Peer A will then send IKE
   messages that from Peer BÆs perspective cannot be authenticated.
   Peer A will now have that IKE SA information until it exceeds 1 year
   (or manual intervention removes it).

   Although some solutions will initiate a new IKE SA From Peer B to
   Peer A when an unauthenticated NOTIFY message is received, this
   behavior could facilitate a DoS attack unless some sort of rate
   limiting mechanism/logging facility was implemented.

   c) Complete the negotiation and send an advisory notification to the
   initiator indicating the responder's true lifetime.

   Since altering the proposal from the initiator is a violation of the
   IKE, there is no way to communicate to the initiator what IKE SA
   lifetime is being used by the responder another method of
   communicating this is required.



4. The IKE Responder Lifetime Notify Message

   The RESPONDER-LIFETIME notify message is the same as described in
   the IPSec DOI[RFC 2407] documentation, but has the IKE DOI.


      Notify Messages - Status Types      Value
      ------------------------------      -----
      RESPONDER-LIFETIME                  24576

                        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  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !              Domain of Interpretation  (DOI)                  !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol-ID  !   SPI Size    !      Notify Message Type      !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                Security Parameter Index (SPI)                 ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                       Notification Data                       ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The RESPONDER-LIFETIME status message may be used to communicate the
   IKE SA lifetime chosen by the responder.
   S. Fanning                                                         3

             Responder Lifetime Notify Message for IKE    December 2001


      When present, the Notification Payload MUST have the following
      format:

       o  Payload Length - set to length of payload + size of data(var)
       o  DOI - set to IKE DOI (0)
       o  Protocol ID - set to selected Protocol ID from chosen SA
       o  SPI Size - set to sixteen (16) (two eight-octet ISAKMP
           cookies)
       o  Notify Message Type - set to RESPONDER-LIFETIME (Section
   4.6.3 of [RFC2507])
       o  SPI - set to the two ISAKMP cookies
       o  Notification Data - contains an ISAKMP attribute list with
   the responder's actual IKE SA lifetime.

   The RESPONDER-LIFETIME SHOULD be sent by the responder if the
   initiating peers lifetime for IKE is longer than the lifetime
   defined in the responders local policy. The receiver of the
   RESPONDER-LIFETIME MAY perform the following actions;

   a) MAY Adjust its IKE SA lifetime to the suggested value. This is
      the preferred action as this most facilitates communication.
   b) MAY terminate the negotiation if the initiating peer insists on
      that lifetime. This action does not facilitate communication, but
      no unexpected loss of traffic will occur.
   c) MAY ignore the RESPONDER-LIFETIME and continue to use the
      proposed one. This is not the preferred action as it may result
      in the "black hole" problem outlined in section 3.

   NOTE: Notify messages are UDP based and are unacknowledged,
   therefore assured delivery cannot be guaranteed.


5. Security Considerations

   The RESPONDER-LIFETIME notify MUST be sent when the notify message
   can be authenticated as per Section 4.6.3 of IPSec DOI[RFC 2407].


















   S. Fanning                                                         4

             Responder Lifetime Notify Message for IKE    December 2001





6. Acknowledgments

   I would like to thank Darren Dukes, Stephane Beaulieu, Dany
   Rochefort, Natalie Timms, Victor Volpe and Paul Del Fante for their
   time reviewing this document and recognizing that such a small
   change can be a big benefit to customers.

7. References

   [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)",
   November 1998

   [RFC-2407] Piper, D., "The Internet IP Security Domain of
   Interpretation for ISAKMP",
              November 1998
   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997

8. Authors' Addresses


      Scott Fanning
      Cisco Systems, Inc.
      170 West Tasman Drive
      San Jose, CA 95134
      Phone: (408) 525-3166
      Email: sfanning@cisco.com


   The IPsec working group can be contacted through the chairs:

      Barbara Fraser
      byfraser@cisco.com
      Cisco Systems, Inc.

      Ted T'so
      tytso@mit.edu
      Massachusetts Institute of Technology













   S. Fanning                                                         5