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
|
<pre>Internet Engineering Task Force (IETF) D. Migault, Ed.
Request for Comments: 7791 Ericsson
Category: Standards Track V. Smyslov
ISSN: 2070-1721 ELVIS-PLUS
March 2016
<span class="h1">Cloning the IKE Security Association</span>
<span class="h1">in the Internet Key Exchange Protocol Version 2 (IKEv2)</span>
Abstract
This document considers a VPN end user establishing an IPsec Security
Association (SA) with a Security Gateway using the Internet Key
Exchange Protocol version 2 (IKEv2), where at least one of the peers
has multiple interfaces or where Security Gateway is a cluster with
each node having its own IP address.
The protocol described allows a peer to clone an IKEv2 SA, where an
additional SA is derived from an existing one. The newly created IKE
SA is set without the IKEv2 authentication exchange. This IKE SA can
later be assigned to another interface or moved to another cluster
node.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7791">http://www.rfc-editor.org/info/rfc7791</a>.
<span class="grey">Migault & Smyslov Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Requirements Notation . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Protocol Details . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Support Negotiation . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Cloning the IKE SA . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.3">5.3</a>. Error Handling . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Payload Description . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#appendix-A">Appendix A</a>. Setting a VPN on Multiple Interfaces . . . . . . . . <a href="#page-11">11</a>
<a href="#appendix-A.1">A.1</a>. Setting VPN_0 . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#appendix-A.2">A.2</a>. Creating an Additional IKE SA . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A.3">A.3</a>. Creating the Child SA for VPN_1 . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A.4">A.4</a>. Moving VPN_1 on Interface_1 . . . . . . . . . . . . . . . <a href="#page-13">13</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<span class="grey">Migault & Smyslov Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The main scenario that motivated this document is a VPN end user
establishing a VPN with a Security Gateway when at least one of the
peers has multiple interfaces. Figure 1 represents the case when the
VPN end user has multiple interfaces, Figure 2 represents the case
when the Security Gateway has multiple interfaces, and Figure 3
represents the case when both the VPN end user and the Security
Gateway have multiple interfaces. With Figure 1 and Figure 2, one of
the peers has n = 2 interfaces and the other has a single interface.
This results in the creation of up to n = 2 VPNs. With Figure 3, the
VPN end user has n = 2 interfaces and the Security Gateway has m = 2
interfaces. This may lead to up to m x n VPNs.
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================= | |
| VPN | v | Security |
| End User | ================== Gateway |
| ================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 1: VPN End User with Multiple Interfaces
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| | ================== |
| VPN | v | Security |
| End User ================= | Gateway |
| | ^================= |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 2: Security Gateway with Multiple Interfaces
+------------+ +------------+
| | Interface_0 Interface_0' | |
| ================================== |
| VPN | \\ // | Security |
| End User | // \\ | Gateway |
| ================================== |
| | Interface_1 Interface_1' | |
+------------+ +------------+
Figure 3: VPN End User and Security Gateway with Multiple Interfaces
<span class="grey">Migault & Smyslov Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
With the current IKEv2 protocol [<a href="./rfc7296" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC7296</a>], each VPN requires an IKE
SA, and setting an IKE SA requires an authentication. Authentication
might require multiple round trips and an activity from the end user
(like EAP-SIM [<a href="./rfc4186" title=""Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)"">RFC4186</a>] or EAP-TLS [<a href="./rfc5216" title=""The EAP-TLS Authentication Protocol"">RFC5216</a>]) as well as crypto
operations that would introduce an additional delay.
Another scenario is a load-balancing solution. Load-sharing clusters
are often built to be transparent for VPN end users. In the case of
IPsec, this means that IKE and IPsec SA states are duplicated on
every cluster node where the load balancer can redirect packets. The
drawback of such an approach is that anti-replay related data (in
particular, Sequence Number) must be reliably synchronized between
participating nodes per every outgoing Authentication Header (AH) or
Encapsulating Security Payload (ESP) packet, which makes building
high-speed systems problematic. Another approach for building load-
balancing systems is to make VPN end users aware of them, which
allows for having two or more Security Gateways sharing the same ID,
but each having its own IP address. In this case, the VPN end user
first establishes an IKE SA with one of these gateways. Then, at
some point of time the gateway makes a decision to move the client to
a different cluster node. This can be done with Redirect Mechanism
for IKEv2 [<a href="./rfc5685" title=""Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5685</a>]. The drawback of such an approach is that it
requires a new IKE SA to be established from scratch, including full
authentication. In some cases, this could be avoided by using IKEv2
Session Resumption [<a href="./rfc5723" title=""Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption"">RFC5723</a>] with a new gateway. However, this
requires the VPN end user to know beforehand which new gateway to
connect to. So, it is desirable to be able to clone the existing IKE
SA, move it to a different Security Gateway, and then indicate to the
VPN end user to use this new SA. This would allow participating
Security Gateways to share the load between them.
This document introduces the possibility of cloning the IKE SA in the
Internet Key Exchange Protocol Version 2 (IKEv2). The main idea is
that the peer with multiple interfaces sets the first IKE SA as
usual. Then it takes advantage of the fact that this SA is completed
and derives as many new parallel IKE SAs from it as the desired
number of VPNs. On each IKE SA a VPN is negotiated by creating one
or more IPsec SAs. This results in coexisting parallel VPNs. Then
the VPN end user moves each IPsec SA to its proper location using the
IKEv2 Mobility and Multihoming Protocol (MOBIKE) [<a href="./rfc4555" title=""IKEv2 Mobility and Multihoming Protocol (MOBIKE)"">RFC4555</a>].
Alternatively, the VPN end user may first move the IKE SAs and then
create the IPsec SAs.
Note that it is up to the host's local policy to decide which
additional VPNs to create and when to do it. The process of
selecting address pairs for migration is a local matter.
<span class="grey">Migault & Smyslov Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
Furthermore, in the case of multiple interfaces on both ends, care
should be taken to avoid the VPNs being duplicated by both ends or
moved to both interfaces.
In addition, multiple MOBIKE operations may be involved from the
Security Gateway or the VPN end user. Suppose, as depicted in
Figure 3 for example, that the cloned VPN is between Interface _0 and
Interface_0', and the VPN end user and the Security Gateway want to
move it to Interface_1 and Interface_1'. The VPN end user may
initiate a MOBIKE exchange in order to move it to Interface_1, in
which case the cloned VPN is now between Interface_1 and
Interface_0'. Then the Security Gateway may also initiate a MOBIKE
exchange in order to move the VPN to Interface_1', in which case the
VPN has reached its final destination.
The combination of the IKE SA cloning with MOBIKE protocol provides
IPsec communications with multiple interfaces the following
advantages. First, cloning the IKE SA requires very few
modifications to already existing IKEv2 implementations. Then, it
takes advantage of the already existing and widely deployed MOBIKE
protocol. Finally, it keeps a dedicated IKE SA for each VPN, which
simplifies reachability tests and VPN maintenance.
Note also that the cloning of the IKE SA is independent from MOBIKE
and can also address other future scenarios not described in the
current document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Notation</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
This section defines terms and acronyms used in this document.
- VPN: Virtual Private Network -- one or more Child (IPsec) SAs
created in tunnel mode between two peers.
- VPN End User: designates the end user that initiates the VPN with
a Security Gateway. This end user may be mobile and move its
VPN from one Security Gateway to another.
<span class="grey">Migault & Smyslov Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
- Security Gateway: designates a point of attachment for the VPN
service. In this document, the VPN service is provided by
multiple Security Gateways. Each Security Gateway may be
considered as a specific hardware.
- IKE SA: IKE Security Association as defined in [<a href="./rfc7296" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC7296</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Overview</span>
This document specifies how to clone existing IKE SAs without
performing new authentication. In order to achieve this goal, this
document proposes that the two peers agree upon their ability to
clone the IKE SA. This is done during the IKE_AUTH exchange by
exchanging the CLONE_IKE_SA_SUPPORTED notifications. To create a new
parallel IKE SA, one of the peers initiates a CREATE_CHILD_SA
exchange as if it would rekey the existing IKE SA. In order to
indicate that the current IKE SA must not be deleted, the initiator
includes the CLONE_IKE_SA notification in the CREATE_CHILD_SA
exchange. This results in two parallel IKE SAs.
Note that without the CLONE_IKE_SA notification, the old IKE SA would
be deleted after the rekey is successfully completed (as specified in
<a href="./rfc7296#section-2.8">Section 2.8 of [RFC7296]</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Protocol Details</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Support Negotiation</span>
The initiator and the responder indicate their support for cloning
IKE SA by exchanging the CLONE_IKE SA_SUPPORTED notifications. This
notification MUST be sent in the IKE_AUTH exchange (in case of
multiple IKE_AUTH exchanges -- in the first IKE_AUTH message from
initiator and in the last IKE_AUTH message from responder). If both
initiator and responder send this notification during the IKE_AUTH
exchange, peers may clone this IKE SA. In the other case, the IKE SA
MUST NOT be cloned.
Initiator Responder
-------------------------------------------------------------------
HDR, SA, KEi, Ni -->
<-- HDR, SA, KEr, Nr
HDR, SK {IDi, AUTH,
SA, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)} -->
<-- HDR, SK {IDr, AUTH,
SA, TSi, TSr,
N(CLONE_IKE_SA_SUPPORTED)}
<span class="grey">Migault & Smyslov Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Cloning the IKE SA</span>
The initiator of the rekey exchange includes the CLONE_IKE_SA
notification in a CREATE_CHILD_SA request for rekeying the IKE SA.
The CLONE_IKE_SA notification indicates that the current IKE SA will
not be immediately deleted once the new IKE SA is created. Instead,
two parallel IKE SAs are expected to coexist. The current IKE SA
becomes the old IKE SA and the newly negotiated IKE SA becomes the
new IKE SA. The CLONE_IKE_SA notification MUST appear only in the
request message of the CREATE_CHILD_SA exchange concerning the IKE SA
rekey. If the CLONE_IKE_SA notification appears in any other
message, it MUST be ignored.
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(CLONE_IKE_SA), SA, Ni, KEi} -->
If the CREATE_CHILD_SA request is concerned with an IKE SA rekey and
contains the CLONE_IKE_SA notification, the responder proceeds to the
IKE SA rekey, creates the new IKE SA, and keeps the old IKE SA. No
additional Notify Payloads are included in the CREATE_CHILD_SA
response as represented below:
<-- HDR, SK {SA, Nr, KEr}
When the IKE SA is cloned, peers MUST NOT transfer existing Child SAs
that were created by the old IKE SA to the newly created IKE SA. So,
all signaling messages concerning those Child SAs would continue to
be sent over the old IKE SA. This is different from the regular IKE
SA rekey in IKEv2.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Error Handling</span>
There may be conditions when the responder for some reason is unable
or unwilling to clone the IKE SA. This inability may be temporary or
permanent.
Temporary inability occurs when the responder doesn't have enough
resources at the moment to clone an IKE SA or when the IKE SA is
being deleted by the responder. In this case, the responder SHOULD
reject the request to clone the IKE SA with the TEMPORARY_FAILURE
notification.
<-- HDR, SK {N(TEMPORARY_FAILURE)}
After receiving this notification, the initiator MAY retry its
request after waiting some period of time. See <a href="./rfc7296#section-2.25">Section 2.25 of
[RFC7296]</a> for details.
<span class="grey">Migault & Smyslov Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
In some cases, the responder may have restrictions on the number of
coexisting IKE SAs with one peer. These restrictions may be either
implicit (some devices may have enough resources to handle only a few
IKE SAs) or explicit (provided by some configuration parameter). If
the initiator wants to clone more IKE SAs than the responder is able
or is configured to handle, the responder SHOULD reject the request
with the NO_ADDITIONAL_SAS notification.
<-- HDR, SK {N(NO_ADDITIONAL_SAS)}
This condition is considered permanent and the initiator SHOULD NOT
retry cloning an IKE SA until some of the existing SAs with the
responder are deleted.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Payload Description</span>
Figure 4 illustrates the Notify Payload packet format as described in
<a href="./rfc7296#section-3.10">Section 3.10 of [RFC7296]</a>. This format is used for both the
CLONE_IKE_SA and the CLONE_IKE_SA_SUPPORTED notifications.
The CLONE_IKE_SA_SUPPORTED notification is used in an IKEv2 exchange
of type IKE_AUTH and the CLONE_IKE_SA is used in an IKEv2 exchange of
type CREATE_CHILD_SA.
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 | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Notify Payload
The fields Next Payload, Critical Bit, RESERVED, and Payload Length
are defined in [<a href="./rfc7296" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC7296</a>]. Specific fields defined in this document
are:
- Protocol ID (1 octet): Set to zero.
- Security Parameter Index (SPI) Size (1 octet): Set to zero.
- Notify Message Type (2 octets): Specifies the type of notification
message. It is set to 16432 for the CLONE_IKE_SA_SUPPORTED
notification or 16433 for the CLONE_IKE_SA notification.
<span class="grey">Migault & Smyslov Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has allocated two values in the "IKEv2 Notify Message Types -
Status Types" registry:
Value Notify Messages - Status Types
-----------------------------------------
16432 CLONE_IKE_SA_SUPPORTED
16433 CLONE_IKE_SA
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The protocol defined in this document does not modify IKEv2.
Security considerations for cloning an IKE SA are mostly the same as
those for the base IKEv2 protocol described in [<a href="./rfc7296" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC7296</a>].
Cloning an IKE SA allows an initiator to duplicate existing SAs. As
a result, it may influence any accounting or control mechanisms based
on a single IKE SA per authentication.
Suppose a system has a limit on the number of IKE SAs it can handle.
In this case, cloning an IKE SA may provide a way for resource
exhaustion, as a single end user may populate multiple IKE SAs.
Suppose a system shares the IPsec resources by limiting the number of
Child SAs per IKE SA. With a single IKE SA per end user, this
provides an equal resource sharing. In this case, cloning the IKE SA
provides the means for an end user to overpass this limit. Such a
system should evaluate the number of Child SAs over the number of all
IKE SAs associated to an end user.
Note that these issues are not unique to the ability of cloning the
IKE SA, as multiple IKE SAs between two peers may be created without
involving a cloning method. Note also that implementation can always
limit the number of cloned IKE SAs.
Suppose the VPN or any other IPsec-based service monitoring is based
on the liveliness of the first IKE SA. Such a system considers a
service is accessed or used from the time IKE performs an
authentication to the time the IKE SA is deleted. Such accounting
methods were fine as any IKE SA required an authentication exchange.
As cloning the IKE SA skips the authentication phase, it may make it
possible to delete the initial IKE SA while the service is being used
on the cloned IKE SA. Such accounting methods should consider that
the service is being used from the first IKE SA establishment to
until the last IKE SA is removed.
<span class="grey">Migault & Smyslov Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
When this solution is used to build load-balancing systems, then
there is a necessity to transfer IKE SA states between nodes of a
load-sharing cluster. Since IKE SA state contains sensitive
information, such as session keys, implementations must take all due
precautions. Such precautions might include using technical and/or
administrative means to protect IKE SA state data. The details of
what is transferred and how it is protected are out of scope of this
document.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC4555">RFC4555</a>] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", <a href="./rfc4555">RFC 4555</a>, DOI 10.17487/RFC4555, June 2006,
<<a href="http://www.rfc-editor.org/info/rfc4555">http://www.rfc-editor.org/info/rfc4555</a>>.
[<a id="ref-RFC7296">RFC7296</a>] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, <a href="./rfc7296">RFC 7296</a>, DOI 10.17487/RFC7296, October
2014, <<a href="http://www.rfc-editor.org/info/rfc7296">http://www.rfc-editor.org/info/rfc7296</a>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC4186">RFC4186</a>] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity Modules
(EAP-SIM)", <a href="./rfc4186">RFC 4186</a>, DOI 10.17487/RFC4186, January 2006,
<<a href="http://www.rfc-editor.org/info/rfc4186">http://www.rfc-editor.org/info/rfc4186</a>>.
[<a id="ref-RFC5216">RFC5216</a>] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", <a href="./rfc5216">RFC 5216</a>, DOI 10.17487/RFC5216,
March 2008, <<a href="http://www.rfc-editor.org/info/rfc5216">http://www.rfc-editor.org/info/rfc5216</a>>.
[<a id="ref-RFC5685">RFC5685</a>] Devarapalli, V. and K. Weniger, "Redirect Mechanism for
the Internet Key Exchange Protocol Version 2 (IKEv2)",
<a href="./rfc5685">RFC 5685</a>, DOI 10.17487/RFC5685, November 2009,
<<a href="http://www.rfc-editor.org/info/rfc5685">http://www.rfc-editor.org/info/rfc5685</a>>.
[<a id="ref-RFC5723">RFC5723</a>] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", <a href="./rfc5723">RFC 5723</a>,
DOI 10.17487/RFC5723, January 2010,
<<a href="http://www.rfc-editor.org/info/rfc5723">http://www.rfc-editor.org/info/rfc5723</a>>.
<span class="grey">Migault & Smyslov Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Setting a VPN on Multiple Interfaces</span>
This section is informational and exposes how a VPN end user, as
illustrated in Figure 1, can build two VPNs on its two interfaces
without multiple authentications. Other cases represented in
Figure 2 and Figure 3 are similar and can be easily derived from this
case. The mechanism is based on cloning the IKE SA and the MOBIKE
extension [<a href="./rfc4555" title=""IKEv2 Mobility and Multihoming Protocol (MOBIKE)"">RFC4555</a>].
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. Setting VPN_0</span>
First, the VPN end user negotiates a VPN using one interface. This
involves regular IKEv2 exchanges. In addition, the VPN end user and
the Security Gateway advertise their support for MOBIKE. At the end
of the IKE_AUTH exchange, VPN_0 is set as represented in Figure 5.
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================= | |
| VPN | v | Security |
| End User | ================== Gateway |
| = | |
| | Interface_1 | |
+------------+ +------------+
Figure 5: VPN End User Establishing VPN_0
The exchanges are completely described in [<a href="./rfc7296" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC7296</a>] and [<a href="./rfc4555" title=""IKEv2 Mobility and Multihoming Protocol (MOBIKE)"">RFC4555</a>].
First, peers negotiate IKE SA parameters and exchange nonces and
public keys in the IKE_SA_INIT exchange. In the figure below, they
also proceed to NAT detection because of the use of MOBIKE.
Initiator Responder
-------------------------------------------------------------------
(IP_I0:500 -> IP_R:500)
HDR, SA, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R:500 -> IP_I0:500)
HDR, SA, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
Then the initiator and the responder proceed to the IKE_AUTH
exchange, advertise their support for MOBIKE and their ability to
clone the IKE SA -- with the MOBIKE_SUPPORTED and the
CLONE_IKE_SA_SUPPORTED notifications -- and negotiate the Child SA
<span class="grey">Migault & Smyslov Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
for VPN_0. Optionally, the initiator and the responder can advertise
their multiple interfaces using the ADDITIONAL_IP4_ADDRESS and/or
ADDITIONAL_IP6_ADDRESS notifications.
(IP_I0:4500 -> IP_R:4500)
HDR, SK {IDi, AUTH,
SA, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_IP*_ADDRESS)+,]
N(CLONE_IKE_SA_SUPPORTED)} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK {IDr, AUTH,
SA, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_IP*_ADDRESS)+,]
N(CLONE_IKE_SA_SUPPORTED)}
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. Creating an Additional IKE SA</span>
In this case, the VPN end user wants to establish an additional VPN
with its Interface_1. The VPN end user will first establish a
parallel IKE SA using a CREATE_CHILD_SA that concerns an IKE SA rekey
associated with a CLONE_IKE_SA notification. This results in two
separate IKE SAs between the VPN end user and the Security Gateway.
Currently both IKE SAs are set using Interface_0 of the VPN end user.
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR, SK {N(CLONE_IKE_SA),
SA, Ni, KEi} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR, SK {SA, Nr, KEr}
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>. Creating the Child SA for VPN_1</span>
Once the new IKE SA has been created, the VPN end user can initiate a
CREATE_CHILD_SA exchange that concerns the creation of a Child SA for
VPN_1. The newly created VPN_1 will use Interface_0 of the VPN end
user.
It is out of scope for this document to define how the VPN end user
handles traffic with multiple interfaces. The VPN end user can use
the same inner IP address on its multiple interfaces. In this case,
the same Traffic Selectors (that is, the IP address used for VPN_0
and VPN_1) can match for both VPNs VPN_0 and VPN_1. The VPN end user
must be aware of such a match and be able to manage it. It can, for
<span class="grey">Migault & Smyslov Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
example, use distinct Traffic Selectors on both VPNs using different
ports, manage the order of its Security Policy Database (SPD), or
have SPD defined per interfaces. Defining these mechanisms is out of
scope for this document. Alternatively, the VPN end user can use a
different inner IP address for each interface.
The creation of VPN_1 is performed via the newly created IKE SA as
follows:
Initiator Responder
-------------------------------------------------------------------
(IP_I0:4500 -> IP_R:4500)
HDR(new), SK(new) {SA, TSi, TSr} -->
<-- (IP_R:4500 -> IP_I0:4500)
HDR(new), SK(new) {SA, TSi, TSr}
The resulting configuration is depicted in Figure 6. VPN_0 and VPN_1
have been created, but both are using the same Interface:
Interface_0.
+------------+ +------------+
| | Interface_0 : VPN_0, VPN_1 | |
| ==================== | |
| VPN ================= v | Security |
| End User | v =============== Gateway |
| | ================== |
| | Interface_1 | |
+------------+ +------------+
Figure 6: VPN End User Establishing VPN_0 and VPN_1
<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">A.4</a>. Moving VPN_1 on Interface_1</span>
In this section, MOBIKE is used to move VPN_1 on Interface_1. The
exchange is described in [<a href="./rfc4555" title=""IKEv2 Mobility and Multihoming Protocol (MOBIKE)"">RFC4555</a>].
(IP_I1:4500 -> IP_R:4500)
HDR(new), SK(new) {N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2)} -->
<-- (IP_R:4500 -> IP_I1:4500)
HDR(new), SK(new) {
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2)}
<span class="grey">Migault & Smyslov Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7791">RFC 7791</a> Cloning IKE SA March 2016</span>
This results in the situation as described in Figure 7.
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| ================== | |
| VPN | v | Security |
| End User | ================= Gateway |
| =================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 7: VPN End User with Multiple Interfaces
Acknowledgments
The ideas for this document came from various input from the IP
Security Maintenance and Extensions (ipsecme) Working Group and from
discussions with Tero Kivinen and Michael Richardson. Yaron Sheffer
and Tero Kivinen provided significant input to set the current design
of the protocol, as well as its designation.
Authors' Addresses
Daniel Migault (editor)
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
Email: daniel.migault@ericsson.com
Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd) 124460
Russian Federation
Phone: +7 495 276 0211
Email: svan@elvis.ru
Migault & Smyslov Standards Track [Page 14]
</pre>
|
