aboutsummaryrefslogtreecommitdiffstats
path: root/doc/standards/draft-sheffer-ipsec-failover-03.txt
blob: e624a95cd57f5824920a907fd0f7fd92ed69ab22 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
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
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
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
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401



Network Working Group                                         Y. Sheffer
Internet-Draft                                               Check Point
Intended status: Experimental                              H. Tschofenig
Expires: September 20, 2008                       Nokia Siemens Networks
                                                              L. Dondeti
                                                            V. Narayanan
                                                          QUALCOMM, Inc.
                                                          March 19, 2008


                    IPsec Gateway Failover Protocol
                  draft-sheffer-ipsec-failover-03.txt

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

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

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 20, 2008.

Abstract

   The Internet Key Exchange version 2 (IKEv2) protocol has
   computational and communication overhead with respect to the number
   of round-trips required and cryptographic operations involved.  In
   remote access situations, the Extensible Authentication Protocol is
   used for authentication, which adds several more round trips and
   therefore latency.

   To re-establish security associations (SA) upon a failure recovery



Sheffer, et al.        Expires September 20, 2008               [Page 1]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   condition is time consuming, especially when an IPsec peer, such as a
   VPN gateway, needs to re-establish a large number of SAs with various
   end points.  A high number of concurrent sessions might cause
   additional problems for an IPsec peer during SA re-establishment.

   In many failure cases it would be useful to provide an efficient way
   to resume an interrupted IKE/IPsec session.  This document proposes
   an extension to IKEv2 that allows a client to re-establish an IKE SA
   with a gateway in a highly efficient manner, utilizing a previously
   established IKE SA.

   A client can reconnect to a gateway from which it was disconnected,
   or alternatively migrate to another gateway that is associated with
   the previous one.  The proposed approach conveys IKEv2 state
   information, in the form of an encrypted ticket, to a VPN client that
   is later presented to the VPN gateway for re-authentication.  The
   encrypted ticket can only be decrypted by the VPN gateway in order to
   restore state for faster session setup.

































Sheffer, et al.        Expires September 20, 2008               [Page 2]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Recovering from a Remote Access Gateway Failover . . . . .  6
     3.2.  Recovering from an Application Server Failover . . . . . .  8
   4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Requesting a Ticket  . . . . . . . . . . . . . . . . . . .  9
     4.2.  Presenting a Ticket  . . . . . . . . . . . . . . . . . . . 10
       4.2.1.  Protection of the IKE_SESSION_RESUME Exchange  . . . . 12
       4.2.2.  Presenting a Ticket: The DoS Case  . . . . . . . . . . 12
       4.2.3.  Requesting a ticket during resumption  . . . . . . . . 13
     4.3.  IKE Notifications  . . . . . . . . . . . . . . . . . . . . 13
     4.4.  TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 14
     4.5.  TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14
     4.6.  Processing Guidelines for IKE SA Establishment . . . . . . 15
   5.  The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  Ticket Contents  . . . . . . . . . . . . . . . . . . . . . 16
     5.2.  Ticket Format  . . . . . . . . . . . . . . . . . . . . . . 17
     5.3.  Ticket Identity and Lifecycle  . . . . . . . . . . . . . . 17
     5.4.  Exchange of Ticket-Protecting Keys . . . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
     7.1.  Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18
     7.2.  Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19
     7.3.  Denial of Service Attacks  . . . . . . . . . . . . . . . . 19
     7.4.  Ticket Protection Key Management . . . . . . . . . . . . . 19
     7.5.  Ticket Lifetime  . . . . . . . . . . . . . . . . . . . . . 19
     7.6.  Alternate Ticket Formats and Distribution Schemes  . . . . 20
     7.7.  Identity Privacy, Anonymity, and Unlinkability . . . . . . 20
     7.8.  Replay Protection in the IKE_SESSION_RESUME Exchange . . . 20
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Appendix A.  Related Work  . . . . . . . . . . . . . . . . . . . . 22
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 22
     B.1.  -03  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     B.2.  -02  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     B.3.  -01  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     B.4.  -00  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 25





Sheffer, et al.        Expires September 20, 2008               [Page 3]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


1.  Introduction

   The Internet Key Exchange version 2 (IKEv2) protocol has
   computational and communication overhead with respect to the number
   of round-trips required and cryptographic operations involved.  In
   particular the Extensible Authentication Protocol is used for
   authentication in remote access cases, which increases latency.

   To re-establish security associations (SA) upon a failure recovery
   condition is time-consuming, especially when an IPsec peer, such as a
   VPN gateway, needs to re-establish a large number of SAs with various
   end points.  A high number of concurrent sessions might cause
   additional problems for an IPsec peer.

   In many failure cases it would be useful to provide an efficient way
   to resume an interrupted IKE/IPsec session.  This document proposes
   an extension to IKEv2 that allows a client to re-establish an IKE SA
   with a gateway in a highly efficient manner, utilizing a previously
   established IKE SA.

   A client can reconnect to a gateway from which it was disconnected,
   or alternatively migrate to another gateway that is associated with
   the previous one.  This document proposes to maintain IKEv2 state in
   a "ticket", an opaque data structure created and used by a server and
   stored by a client, which the client cannot understand or tamper
   with.  The IKEv2 protocol is extended to allow a client to request
   and present a ticket.  When two gateways mutually trust each other,
   one can accept a ticket generated by the other.

   This approach is similar to the one taken by TLS session resumption
   [RFC4507] with the required adaptations for IKEv2, e.g., to
   accommodate the two-phase protocol structure.  We have borrowed
   heavily from that specification.

1.1.  Goals

   The high-level goal of this extension is to provide an IPsec failover
   solution, according to the requirements defined in
   [I-D.vidya-ipsec-failover-ps].

   Specifically, the proposed extension should allow IPsec sessions to
   be recovered from failures in remote access scenarios, in a more
   efficient manner than the basic IKE solution.  This efficiency is
   primarily on the gateway side, since the gateway might have to deal
   with many thousands of concurrent requests.  We should enable the
   following cases:





Sheffer, et al.        Expires September 20, 2008               [Page 4]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   o  Failover from one gateway to another, where the two gateways do
      not share state but do have mutual trust.  For example, the
      gateways may be operated by the same provider and share the same
      keying materials to access an encrypted ticket.
   o  Recovery from an intermittent connectivity, where clients
      reconnect into the same gateway.  In this case, the gateway would
      typically have detected the clients' absence and removed the state
      associated with them.
   o  Recovery from a gateway restart, where clients reconnect into the
      same gateway.

   The proposed solution should additionally meet the following goals:

   o  Using only symmetric cryptography to minimize CPU consumption.
   o  Allowing a gateway to push state to clients.
   o  Providing cryptographic agility.
   o  Having no negative impact on IKEv2 security features.

1.2.  Non-Goals

   The following are non-goals of this solution:
   o  Providing load balancing among gateways.
   o  Specifying how a client detects the need for a failover.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document uses terminology defined in [RFC4301], [RFC4306], and
   [RFC4555].  In addition, this document uses the following terms:

   Secure domain:  A secure domain comprises a set of gateways that are
      able to resume an IKEv2 session that may have been established by
      any other gateway within the domain.  All gateways in the secure
      domain are expected to share some secrets, so that they can
      generate an IKEv2 ticket, verify the validity of the ticket and
      extract the IKEv2 policy and session key material from the ticket.
   IKEv2 ticket:  An IKEv2 ticket is a data structure that contains all
      the necessary information that allows any gateway within the same
      secure domain as the gateway that created the ticket to verify the
      validity of the ticket and extract IKEv2 policy and session keys
      to re-establish an IKEv2 session.






Sheffer, et al.        Expires September 20, 2008               [Page 5]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


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


3.  Usage Scenarios

   This specification envisions two usage scenarios for efficient IKEv2
   and IPsec SA session re-establishment.

   The first is similar to the use case specified in Section 1.1.3 of
   the IKEv2 specification [RFC4306], where the IPsec tunnel mode is
   used to establish a secure channel between a remote access client and
   a gateway; the traffic flow may be between the client and entities
   beyond the gateway.

   The second use case focuses on the usage of transport (or tunnel)
   mode to secure the communicate between two end points (e.g., two
   servers).  The two endpoints have a client-server relationship with
   respect to a protocol that runs using the protections afforded by the
   IPsec SA.

3.1.  Recovering from a Remote Access Gateway Failover























Sheffer, et al.        Expires September 20, 2008               [Page 6]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


    (a)

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


    (b)

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



                  Figure 1: Remote Access Gateway Failure

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

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

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

   The protocol defined in this document supports the re-allocation of
   an IP address to the client, if this capability is provided by the



Sheffer, et al.        Expires September 20, 2008               [Page 7]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   network.  For example, if routing tables are modified so that traffic
   is rerouted through the new gateway.  This capability is implicit in
   the use of the IKE Config mechanism, which allows the client to
   present its existing IP address and receive the same address back, if
   allowed by the gateway.

   The protocol defined here supports both stateful and stateless
   scenarios.  In other words, tickets can be stored wholly on the
   client, or the ticket can be stored on the gateway (or in a database
   shared between multiple gateways), with the client only presenting a
   handle that identifies a particular ticket.  In fact these scenarios
   are transparent to the protocols, with the only change being the non-
   mandatory ticket format.

3.2.  Recovering from an Application Server Failover


     (a)

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


    (b)

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


                   Figure 2: Application Server Failover

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



Sheffer, et al.        Expires September 20, 2008               [Page 8]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   as long as the Responder (or the application server) allows it.

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

   The client-server relationship at the application layer ensures that
   one of the entities in this usage scenario is unambiguously always
   the Initiator and the other the Responder.  This role determination
   also allows the Initiator to request an address in the Responder's
   network using the Configuration Payload mechanism of the IKEv2
   protocol.  If the client has thus received an address during the
   initial IKEv2 exchange, when it associates with a new server upon
   failure of the original server, it needs to request an address,
   specifying its assigned address.  The server may allow the client to
   use the original address or if it is not permitted to use that
   address, assign a new address.


4.  Protocol Details

   This section provides protocol details and contains the normative
   parts.  This document defines two protocol exchanges, namely
   requesting a ticket and presenting a ticket.  Section 4.1 describes
   the procedure to request a ticket and Section 4.2 illustrates how to
   present a ticket.

4.1.  Requesting a Ticket

   A client MAY request a ticket in the following exchanges:

   o  In an IKE_AUTH exchange, as shown in the example message exchange
      in Figure 3 below.
   o  In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed.
   o  In an Informational exchange, if the gateway previously replied
      with an N(TICKET_ACK) instead of providing a ticket.
   o  In an Informational exchange, when the ticket lifetime is about to
      expire.
   o  In an IKE_SESSION_RESUME exchange, see Section 4.2.3.

   Normally, a client requests a ticket in the third message of an IKEv2
   exchange (the first of IKE_AUTH).  Figure 3 shows the message
   exchange for this typical case.






Sheffer, et al.        Expires September 20, 2008               [Page 9]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


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

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

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

        Figure 3: Example Message Exchange for Requesting a Ticket

   The notification payloads are described in Section 4.3.  The above is
   an example, and IKEv2 allows a number of variants on these messages.
   A complete description of IKEv2 can be found in [RFC4718].

   When an IKEv2 responder receives a request for a ticket using the
   N(TICKET_REQUEST) payload it MUST perform one of the following
   operations if it supports the extension defined in this document:
   o  it creates a ticket and returns it with the N(TICKET_OPAQUE)
      payload in a subsequent message towards the IKEv2 initiator.  This
      is shown in Figure 4.
   o  it returns an N(TICKET_NACK) payload, if it refuses to grant a
      ticket for some reason.
   o  it returns an N(TICKET_ACK), if it cannot grant a ticket
      immediately, e.g., due to packet size limitations.  In this case
      the client MAY request a ticket later using an Informational
      exchange, at any time during the lifetime of the IKE SA.

   Provided the IKEv2 exchange was successful, the IKEv2 initiator can
   accept the requested ticket.  The ticket may be used later with an
   IKEv2 responder which supports this extension.  Figure 4 shows how
   the initiator receives the ticket.



     Initiator                Responder
     -----------              -----------
            <--    HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
                        TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]}


                       Figure 4: Receiving a Ticket

4.2.  Presenting a Ticket

   Following a communication failure, a client re-initiates an IKE
   exchange to the same gateway or to a different one, and includes a
   ticket in the first message.  A client MAY initiate a regular (non-



Sheffer, et al.        Expires September 20, 2008              [Page 10]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   ticket-based) IKEv2 exchange even if it is in possession of a valid
   ticket.  A client MUST NOT present a ticket after the ticket's
   lifetime has expired.

   It is up to the client's local policy to decide when the
   communication with the IKEv2 responder is seen as interrupted and a
   new exchange needs to be initiated and the session resumption
   procedure to be initiated.

   Tickets are intended for one-time use: a client MUST NOT reuse a
   ticket, either with the same or with a different gateway.  A gateway
   SHOULD reject a reused ticket.  Note however that a gateway can elect
   not to retain a list of already-used tickets.  Potential replay
   attacks on such gateways are mitigated by the cookie mechanism
   described in Section 4.2.2.

   This document specifies a new IKEv2 exchange type called
   IKE_SESSION_RESUME whose value is TBA by IANA.  This exchange is
   somewhat similar to the IKE_AUTH exchange, and results in the
   creation of a Child SA.  The client SHOULD NOT use this exchange type
   unless it knows that the gateway supports it, either through
   configuration, by out-of-band means or by using the Gateway List
   provision.



    Initiator                Responder
    -----------              -----------
    HDR, Ni, N(TICKET_OPAQUE), [N+,]
         SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->

   The exchange type in HDR is set to 'IKE_SESSION_RESUME'.

   See Section 4.2.1 for details on computing the protected (SK)
   payload.

   When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
   payload it MUST perform one of the following steps if it supports the
   extension defined in this document:
   o  If it is willing to accept the ticket, it responds as shown in
      Figure 5.
   o  It responds with an unprotected N(TICKET_NACK) notification, if it
      rejects the ticket for any reason.  In that case, the initiator
      should re-initiate a regular IKE exchange.  One such case is when
      the responder receives a ticket for an IKE SA that has previously
      been terminated on the responder itself, which may indicate
      inconsistent state between the IKEv2 initiator and the responder.
      However, a responder is not required to maintain the state for



Sheffer, et al.        Expires September 20, 2008              [Page 11]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


      terminated sessions.
   o  When the responder receives a ticket for an IKE SA that is still
      active and if the responder accepts it, then the old SAs SHOULD be
      silently deleted without sending a DELETE informational exchange.



    Initiator                Responder
    -----------              -----------
                    <--  HDR, SK {IDr, Nr, SAr2, [TSi, TSr],
                         [CP(CFG_REPLY)]}

               Figure 5: IKEv2 Responder accepts the ticket

   Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'.

   The SK payload is protected using the cryptographic parameters
   derived from the ticket, see Section 4.2.1 below.

   At this point a new IKE SA is created by both parties, see
   Section 4.6.  This is followed by normal derivation of a child SA,
   per Sec. 2.17 of [RFC4306].

4.2.1.  Protection of the IKE_SESSION_RESUME Exchange

   The two messages of this exchange are protected by a "subset" IKE SA.
   The key material is derived from the ticket, as follows:


        {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni)

   where SK_d_old is the SK_d value of the original IKE SA, as retrieved
   from the ticket.  Ni guarantees freshness of the key material.  SK_d2
   is used later to derive the new IKE SA, see Section 4.6.

   See [RFC4306] for the notation. "prf" is determined from the SA value
   in the ticket.

4.2.2.  Presenting a Ticket: The DoS Case

   When receiving the first message of the IKE_SESSION_RESUME exchange,
   the gateway may decide that it is under a denial-of-service attack.
   In such a case, the gateway SHOULD defer the establishment of session
   state until it has verified the identity of the client.  We use a
   variation of the IKEv2 Cookie mechanism, where the cookie is
   protected.

   In the two messages that follow, the gateway responds that it is



Sheffer, et al.        Expires September 20, 2008              [Page 12]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   unwilling to resume the session until the client is verified, and the
   client resubmits its first message, this time with the cookie:



 Initiator                Responder
 -----------              -----------
                 <-- HDR, SK{N(COOKIE)}
HDR, Ni, N(TICKET_OPAQUE), [N+,]
      SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->

   Assuming the cookie is correct, the gateway now replies normally.

   This now becomes a 4-message exchange.  The entire exchange is
   protected as defined in Section 4.2.1.

   See Sec. 2.6 and Sec. 3.10.1 of [RFC4306] for more guidance regarding
   the usage and syntax of the cookie.  Note that the cookie is
   completely independent of the IKEv2 ticket.

4.2.3.  Requesting a ticket during resumption

   When resuming a session, a client will typically request a new ticket
   immediately, so it is able to resume the session again in the case of
   a second failure.  Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE)
   and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as
   protected payloads to the IKE_SESSION_RESUME exchange.

   The returned ticket (if any) will correspond to the IKE SA created
   per the rules described in Section 4.6.

4.3.  IKE Notifications

   This document defines a number of notifications.  The notification
   numbers are TBA by IANA.

            +---------------------+--------+-----------------+
            | Notification Name   | Number | Data            |
            +---------------------+--------+-----------------+
            | TICKET_OPAQUE       | TBA1   | See Section 4.4 |
            | TICKET_REQUEST      | TBA2   | None            |
            | TICKET_ACK          | TBA3   | None            |
            | TICKET_NACK         | TBA4   | None            |
            | TICKET_GATEWAY_LIST | TBA5   | See Section 4.5 |
            +---------------------+--------+-----------------+






Sheffer, et al.        Expires September 20, 2008              [Page 13]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


4.4.  TICKET_OPAQUE Notify Payload

   The data for the TICKET_OPAQUE Notify payload consists of the Notify
   message header, a lifetime field and the ticket itself.  The four
   octet lifetime field contains the number of seconds until the ticket
   expires as an unsigned integer.  Section 5.2 describes a possible
   ticket format, and Section 5.3 offers further guidelines regarding
   the ticket's lifetime.


        0                     1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Next Payload  !C!  Reserved   !      Payload Length           !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Protocol ID   ! SPI Size = 0  !    Notify Message Type        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                       Lifetime                                !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                                                               !
       ~                        Ticket                                 ~
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 6: TICKET_OPAQUE Notify Payload

4.5.  TICKET_GATEWAY_LIST Notify Payload

   The TICKET_GATEWAY_LIST Notify payload contains the Notify payload
   header followed by a sequence of one or more gateway identifiers,
   each of the format depicted in Figure 8.


        0                     1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Next Payload  !C!  Reserved   !      Payload Length           !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Protocol ID   ! SPI Size = 0  !    Notify Message Type        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                                                               !
       ~                   Gateway Identifier List                     ~
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 7: TICKET_GATEWAY_LIST Notify Payload



Sheffer, et al.        Expires September 20, 2008              [Page 14]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


        0                     1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !    ID Type    !   Reserved    !             Length            !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                                                               !
       ~                     Identification Data                       ~
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 8: Gateway Identifier for One Gateway

   ID Type:

      The ID Type contains a restricted set of the IKEv2 ID payloads
      (see [RFC4306], Section 3.5).  Allowed ID types are: ID_IPV4_ADDR,
      ID_IPV6_ADDR, ID_FQDN and the various reserved values.

   Reserved:

      This field must be sent as 0 and must be ignored when received.

   Length:

      The length field indicates the total size of the Identification
      data.

   Identification Data:

      The Identification Data field is of variable length and depends on
      the ID type.  The length is not necessarily a multiple of 4.

4.6.  Processing Guidelines for IKE SA Establishment

   When a ticket is presented, the gateway parses the ticket to retrieve
   the state of the old IKE SA, and the client retrieves this state from
   its local store.  Both peers now create state for the new IKE SA as
   follows:

   o  The SA value (transforms etc.) is taken directly from the ticket.
   o  The sequence numbers are reset to 0.
   o  The IDi value is obtained from the ticket.
   o  The IDr value is obtained from the new exchange.  The gateway MAY
      make policy decisions based on the IDr value encoded in the
      ticket.





Sheffer, et al.        Expires September 20, 2008              [Page 15]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   o  The SPI values are created anew, similarly to a regular IKE
      exchange.  SPI values from the ticket SHOULD NOT be reused.  This
      restriction is to avoid problems caused by collisions with other
      SPI values used already by the initiator/responder.  The SPI value
      should only be reused if collision avoidance can be ensured
      through other means.

   The cryptographic material is refreshed based on the ticket and the
   nonce values, Ni, and Nr, from the current exchange.  A new SKEYSEED
   value is derived as follows:


        SKEYSEED = prf(SK_d2, Ni | Nr)

   where SK_d2 was computed earlier (Section 4.2.1).

   The keys are derived as follows, unchanged from IKEv2:


       {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
                                   prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)

   where SPIi, SPIr are the SPI values created in the new IKE exchange.

   See [RFC4306] for the notation. "prf" is determined from the SA value
   in the ticket.


5.  The IKE Ticket

   This section lists the required contents of the ticket, and
   recommends a non-normative format.  This is followed by a discussion
   of the ticket's lifecycle.

5.1.  Ticket Contents

   The ticket MUST encode at least the following state from an IKE SA.
   These values MUST be encrypted and authenticated.

   o  IDi, IDr.
   o  SPIi, SPIr.
   o  SAr (the accepted proposal).
   o  SK_d.

   In addition, the ticket MUST encode a protected ticket expiration
   value.





Sheffer, et al.        Expires September 20, 2008              [Page 16]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


5.2.  Ticket Format

   This document does not specify a mandatory-to-implement or a
   mandatory-to-use ticket format.  The following format is RECOMMENDED,
   if interoperability between gateways is desired.


  struct {
      [authenticated] struct {
          octet format_version;    // 1 for this version of the protocol
          octet reserved[3];       // sent as 0, ignored by receiver.
          octet key_id[8];         // arbitrary byte string
          opaque IV[0..255];       // actual length (possibly 0) depends
                                   // on the encryption algorithm

          [encrypted] struct {
              opaque IDi, IDr;     // the full payloads
              octet SPIi[8], SPIr[8];
              opaque SA;           // the full SAr payload
              octet SK_d[0..255];  // actual length depends on SA value
              int32 expiration;    // an absolute time value, seconds
                                   // since Jan. 1, 1970
          } ikev2_state;
      } protected_part;
      opaque MAC[0..255];          // the length (possibly 0) depends
                                   // on the integrity algorithm
  } ticket;

   Note that the key defined by "key_id" determines the encryption and
   authentication algorithms used for this ticket.  Those algorithms are
   unrelated to the transforms defined by the SA payload.

   The reader is referred to a recent draft
   [I-D.rescorla-stateless-tokens] that recommends a similar (but not
   identical) ticket format, and discusses related security
   considerations in depth.

5.3.  Ticket Identity and Lifecycle

   Each ticket is associated with a single IKE SA.  In particular, when
   an IKE SA is deleted, the client MUST delete its stored ticket.

   A ticket is therefore associated with the tuple (IDi, IDr).  The
   client MAY however use a ticket to approach other gateways that are
   willing to accept it.  How a client discovers such gateways is
   outside the scope of this document.

   The lifetime of the ticket carried in the N(TICKET_OPAQUE)



Sheffer, et al.        Expires September 20, 2008              [Page 17]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   notification should be the minimum of the IKE SA lifetime (per the
   gateway's local policy) and its re-authentication time, according to
   [RFC4478].  Even if neither of these are enforced by the gateway, a
   finite lifetime MUST be specified for the ticket.

5.4.  Exchange of Ticket-Protecting Keys

   This document does not define an interoperable mechanism for the
   generation and distribution of the keys that protect IKE keys.  Such
   a mechanism can be developed, based on the GDOI group key exchange
   protocol [RFC3547].  There is on-going work to enable the generation
   of non-IPsec keys by means of GDOI, e.g. to provide RSVP router
   groups with a single key [I-D.weis-gdoi-for-rsvp].  This work can be
   generalized for our purposes.  We note that there are no significant
   performance requirements on such a protocol, as key rollover can be
   at a daily or even more leisurely rate.


6.  IANA Considerations

   This document requires a number of IKEv2 notification status types in
   Section 4.3, to be registered by IANA.  The corresponding registry
   was established by IANA.

   The document defines a new IKEv2 exchange in Section 4.2.  The
   corresponding registry was established by IANA.


7.  Security Considerations

   This section addresses security issues related to the usage of a
   ticket.

7.1.  Stolen Tickets

   An eavesdropper or man-in-the-middle may try to obtain a ticket and
   use it to establish a session with the IKEv2 responder.  This can
   happen in different ways: by eavesdropping on the initial
   communication and copying the ticket when it is granted and before it
   is used, or by listening in on a client's use of the ticket to resume
   a session.  However, since the ticket's contents is encrypted and the
   attacker does not know the corresponding secret key (specifically,
   SK_d), a stolen ticket cannot be used by an attacker to resume a
   session.  An IKEv2 responder MUST use strong encryption and integrity
   protection of the ticket to prevent an attacker from obtaining the
   ticket's contents, e.g., by using a brute force attack.





Sheffer, et al.        Expires September 20, 2008              [Page 18]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


7.2.  Forged Tickets

   A malicious user could forge or alter a ticket in order to resume a
   session, to extend its lifetime, to impersonate as another user, or
   to gain additional privileges.  This attack is not possible if the
   ticket is protected using a strong integrity protection algorithm.

7.3.  Denial of Service Attacks

   The key_id field defined in the recommended ticket format helps the
   server efficiently reject tickets that it did not issue.  However, an
   adversary could generate and send a large number of tickets to a
   gateway for verification.  To minimize the possibility of such denial
   of service, ticket verification should be lightweight (e.g., using
   efficient symmetric key cryptographic algorithms).

7.4.  Ticket Protection Key Management

   A full description of the management of the keys used to protect the
   ticket is beyond the scope of this document.  A list of RECOMMENDED
   practices is given below.
   o  The keys should be generated securely following the randomness
      recommendations in [RFC4086].
   o  The keys and cryptographic protection algorithms should be at
      least 128 bits in strength.
   o  The keys should not be used for any other purpose than generating
      and verifying tickets.
   o  The keys should be changed regularly.
   o  The keys should be changed if the ticket format or cryptographic
      protection algorithms change.

7.5.  Ticket Lifetime

   An IKEv2 responder controls the lifetime of a ticket, based on the
   operational and security requirements of the environment in which it
   is deployed.  The responder provides information about the ticket
   lifetime to the IKEv2 initiator, allowing it to manage its tickets.

   An IKEv2 client may present a ticket in its possession to a gateway,
   even if the IKE SA associated with this ticket had previously been
   terminated by another gateway (the gateway that originally provided
   the ticket).  Where such usage is against the local security policy,
   an Invalid Ticket List (ITL) may be used, see
   [I-D.rescorla-stateless-tokens].  Management of such lists is outside
   the scope of the current document.  Note that a policy that requires
   tickets to have shorter lifetimes (e.g., 1 hour) significantly
   mitigates this risk.




Sheffer, et al.        Expires September 20, 2008              [Page 19]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


7.6.  Alternate Ticket Formats and Distribution Schemes

   If the ticket format or distribution scheme defined in this document
   is not used, then great care must be taken in analyzing the security
   of the solution.  In particular, if confidential information, such as
   a secret key, is transferred to the client, it MUST be done using
   secure communication to prevent attackers from obtaining or modifying
   the key.  Also, the ticket MUST have its integrity and
   confidentiality protected with strong cryptographic techniques to
   prevent a breach in the security of the system.

7.7.  Identity Privacy, Anonymity, and Unlinkability

   This document mandates that the content of the ticket MUST be
   encrypted in order to avoid leakage of information, such as the
   identities of an IKEv2 initiator and a responder.  Thus, it prevents
   the disclosure of potentially sensitive information carried within
   the ticket.

   When an IKEv2 initiator presents the ticket as part of the
   IKE_SESSION_RESUME exchange, confidentiality is not provided for the
   exchange.  Although the ticket itself is encrypted there might still
   be a possibility for an on-path adversary to observe multiple
   exchange handshakes where the same ticket is used and therefore to
   conclude that they belong to the same communication end points.
   Administrators that use the ticket mechanism described in this
   document should be aware that unlinkability may not be provided by
   this mechanism.  Note, however, that IKEv2 does not provide active
   user identity confidentiality for the IKEv2 initiator either.

7.8.  Replay Protection in the IKE_SESSION_RESUME Exchange

   A major design goal of this protocol extension has been the two-
   message exchange for session resumption.  There is a tradeoff between
   this abbreviated exchange and replay protection.  It is RECOMMENDED
   that the gateway should cache tickets, and reject replayed ones.
   However some gateways may not do that in order to reduce state size.
   In addition, an adversary may replay a ticket last presented to
   gateway A, into gateway B. Our cookie-based mechanism (Section 4.2.2)
   mitigates both scenarios by ensuring that the client presenting the
   ticket is indeed its "owner": the client can be required by the
   gateway to prove that it knows the ticket's secret, before any state
   is committed on the gateway.  Note that this is a stronger guarantee
   than the regular IKE cookie mechanism, which only proves IP return
   routability of the client.  This is enabled by including the cookie
   in the protected portion of the message.

   For performance reasons, the cookie mechanism is optional, and



Sheffer, et al.        Expires September 20, 2008              [Page 20]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   invoked by the gateway only when it suspects that it is the subject
   of a denial-of-service attack.

   In any case, a ticket replayed by an adversary only causes partial
   IKE state to be created on the gateway.  The IKE exchange cannot be
   completed and an IKE SA cannot be created unless the client knows the
   ticket's secret values.


8.  Acknowledgements

   We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
   Yoav Nir and Tero Kivinen for their many helpful comments.


9.  References

9.1.  Normative References

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

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

9.2.  Informative References

   [I-D.friedman-ike-short-term-certs]
              Friedman, A., "Short-Term Certificates",
              draft-friedman-ike-short-term-certs-02 (work in progress),
              June 2007.

   [I-D.rescorla-stateless-tokens]
              Rescorla, E., "How to Implement Secure (Mostly) Stateless
              Tokens", draft-rescorla-stateless-tokens-01 (work in
              progress), March 2007.

   [I-D.vidya-ipsec-failover-ps]
              Narayanan, V., "IPsec Gateway Failover and Redundancy -
              Problem Statement and Goals",
              draft-vidya-ipsec-failover-ps-02 (work in progress),
              December 2007.

   [I-D.weis-gdoi-for-rsvp]
              Weis, B., "Group Domain of Interpretation (GDOI) support
              for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress),
              February 2008.




Sheffer, et al.        Expires September 20, 2008              [Page 21]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


   [RFC3547]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
              Group Domain of Interpretation", RFC 3547, July 2003.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

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

   [RFC4478]  Nir, Y., "Repeated Authentication in Internet Key Exchange
              (IKEv2) Protocol", RFC 4478, April 2006.

   [RFC4507]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 4507, May 2006.

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

   [RFC4718]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
              Implementation Guidelines", RFC 4718, October 2006.


Appendix A.  Related Work

   [I-D.friedman-ike-short-term-certs] is on-going work that discusses
   the use of short-term certificates for client re-authentication.  It
   is similar to the ticket approach described in this document in that
   they both require enhancements to IKEv2 to allow information request,
   e.g., for a certificate or a ticket.  However, the changes required
   by the former are fewer since an obtained certificate is valid for
   any IKE responder that is able to verify them.  On the other hand,
   short-term certificates, while eliminating the usability issues of
   user re-authentication, do not reduce the amount of effort performed
   by the gateway in failover situations.


Appendix B.  Change Log

B.1.  -03

   Removed counter mechanism.  Added an optional anti-DoS mechanism,
   based on IKEv2 cookies (removed previous discussion of cookies).
   Clarified that gateways may support reallocation of same IP address,
   if provided by network.  Proposed a solution outline to the problem
   of key exchange for the keys that protect tickets.  Added fields to
   the ticket to enable interoperability.  Removed incorrect MOBIKE
   notification.



Sheffer, et al.        Expires September 20, 2008              [Page 22]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


B.2.  -02

   Clarifications on generation of SPI values, on the ticket's lifetime
   and on the integrity protection of the anti-replay counter.
   Eliminated redundant SPIs from the notification payloads.

B.3.  -01

   Editorial review.  Removed 24-hour limitation on ticket lifetime,
   lifetime is up to local policy.

B.4.  -00

   Initial version.  This draft is a selective merge of
   draft-sheffer-ike-session-resumption-00 and
   draft-dondeti-ipsec-failover-sol-00.


Authors' Addresses

   Yaron Sheffer
   Check Point Software Technologies Ltd.
   5 Hasolelim St.
   Tel Aviv  67897
   Israel

   Email: yaronf@checkpoint.com


   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.priv.at


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

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




Sheffer, et al.        Expires September 20, 2008              [Page 23]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


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

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











































Sheffer, et al.        Expires September 20, 2008              [Page 24]

Internet-Draft       IPsec Gateway Failover Protocol          March 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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

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


Intellectual Property

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

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

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











Sheffer, et al.        Expires September 20, 2008              [Page 25]