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]