[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                         L. Dondeti
Internet-Draft                                              V. Narayanan
Intended status: Standards Track                          QUALCOMM, Inc.
Expires: August 29, 2007                               February 25, 2007


             IPsec Gateway Failover and Redundancy Protocol
                  draft-dondeti-ipsec-failover-sol-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on August 29, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   IPsec gateways and servers maintaining SAs with large number of
   clients can quickly recover from failover using the protocols and
   procedures specified in this document.  These techniques also
   facilitate IPsec clients to move from one gateway to another and
   resume operation without having to rerun IKEv2.  The idea is to
   maintain IKEv2 and IPsec SA state at either the client or one or more
   backup servers to reduce the communication and computation overhead
   associated with reestablishing the SAs from scratch.  Client to



Dondeti & Narayanan      Expires August 29, 2007                [Page 1]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   server SA state storage retrieval mechanisms and client-initiated or
   server-initiated failover recovery protocols are specified.  This
   document, however, does not define an inter-gateway transport
   mechanism to transfer the state across entities at the backend.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Recovering from a Remote Access Gateway Failover . . . . .  5
     3.2.  Recovering from an Application Server Failover . . . . . .  7
   4.  IKEv2 Session Resumption Protocol Details  . . . . . . . . . .  8
     4.1.  Capability Negotiation and State Transfer  . . . . . . . .  8
       4.1.1.  Extensions to the IKE_INIT_SA message  . . . . . . . .  9
       4.1.2.  Extensions to the IKE_AUTH Exchange  . . . . . . . . .  9
       4.1.3.  Capability Negotiation and State Transfer via an
               Informational Exchange . . . . . . . . . . . . . . . . 11
       4.1.4.  IKEv2 Ticket . . . . . . . . . . . . . . . . . . . . . 12
     4.2.  IKEv2 Session Resumption . . . . . . . . . . . . . . . . . 13
       4.2.1.  IKE_SESSION_RESUME Exchange  . . . . . . . . . . . . . 14
       4.2.2.  Replay Protection of Session Resumption Exchange . . . 15
       4.2.3.  Processing IKE_SESSION_RESUME messages . . . . . . . . 16
   5.  Message Types and Formats  . . . . . . . . . . . . . . . . . . 18
     5.1.  IKEv2 Header with Gateway Switch Count . . . . . . . . . . 18
     5.2.  SESSION_RESUMPTION_SUPPORTED Notify Message Type . . . . . 19
     5.3.  Other Payload Specifications . . . . . . . . . . . . . . . 19
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     6.1.  Properties of the Secure Domain  . . . . . . . . . . . . . 20
     6.2.  Properties of Capability Negotiation . . . . . . . . . . . 20
     6.3.  Properties of SA Ticket Creation, Distribution and Use . . 21
     6.4.  Properties of the Session Resumption Protocol  . . . . . . 22
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 25













Dondeti & Narayanan      Expires August 29, 2007                [Page 2]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


1.  Introduction

   Recovering from failure of IPsec gateways or servers maintaining SAs
   with large numbers of clients may take several minutes, if they need
   to re-establish the IPsec SAs by re-running the key management
   protocol, IKEv2.  A similar problem arises in the event of a network
   outage resulting in the failure of several gateways and servers.  The
   computational and communication latency in running IKEv2 or IKEv2
   with EAP for client authentication is significant, leading to a need
   for a faster and yet secure failover solution.  The problem statement
   and goals for a failover solution are described in [1].

   When an IPsec gateway fails or otherwise unreachable for a client,
   the situation may be temporary or long lasting.  The client should be
   able to recover in either scenario.  In other words, the client may
   go back to the original gateway or alternatively, it may go to
   another gateway to re-establish the session.  The new gateway needs
   access to the IKEv2 SA that the client and the old gateway
   established with each other.  The new gateway may acquire the SA from
   the old gateway or another infrastructure entity where the old
   gateway has stored the SA.  The only other possibility for SA storage
   and retrieval is for the old gateway to store the SA at the client
   itself in the form of a "ticket."  The client then presents the
   ticket to the new or the old gateway.  To facilitate such SA storage
   and retrieval, the gateways must share security associations between
   themselves or with an infrastructure entity.

   For convenience we call gateways that share a security association
   with each other either directly or through another entity, as
   belonging to a secure domain.  When the SA state is stored at the
   client, the infrastructure is "stateless" until the client restores
   the SA with one of the gateways within the secure domain; thus, we
   refer to SA resumption with SA storage at the client as stateless
   session resumption.  When the infrastructure maintains SA state, we
   refer to the process as stateful session resumption.

   We identify three components to an efficient failover solution:

      In the first part, the client and the gateway negotiate failover
      support.  More specifically, the client indicates supports for
      failover and any related capabilities.  The gateway verifies its
      policy and may accept or reject support for failover for the
      client; if it accepts the request, it indicates its own
      capabilities in supporting the failover.  The gateway may include
      a list of backup gateways in its response; when the gateway does
      not return a list of alternative gateways, the clients are
      expected to discover the backup gateways or servers through a
      mechanism external to IPsec key management.  Capability



Dondeti & Narayanan      Expires August 29, 2007                [Page 3]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


      negotiation can be piggybacked on the IKE_AUTH exchange.  The
      client indicates whether it supports failover in the IKE_AUTH
      request message via a notify payload; the gateway indicates
      whether it supports failover for that client and may send a list
      of other gateways in the secure domain, all via notify payloads in
      the IKE_AUTH response message.

      In the second part, the gateway creates a ticket and stores it in
      the infrastructure or supplies it to the client, if the client had
      indicated support for it and the gateway's policy allows storing
      state in the client for that particular client.  The gateway may
      send the ticket via a notify payload included in the IKE_AUTH
      response message.

      The third part is session re-establishment itself: When a client
      discovers that it cannot reach a gateway or application server
      with which it has an IPsec SA, it attempts to reach another
      gateway within the same secure domain as the initial gateway.  In
      other cases, the client may have gone dormant and could be
      resuming the session with the original gateway.  For session re-
      establishment, we specify a new IKE exchange, IKE_SESSION_RESUME,
      which is quite similar to CREATE_CHILD_SA in many ways, but with
      some crucial differences also.  In simple terms, processing
      IKE_SESSION_RESUME request is a cross between processing
      IKE_SA_INIT and CREATE_CHILD_SA.  For the scope of this work, it
      is assumed that the gateways in the secure domain do not share the
      same IP address and may not share the same view of the network,
      i.e., they may be connected to different DHCP servers.  Thus, the
      client may need to acquire a new IP address upon reestablishing an
      IKE session with a new gateway.  It is assumed that in this case,
      the original IKEv2 exchange used the Configuration Payload to
      acquire configuration information.

   Note that it is plausible to run the capability negotiation and
   ticket request/response via a information exchange after the SA has
   been established.  Another possibility is to piggyback the
   negotiation and ticket request/response on a CREATE_CHILD_SA
   exchange.


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

   This document uses terminology defined in [3], [4], and [5].  In
   addition, this document uses the following terms:



Dondeti & Narayanan      Expires August 29, 2007                [Page 4]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   Secure domain:  A secure domain comprises a set of gateways that are
      able to resume an IKEv2 session that may have been established any
      other gateway within the domain.  All the gateways in the secure
      domain are expected to share a security association -- either with
      each other or through a trusted third party -- so they can verify
      the validity of the ticket and can extract the IKEv2 policy and
      session key material from the ticket.

   IKEv2 ticket:  An IKEv2 ticket is a data structure that contains all
      the necessary information that allows any gateway within the same
      secure domain as the gateway that created the ticket to verify the
      validity of the ticket and extract IKEv2 policy and session keys
      to re-establish an IKEv2 session.

   Stateless failover:  When the IKEv2 session state is stored at the
      client, the infrastructure is "stateless" until the client
      restores the SA with one of the gateways within the secure domain;
      thus, we refer to SA resumption with SA storage at the client as
      stateless session resumption.

   Stateful failover:  When the infrastructure maintains IKEv2 session
      state, we refer to the process of IKEv2 SA re-establishment as
      stateful session resumption.


3.  Usage Scenarios

   This specification envisions two usage scenarios for efficient IKEv2
   and IPsec SA session re-establishment: The first is similar to the
   use case specified in Section 1.1.3 of the IKEv2 specification [4],
   where IPsec tunnel mode is to establish a secure channel between a
   remote access client and a gateway; the traffic flow may be between
   the client and entities beyond the gateway.  The second use case is
   somewhat different from any of the use cases defined in the IKEv2
   specification: at the IP layer, two endpoints use transport (or
   tunnel) mode to communicate between themselves.  The two endpoints
   have a client-server relationship with respect to a protocol that
   runs using the protections afforded by the IPsec SA.

3.1.  Recovering from a Remote Access Gateway Failover











Dondeti & Narayanan      Expires August 29, 2007                [Page 5]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


    (a)

    +-+-+-+-+-+                          +-+-+-+-+-+
    !         !      IKEv2/IKEv2-EAP     !         !     Protected
    ! Remote  !<------------------------>! Remote  !     Subnet
    ! Access  !                          ! Access  !<--- and/or
    ! Client  !<------------------------>! Gateway !     Internet
    !         !      IPsec tunnel        !         !
    +-+-+-+-+-+                          +-+-+-+-+-+


    (b)

    +-+-+-+-+-+                          +-+-+-+-+-+
    !         !    IKE_SESSION_RESUME    !         !
    ! Remote  !<------------------------>! New/Old !
    ! Access  !                          ! Gateway !
    ! Client  !<------------------------>!         !
    !         !      IPsec tunnel        !         !
    +-+-+-+-+-+                          +-+-+-+-+-+



                  Figure 1: Remote Access Gateway Failure

   In this scenario, an endhost (an entity with a host implementation of
   IPsec [3] ) establishes a tunnel mode IPsec SA with a gateway in a
   remote network using IKEv2.  The endhost in this scenario is
   sometimes referred to as a remote access client.  When the remote
   gateway fails, all the clients associated with the gateway either
   need to re-establish IKEv2 sessions with another gateway within the
   same secure domain of the original gateway, or with the original
   gateway if the server is back online soon.

   The clients may choose to establish IPsec SAs using a full IKEv2
   exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1).

   In this scenario, the client needs to get an IP address from the
   remote network so that traffic can be encapsulated by the remote
   access gateway before reaching the client.  In the initial exchange,
   the gateway may acquire IP addresses from the address pool of a local
   DHCP server.  The new gateway that a client gets associated may not
   receive addresses from the same address pool.  Thus, the session
   resumption protocol needs to be able to support for new IP address
   assignment.






Dondeti & Narayanan      Expires August 29, 2007                [Page 6]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


3.2.  Recovering from an Application Server Failover


     (a)

    +-+-+-+-+-+                          +-+-+-+-+-+
    !   App.  !      IKEv2/IKEv2-EAP     !   App.  !
    !  Client !<------------------------>!  Server !
    !    &    !                          !    &    !
    !  IPsec  !<------------------------>!  IPsec  !
    !   host  !  IPsec transport/        !   host  !
    +-+-+-+-+-+        tunnel mode SA    +-+-+-+-+-+


    (b)

    +-+-+-+-+-+                          +-+-+-+-+-+
    !   App.  !    IKE_SESSION_RESUME    !   New   !
    !  Client !<------------------------>!  Server !
    !    &    !                          !    &    !
    !  IPsec  !<------------------------>!  IPsec  !
    !   host  !  IPsec transport/        !   host  !
    +-+-+-+-+-+        tunnel mode SA    +-+-+-+-+-+


                   Figure 2: Application Server Failover

   The second usage scenario is as follows: two entities with IPsec host
   implementations establish an IPsec transport or tunnel mode SA
   between themselves; this is similar to the model described in Section
   1.1.2. of [4].  At the application level, one of the entities is
   always the client and the other is a server.  From that view point,
   the IKEv2 exchange is always initiated by the client.  This allows
   the Initiator (the client) to authenticate itself using EAP, as long
   as the Responder (or the application server) allows it.

   If the application server fails, the client may find other servers
   within the same secure domain for service continuity.  It may use a
   full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re-
   establish the IPsec SAs for secure communication required by the
   application layer signaling.

   The client-server relationship at the application layer ensures that
   one of the entities in this usage scenario is unambiguously always
   the Initiator and the other the Responder.  This role determination
   also allows the Initiator to request an address in the Responder's
   network using the Configuration Payload mechanism of the IKEv2
   protocol.  If the client has thus received an address during the



Dondeti & Narayanan      Expires August 29, 2007                [Page 7]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   initial IKEv2 exchange, when it associates with a new server upon
   failure of the original server, it needs to request an address,
   specifying its assigned address.  The server may allow the client to
   use the original address or if it is not permitted to use that
   address, assigns a new address.


4.  IKEv2 Session Resumption Protocol Details

   The IKEv2 session resumption protocol specified in this document has
   three components: capability negotiation, state transfer, and session
   resumption.  Capability negotiation and state transfer are extensions
   to the IKEv2 base exchange.  IKE_SESSION_RESUME exchange is new; it
   is modelled after the CREATE_CHILD_SA, but looks slightly different
   in transit and has different processing semantics.  It does share a
   majority of the structure, format and processing semantics of the
   CREATE_CHILD_SA exchange, but also has some fundamental differences.

4.1.  Capability Negotiation and State Transfer

   IKEv2 session resumption capabilities -- whether the client and
   server support session resumption, whether the client needs the
   gateway list and whether the client can store state-- are negotiated
   via notify payloads.  The Initiator uses a notify payload to indicate
   what it supports and what it needs: for session resumption, the
   client MUST send a notify payload of type
   SESSION_RESUMPTION_SUPPORTED.  The notification data filed of this
   type of notify payload defines two flags: the Initiator may indicate
   support for client side state storage (in other words, request an
   IKEv2 ticket) setting the flag CLIENT_SIDE_STORAGE_SUPPORTED and may
   request the list of backup gateways from the Responder, by setting
   the flag CLIENT_REQUEST_GW_LIST.

   The Responder processes the notify payload and if it supports session
   resumption for the client in question, then it returns a notify
   payload of type SESSION_RESUMPTION_SUPPORTED.  In addition, if the
   Initiator request a list of gateways, the Responder SHOULD send a
   notify payload of type ALT_GW_LIST, with a list of gateway addresses
   belonging to the same secure domain.  Finally, if the Responder
   supports client side state storage, it sends a ticket via a notify
   payload of type IKEv2_TICKET.

   Capability negotiation can be piggybacked on the IKE_SA_INIT, the
   IKE_AUTH or an Informational exchange after the base exchange is
   complete.  Session state transfer cannot occur until mutual
   authentication and IKE SA establishment is complete.  Thus, session
   state transfer can be piggybacked on the IKE_AUTH exchange or an
   Informational exchange after the base exchange is complete.



Dondeti & Narayanan      Expires August 29, 2007                [Page 8]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


4.1.1.  Extensions to the IKE_INIT_SA message

   The initiator indicates support for session resumption by including
   the Notify payload of type SESSION_RESUMPTION_SUPPORTED in the
   IKE_INIT_SA request message.  If the responder does not support such
   a capability, it MUST ignore the session resumption notify payload.
   A responder that supports failover and is willing to offer that
   support to the client MUST return a notify payload of type
   SESSION_RESUMPTION_SUPPORTED in the IKE_INIT_SA response message.  If
   the Initiator sets the flag CLIENT_REQUEST_GW_LIST, the responder
   typically returns a list of gateways in a separate notify payload, of
   type ALT_GW_LIST.

   Implementations support session transfer MAY support extensions to
   the IKE_INIT_SA messages.  If the responder does not respond to
   capability negotiation during the IKE_INIT_SA exchange, the initiator
   may choose to try again during the IKE_AUTH exchange.

   The capability negotiation is authenticated as part of the mutual
   authentication processes during the IKE_AUTH exchange.

   If the Initiator sets the flag CLIENT_SIDE_STORAGE_SUPPORTED, the
   Responder may send the state via a notify payload of type
   IKEv2_TICKET as part of the subsequent IKE_AUTH exchange.  See
   Section 4.1.2 for additional details.


    Initiator                          Responder
   -----------                        -----------
   HDR, SAi1, KEi, Ni,
   N(SESSION_RESUMPTION_SUPPORTED) -->

                        <--    HDR, SAr1, KEr, Nr, [CERTREQ],
                               N(SESSION_RESUMPTION_SUPPORTED)


             Figure 3: Piggybacking over IKE_INIT_SA messages

4.1.2.  Extensions to the IKE_AUTH Exchange

   Capability negotiation and the state transfer can together be
   piggybacked on the IKE_AUTH exchange, in the 4-message version or the
   version where EAP is used for client authentication.  The ticket can
   in fact be sent in the clear -- more on that later -- but it is
   simpler to include it within the SK payload of the IKE_AUTH message
   and that allows us to make minimal modifications to the IKE_AUTH
   message processing semantics.




Dondeti & Narayanan      Expires August 29, 2007                [Page 9]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   If the Initiator supports ticket storage, it is RECOMMENDED that the
   IKE_AUTH exchange be used for capability negotiation and state
   transfer.

   The capability negotiation and state transfer semantics are as
   specified in Section Section 4.1.1.  The exchange is protected by the
   MAC in the IKE_AUTH exchange.  Note that when the capability exchange
   is piggybacked on the IKE_SA_INIT exchange the protection afforded to
   the negotiation is the same as that afforded to the IKE SA parameter
   negotiation and when it is piggybacked on the IKE_AUTH exchange, the
   protections afforded are the same as that to the Child SA parameter
   negotiation.


 Initiator                                 Responder
-----------                               -----------
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr,
[N(SESSION_RESUMPTION_SUPPORTED)]}  -->

                            <--    HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi
                                   TSr, [N(SESSION_RESUMPTION_SUPPORTED),
                                         N(IKEv2_TICKET)]}


             Figure 4: Piggybacking over the IKE_AUTH Exchange

























Dondeti & Narayanan      Expires August 29, 2007               [Page 10]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


    Initiator                          Responder
   -----------                        -----------
   HDR, SAi1, KEi, Ni         -->

                              <--    HDR, SAr1, KEr, Nr, [CERTREQ]

   HDR, SK {IDi, [CERTREQ,] [IDr,]
   SAi2, TSi, TSr
   [N(SESSION_RESUMPTION_SUPPORTED)]}  -->

                              <--    HDR, SK {IDr, [CERT,] AUTH,
                                                   EAP }

   HDR, SK {EAP}              -->

                              <--    HDR, SK {EAP (success)}

   HDR, SK {AUTH}             -->

                              <--    HDR, SK {AUTH, SAr2, TSi, TSr
                                     [N(SESSION_RESUMPTION_SUPPORTED),
                                      N(IKEv2_TICKET)]}


   Figure 5: Piggyback over IKE_AUTH with EAP for Client Authentication

   If the Initiator sets the flag CLIENT_SIDE_STORAGE_SUPPORTED, the
   Responder MAY send the state via a notify payload of type
   IKEv2_TICKET in the IKE_AUTH response message.  In case of IKEv2-EAP
   exchange the request for session resumption support is indicated in
   the first message of the IKE_AUTH sequence of messages from the
   initiator and the response is included in the last message from the
   responder.

   The client is expected the store the ticket and present it to the
   gateway with which it is resuming the session.  The
   IKE_SESSION_RESUME exchange is used for that purpose.

   The Ticket is included as part of a Notify message and can be opaque
   or conformant to the format specified in this document.

4.1.3.  Capability Negotiation and State Transfer via an Informational
        Exchange

   An initiator may choose to wait until the IKEv2 and IPsec SA
   establishment is complete before negotiating the IKEv2 session
   transfer support.  The initiator then uses an informational exchange
   to indicate support for session resumption and the responder can



Dondeti & Narayanan      Expires August 29, 2007               [Page 11]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   agree to support the capability and may send the ticket in response,
   as applicable.  The negotiation is protected as the Notify payloads
   are within the SK payload of IKEv2.


  Initiator                        Responder
-----------                      -----------
HDR, SK {
N(SESSION_RESUMPTION_SUPPORTED),
         [N(SPI)]}         -->
                           <-- HDR, SK {N(SESSION_RESUMPTION_SUPPORTED),
                                       [N(IKEv2_TICKET)]}


    Figure 6: Informational Exchange for Session Resumption Negotiation

4.1.4.  IKEv2 Ticket

   To enable clients to present the IKEv2 ticket received from one
   gateway to another, the contents of the ticket need to specified.
   The ticket structure may be used by a gateway to send state to the
   client or to another gateway or SA store.  In the event of backend
   storage of state, the SA store may be present in a highly available
   centralized entity or distributed across the backup gateways.  This
   document does not provide a protocol to upload or download state to/
   from the SA store.  However, such an exchange MUST be encrypted,
   authenticated and replay protected.

   In the simplest IKEv2 session, there is an IKE SA and a single IPsec
   SA.  The IKEv2 ticket may have been sent by the gateway during the
   base exchange or via an Informational exchange.  If either the IPsec
   SA or the IKE SA is rekeyed, the gateway sends the new ticket to the
   client.  The ticket is then associated with the IPsec SA in that when
   an SA is deleted, the corresponding ticket is also expected to be
   deleted, even if the ticket has not expired.

   The ticket contains all the necessary information for a gateway to
   restore the IKE SA; more specifically, it contains the negotiated IKE
   SA parameters and the corresponding attributes where applicable.
   There is also a lifetime to the ticket, which takes the form of a
   timestamp after which the ticket is no longer valid.  The ticket
   itself is protected -- encrypted and integrity protected -- with a
   security association created specifically for generating and
   validating tickets within a given secure domain.  The ticket
   generation SA (TGS) is identified with the TGS-SPI and that is
   included in the clear with the ticket.  The TGS-SPI allows the new
   gateway to identify the SA to use in validating the ticket.  The TGS-
   SPI is a blob that only the entities within a secure domain need to



Dondeti & Narayanan      Expires August 29, 2007               [Page 12]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   understand; for instance, if the gateways within a secure domain form
   a multicast group and use a group IPsec SA, the SPI may contain the
   destination address (group's multicast address) and a 32-bit random
   value.  The ticket may also contain the identity of the gateway/
   domain issuing it.

   When multiple IPsec SAs are created, the gateway MAY send a new
   ticket in each CREATE_CHILD_SA response message.  It is not clear
   whether the fields within the ticket, other than the lifetime of the
   ticket will be different.

   The ticket may contain IPsec specific information such as the tunnel
   inner address (TIA) assigned by the gateway.  In that case, each
   ticket is different.  Whether there is a need to include the TIA in
   the ticket is for discussion.

4.2.  IKEv2 Session Resumption

   When a client discovers that the gateway it is associated with is
   unreachable, according to the IKEv2 specification the client needs to
   verify the liveness of the gateway through IKEv2.  If the client
   determines that the gateway is unreachable, it is to delete the IKE
   SA and all associated CHILD SAs.  This specification modifies that
   behavior.

   If session resumption capability has been negotiated for the IKE SA,
   the client MAY reestablish the session with a backup gateway instead
   of deleting it.  The client needs to first find an alternative
   gateway: we refer to this step as gateway discovery.  There are a few
   possible ways of gateway discovery:

   Preconfiguration:  The client may have been pre-configured with a
      list of backup gateways.  In other words, the client learns of the
      backup gateways just as it does the address of the original
      gateway.

   Discovery through IKEv2:  First, the client may have requested and
      received a list of gateways during the capability negotiation
      phase.  In this case, the list of gateways is provided by the
      original gateway and the discovery has the protection of an IKEv2
      exchange.

   Discovery through application:  The client may discover that a
      gateway has failed and a new gateway must be used for connectivity
      through application layer messages.  An example of this is the
      Mobile IPv6 Home Agent (HA) discovery, where the client may
      discover the HA via MIP6 bootstrapping mechanisms.  The IKEv2
      specification has details on expected behavior on receiving



Dondeti & Narayanan      Expires August 29, 2007               [Page 13]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


      unauthenticated information about gateway unreachability.  Those
      rules still apply in this case, in that the client should verify
      the non-reachability before initiating a switch to the new
      gateway.

4.2.1.  IKE_SESSION_RESUME Exchange

   Subsequent to discovering gateway failure and alternative gateways to
   contact, a client may choose to run a full IKEv2 exchange to
   establish a new IKEv2 session or to resume the use of the previously
   established SA at the new gateway.  There are two cases to consider:
   in the first, the client has received an IKEv2_ticket from the
   original gateway and presents that to the new gateway.  In the second
   case, the client has no ticket to present and therefore simply
   attempts to reestablish the session with the new gateway.

   Note that it is impractical for all the gateways to be in synchrony
   with each other on all the replay protection state at each entity.
   Thus we need a special IKE SA created for session reestablishment and
   use that in the IKEv2 ticket or we need to tweak the IKEv2 replay
   protection mechanism as the client moves between gateways.  Next, the
   new gateway may not be able to support the same tunnel inner address
   as the original gateway.  Finally, for stateless failover, the new
   gateway will need to supply the next IKEv2_ticket to the client.
   Thus, the session resumption exchange comprises an IPsec SA
   establishment, optional IKEv2 SA rekeying, optional IP address
   assignment, and optional ticket delivery from the gateway to the
   client.  For the purposes of this specification, we assume that the
   client always initiates SA reestablishment.  We consider the case of
   gateway initiating SA recovery out of scope of the specification.

   We specify a new IKEv2 exchange type called IKE_SESSION_RESUME of
   type IANA-TBA.


Initiator                                 Responder
-----------                               -----------
HDR, [N(IKEv2_Ticket)], [N,] SK { SA, Ni,
[KEi], [TSi, TSr], [CP(CFG_Request)],
       [N(UPDATE_SA_ADDRESSES)]}      -->

                              <--    HDR, SK {SA, Nr, [KEr], [TSi, TSr],
                                         [CP(CFG_REPLY)], [N(IKEv2_Ticket)]}


                   Figure 7: IKE_SESSION_RESUME Exchange

   The HDR contains the Initiator's SPI as a random number of 8 octets



Dondeti & Narayanan      Expires August 29, 2007               [Page 14]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   chosen by the Initiator.  The Responder's SPI is set to zero.  The
   new gateway will pick the SPI and include it in the return message.
   The exchange type is set to 'IKE_SESSION_RESUME'.  We use a message
   ID of structure Gateway_Switch_Count (GSC) || message_ID, where
   Gateway_Switch_Count indicates the number of gateways the client has
   switched with the given IKE SA and message_ID is zero (or a suitable
   default value).

   In case of stateless failover, the client MUST include the
   IKEv2_Ticket payload.  For stateful failover, the client MUST include
   a Notify payload with the original IKEv2 SPI pair so that the new
   gateway can look up the SA and verify the validity of the
   IKE_SESSION_RESUME message.  Only one of these payloads MUST be
   present.  Note that the IKEv2_Ticket payload and the Notify payload
   containing the SPI values are included after the header, but, outside
   the encrypted data.  This allows for integrity protection of these
   payloads and not encryption.  The Responder must be able to read
   these payloads before it can decrypt the SK payload in the
   IKE_SESSION_RESUME message.

   If the client is contacting the same gateway to resume the IKE
   session, it may not require a new IP address or any configuration
   parameters.  For the purpose of this document, gateways that have the
   same view of the backend and are capable of supporting the same IP
   address for the clients are viewed as being a single gateway.  If the
   client does not know whether the new gateway can assign the same
   tunnel inner IP address and then it MUST include the CFG_Request
   Configuration Payload, indicating the need for an IP address.  It MAY
   include the original tunnel inner address in the request.  For tunnel
   mode IPsec, this is the tunnel inner address of the client.  If the
   local address of the client (tunnel outer address in tunnel mode) has
   also changed in the meantime, the client MUST include the
   UPDATE_SA_ADDRESSES notify payload defined in [5] in the session
   reestablishment Request message.

4.2.2.  Replay Protection of Session Resumption Exchange

   IKEv2, as defined in [4] provides replay protection between the
   initiator and the responder using sequence numbers.  Each entity
   maintains its own sequence number space and the sequence number is
   incremented after transmission of a request message.  When one of the
   entities involved in the IKEv2 exchange may change within the same
   IKE session, replay protection will require per packet update of
   state to continue to use the same model of sequence numbers specified
   in [4].  Per packet state updates are impractical and also do not
   always work.  It is plausible for the SA endpoints to fall out of
   sync or fail before an update is done, effectively opening up the
   possibility of replays.



Dondeti & Narayanan      Expires August 29, 2007               [Page 15]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   In order to provide replay protection even when one of the entities
   is changing mid-session, this document proposes a structure to the
   message ID field of the IKEv2 header.  The message ID field is
   composed as GSC||s_message_ID, where the GSC is a 4-bit value and the
   s_message_ID is a 28-bit value; the s_message_ID has the same
   semantics as the IKEv2 message ID except for the smaller size.  The
   s_message_ID starts at zero (or a suitable constant) every time the
   client switches to a new gateway.

   The initiator and the responder initialize the GSC to zero at the
   time of establishment of the IKE SA.  In case of stateless failover,
   the responder includes the GSC in the IKEv2_Ticket.  The initiator
   increments the GSC and uses GSC||s_message_ID as the IKEv2 message_ID
   in theIKE_SESSION_RESUME exchange.  The responder uses the same
   message ID in the response.  When a failover or switch to another
   gateway occurs, this count is incremented.  Note that the GSC is
   incremented even if the client has visited the "new" gateway in the
   past under the protection of the same IKE SA.  Continuing with the
   case of stateless failover, the responder includes the new GSC in the
   new ticket and includes the new ticket along with the
   IKE_SESSION_RESUME response message.  If the initiator never receives
   the response, it may use the same GSC in a future IKE_SESSION_RESUME
   exchange with the same or a different gateway.

   In case of stateful failover, the responder maintains the GSC value
   independent of the initiator and thus the initiator must increment
   the GSC for use with every fresh IKE_SESSION_RESUME request message.
   Note that the responder increments its local value of the GSC as soon
   as it responds with an IKE_SESSION_RESUME response message and
   updates the SA state of the client with the new GSC value.  A new
   gateway MUST only accept an IKE_SESSION_RESUME request message, if
   the GSC value in the message ID is greater than the GSC value present
   as part of the state.

   The presence of the GSC provides replay protection across gateways
   without per packet state updates.  The IKE_SA MUST be re-keyed before
   the GSC overflows.  The IKE_SA MUST also be re-keyed before the 28-
   bit sequence number overflows, as required by [4].  This re-keying,
   however, may be done off the critical path, instead of at the time of
   failover.

4.2.3.  Processing IKE_SESSION_RESUME messages

   IKE_SESSION_RESUME messages are treated much like IKE_SA_INIT
   messages in that the first step in processing them is not looking up
   the SA.  In case of IKE_SA_INIT, the responder processes the entire
   message and sends a response either by challenging the initiator to
   prove liveness or by sending the IKE_SA_INIT response message.  In



Dondeti & Narayanan      Expires August 29, 2007               [Page 16]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   case of IKE_SESSION_RESUME message case, the first step is to process
   the message partially, provisionally revive the old SA to verify the
   session resumption request and process the rest of the message; the
   result of the processing, assuming everything is in order, is to
   install an IKE SA and one or more IPsec SAs at both ends.

   The responder follows the steps below in processing an
   IKE_SESSION_RESUME request message:

   o  When an IKEv2 entity receives a message of exchange type
      'IKE_SESSION_RESUME' it first verifies the consistency of the
      message.  The Initiator's SPI must be non-NULL; the Responder's
      SPI can be ignored.  The GSC must be greater than 1.  The message
      must have either an N payload or the IKEv2_Ticket payload followed
      by an SK payload.

   o  The next step is to recover the SA to be reestablished.  If the
      received message contains an IKEv2_Ticket payload, the receiver
      validates the ticket.  It uses the TGS-SPI of the ticket to lookup
      the SA that protects the ticket.  It then verifies the integrity
      of the ticket.  It then verifies that the ticket is fresh and not
      invalidated by policy.  The next step is to verify whether the
      received session resumption request itself is fresh: the received
      GSC must be greater than the GSC within the ticket.

   o  If the received message contains a Notify payload, the SPIs within
      the payload are used to lookup the SA that protects the received
      session resumption request message.  The responder retrieves the
      SA from the SA store.  It then verifies that the received GSC is
      greater than the local GSC.

   o  After replay verification, the next step is to verify the
      integrity of the session resumption request message itself.  If
      the integrity checksum is valid, the purported sender of the
      message in fact has access to the IKE SA corresponding to the SPI
      in the N payload or the IKE SA contained in the IKEv2_Ticket.

   o  The responder then proceeds to process the rest of the
      IKE_SESSION_RESUME just as it would process a CREATE_CHILD_SA
      request message.  It first decrypts the SK payload.  The first
      encrypted payload is not an N payload (if it is, the responder
      returns an error message to the initiator) and so the message is
      treated as a request to create a new IPsec SA.

   o

   In response to a session resumption request message, the responder
   sends a message that is quite similar to a CREATE_CHILD_SA response



Dondeti & Narayanan      Expires August 29, 2007               [Page 17]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   message.  There are some subtle differences between the
   CREATE_CHILD_SA response and an IKE_SESSION_RESUME response message.

   The IKE_SESSION_RESUME response message is composed as follows: the
   responder picks an SPI and includes it in the Responder's SPI field
   of the IKEv2 header.  The message ID is the same as the message ID in
   the request message.  In case of stateless failover the responder
   creates a new IKEv2_ticket and includes the current GSC in the
   ticket.  The new ticket is included within the SK as one of the
   encrypted payloads.  Encryption of the new ticket prevents an
   attacker from attempting to present the ticket to another gateway
   before the client has had a chance to use it.


5.  Message Types and Formats

5.1.  IKEv2 Header with Gateway Switch Count


                              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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                       IKE_SA Initiator's SPI                  !
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                       IKE_SA Responder's SPI                  !
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !GSC|                  S-Message ID (28 bits)                   !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                            Length                             !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 8: IKEv2 Header with GSC

   GSC - This 4-bit field indicates the Gateway Switch Count.  It is
   initialized to zero when the IKE_SA is created and incremented by one
   every time a CREATE_CHILD_SA failover request message is sent by an
   IKE peer.

   S-Message ID - This is a 28-bit field that has the same semantics as
   the message ID field of the IKEv2 header.






Dondeti & Narayanan      Expires August 29, 2007               [Page 18]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


5.2.  SESSION_RESUMPTION_SUPPORTED Notify Message Type

   The SESSION_RESUMPTION_SUPPORTED Notify message type may be present
   in a Notify payload and indicates the support for failover at an IKE
   peer.  The Notify Message Type value is IANA-TBD.  The Notification
   Data contains an 8 bit flags field, the format of which is defined
   below.


        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |S|L| Reserved  |
       +-+-+-+-+-+-+-+-+



         Figure 9: SESSION_RESUMPTION_SUPPORTED Notification Data

   The S (CLIENT_SIDE_STORAGE_SUPPORTED) flag is set by the IKE peer to
   indicate support for stateless failover operation.  The gateway MUST
   NOT set this flag if it does not also include a STATE_TICKET Notify
   payload in the response message. [***NOTE: Are we allowing not
   supporting the GSC?  If so, we need to include the GW ID in the
   exchange and also defined how it is used in the IDr payload]

   The L(CLIENT_REQUEST_GW_LIST) flag is set by the IKE peer to indicate
   a message that requests or contains the list of gateways.

5.3.  Other Payload Specifications

   TBD.


6.  Security Considerations

   IKEv2 establishes an IKE SA and an IPsec SA in a 4 (or 6 message)
   base exchange.  The number of messages can be larger than that if EAP
   is used for client authentication.  The goal of this document is to
   specify a fast session resumption protocol.  The session resumption
   protocol enables an IPsec client to quickly resume the use of the IKE
   SA and establish a new IPsec SA with the original gateway (after it
   fails and recovers) or another gateway within a secure domain.

   If the new gateway is in perfect synchrony with the old gateway, the
   only thing that changes is the IP address of one of the parties to
   the IKE exchange.  A protocol similar to MOBIKE may be used to signal
   the change in the IP address of one of the end points of the session.
   Perfect synchronization is impractical and thus there is a need to



Dondeti & Narayanan      Expires August 29, 2007               [Page 19]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   design an IKEv2 session resumption protocol.

   It is plausible that the new gateway obtains the SA state from within
   the secure domain, either from the old gateway or from another entity
   to which the old gateway has sent the SA state.  It is also plausible
   for the old gateway to send the state to the client itself so it can
   present the state to the new gateway.

   There are several components to the solution: we need to define a
   secure domain, identify the security properties required for session
   resumption capability negotiation, identify the security properties
   required for SA storage or ticket creation, distribution and use, and
   finally identify the requirements of a session resumption protocol.
   Replay protection for the IKE SA as it is used across gateways is a
   crucial component of the ticket use and session resumption protocol.

6.1.  Properties of the Secure Domain

   A secure domain consists of a pool of gateways that are able to
   resume SAs created by any gateway belonging to the same domain.  It
   is not necessary for any two gateways to share the same IP address or
   have the same view of the network.

   All the gateways in the secure domain must share a security
   association for state storage and retrieval purposes.  Such a
   security association must provide confidentiality, integrity and
   replay protection for the state stored or retrieved.  The gateways
   may share a group SA or each gateway in the secure domain may share
   an individual SA with a central entity.  In the case of stateful
   session resumption, the central entity may act as the SA store.  In
   the case of stateless session resumption, such a central SA manager
   will imply that the tickets are protected with an SA known only to
   the central entity and each gateway needs to contact the central
   entity to encrypt or decrypt the contents of the tickets.

6.2.  Properties of Capability Negotiation

   The failover solution described here relies on a capability exchange
   occurring as part of the initial IKEv2 exchange.  The capability for
   failover support may be indicated by the initiator as part of the
   IKE_INIT or IKE_AUTH exchange and the failover support and any
   corresponding information (such as list of gateways or state) is
   included by the gateway as part of the IKE_AUTH exchange.  The
   capability negotiation is authenticated as part of the mutual
   authentication processes during the IKE_AUTH exchange or is integrity
   protected by the MAC in the SK payload.

   Further, if the responder includes a ticket containing the session



Dondeti & Narayanan      Expires August 29, 2007               [Page 20]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   state, that ticket is encrypted and integrity protected in a self-
   contained manner.  This is so that upon session resumption, the
   gateway can verify the validity of the ticket.  The SA used to
   encrypt and integrity protect the ticket depends on the type of SAs
   used in the secure domain, as described in Section 6.1.

6.3.  Properties of SA Ticket Creation, Distribution and Use

   For the purpose of stateless session resumption, the gateway may
   distribute a ticket containing the SA state to the client.  Any
   gateway in the secure domain may then allow the client to resume the
   IKE session upon successful processing of the ticket and installation
   of the SA.  There are some security properties to consider in such
   ticket creation and distribution.

   The ticket must contain information that will allow the gateway
   resuming the session to determine the validity of the ticket based on
   the lifetime policies of the secure domain.  The ticket itself may
   also contain information necessary to determine its lifetime that is
   allowed by the issuing gateway.  This will prevent a ticket from
   being indefinitely used.

   All the contents of the ticket, except the SPI that indicates the SA
   to be used, must be encrypted and a MAC must be generated on the
   encrypted data.  This prevents an eavesdropper from obtaining the
   contents of the ticket.

   In addition to the confidentiality of the ticket contents itself,
   ticket revocation is an issue that cannot be easily addressed without
   some gateway side state.  If a ticket needs to be revoked and the
   client needs to be denied access, the gateways in the secure domain
   must contain some state or must be able to obtain the necessary
   information from a trusted source elsewhere.  This will allow the
   infrastructure to reject resumption of a session after a client has
   been revoked access.

   Every time the SA state is updated or the client attaches to a new
   gateway, it receives a new ticket which is supposed to be used for
   subsequent session resumption.  However, there is no way the gateways
   in the secure domain can ensure that the client always presents the
   latest ticket, unless some state on the ticket itself is maintained
   in the secure domain.  While such state will be significantly less
   than storing the entire SA, that still somewhat negates the goal of
   remaining stateless.

   Hence, if the infrastructure is completely stateless on the tickets,
   it is feasible for the client to re-use old tickets.  For the client
   itself, there is typically no incentive in using an older ticket, as



Dondeti & Narayanan      Expires August 29, 2007               [Page 21]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   opposed to a newer one and hence, it is less of a problem.  However,
   the possibility of ticket re-use leads to possible message replays.
   An attacker would be able to capture an IKE_SESSION_RESUME request
   message and replay it at a later time.  Since the ticket contains an
   older value of the Gateway Switch Count (GSC), the message will be
   accepted by the gateway, as long as the lifetime of the ticket is
   still valid.  While this would result in the IKE SA being installed
   on the gateway, it will result in a new IPsec SA being created, which
   will not be available to the attacker.  Hence, replay of IPsec
   packets is not feasible in this case.  Hence, the worst impact of
   message replays with old tickets is the installation of the IKE_SA at
   the gateway and creation of a new IPsec SA.  It should be noted that
   if that gateway happens to be still serving the client to which the
   ticket actually belongs, it will most likely lead to re-installation
   of the same IKE SA or rejection of the replayed IKE_SESSION_RESUME
   since a different IKE SA for the same client is already present.
   Hence, ticket re-use is not a serious problem, although it could
   result in consumption of unnecessary resources at the gateway.

   If an attacker replayed a message with a ticket and successfully
   created state at the gateway and the client attempted to re-connect
   to that gateway, its request may be rejected by the gateway.  Hence,
   depending on the timing of the replay, it is feasible to cause a DoS
   attack on the legitimate client.

6.4.  Properties of the Session Resumption Protocol

   This document defines an IKE_SESSION_RESUME exchange to allow
   resumption of an already established IKE SA.  The security properties
   of this exchange are largely similar to that of the
   IKE_CREATE_CHILD_SA exchange.  The only difference is that before the
   creation of the IPsec SA, the recipient processing session resume
   request message first needs to provisionally install the IKE SA
   corresponding to the request.  This IKE SA may be retrieved from the
   SA store or from the ticket presented by the client.  The gateway
   must first install this SA and verify the validity of the
   IKE_SESSION_RESUME Request message.  If the session resume request
   message is valid, the installed SA is kept; otherwise it is deleted
   and any related state updates are rolled back.  When the validity
   check succeeds, the processing of the rest of the message and
   creation of the IPsec SA is analogous to processing an
   IKE_CREATE_CHILD_SA message.


7.  IANA Considerations

   This document specifies a new IKEv2 exchange type and several notify
   payload types.  Detailed instructions to IANA will be provided when



Dondeti & Narayanan      Expires August 29, 2007               [Page 22]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   the protocol specification becomes more stable.


8.  Acknowledgments

   Thanks to Paul Hoffman for his valuable input to discussions on the
   design of this protocol.


9.  Normative References

   [1]  Narayanan, V., "IPsec Gateway Failover and Redundancy - Problem
        Statement and Goals", draft-vidya-ipsec-failover-ps-00 (work in
        progress), December 2006.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", RFC 4301, December 2005.

   [4]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
        December 2005.

   [5]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
        RFC 4555, June 2006.


Authors' Addresses

   Lakshminath Dondeti
   QUALCOMM, Inc.
   5775 Morehouse Dr
   San Diego, CA
   USA

   Phone: +1 858-845-1267
   Email: ldondeti@qualcomm.com













Dondeti & Narayanan      Expires August 29, 2007               [Page 23]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


   Vidya Narayanan
   QUALCOMM, Inc.
   5775 Morehouse Dr
   San Diego, CA
   USA

   Phone: +1 858-845-2483
   Email: vidyan@qualcomm.com











































Dondeti & Narayanan      Expires August 29, 2007               [Page 24]

Internet-Draft     IPsec Failover Redundancy Solution      February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Dondeti & Narayanan      Expires August 29, 2007               [Page 25]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/