aboutsummaryrefslogtreecommitdiffstats
path: root/doc/standards/draft-sheffer-ipsec-failover-03.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/standards/draft-sheffer-ipsec-failover-03.txt')
-rw-r--r--doc/standards/draft-sheffer-ipsec-failover-03.txt1401
1 files changed, 1401 insertions, 0 deletions
diff --git a/doc/standards/draft-sheffer-ipsec-failover-03.txt b/doc/standards/draft-sheffer-ipsec-failover-03.txt
new file mode 100644
index 000000000..e624a95cd
--- /dev/null
+++ b/doc/standards/draft-sheffer-ipsec-failover-03.txt
@@ -0,0 +1,1401 @@
+
+
+
+Network Working Group Y. Sheffer
+Internet-Draft Check Point
+Intended status: Experimental H. Tschofenig
+Expires: September 20, 2008 Nokia Siemens Networks
+ L. Dondeti
+ V. Narayanan
+ QUALCOMM, Inc.
+ March 19, 2008
+
+
+ IPsec Gateway Failover Protocol
+ draft-sheffer-ipsec-failover-03.txt
+
+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 September 20, 2008.
+
+Abstract
+
+ The Internet Key Exchange version 2 (IKEv2) protocol has
+ computational and communication overhead with respect to the number
+ of round-trips required and cryptographic operations involved. In
+ remote access situations, the Extensible Authentication Protocol is
+ used for authentication, which adds several more round trips and
+ therefore latency.
+
+ To re-establish security associations (SA) upon a failure recovery
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 1]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ condition is time consuming, especially when an IPsec peer, such as a
+ VPN gateway, needs to re-establish a large number of SAs with various
+ end points. A high number of concurrent sessions might cause
+ additional problems for an IPsec peer during SA re-establishment.
+
+ In many failure cases it would be useful to provide an efficient way
+ to resume an interrupted IKE/IPsec session. This document proposes
+ an extension to IKEv2 that allows a client to re-establish an IKE SA
+ with a gateway in a highly efficient manner, utilizing a previously
+ established IKE SA.
+
+ A client can reconnect to a gateway from which it was disconnected,
+ or alternatively migrate to another gateway that is associated with
+ the previous one. The proposed approach conveys IKEv2 state
+ information, in the form of an encrypted ticket, to a VPN client that
+ is later presented to the VPN gateway for re-authentication. The
+ encrypted ticket can only be decrypted by the VPN gateway in order to
+ restore state for faster session setup.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 2]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. Recovering from a Remote Access Gateway Failover . . . . . 6
+ 3.2. Recovering from an Application Server Failover . . . . . . 8
+ 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 9
+ 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10
+ 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 12
+ 4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 12
+ 4.2.3. Requesting a ticket during resumption . . . . . . . . 13
+ 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 13
+ 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 14
+ 4.5. TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14
+ 4.6. Processing Guidelines for IKE SA Establishment . . . . . . 15
+ 5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 16
+ 5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
+ 5.4. Exchange of Ticket-Protecting Keys . . . . . . . . . . . . 18
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18
+ 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19
+ 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 19
+ 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 19
+ 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19
+ 7.6. Alternate Ticket Formats and Distribution Schemes . . . . 20
+ 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 20
+ 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 20
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
+ Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 22
+ Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
+ B.1. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ B.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
+ Intellectual Property and Copyright Statements . . . . . . . . . . 25
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 3]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+1. Introduction
+
+ The Internet Key Exchange version 2 (IKEv2) protocol has
+ computational and communication overhead with respect to the number
+ of round-trips required and cryptographic operations involved. In
+ particular the Extensible Authentication Protocol is used for
+ authentication in remote access cases, which increases latency.
+
+ To re-establish security associations (SA) upon a failure recovery
+ condition is time-consuming, especially when an IPsec peer, such as a
+ VPN gateway, needs to re-establish a large number of SAs with various
+ end points. A high number of concurrent sessions might cause
+ additional problems for an IPsec peer.
+
+ In many failure cases it would be useful to provide an efficient way
+ to resume an interrupted IKE/IPsec session. This document proposes
+ an extension to IKEv2 that allows a client to re-establish an IKE SA
+ with a gateway in a highly efficient manner, utilizing a previously
+ established IKE SA.
+
+ A client can reconnect to a gateway from which it was disconnected,
+ or alternatively migrate to another gateway that is associated with
+ the previous one. This document proposes to maintain IKEv2 state in
+ a "ticket", an opaque data structure created and used by a server and
+ stored by a client, which the client cannot understand or tamper
+ with. The IKEv2 protocol is extended to allow a client to request
+ and present a ticket. When two gateways mutually trust each other,
+ one can accept a ticket generated by the other.
+
+ This approach is similar to the one taken by TLS session resumption
+ [RFC4507] with the required adaptations for IKEv2, e.g., to
+ accommodate the two-phase protocol structure. We have borrowed
+ heavily from that specification.
+
+1.1. Goals
+
+ The high-level goal of this extension is to provide an IPsec failover
+ solution, according to the requirements defined in
+ [I-D.vidya-ipsec-failover-ps].
+
+ Specifically, the proposed extension should allow IPsec sessions to
+ be recovered from failures in remote access scenarios, in a more
+ efficient manner than the basic IKE solution. This efficiency is
+ primarily on the gateway side, since the gateway might have to deal
+ with many thousands of concurrent requests. We should enable the
+ following cases:
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 4]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ o Failover from one gateway to another, where the two gateways do
+ not share state but do have mutual trust. For example, the
+ gateways may be operated by the same provider and share the same
+ keying materials to access an encrypted ticket.
+ o Recovery from an intermittent connectivity, where clients
+ reconnect into the same gateway. In this case, the gateway would
+ typically have detected the clients' absence and removed the state
+ associated with them.
+ o Recovery from a gateway restart, where clients reconnect into the
+ same gateway.
+
+ The proposed solution should additionally meet the following goals:
+
+ o Using only symmetric cryptography to minimize CPU consumption.
+ o Allowing a gateway to push state to clients.
+ o Providing cryptographic agility.
+ o Having no negative impact on IKEv2 security features.
+
+1.2. Non-Goals
+
+ The following are non-goals of this solution:
+ o Providing load balancing among gateways.
+ o Specifying how a client detects the need for a failover.
+
+
+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 [RFC2119].
+
+ This document uses terminology defined in [RFC4301], [RFC4306], and
+ [RFC4555]. In addition, this document uses the following terms:
+
+ Secure domain: A secure domain comprises a set of gateways that are
+ able to resume an IKEv2 session that may have been established by
+ any other gateway within the domain. All gateways in the secure
+ domain are expected to share some secrets, so that they can
+ generate an IKEv2 ticket, verify the validity of the ticket and
+ 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.
+
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 5]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ Stateless failover: When the IKEv2 session state is stored at the
+ client, the IKEv2 responder 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 [RFC4306], where the IPsec tunnel mode is
+ used 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 focuses on the usage of transport (or tunnel)
+ mode to secure the communicate between two end points (e.g., two
+ servers). 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 6]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ (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 end-host (an entity with a host implementation
+ of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a
+ gateway in a remote network using IKEv2. The end-host 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 support the assignment of a new IP
+ address.
+
+ The protocol defined in this document supports the re-allocation of
+ an IP address to the client, if this capability is provided by the
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 7]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ network. For example, if routing tables are modified so that traffic
+ is rerouted through the new gateway. This capability is implicit in
+ the use of the IKE Config mechanism, which allows the client to
+ present its existing IP address and receive the same address back, if
+ allowed by the gateway.
+
+ The protocol defined here supports both stateful and stateless
+ scenarios. In other words, tickets can be stored wholly on the
+ client, or the ticket can be stored on the gateway (or in a database
+ shared between multiple gateways), with the client only presenting a
+ handle that identifies a particular ticket. In fact these scenarios
+ are transparent to the protocols, with the only change being the non-
+ mandatory ticket format.
+
+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 [RFC4306]. 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,
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 8]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ 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
+ 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, assign a new address.
+
+
+4. Protocol Details
+
+ This section provides protocol details and contains the normative
+ parts. This document defines two protocol exchanges, namely
+ requesting a ticket and presenting a ticket. Section 4.1 describes
+ the procedure to request a ticket and Section 4.2 illustrates how to
+ present a ticket.
+
+4.1. Requesting a Ticket
+
+ A client MAY request a ticket in the following exchanges:
+
+ o In an IKE_AUTH exchange, as shown in the example message exchange
+ in Figure 3 below.
+ o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed.
+ o In an Informational exchange, if the gateway previously replied
+ with an N(TICKET_ACK) instead of providing a ticket.
+ o In an Informational exchange, when the ticket lifetime is about to
+ expire.
+ o In an IKE_SESSION_RESUME exchange, see Section 4.2.3.
+
+ Normally, a client requests a ticket in the third message of an IKEv2
+ exchange (the first of IKE_AUTH). Figure 3 shows the message
+ exchange for this typical case.
+
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 9]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ Initiator Responder
+ ----------- -----------
+ HDR, SAi1, KEi, Ni -->
+
+ <-- HDR, SAr1, KEr, Nr, [CERTREQ]
+
+ HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
+ AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
+
+ Figure 3: Example Message Exchange for Requesting a Ticket
+
+ The notification payloads are described in Section 4.3. The above is
+ an example, and IKEv2 allows a number of variants on these messages.
+ A complete description of IKEv2 can be found in [RFC4718].
+
+ When an IKEv2 responder receives a request for a ticket using the
+ N(TICKET_REQUEST) payload it MUST perform one of the following
+ operations if it supports the extension defined in this document:
+ o it creates a ticket and returns it with the N(TICKET_OPAQUE)
+ payload in a subsequent message towards the IKEv2 initiator. This
+ is shown in Figure 4.
+ o it returns an N(TICKET_NACK) payload, if it refuses to grant a
+ ticket for some reason.
+ o it returns an N(TICKET_ACK), if it cannot grant a ticket
+ immediately, e.g., due to packet size limitations. In this case
+ the client MAY request a ticket later using an Informational
+ exchange, at any time during the lifetime of the IKE SA.
+
+ Provided the IKEv2 exchange was successful, the IKEv2 initiator can
+ accept the requested ticket. The ticket may be used later with an
+ IKEv2 responder which supports this extension. Figure 4 shows how
+ the initiator receives the ticket.
+
+
+
+ Initiator Responder
+ ----------- -----------
+ <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
+ TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]}
+
+
+ Figure 4: Receiving a Ticket
+
+4.2. Presenting a Ticket
+
+ Following a communication failure, a client re-initiates an IKE
+ exchange to the same gateway or to a different one, and includes a
+ ticket in the first message. A client MAY initiate a regular (non-
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 10]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ ticket-based) IKEv2 exchange even if it is in possession of a valid
+ ticket. A client MUST NOT present a ticket after the ticket's
+ lifetime has expired.
+
+ It is up to the client's local policy to decide when the
+ communication with the IKEv2 responder is seen as interrupted and a
+ new exchange needs to be initiated and the session resumption
+ procedure to be initiated.
+
+ Tickets are intended for one-time use: a client MUST NOT reuse a
+ ticket, either with the same or with a different gateway. A gateway
+ SHOULD reject a reused ticket. Note however that a gateway can elect
+ not to retain a list of already-used tickets. Potential replay
+ attacks on such gateways are mitigated by the cookie mechanism
+ described in Section 4.2.2.
+
+ This document specifies a new IKEv2 exchange type called
+ IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is
+ somewhat similar to the IKE_AUTH exchange, and results in the
+ creation of a Child SA. The client SHOULD NOT use this exchange type
+ unless it knows that the gateway supports it, either through
+ configuration, by out-of-band means or by using the Gateway List
+ provision.
+
+
+
+ Initiator Responder
+ ----------- -----------
+ HDR, Ni, N(TICKET_OPAQUE), [N+,]
+ SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
+
+ The exchange type in HDR is set to 'IKE_SESSION_RESUME'.
+
+ See Section 4.2.1 for details on computing the protected (SK)
+ payload.
+
+ When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
+ payload it MUST perform one of the following steps if it supports the
+ extension defined in this document:
+ o If it is willing to accept the ticket, it responds as shown in
+ Figure 5.
+ o It responds with an unprotected N(TICKET_NACK) notification, if it
+ rejects the ticket for any reason. In that case, the initiator
+ should re-initiate a regular IKE exchange. One such case is when
+ the responder receives a ticket for an IKE SA that has previously
+ been terminated on the responder itself, which may indicate
+ inconsistent state between the IKEv2 initiator and the responder.
+ However, a responder is not required to maintain the state for
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 11]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ terminated sessions.
+ o When the responder receives a ticket for an IKE SA that is still
+ active and if the responder accepts it, then the old SAs SHOULD be
+ silently deleted without sending a DELETE informational exchange.
+
+
+
+ Initiator Responder
+ ----------- -----------
+ <-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr],
+ [CP(CFG_REPLY)]}
+
+ Figure 5: IKEv2 Responder accepts the ticket
+
+ Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'.
+
+ The SK payload is protected using the cryptographic parameters
+ derived from the ticket, see Section 4.2.1 below.
+
+ At this point a new IKE SA is created by both parties, see
+ Section 4.6. This is followed by normal derivation of a child SA,
+ per Sec. 2.17 of [RFC4306].
+
+4.2.1. Protection of the IKE_SESSION_RESUME Exchange
+
+ The two messages of this exchange are protected by a "subset" IKE SA.
+ The key material is derived from the ticket, as follows:
+
+
+ {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni)
+
+ where SK_d_old is the SK_d value of the original IKE SA, as retrieved
+ from the ticket. Ni guarantees freshness of the key material. SK_d2
+ is used later to derive the new IKE SA, see Section 4.6.
+
+ See [RFC4306] for the notation. "prf" is determined from the SA value
+ in the ticket.
+
+4.2.2. Presenting a Ticket: The DoS Case
+
+ When receiving the first message of the IKE_SESSION_RESUME exchange,
+ the gateway may decide that it is under a denial-of-service attack.
+ In such a case, the gateway SHOULD defer the establishment of session
+ state until it has verified the identity of the client. We use a
+ variation of the IKEv2 Cookie mechanism, where the cookie is
+ protected.
+
+ In the two messages that follow, the gateway responds that it is
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 12]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ unwilling to resume the session until the client is verified, and the
+ client resubmits its first message, this time with the cookie:
+
+
+
+ Initiator Responder
+ ----------- -----------
+ <-- HDR, SK{N(COOKIE)}
+HDR, Ni, N(TICKET_OPAQUE), [N+,]
+ SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
+
+ Assuming the cookie is correct, the gateway now replies normally.
+
+ This now becomes a 4-message exchange. The entire exchange is
+ protected as defined in Section 4.2.1.
+
+ See Sec. 2.6 and Sec. 3.10.1 of [RFC4306] for more guidance regarding
+ the usage and syntax of the cookie. Note that the cookie is
+ completely independent of the IKEv2 ticket.
+
+4.2.3. Requesting a ticket during resumption
+
+ When resuming a session, a client will typically request a new ticket
+ immediately, so it is able to resume the session again in the case of
+ a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE)
+ and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as
+ protected payloads to the IKE_SESSION_RESUME exchange.
+
+ The returned ticket (if any) will correspond to the IKE SA created
+ per the rules described in Section 4.6.
+
+4.3. IKE Notifications
+
+ This document defines a number of notifications. The notification
+ numbers are TBA by IANA.
+
+ +---------------------+--------+-----------------+
+ | Notification Name | Number | Data |
+ +---------------------+--------+-----------------+
+ | TICKET_OPAQUE | TBA1 | See Section 4.4 |
+ | TICKET_REQUEST | TBA2 | None |
+ | TICKET_ACK | TBA3 | None |
+ | TICKET_NACK | TBA4 | None |
+ | TICKET_GATEWAY_LIST | TBA5 | See Section 4.5 |
+ +---------------------+--------+-----------------+
+
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 13]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+4.4. TICKET_OPAQUE Notify Payload
+
+ The data for the TICKET_OPAQUE Notify payload consists of the Notify
+ message header, a lifetime field and the ticket itself. The four
+ octet lifetime field contains the number of seconds until the ticket
+ expires as an unsigned integer. Section 5.2 describes a possible
+ ticket format, and Section 5.3 offers further guidelines regarding
+ the ticket's lifetime.
+
+
+ 0 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 ! SPI Size = 0 ! Notify Message Type !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Lifetime !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! !
+ ~ Ticket ~
+ ! !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Figure 6: TICKET_OPAQUE Notify Payload
+
+4.5. TICKET_GATEWAY_LIST Notify Payload
+
+ The TICKET_GATEWAY_LIST Notify payload contains the Notify payload
+ header followed by a sequence of one or more gateway identifiers,
+ each of the format depicted in Figure 8.
+
+
+ 0 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 ! SPI Size = 0 ! Notify Message Type !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! !
+ ~ Gateway Identifier List ~
+ ! !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Figure 7: TICKET_GATEWAY_LIST Notify Payload
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 14]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ 0 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! ID Type ! Reserved ! Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! !
+ ~ Identification Data ~
+ ! !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Figure 8: Gateway Identifier for One Gateway
+
+ ID Type:
+
+ The ID Type contains a restricted set of the IKEv2 ID payloads
+ (see [RFC4306], Section 3.5). Allowed ID types are: ID_IPV4_ADDR,
+ ID_IPV6_ADDR, ID_FQDN and the various reserved values.
+
+ Reserved:
+
+ This field must be sent as 0 and must be ignored when received.
+
+ Length:
+
+ The length field indicates the total size of the Identification
+ data.
+
+ Identification Data:
+
+ The Identification Data field is of variable length and depends on
+ the ID type. The length is not necessarily a multiple of 4.
+
+4.6. Processing Guidelines for IKE SA Establishment
+
+ When a ticket is presented, the gateway parses the ticket to retrieve
+ the state of the old IKE SA, and the client retrieves this state from
+ its local store. Both peers now create state for the new IKE SA as
+ follows:
+
+ o The SA value (transforms etc.) is taken directly from the ticket.
+ o The sequence numbers are reset to 0.
+ o The IDi value is obtained from the ticket.
+ o The IDr value is obtained from the new exchange. The gateway MAY
+ make policy decisions based on the IDr value encoded in the
+ ticket.
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 15]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ o The SPI values are created anew, similarly to a regular IKE
+ exchange. SPI values from the ticket SHOULD NOT be reused. This
+ restriction is to avoid problems caused by collisions with other
+ SPI values used already by the initiator/responder. The SPI value
+ should only be reused if collision avoidance can be ensured
+ through other means.
+
+ The cryptographic material is refreshed based on the ticket and the
+ nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED
+ value is derived as follows:
+
+
+ SKEYSEED = prf(SK_d2, Ni | Nr)
+
+ where SK_d2 was computed earlier (Section 4.2.1).
+
+ The keys are derived as follows, unchanged from IKEv2:
+
+
+ {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
+ prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
+
+ where SPIi, SPIr are the SPI values created in the new IKE exchange.
+
+ See [RFC4306] for the notation. "prf" is determined from the SA value
+ in the ticket.
+
+
+5. The IKE Ticket
+
+ This section lists the required contents of the ticket, and
+ recommends a non-normative format. This is followed by a discussion
+ of the ticket's lifecycle.
+
+5.1. Ticket Contents
+
+ The ticket MUST encode at least the following state from an IKE SA.
+ These values MUST be encrypted and authenticated.
+
+ o IDi, IDr.
+ o SPIi, SPIr.
+ o SAr (the accepted proposal).
+ o SK_d.
+
+ In addition, the ticket MUST encode a protected ticket expiration
+ value.
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 16]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+5.2. Ticket Format
+
+ This document does not specify a mandatory-to-implement or a
+ mandatory-to-use ticket format. The following format is RECOMMENDED,
+ if interoperability between gateways is desired.
+
+
+ struct {
+ [authenticated] struct {
+ octet format_version; // 1 for this version of the protocol
+ octet reserved[3]; // sent as 0, ignored by receiver.
+ octet key_id[8]; // arbitrary byte string
+ opaque IV[0..255]; // actual length (possibly 0) depends
+ // on the encryption algorithm
+
+ [encrypted] struct {
+ opaque IDi, IDr; // the full payloads
+ octet SPIi[8], SPIr[8];
+ opaque SA; // the full SAr payload
+ octet SK_d[0..255]; // actual length depends on SA value
+ int32 expiration; // an absolute time value, seconds
+ // since Jan. 1, 1970
+ } ikev2_state;
+ } protected_part;
+ opaque MAC[0..255]; // the length (possibly 0) depends
+ // on the integrity algorithm
+ } ticket;
+
+ Note that the key defined by "key_id" determines the encryption and
+ authentication algorithms used for this ticket. Those algorithms are
+ unrelated to the transforms defined by the SA payload.
+
+ The reader is referred to a recent draft
+ [I-D.rescorla-stateless-tokens] that recommends a similar (but not
+ identical) ticket format, and discusses related security
+ considerations in depth.
+
+5.3. Ticket Identity and Lifecycle
+
+ Each ticket is associated with a single IKE SA. In particular, when
+ an IKE SA is deleted, the client MUST delete its stored ticket.
+
+ A ticket is therefore associated with the tuple (IDi, IDr). The
+ client MAY however use a ticket to approach other gateways that are
+ willing to accept it. How a client discovers such gateways is
+ outside the scope of this document.
+
+ The lifetime of the ticket carried in the N(TICKET_OPAQUE)
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 17]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ notification should be the minimum of the IKE SA lifetime (per the
+ gateway's local policy) and its re-authentication time, according to
+ [RFC4478]. Even if neither of these are enforced by the gateway, a
+ finite lifetime MUST be specified for the ticket.
+
+5.4. Exchange of Ticket-Protecting Keys
+
+ This document does not define an interoperable mechanism for the
+ generation and distribution of the keys that protect IKE keys. Such
+ a mechanism can be developed, based on the GDOI group key exchange
+ protocol [RFC3547]. There is on-going work to enable the generation
+ of non-IPsec keys by means of GDOI, e.g. to provide RSVP router
+ groups with a single key [I-D.weis-gdoi-for-rsvp]. This work can be
+ generalized for our purposes. We note that there are no significant
+ performance requirements on such a protocol, as key rollover can be
+ at a daily or even more leisurely rate.
+
+
+6. IANA Considerations
+
+ This document requires a number of IKEv2 notification status types in
+ Section 4.3, to be registered by IANA. The corresponding registry
+ was established by IANA.
+
+ The document defines a new IKEv2 exchange in Section 4.2. The
+ corresponding registry was established by IANA.
+
+
+7. Security Considerations
+
+ This section addresses security issues related to the usage of a
+ ticket.
+
+7.1. Stolen Tickets
+
+ An eavesdropper or man-in-the-middle may try to obtain a ticket and
+ use it to establish a session with the IKEv2 responder. This can
+ happen in different ways: by eavesdropping on the initial
+ communication and copying the ticket when it is granted and before it
+ is used, or by listening in on a client's use of the ticket to resume
+ a session. However, since the ticket's contents is encrypted and the
+ attacker does not know the corresponding secret key (specifically,
+ SK_d), a stolen ticket cannot be used by an attacker to resume a
+ session. An IKEv2 responder MUST use strong encryption and integrity
+ protection of the ticket to prevent an attacker from obtaining the
+ ticket's contents, e.g., by using a brute force attack.
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 18]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+7.2. Forged Tickets
+
+ A malicious user could forge or alter a ticket in order to resume a
+ session, to extend its lifetime, to impersonate as another user, or
+ to gain additional privileges. This attack is not possible if the
+ ticket is protected using a strong integrity protection algorithm.
+
+7.3. Denial of Service Attacks
+
+ The key_id field defined in the recommended ticket format helps the
+ server efficiently reject tickets that it did not issue. However, an
+ adversary could generate and send a large number of tickets to a
+ gateway for verification. To minimize the possibility of such denial
+ of service, ticket verification should be lightweight (e.g., using
+ efficient symmetric key cryptographic algorithms).
+
+7.4. Ticket Protection Key Management
+
+ A full description of the management of the keys used to protect the
+ ticket is beyond the scope of this document. A list of RECOMMENDED
+ practices is given below.
+ o The keys should be generated securely following the randomness
+ recommendations in [RFC4086].
+ o The keys and cryptographic protection algorithms should be at
+ least 128 bits in strength.
+ o The keys should not be used for any other purpose than generating
+ and verifying tickets.
+ o The keys should be changed regularly.
+ o The keys should be changed if the ticket format or cryptographic
+ protection algorithms change.
+
+7.5. Ticket Lifetime
+
+ An IKEv2 responder controls the lifetime of a ticket, based on the
+ operational and security requirements of the environment in which it
+ is deployed. The responder provides information about the ticket
+ lifetime to the IKEv2 initiator, allowing it to manage its tickets.
+
+ An IKEv2 client may present a ticket in its possession to a gateway,
+ even if the IKE SA associated with this ticket had previously been
+ terminated by another gateway (the gateway that originally provided
+ the ticket). Where such usage is against the local security policy,
+ an Invalid Ticket List (ITL) may be used, see
+ [I-D.rescorla-stateless-tokens]. Management of such lists is outside
+ the scope of the current document. Note that a policy that requires
+ tickets to have shorter lifetimes (e.g., 1 hour) significantly
+ mitigates this risk.
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 19]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+7.6. Alternate Ticket Formats and Distribution Schemes
+
+ If the ticket format or distribution scheme defined in this document
+ is not used, then great care must be taken in analyzing the security
+ of the solution. In particular, if confidential information, such as
+ a secret key, is transferred to the client, it MUST be done using
+ secure communication to prevent attackers from obtaining or modifying
+ the key. Also, the ticket MUST have its integrity and
+ confidentiality protected with strong cryptographic techniques to
+ prevent a breach in the security of the system.
+
+7.7. Identity Privacy, Anonymity, and Unlinkability
+
+ This document mandates that the content of the ticket MUST be
+ encrypted in order to avoid leakage of information, such as the
+ identities of an IKEv2 initiator and a responder. Thus, it prevents
+ the disclosure of potentially sensitive information carried within
+ the ticket.
+
+ When an IKEv2 initiator presents the ticket as part of the
+ IKE_SESSION_RESUME exchange, confidentiality is not provided for the
+ exchange. Although the ticket itself is encrypted there might still
+ be a possibility for an on-path adversary to observe multiple
+ exchange handshakes where the same ticket is used and therefore to
+ conclude that they belong to the same communication end points.
+ Administrators that use the ticket mechanism described in this
+ document should be aware that unlinkability may not be provided by
+ this mechanism. Note, however, that IKEv2 does not provide active
+ user identity confidentiality for the IKEv2 initiator either.
+
+7.8. Replay Protection in the IKE_SESSION_RESUME Exchange
+
+ A major design goal of this protocol extension has been the two-
+ message exchange for session resumption. There is a tradeoff between
+ this abbreviated exchange and replay protection. It is RECOMMENDED
+ that the gateway should cache tickets, and reject replayed ones.
+ However some gateways may not do that in order to reduce state size.
+ In addition, an adversary may replay a ticket last presented to
+ gateway A, into gateway B. Our cookie-based mechanism (Section 4.2.2)
+ mitigates both scenarios by ensuring that the client presenting the
+ ticket is indeed its "owner": the client can be required by the
+ gateway to prove that it knows the ticket's secret, before any state
+ is committed on the gateway. Note that this is a stronger guarantee
+ than the regular IKE cookie mechanism, which only proves IP return
+ routability of the client. This is enabled by including the cookie
+ in the protected portion of the message.
+
+ For performance reasons, the cookie mechanism is optional, and
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 20]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ invoked by the gateway only when it suspects that it is the subject
+ of a denial-of-service attack.
+
+ In any case, a ticket replayed by an adversary only causes partial
+ IKE state to be created on the gateway. The IKE exchange cannot be
+ completed and an IKE SA cannot be created unless the client knows the
+ ticket's secret values.
+
+
+8. Acknowledgements
+
+ We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
+ Yoav Nir and Tero Kivinen for their many helpful comments.
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+ RFC 4306, December 2005.
+
+9.2. Informative References
+
+ [I-D.friedman-ike-short-term-certs]
+ Friedman, A., "Short-Term Certificates",
+ draft-friedman-ike-short-term-certs-02 (work in progress),
+ June 2007.
+
+ [I-D.rescorla-stateless-tokens]
+ Rescorla, E., "How to Implement Secure (Mostly) Stateless
+ Tokens", draft-rescorla-stateless-tokens-01 (work in
+ progress), March 2007.
+
+ [I-D.vidya-ipsec-failover-ps]
+ Narayanan, V., "IPsec Gateway Failover and Redundancy -
+ Problem Statement and Goals",
+ draft-vidya-ipsec-failover-ps-02 (work in progress),
+ December 2007.
+
+ [I-D.weis-gdoi-for-rsvp]
+ Weis, B., "Group Domain of Interpretation (GDOI) support
+ for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress),
+ February 2008.
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 21]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
+ Group Domain of Interpretation", RFC 3547, July 2003.
+
+ [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
+ (IKEv2) Protocol", RFC 4478, April 2006.
+
+ [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
+ "Transport Layer Security (TLS) Session Resumption without
+ Server-Side State", RFC 4507, May 2006.
+
+ [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
+ (MOBIKE)", RFC 4555, June 2006.
+
+ [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
+ Implementation Guidelines", RFC 4718, October 2006.
+
+
+Appendix A. Related Work
+
+ [I-D.friedman-ike-short-term-certs] is on-going work that discusses
+ the use of short-term certificates for client re-authentication. It
+ is similar to the ticket approach described in this document in that
+ they both require enhancements to IKEv2 to allow information request,
+ e.g., for a certificate or a ticket. However, the changes required
+ by the former are fewer since an obtained certificate is valid for
+ any IKE responder that is able to verify them. On the other hand,
+ short-term certificates, while eliminating the usability issues of
+ user re-authentication, do not reduce the amount of effort performed
+ by the gateway in failover situations.
+
+
+Appendix B. Change Log
+
+B.1. -03
+
+ Removed counter mechanism. Added an optional anti-DoS mechanism,
+ based on IKEv2 cookies (removed previous discussion of cookies).
+ Clarified that gateways may support reallocation of same IP address,
+ if provided by network. Proposed a solution outline to the problem
+ of key exchange for the keys that protect tickets. Added fields to
+ the ticket to enable interoperability. Removed incorrect MOBIKE
+ notification.
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 22]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+B.2. -02
+
+ Clarifications on generation of SPI values, on the ticket's lifetime
+ and on the integrity protection of the anti-replay counter.
+ Eliminated redundant SPIs from the notification payloads.
+
+B.3. -01
+
+ Editorial review. Removed 24-hour limitation on ticket lifetime,
+ lifetime is up to local policy.
+
+B.4. -00
+
+ Initial version. This draft is a selective merge of
+ draft-sheffer-ike-session-resumption-00 and
+ draft-dondeti-ipsec-failover-sol-00.
+
+
+Authors' Addresses
+
+ Yaron Sheffer
+ Check Point Software Technologies Ltd.
+ 5 Hasolelim St.
+ Tel Aviv 67897
+ Israel
+
+ Email: yaronf@checkpoint.com
+
+
+ Hannes Tschofenig
+ Nokia Siemens Networks
+ Otto-Hahn-Ring 6
+ Munich, Bavaria 81739
+ Germany
+
+ Email: Hannes.Tschofenig@nsn.com
+ URI: http://www.tschofenig.priv.at
+
+
+ Lakshminath Dondeti
+ QUALCOMM, Inc.
+ 5775 Morehouse Dr
+ San Diego, CA
+ USA
+
+ Phone: +1 858-845-1267
+ Email: ldondeti@qualcomm.com
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 23]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+ Vidya Narayanan
+ QUALCOMM, Inc.
+ 5775 Morehouse Dr
+ San Diego, CA
+ USA
+
+ Phone: +1 858-845-2483
+ Email: vidyan@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 24]
+
+Internet-Draft IPsec Gateway Failover Protocol March 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Sheffer, et al. Expires September 20, 2008 [Page 25]
+
+
generated by cgit v1.2.3 (git 2.25.1) at 2025-09-14 06:40:20 +0000