child-sa: Don't update outbound policies if they are not installed
[strongswan.git] / doc / standards / draft-sheffer-ipsec-failover-03.txt
1
2
3
4 Network Working Group                                         Y. Sheffer
5 Internet-Draft                                               Check Point
6 Intended status: Experimental                              H. Tschofenig
7 Expires: September 20, 2008                       Nokia Siemens Networks
8                                                               L. Dondeti
9                                                             V. Narayanan
10                                                           QUALCOMM, Inc.
11                                                           March 19, 2008
12
13
14                     IPsec Gateway Failover Protocol
15                   draft-sheffer-ipsec-failover-03.txt
16
17 Status of this Memo
18
19    By submitting this Internet-Draft, each author represents that any
20    applicable patent or other IPR claims of which he or she is aware
21    have been or will be disclosed, and any of which he or she becomes
22    aware will be disclosed, in accordance with Section 6 of BCP 79.
23
24    Internet-Drafts are working documents of the Internet Engineering
25    Task Force (IETF), its areas, and its working groups.  Note that
26    other groups may also distribute working documents as Internet-
27    Drafts.
28
29    Internet-Drafts are draft documents valid for a maximum of six months
30    and may be updated, replaced, or obsoleted by other documents at any
31    time.  It is inappropriate to use Internet-Drafts as reference
32    material or to cite them other than as "work in progress."
33
34    The list of current Internet-Drafts can be accessed at
35    http://www.ietf.org/ietf/1id-abstracts.txt.
36
37    The list of Internet-Draft Shadow Directories can be accessed at
38    http://www.ietf.org/shadow.html.
39
40    This Internet-Draft will expire on September 20, 2008.
41
42 Abstract
43
44    The Internet Key Exchange version 2 (IKEv2) protocol has
45    computational and communication overhead with respect to the number
46    of round-trips required and cryptographic operations involved.  In
47    remote access situations, the Extensible Authentication Protocol is
48    used for authentication, which adds several more round trips and
49    therefore latency.
50
51    To re-establish security associations (SA) upon a failure recovery
52
53
54
55 Sheffer, et al.        Expires September 20, 2008               [Page 1]
56 \f
57 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
58
59
60    condition is time consuming, especially when an IPsec peer, such as a
61    VPN gateway, needs to re-establish a large number of SAs with various
62    end points.  A high number of concurrent sessions might cause
63    additional problems for an IPsec peer during SA re-establishment.
64
65    In many failure cases it would be useful to provide an efficient way
66    to resume an interrupted IKE/IPsec session.  This document proposes
67    an extension to IKEv2 that allows a client to re-establish an IKE SA
68    with a gateway in a highly efficient manner, utilizing a previously
69    established IKE SA.
70
71    A client can reconnect to a gateway from which it was disconnected,
72    or alternatively migrate to another gateway that is associated with
73    the previous one.  The proposed approach conveys IKEv2 state
74    information, in the form of an encrypted ticket, to a VPN client that
75    is later presented to the VPN gateway for re-authentication.  The
76    encrypted ticket can only be decrypted by the VPN gateway in order to
77    restore state for faster session setup.
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111 Sheffer, et al.        Expires September 20, 2008               [Page 2]
112 \f
113 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
114
115
116 Table of Contents
117
118    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119      1.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
120      1.2.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . .  5
121    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
122    3.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  6
123      3.1.  Recovering from a Remote Access Gateway Failover . . . . .  6
124      3.2.  Recovering from an Application Server Failover . . . . . .  8
125    4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  9
126      4.1.  Requesting a Ticket  . . . . . . . . . . . . . . . . . . .  9
127      4.2.  Presenting a Ticket  . . . . . . . . . . . . . . . . . . . 10
128        4.2.1.  Protection of the IKE_SESSION_RESUME Exchange  . . . . 12
129        4.2.2.  Presenting a Ticket: The DoS Case  . . . . . . . . . . 12
130        4.2.3.  Requesting a ticket during resumption  . . . . . . . . 13
131      4.3.  IKE Notifications  . . . . . . . . . . . . . . . . . . . . 13
132      4.4.  TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 14
133      4.5.  TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14
134      4.6.  Processing Guidelines for IKE SA Establishment . . . . . . 15
135    5.  The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16
136      5.1.  Ticket Contents  . . . . . . . . . . . . . . . . . . . . . 16
137      5.2.  Ticket Format  . . . . . . . . . . . . . . . . . . . . . . 17
138      5.3.  Ticket Identity and Lifecycle  . . . . . . . . . . . . . . 17
139      5.4.  Exchange of Ticket-Protecting Keys . . . . . . . . . . . . 18
140    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
141    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
142      7.1.  Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18
143      7.2.  Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19
144      7.3.  Denial of Service Attacks  . . . . . . . . . . . . . . . . 19
145      7.4.  Ticket Protection Key Management . . . . . . . . . . . . . 19
146      7.5.  Ticket Lifetime  . . . . . . . . . . . . . . . . . . . . . 19
147      7.6.  Alternate Ticket Formats and Distribution Schemes  . . . . 20
148      7.7.  Identity Privacy, Anonymity, and Unlinkability . . . . . . 20
149      7.8.  Replay Protection in the IKE_SESSION_RESUME Exchange . . . 20
150    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
151    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
152      9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
153      9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
154    Appendix A.  Related Work  . . . . . . . . . . . . . . . . . . . . 22
155    Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 22
156      B.1.  -03  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
157      B.2.  -02  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
158      B.3.  -01  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
159      B.4.  -00  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
160    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
161    Intellectual Property and Copyright Statements . . . . . . . . . . 25
162
163
164
165
166
167 Sheffer, et al.        Expires September 20, 2008               [Page 3]
168 \f
169 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
170
171
172 1.  Introduction
173
174    The Internet Key Exchange version 2 (IKEv2) protocol has
175    computational and communication overhead with respect to the number
176    of round-trips required and cryptographic operations involved.  In
177    particular the Extensible Authentication Protocol is used for
178    authentication in remote access cases, which increases latency.
179
180    To re-establish security associations (SA) upon a failure recovery
181    condition is time-consuming, especially when an IPsec peer, such as a
182    VPN gateway, needs to re-establish a large number of SAs with various
183    end points.  A high number of concurrent sessions might cause
184    additional problems for an IPsec peer.
185
186    In many failure cases it would be useful to provide an efficient way
187    to resume an interrupted IKE/IPsec session.  This document proposes
188    an extension to IKEv2 that allows a client to re-establish an IKE SA
189    with a gateway in a highly efficient manner, utilizing a previously
190    established IKE SA.
191
192    A client can reconnect to a gateway from which it was disconnected,
193    or alternatively migrate to another gateway that is associated with
194    the previous one.  This document proposes to maintain IKEv2 state in
195    a "ticket", an opaque data structure created and used by a server and
196    stored by a client, which the client cannot understand or tamper
197    with.  The IKEv2 protocol is extended to allow a client to request
198    and present a ticket.  When two gateways mutually trust each other,
199    one can accept a ticket generated by the other.
200
201    This approach is similar to the one taken by TLS session resumption
202    [RFC4507] with the required adaptations for IKEv2, e.g., to
203    accommodate the two-phase protocol structure.  We have borrowed
204    heavily from that specification.
205
206 1.1.  Goals
207
208    The high-level goal of this extension is to provide an IPsec failover
209    solution, according to the requirements defined in
210    [I-D.vidya-ipsec-failover-ps].
211
212    Specifically, the proposed extension should allow IPsec sessions to
213    be recovered from failures in remote access scenarios, in a more
214    efficient manner than the basic IKE solution.  This efficiency is
215    primarily on the gateway side, since the gateway might have to deal
216    with many thousands of concurrent requests.  We should enable the
217    following cases:
218
219
220
221
222
223 Sheffer, et al.        Expires September 20, 2008               [Page 4]
224 \f
225 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
226
227
228    o  Failover from one gateway to another, where the two gateways do
229       not share state but do have mutual trust.  For example, the
230       gateways may be operated by the same provider and share the same
231       keying materials to access an encrypted ticket.
232    o  Recovery from an intermittent connectivity, where clients
233       reconnect into the same gateway.  In this case, the gateway would
234       typically have detected the clients' absence and removed the state
235       associated with them.
236    o  Recovery from a gateway restart, where clients reconnect into the
237       same gateway.
238
239    The proposed solution should additionally meet the following goals:
240
241    o  Using only symmetric cryptography to minimize CPU consumption.
242    o  Allowing a gateway to push state to clients.
243    o  Providing cryptographic agility.
244    o  Having no negative impact on IKEv2 security features.
245
246 1.2.  Non-Goals
247
248    The following are non-goals of this solution:
249    o  Providing load balancing among gateways.
250    o  Specifying how a client detects the need for a failover.
251
252
253 2.  Terminology
254
255    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
256    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
257    document are to be interpreted as described in [RFC2119].
258
259    This document uses terminology defined in [RFC4301], [RFC4306], and
260    [RFC4555].  In addition, this document uses the following terms:
261
262    Secure domain:  A secure domain comprises a set of gateways that are
263       able to resume an IKEv2 session that may have been established by
264       any other gateway within the domain.  All gateways in the secure
265       domain are expected to share some secrets, so that they can
266       generate an IKEv2 ticket, verify the validity of the ticket and
267       extract the IKEv2 policy and session key material from the ticket.
268    IKEv2 ticket:  An IKEv2 ticket is a data structure that contains all
269       the necessary information that allows any gateway within the same
270       secure domain as the gateway that created the ticket to verify the
271       validity of the ticket and extract IKEv2 policy and session keys
272       to re-establish an IKEv2 session.
273
274
275
276
277
278
279 Sheffer, et al.        Expires September 20, 2008               [Page 5]
280 \f
281 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
282
283
284    Stateless failover:  When the IKEv2 session state is stored at the
285       client, the IKEv2 responder is "stateless" until the client
286       restores the SA with one of the gateways within the secure domain;
287       thus, we refer to SA resumption with SA storage at the client as
288       stateless session resumption.
289    Stateful failover:  When the infrastructure maintains IKEv2 session
290       state, we refer to the process of IKEv2 SA re-establishment as
291       stateful session resumption.
292
293
294 3.  Usage Scenarios
295
296    This specification envisions two usage scenarios for efficient IKEv2
297    and IPsec SA session re-establishment.
298
299    The first is similar to the use case specified in Section 1.1.3 of
300    the IKEv2 specification [RFC4306], where the IPsec tunnel mode is
301    used to establish a secure channel between a remote access client and
302    a gateway; the traffic flow may be between the client and entities
303    beyond the gateway.
304
305    The second use case focuses on the usage of transport (or tunnel)
306    mode to secure the communicate between two end points (e.g., two
307    servers).  The two endpoints have a client-server relationship with
308    respect to a protocol that runs using the protections afforded by the
309    IPsec SA.
310
311 3.1.  Recovering from a Remote Access Gateway Failover
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335 Sheffer, et al.        Expires September 20, 2008               [Page 6]
336 \f
337 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
338
339
340     (a)
341
342     +-+-+-+-+-+                          +-+-+-+-+-+
343     !         !      IKEv2/IKEv2-EAP     !         !     Protected
344     ! Remote  !<------------------------>! Remote  !     Subnet
345     ! Access  !                          ! Access  !<--- and/or
346     ! Client  !<------------------------>! Gateway !     Internet
347     !         !      IPsec tunnel        !         !
348     +-+-+-+-+-+                          +-+-+-+-+-+
349
350
351     (b)
352
353     +-+-+-+-+-+                          +-+-+-+-+-+
354     !         !    IKE_SESSION_RESUME    !         !
355     ! Remote  !<------------------------>! New/Old !
356     ! Access  !                          ! Gateway !
357     ! Client  !<------------------------>!         !
358     !         !      IPsec tunnel        !         !
359     +-+-+-+-+-+                          +-+-+-+-+-+
360
361
362
363                   Figure 1: Remote Access Gateway Failure
364
365    In this scenario, an end-host (an entity with a host implementation
366    of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a
367    gateway in a remote network using IKEv2.  The end-host in this
368    scenario is sometimes referred to as a remote access client.  When
369    the remote gateway fails, all the clients associated with the gateway
370    either need to re-establish IKEv2 sessions with another gateway
371    within the same secure domain of the original gateway, or with the
372    original gateway if the server is back online soon.
373
374    The clients may choose to establish IPsec SAs using a full IKEv2
375    exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1).
376
377    In this scenario, the client needs to get an IP address from the
378    remote network so that traffic can be encapsulated by the remote
379    access gateway before reaching the client.  In the initial exchange,
380    the gateway may acquire IP addresses from the address pool of a local
381    DHCP server.  The new gateway that a client gets associated may not
382    receive addresses from the same address pool.  Thus, the session
383    resumption protocol needs to support the assignment of a new IP
384    address.
385
386    The protocol defined in this document supports the re-allocation of
387    an IP address to the client, if this capability is provided by the
388
389
390
391 Sheffer, et al.        Expires September 20, 2008               [Page 7]
392 \f
393 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
394
395
396    network.  For example, if routing tables are modified so that traffic
397    is rerouted through the new gateway.  This capability is implicit in
398    the use of the IKE Config mechanism, which allows the client to
399    present its existing IP address and receive the same address back, if
400    allowed by the gateway.
401
402    The protocol defined here supports both stateful and stateless
403    scenarios.  In other words, tickets can be stored wholly on the
404    client, or the ticket can be stored on the gateway (or in a database
405    shared between multiple gateways), with the client only presenting a
406    handle that identifies a particular ticket.  In fact these scenarios
407    are transparent to the protocols, with the only change being the non-
408    mandatory ticket format.
409
410 3.2.  Recovering from an Application Server Failover
411
412
413      (a)
414
415     +-+-+-+-+-+                          +-+-+-+-+-+
416     !   App.  !      IKEv2/IKEv2-EAP     !   App.  !
417     !  Client !<------------------------>!  Server !
418     !    &    !                          !    &    !
419     !  IPsec  !<------------------------>!  IPsec  !
420     !   host  !  IPsec transport/        !   host  !
421     +-+-+-+-+-+        tunnel mode SA    +-+-+-+-+-+
422
423
424     (b)
425
426     +-+-+-+-+-+                          +-+-+-+-+-+
427     !   App.  !    IKE_SESSION_RESUME    !   New   !
428     !  Client !<------------------------>!  Server !
429     !    &    !                          !    &    !
430     !  IPsec  !<------------------------>!  IPsec  !
431     !   host  !  IPsec transport/        !   host  !
432     +-+-+-+-+-+        tunnel mode SA    +-+-+-+-+-+
433
434
435                    Figure 2: Application Server Failover
436
437    The second usage scenario is as follows: two entities with IPsec host
438    implementations establish an IPsec transport or tunnel mode SA
439    between themselves; this is similar to the model described in Section
440    1.1.2. of [RFC4306].  At the application level, one of the entities
441    is always the client and the other is a server.  From that view
442    point, the IKEv2 exchange is always initiated by the client.  This
443    allows the Initiator (the client) to authenticate itself using EAP,
444
445
446
447 Sheffer, et al.        Expires September 20, 2008               [Page 8]
448 \f
449 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
450
451
452    as long as the Responder (or the application server) allows it.
453
454    If the application server fails, the client may find other servers
455    within the same secure domain for service continuity.  It may use a
456    full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re-
457    establish the IPsec SAs for secure communication required by the
458    application layer signaling.
459
460    The client-server relationship at the application layer ensures that
461    one of the entities in this usage scenario is unambiguously always
462    the Initiator and the other the Responder.  This role determination
463    also allows the Initiator to request an address in the Responder's
464    network using the Configuration Payload mechanism of the IKEv2
465    protocol.  If the client has thus received an address during the
466    initial IKEv2 exchange, when it associates with a new server upon
467    failure of the original server, it needs to request an address,
468    specifying its assigned address.  The server may allow the client to
469    use the original address or if it is not permitted to use that
470    address, assign a new address.
471
472
473 4.  Protocol Details
474
475    This section provides protocol details and contains the normative
476    parts.  This document defines two protocol exchanges, namely
477    requesting a ticket and presenting a ticket.  Section 4.1 describes
478    the procedure to request a ticket and Section 4.2 illustrates how to
479    present a ticket.
480
481 4.1.  Requesting a Ticket
482
483    A client MAY request a ticket in the following exchanges:
484
485    o  In an IKE_AUTH exchange, as shown in the example message exchange
486       in Figure 3 below.
487    o  In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed.
488    o  In an Informational exchange, if the gateway previously replied
489       with an N(TICKET_ACK) instead of providing a ticket.
490    o  In an Informational exchange, when the ticket lifetime is about to
491       expire.
492    o  In an IKE_SESSION_RESUME exchange, see Section 4.2.3.
493
494    Normally, a client requests a ticket in the third message of an IKEv2
495    exchange (the first of IKE_AUTH).  Figure 3 shows the message
496    exchange for this typical case.
497
498
499
500
501
502
503 Sheffer, et al.        Expires September 20, 2008               [Page 9]
504 \f
505 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
506
507
508      Initiator                Responder
509      -----------              -----------
510     HDR, SAi1, KEi, Ni  -->
511
512                         <--    HDR, SAr1, KEr, Nr, [CERTREQ]
513
514     HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
515     AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)}     -->
516
517         Figure 3: Example Message Exchange for Requesting a Ticket
518
519    The notification payloads are described in Section 4.3.  The above is
520    an example, and IKEv2 allows a number of variants on these messages.
521    A complete description of IKEv2 can be found in [RFC4718].
522
523    When an IKEv2 responder receives a request for a ticket using the
524    N(TICKET_REQUEST) payload it MUST perform one of the following
525    operations if it supports the extension defined in this document:
526    o  it creates a ticket and returns it with the N(TICKET_OPAQUE)
527       payload in a subsequent message towards the IKEv2 initiator.  This
528       is shown in Figure 4.
529    o  it returns an N(TICKET_NACK) payload, if it refuses to grant a
530       ticket for some reason.
531    o  it returns an N(TICKET_ACK), if it cannot grant a ticket
532       immediately, e.g., due to packet size limitations.  In this case
533       the client MAY request a ticket later using an Informational
534       exchange, at any time during the lifetime of the IKE SA.
535
536    Provided the IKEv2 exchange was successful, the IKEv2 initiator can
537    accept the requested ticket.  The ticket may be used later with an
538    IKEv2 responder which supports this extension.  Figure 4 shows how
539    the initiator receives the ticket.
540
541
542
543      Initiator                Responder
544      -----------              -----------
545             <--    HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
546                         TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]}
547
548
549                        Figure 4: Receiving a Ticket
550
551 4.2.  Presenting a Ticket
552
553    Following a communication failure, a client re-initiates an IKE
554    exchange to the same gateway or to a different one, and includes a
555    ticket in the first message.  A client MAY initiate a regular (non-
556
557
558
559 Sheffer, et al.        Expires September 20, 2008              [Page 10]
560 \f
561 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
562
563
564    ticket-based) IKEv2 exchange even if it is in possession of a valid
565    ticket.  A client MUST NOT present a ticket after the ticket's
566    lifetime has expired.
567
568    It is up to the client's local policy to decide when the
569    communication with the IKEv2 responder is seen as interrupted and a
570    new exchange needs to be initiated and the session resumption
571    procedure to be initiated.
572
573    Tickets are intended for one-time use: a client MUST NOT reuse a
574    ticket, either with the same or with a different gateway.  A gateway
575    SHOULD reject a reused ticket.  Note however that a gateway can elect
576    not to retain a list of already-used tickets.  Potential replay
577    attacks on such gateways are mitigated by the cookie mechanism
578    described in Section 4.2.2.
579
580    This document specifies a new IKEv2 exchange type called
581    IKE_SESSION_RESUME whose value is TBA by IANA.  This exchange is
582    somewhat similar to the IKE_AUTH exchange, and results in the
583    creation of a Child SA.  The client SHOULD NOT use this exchange type
584    unless it knows that the gateway supports it, either through
585    configuration, by out-of-band means or by using the Gateway List
586    provision.
587
588
589
590     Initiator                Responder
591     -----------              -----------
592     HDR, Ni, N(TICKET_OPAQUE), [N+,]
593          SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
594
595    The exchange type in HDR is set to 'IKE_SESSION_RESUME'.
596
597    See Section 4.2.1 for details on computing the protected (SK)
598    payload.
599
600    When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
601    payload it MUST perform one of the following steps if it supports the
602    extension defined in this document:
603    o  If it is willing to accept the ticket, it responds as shown in
604       Figure 5.
605    o  It responds with an unprotected N(TICKET_NACK) notification, if it
606       rejects the ticket for any reason.  In that case, the initiator
607       should re-initiate a regular IKE exchange.  One such case is when
608       the responder receives a ticket for an IKE SA that has previously
609       been terminated on the responder itself, which may indicate
610       inconsistent state between the IKEv2 initiator and the responder.
611       However, a responder is not required to maintain the state for
612
613
614
615 Sheffer, et al.        Expires September 20, 2008              [Page 11]
616 \f
617 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
618
619
620       terminated sessions.
621    o  When the responder receives a ticket for an IKE SA that is still
622       active and if the responder accepts it, then the old SAs SHOULD be
623       silently deleted without sending a DELETE informational exchange.
624
625
626
627     Initiator                Responder
628     -----------              -----------
629                     <--  HDR, SK {IDr, Nr, SAr2, [TSi, TSr],
630                          [CP(CFG_REPLY)]}
631
632                Figure 5: IKEv2 Responder accepts the ticket
633
634    Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'.
635
636    The SK payload is protected using the cryptographic parameters
637    derived from the ticket, see Section 4.2.1 below.
638
639    At this point a new IKE SA is created by both parties, see
640    Section 4.6.  This is followed by normal derivation of a child SA,
641    per Sec. 2.17 of [RFC4306].
642
643 4.2.1.  Protection of the IKE_SESSION_RESUME Exchange
644
645    The two messages of this exchange are protected by a "subset" IKE SA.
646    The key material is derived from the ticket, as follows:
647
648
649         {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni)
650
651    where SK_d_old is the SK_d value of the original IKE SA, as retrieved
652    from the ticket.  Ni guarantees freshness of the key material.  SK_d2
653    is used later to derive the new IKE SA, see Section 4.6.
654
655    See [RFC4306] for the notation. "prf" is determined from the SA value
656    in the ticket.
657
658 4.2.2.  Presenting a Ticket: The DoS Case
659
660    When receiving the first message of the IKE_SESSION_RESUME exchange,
661    the gateway may decide that it is under a denial-of-service attack.
662    In such a case, the gateway SHOULD defer the establishment of session
663    state until it has verified the identity of the client.  We use a
664    variation of the IKEv2 Cookie mechanism, where the cookie is
665    protected.
666
667    In the two messages that follow, the gateway responds that it is
668
669
670
671 Sheffer, et al.        Expires September 20, 2008              [Page 12]
672 \f
673 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
674
675
676    unwilling to resume the session until the client is verified, and the
677    client resubmits its first message, this time with the cookie:
678
679
680
681  Initiator                Responder
682  -----------              -----------
683                  <-- HDR, SK{N(COOKIE)}
684 HDR, Ni, N(TICKET_OPAQUE), [N+,]
685       SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
686
687    Assuming the cookie is correct, the gateway now replies normally.
688
689    This now becomes a 4-message exchange.  The entire exchange is
690    protected as defined in Section 4.2.1.
691
692    See Sec. 2.6 and Sec. 3.10.1 of [RFC4306] for more guidance regarding
693    the usage and syntax of the cookie.  Note that the cookie is
694    completely independent of the IKEv2 ticket.
695
696 4.2.3.  Requesting a ticket during resumption
697
698    When resuming a session, a client will typically request a new ticket
699    immediately, so it is able to resume the session again in the case of
700    a second failure.  Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE)
701    and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as
702    protected payloads to the IKE_SESSION_RESUME exchange.
703
704    The returned ticket (if any) will correspond to the IKE SA created
705    per the rules described in Section 4.6.
706
707 4.3.  IKE Notifications
708
709    This document defines a number of notifications.  The notification
710    numbers are TBA by IANA.
711
712             +---------------------+--------+-----------------+
713             | Notification Name   | Number | Data            |
714             +---------------------+--------+-----------------+
715             | TICKET_OPAQUE       | TBA1   | See Section 4.4 |
716             | TICKET_REQUEST      | TBA2   | None            |
717             | TICKET_ACK          | TBA3   | None            |
718             | TICKET_NACK         | TBA4   | None            |
719             | TICKET_GATEWAY_LIST | TBA5   | See Section 4.5 |
720             +---------------------+--------+-----------------+
721
722
723
724
725
726
727 Sheffer, et al.        Expires September 20, 2008              [Page 13]
728 \f
729 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
730
731
732 4.4.  TICKET_OPAQUE Notify Payload
733
734    The data for the TICKET_OPAQUE Notify payload consists of the Notify
735    message header, a lifetime field and the ticket itself.  The four
736    octet lifetime field contains the number of seconds until the ticket
737    expires as an unsigned integer.  Section 5.2 describes a possible
738    ticket format, and Section 5.3 offers further guidelines regarding
739    the ticket's lifetime.
740
741
742         0                     1                   2                   3
743         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
744        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
745        ! Next Payload  !C!  Reserved   !      Payload Length           !
746        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
747        ! Protocol ID   ! SPI Size = 0  !    Notify Message Type        !
748        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
749        !                       Lifetime                                !
750        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
751        !                                                               !
752        ~                        Ticket                                 ~
753        !                                                               !
754        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
755
756
757                   Figure 6: TICKET_OPAQUE Notify Payload
758
759 4.5.  TICKET_GATEWAY_LIST Notify Payload
760
761    The TICKET_GATEWAY_LIST Notify payload contains the Notify payload
762    header followed by a sequence of one or more gateway identifiers,
763    each of the format depicted in Figure 8.
764
765
766         0                     1                   2                   3
767         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
768        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
769        ! Next Payload  !C!  Reserved   !      Payload Length           !
770        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
771        ! Protocol ID   ! SPI Size = 0  !    Notify Message Type        !
772        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
773        !                                                               !
774        ~                   Gateway Identifier List                     ~
775        !                                                               !
776        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
777
778
779                Figure 7: TICKET_GATEWAY_LIST Notify Payload
780
781
782
783 Sheffer, et al.        Expires September 20, 2008              [Page 14]
784 \f
785 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
786
787
788         0                     1                   2                   3
789         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
790        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
791        !    ID Type    !   Reserved    !             Length            !
792        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
793        !                                                               !
794        ~                     Identification Data                       ~
795        !                                                               !
796        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
797
798
799                Figure 8: Gateway Identifier for One Gateway
800
801    ID Type:
802
803       The ID Type contains a restricted set of the IKEv2 ID payloads
804       (see [RFC4306], Section 3.5).  Allowed ID types are: ID_IPV4_ADDR,
805       ID_IPV6_ADDR, ID_FQDN and the various reserved values.
806
807    Reserved:
808
809       This field must be sent as 0 and must be ignored when received.
810
811    Length:
812
813       The length field indicates the total size of the Identification
814       data.
815
816    Identification Data:
817
818       The Identification Data field is of variable length and depends on
819       the ID type.  The length is not necessarily a multiple of 4.
820
821 4.6.  Processing Guidelines for IKE SA Establishment
822
823    When a ticket is presented, the gateway parses the ticket to retrieve
824    the state of the old IKE SA, and the client retrieves this state from
825    its local store.  Both peers now create state for the new IKE SA as
826    follows:
827
828    o  The SA value (transforms etc.) is taken directly from the ticket.
829    o  The sequence numbers are reset to 0.
830    o  The IDi value is obtained from the ticket.
831    o  The IDr value is obtained from the new exchange.  The gateway MAY
832       make policy decisions based on the IDr value encoded in the
833       ticket.
834
835
836
837
838
839 Sheffer, et al.        Expires September 20, 2008              [Page 15]
840 \f
841 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
842
843
844    o  The SPI values are created anew, similarly to a regular IKE
845       exchange.  SPI values from the ticket SHOULD NOT be reused.  This
846       restriction is to avoid problems caused by collisions with other
847       SPI values used already by the initiator/responder.  The SPI value
848       should only be reused if collision avoidance can be ensured
849       through other means.
850
851    The cryptographic material is refreshed based on the ticket and the
852    nonce values, Ni, and Nr, from the current exchange.  A new SKEYSEED
853    value is derived as follows:
854
855
856         SKEYSEED = prf(SK_d2, Ni | Nr)
857
858    where SK_d2 was computed earlier (Section 4.2.1).
859
860    The keys are derived as follows, unchanged from IKEv2:
861
862
863        {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
864                                    prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
865
866    where SPIi, SPIr are the SPI values created in the new IKE exchange.
867
868    See [RFC4306] for the notation. "prf" is determined from the SA value
869    in the ticket.
870
871
872 5.  The IKE Ticket
873
874    This section lists the required contents of the ticket, and
875    recommends a non-normative format.  This is followed by a discussion
876    of the ticket's lifecycle.
877
878 5.1.  Ticket Contents
879
880    The ticket MUST encode at least the following state from an IKE SA.
881    These values MUST be encrypted and authenticated.
882
883    o  IDi, IDr.
884    o  SPIi, SPIr.
885    o  SAr (the accepted proposal).
886    o  SK_d.
887
888    In addition, the ticket MUST encode a protected ticket expiration
889    value.
890
891
892
893
894
895 Sheffer, et al.        Expires September 20, 2008              [Page 16]
896 \f
897 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
898
899
900 5.2.  Ticket Format
901
902    This document does not specify a mandatory-to-implement or a
903    mandatory-to-use ticket format.  The following format is RECOMMENDED,
904    if interoperability between gateways is desired.
905
906
907   struct {
908       [authenticated] struct {
909           octet format_version;    // 1 for this version of the protocol
910           octet reserved[3];       // sent as 0, ignored by receiver.
911           octet key_id[8];         // arbitrary byte string
912           opaque IV[0..255];       // actual length (possibly 0) depends
913                                    // on the encryption algorithm
914
915           [encrypted] struct {
916               opaque IDi, IDr;     // the full payloads
917               octet SPIi[8], SPIr[8];
918               opaque SA;           // the full SAr payload
919               octet SK_d[0..255];  // actual length depends on SA value
920               int32 expiration;    // an absolute time value, seconds
921                                    // since Jan. 1, 1970
922           } ikev2_state;
923       } protected_part;
924       opaque MAC[0..255];          // the length (possibly 0) depends
925                                    // on the integrity algorithm
926   } ticket;
927
928    Note that the key defined by "key_id" determines the encryption and
929    authentication algorithms used for this ticket.  Those algorithms are
930    unrelated to the transforms defined by the SA payload.
931
932    The reader is referred to a recent draft
933    [I-D.rescorla-stateless-tokens] that recommends a similar (but not
934    identical) ticket format, and discusses related security
935    considerations in depth.
936
937 5.3.  Ticket Identity and Lifecycle
938
939    Each ticket is associated with a single IKE SA.  In particular, when
940    an IKE SA is deleted, the client MUST delete its stored ticket.
941
942    A ticket is therefore associated with the tuple (IDi, IDr).  The
943    client MAY however use a ticket to approach other gateways that are
944    willing to accept it.  How a client discovers such gateways is
945    outside the scope of this document.
946
947    The lifetime of the ticket carried in the N(TICKET_OPAQUE)
948
949
950
951 Sheffer, et al.        Expires September 20, 2008              [Page 17]
952 \f
953 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
954
955
956    notification should be the minimum of the IKE SA lifetime (per the
957    gateway's local policy) and its re-authentication time, according to
958    [RFC4478].  Even if neither of these are enforced by the gateway, a
959    finite lifetime MUST be specified for the ticket.
960
961 5.4.  Exchange of Ticket-Protecting Keys
962
963    This document does not define an interoperable mechanism for the
964    generation and distribution of the keys that protect IKE keys.  Such
965    a mechanism can be developed, based on the GDOI group key exchange
966    protocol [RFC3547].  There is on-going work to enable the generation
967    of non-IPsec keys by means of GDOI, e.g. to provide RSVP router
968    groups with a single key [I-D.weis-gdoi-for-rsvp].  This work can be
969    generalized for our purposes.  We note that there are no significant
970    performance requirements on such a protocol, as key rollover can be
971    at a daily or even more leisurely rate.
972
973
974 6.  IANA Considerations
975
976    This document requires a number of IKEv2 notification status types in
977    Section 4.3, to be registered by IANA.  The corresponding registry
978    was established by IANA.
979
980    The document defines a new IKEv2 exchange in Section 4.2.  The
981    corresponding registry was established by IANA.
982
983
984 7.  Security Considerations
985
986    This section addresses security issues related to the usage of a
987    ticket.
988
989 7.1.  Stolen Tickets
990
991    An eavesdropper or man-in-the-middle may try to obtain a ticket and
992    use it to establish a session with the IKEv2 responder.  This can
993    happen in different ways: by eavesdropping on the initial
994    communication and copying the ticket when it is granted and before it
995    is used, or by listening in on a client's use of the ticket to resume
996    a session.  However, since the ticket's contents is encrypted and the
997    attacker does not know the corresponding secret key (specifically,
998    SK_d), a stolen ticket cannot be used by an attacker to resume a
999    session.  An IKEv2 responder MUST use strong encryption and integrity
1000    protection of the ticket to prevent an attacker from obtaining the
1001    ticket's contents, e.g., by using a brute force attack.
1002
1003
1004
1005
1006
1007 Sheffer, et al.        Expires September 20, 2008              [Page 18]
1008 \f
1009 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
1010
1011
1012 7.2.  Forged Tickets
1013
1014    A malicious user could forge or alter a ticket in order to resume a
1015    session, to extend its lifetime, to impersonate as another user, or
1016    to gain additional privileges.  This attack is not possible if the
1017    ticket is protected using a strong integrity protection algorithm.
1018
1019 7.3.  Denial of Service Attacks
1020
1021    The key_id field defined in the recommended ticket format helps the
1022    server efficiently reject tickets that it did not issue.  However, an
1023    adversary could generate and send a large number of tickets to a
1024    gateway for verification.  To minimize the possibility of such denial
1025    of service, ticket verification should be lightweight (e.g., using
1026    efficient symmetric key cryptographic algorithms).
1027
1028 7.4.  Ticket Protection Key Management
1029
1030    A full description of the management of the keys used to protect the
1031    ticket is beyond the scope of this document.  A list of RECOMMENDED
1032    practices is given below.
1033    o  The keys should be generated securely following the randomness
1034       recommendations in [RFC4086].
1035    o  The keys and cryptographic protection algorithms should be at
1036       least 128 bits in strength.
1037    o  The keys should not be used for any other purpose than generating
1038       and verifying tickets.
1039    o  The keys should be changed regularly.
1040    o  The keys should be changed if the ticket format or cryptographic
1041       protection algorithms change.
1042
1043 7.5.  Ticket Lifetime
1044
1045    An IKEv2 responder controls the lifetime of a ticket, based on the
1046    operational and security requirements of the environment in which it
1047    is deployed.  The responder provides information about the ticket
1048    lifetime to the IKEv2 initiator, allowing it to manage its tickets.
1049
1050    An IKEv2 client may present a ticket in its possession to a gateway,
1051    even if the IKE SA associated with this ticket had previously been
1052    terminated by another gateway (the gateway that originally provided
1053    the ticket).  Where such usage is against the local security policy,
1054    an Invalid Ticket List (ITL) may be used, see
1055    [I-D.rescorla-stateless-tokens].  Management of such lists is outside
1056    the scope of the current document.  Note that a policy that requires
1057    tickets to have shorter lifetimes (e.g., 1 hour) significantly
1058    mitigates this risk.
1059
1060
1061
1062
1063 Sheffer, et al.        Expires September 20, 2008              [Page 19]
1064 \f
1065 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
1066
1067
1068 7.6.  Alternate Ticket Formats and Distribution Schemes
1069
1070    If the ticket format or distribution scheme defined in this document
1071    is not used, then great care must be taken in analyzing the security
1072    of the solution.  In particular, if confidential information, such as
1073    a secret key, is transferred to the client, it MUST be done using
1074    secure communication to prevent attackers from obtaining or modifying
1075    the key.  Also, the ticket MUST have its integrity and
1076    confidentiality protected with strong cryptographic techniques to
1077    prevent a breach in the security of the system.
1078
1079 7.7.  Identity Privacy, Anonymity, and Unlinkability
1080
1081    This document mandates that the content of the ticket MUST be
1082    encrypted in order to avoid leakage of information, such as the
1083    identities of an IKEv2 initiator and a responder.  Thus, it prevents
1084    the disclosure of potentially sensitive information carried within
1085    the ticket.
1086
1087    When an IKEv2 initiator presents the ticket as part of the
1088    IKE_SESSION_RESUME exchange, confidentiality is not provided for the
1089    exchange.  Although the ticket itself is encrypted there might still
1090    be a possibility for an on-path adversary to observe multiple
1091    exchange handshakes where the same ticket is used and therefore to
1092    conclude that they belong to the same communication end points.
1093    Administrators that use the ticket mechanism described in this
1094    document should be aware that unlinkability may not be provided by
1095    this mechanism.  Note, however, that IKEv2 does not provide active
1096    user identity confidentiality for the IKEv2 initiator either.
1097
1098 7.8.  Replay Protection in the IKE_SESSION_RESUME Exchange
1099
1100    A major design goal of this protocol extension has been the two-
1101    message exchange for session resumption.  There is a tradeoff between
1102    this abbreviated exchange and replay protection.  It is RECOMMENDED
1103    that the gateway should cache tickets, and reject replayed ones.
1104    However some gateways may not do that in order to reduce state size.
1105    In addition, an adversary may replay a ticket last presented to
1106    gateway A, into gateway B. Our cookie-based mechanism (Section 4.2.2)
1107    mitigates both scenarios by ensuring that the client presenting the
1108    ticket is indeed its "owner": the client can be required by the
1109    gateway to prove that it knows the ticket's secret, before any state
1110    is committed on the gateway.  Note that this is a stronger guarantee
1111    than the regular IKE cookie mechanism, which only proves IP return
1112    routability of the client.  This is enabled by including the cookie
1113    in the protected portion of the message.
1114
1115    For performance reasons, the cookie mechanism is optional, and
1116
1117
1118
1119 Sheffer, et al.        Expires September 20, 2008              [Page 20]
1120 \f
1121 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
1122
1123
1124    invoked by the gateway only when it suspects that it is the subject
1125    of a denial-of-service attack.
1126
1127    In any case, a ticket replayed by an adversary only causes partial
1128    IKE state to be created on the gateway.  The IKE exchange cannot be
1129    completed and an IKE SA cannot be created unless the client knows the
1130    ticket's secret values.
1131
1132
1133 8.  Acknowledgements
1134
1135    We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
1136    Yoav Nir and Tero Kivinen for their many helpful comments.
1137
1138
1139 9.  References
1140
1141 9.1.  Normative References
1142
1143    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1144               Requirement Levels", BCP 14, RFC 2119, March 1997.
1145
1146    [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
1147               RFC 4306, December 2005.
1148
1149 9.2.  Informative References
1150
1151    [I-D.friedman-ike-short-term-certs]
1152               Friedman, A., "Short-Term Certificates",
1153               draft-friedman-ike-short-term-certs-02 (work in progress),
1154               June 2007.
1155
1156    [I-D.rescorla-stateless-tokens]
1157               Rescorla, E., "How to Implement Secure (Mostly) Stateless
1158               Tokens", draft-rescorla-stateless-tokens-01 (work in
1159               progress), March 2007.
1160
1161    [I-D.vidya-ipsec-failover-ps]
1162               Narayanan, V., "IPsec Gateway Failover and Redundancy -
1163               Problem Statement and Goals",
1164               draft-vidya-ipsec-failover-ps-02 (work in progress),
1165               December 2007.
1166
1167    [I-D.weis-gdoi-for-rsvp]
1168               Weis, B., "Group Domain of Interpretation (GDOI) support
1169               for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress),
1170               February 2008.
1171
1172
1173
1174
1175 Sheffer, et al.        Expires September 20, 2008              [Page 21]
1176 \f
1177 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
1178
1179
1180    [RFC3547]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
1181               Group Domain of Interpretation", RFC 3547, July 2003.
1182
1183    [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
1184               Requirements for Security", BCP 106, RFC 4086, June 2005.
1185
1186    [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
1187               Internet Protocol", RFC 4301, December 2005.
1188
1189    [RFC4478]  Nir, Y., "Repeated Authentication in Internet Key Exchange
1190               (IKEv2) Protocol", RFC 4478, April 2006.
1191
1192    [RFC4507]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
1193               "Transport Layer Security (TLS) Session Resumption without
1194               Server-Side State", RFC 4507, May 2006.
1195
1196    [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
1197               (MOBIKE)", RFC 4555, June 2006.
1198
1199    [RFC4718]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
1200               Implementation Guidelines", RFC 4718, October 2006.
1201
1202
1203 Appendix A.  Related Work
1204
1205    [I-D.friedman-ike-short-term-certs] is on-going work that discusses
1206    the use of short-term certificates for client re-authentication.  It
1207    is similar to the ticket approach described in this document in that
1208    they both require enhancements to IKEv2 to allow information request,
1209    e.g., for a certificate or a ticket.  However, the changes required
1210    by the former are fewer since an obtained certificate is valid for
1211    any IKE responder that is able to verify them.  On the other hand,
1212    short-term certificates, while eliminating the usability issues of
1213    user re-authentication, do not reduce the amount of effort performed
1214    by the gateway in failover situations.
1215
1216
1217 Appendix B.  Change Log
1218
1219 B.1.  -03
1220
1221    Removed counter mechanism.  Added an optional anti-DoS mechanism,
1222    based on IKEv2 cookies (removed previous discussion of cookies).
1223    Clarified that gateways may support reallocation of same IP address,
1224    if provided by network.  Proposed a solution outline to the problem
1225    of key exchange for the keys that protect tickets.  Added fields to
1226    the ticket to enable interoperability.  Removed incorrect MOBIKE
1227    notification.
1228
1229
1230
1231 Sheffer, et al.        Expires September 20, 2008              [Page 22]
1232 \f
1233 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
1234
1235
1236 B.2.  -02
1237
1238    Clarifications on generation of SPI values, on the ticket's lifetime
1239    and on the integrity protection of the anti-replay counter.
1240    Eliminated redundant SPIs from the notification payloads.
1241
1242 B.3.  -01
1243
1244    Editorial review.  Removed 24-hour limitation on ticket lifetime,
1245    lifetime is up to local policy.
1246
1247 B.4.  -00
1248
1249    Initial version.  This draft is a selective merge of
1250    draft-sheffer-ike-session-resumption-00 and
1251    draft-dondeti-ipsec-failover-sol-00.
1252
1253
1254 Authors' Addresses
1255
1256    Yaron Sheffer
1257    Check Point Software Technologies Ltd.
1258    5 Hasolelim St.
1259    Tel Aviv  67897
1260    Israel
1261
1262    Email: yaronf@checkpoint.com
1263
1264
1265    Hannes Tschofenig
1266    Nokia Siemens Networks
1267    Otto-Hahn-Ring 6
1268    Munich, Bavaria  81739
1269    Germany
1270
1271    Email: Hannes.Tschofenig@nsn.com
1272    URI:   http://www.tschofenig.priv.at
1273
1274
1275    Lakshminath Dondeti
1276    QUALCOMM, Inc.
1277    5775 Morehouse Dr
1278    San Diego, CA
1279    USA
1280
1281    Phone: +1 858-845-1267
1282    Email: ldondeti@qualcomm.com
1283
1284
1285
1286
1287 Sheffer, et al.        Expires September 20, 2008              [Page 23]
1288 \f
1289 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
1290
1291
1292    Vidya Narayanan
1293    QUALCOMM, Inc.
1294    5775 Morehouse Dr
1295    San Diego, CA
1296    USA
1297
1298    Phone: +1 858-845-2483
1299    Email: vidyan@qualcomm.com
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343 Sheffer, et al.        Expires September 20, 2008              [Page 24]
1344 \f
1345 Internet-Draft       IPsec Gateway Failover Protocol          March 2008
1346
1347
1348 Full Copyright Statement
1349
1350    Copyright (C) The IETF Trust (2008).
1351
1352    This document is subject to the rights, licenses and restrictions
1353    contained in BCP 78, and except as set forth therein, the authors
1354    retain all their rights.
1355
1356    This document and the information contained herein are provided on an
1357    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1358    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1359    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1360    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1361    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1362    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1363
1364
1365 Intellectual Property
1366
1367    The IETF takes no position regarding the validity or scope of any
1368    Intellectual Property Rights or other rights that might be claimed to
1369    pertain to the implementation or use of the technology described in
1370    this document or the extent to which any license under such rights
1371    might or might not be available; nor does it represent that it has
1372    made any independent effort to identify any such rights.  Information
1373    on the procedures with respect to rights in RFC documents can be
1374    found in BCP 78 and BCP 79.
1375
1376    Copies of IPR disclosures made to the IETF Secretariat and any
1377    assurances of licenses to be made available, or the result of an
1378    attempt made to obtain a general license or permission for the use of
1379    such proprietary rights by implementers or users of this
1380    specification can be obtained from the IETF on-line IPR repository at
1381    http://www.ietf.org/ipr.
1382
1383    The IETF invites any interested party to bring to its attention any
1384    copyrights, patents or patent applications, or other proprietary
1385    rights that may cover technology that may be required to implement
1386    this standard.  Please address the information to the IETF at
1387    ietf-ipr@ietf.org.
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399 Sheffer, et al.        Expires September 20, 2008              [Page 25]
1400 \f
1401