7
Network Working Group P. Eronen, Ed.
8
Request for Comments: 4555 Nokia
9
Category: Standards Track June 2006
12
IKEv2 Mobility and Multihoming Protocol (MOBIKE)
16
This document specifies an Internet standards track protocol for the
17
Internet community, and requests discussion and suggestions for
18
improvements. Please refer to the current edition of the "Internet
19
Official Protocol Standards" (STD 1) for the standardization state
20
and status of this protocol. Distribution of this memo is unlimited.
24
Copyright (C) The Internet Society (2006).
28
This document describes the MOBIKE protocol, a mobility and
29
multihoming extension to Internet Key Exchange (IKEv2). MOBIKE
30
allows the IP addresses associated with IKEv2 and tunnel mode IPsec
31
Security Associations to change. A mobile Virtual Private Network
32
(VPN) client could use MOBIKE to keep the connection with the VPN
33
gateway active while moving from one address to another. Similarly,
34
a multihomed host could use MOBIKE to move the traffic to a different
35
interface if, for instance, the one currently being used stops
58
Eronen Standards Track [Page 1]
60
RFC 4555 MOBIKE Protocol June 2006
65
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
67
1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4
68
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4
69
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
70
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
71
2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 6
72
2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9
73
3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
74
3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
75
3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
76
3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11
77
3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11
78
3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12
79
3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15
80
3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17
81
3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
82
3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
83
3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
84
3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20
85
3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20
86
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
87
4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21
88
4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21
89
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
90
5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24
91
5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
92
5.3. Denial-of-Service Attacks against Third Parties . . . . . 25
93
5.4. Spoofing Network Connectivity Indications . . . . . . . . 26
94
5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27
95
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
96
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
97
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
98
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
99
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
100
Appendix A. Implementation Considerations . . . . . . . . . . . . 31
101
A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
102
A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31
114
Eronen Standards Track [Page 2]
116
RFC 4555 MOBIKE Protocol June 2006
123
IKEv2 is used for performing mutual authentication, as well as
124
establishing and maintaining IPsec Security Associations (SAs). In
125
the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec
126
SAs are created implicitly between the IP addresses that are used
127
when the IKE_SA is established. These IP addresses are then used as
128
the outer (tunnel header) addresses for tunnel mode IPsec packets
129
(transport mode IPsec SAs are beyond the scope of this document).
130
Currently, it is not possible to change these addresses after the
131
IKE_SA has been created.
133
There are scenarios where these IP addresses might change. One
134
example is mobility: a host changes its point of network attachment
135
and receives a new IP address. Another example is a multihoming host
136
that would like to change to a different interface if, for instance,
137
the currently used interface stops working for some reason.
139
Although the problem can be solved by creating new IKE and IPsec SAs
140
when the addresses need to be changed, this may not be optimal for
141
several reasons. In some cases, creating a new IKE_SA may require
142
user interaction for authentication, such as entering a code from a
143
token card. Creating new SAs often involves expensive calculations
144
and possibly a large number of round-trips. For these reasons, a
145
mechanism for updating the IP addresses of existing IKE and IPsec SAs
146
is needed. The MOBIKE protocol described in this document provides
149
The main scenario for MOBIKE is enabling a remote access VPN user to
150
move from one address to another without re-establishing all security
151
associations with the VPN gateway. For instance, a user could start
152
from fixed Ethernet in the office and then disconnect the laptop and
153
move to the office's wireless LAN. When the user leaves the office,
154
the laptop could start using General Packet Radio Service (GPRS);
155
when the user arrives home, the laptop could switch to the home
156
wireless LAN. MOBIKE updates only the outer (tunnel header)
157
addresses of IPsec SAs, and the addresses and other traffic selectors
158
used inside the tunnel stay unchanged. Thus, mobility can be
159
(mostly) invisible to applications and their connections using the
170
Eronen Standards Track [Page 3]
172
RFC 4555 MOBIKE Protocol June 2006
175
MOBIKE also supports more complex scenarios where the VPN gateway
176
also has several network interfaces: these interfaces could be
177
connected to different networks or ISPs, they may be a mix of IPv4
178
and IPv6 addresses, and the addresses may change over time.
179
Furthermore, both parties could be VPN gateways relaying traffic for
182
1.2. Scope and Limitations
184
This document focuses on the main scenario outlined above and
185
supports only tunnel mode IPsec SAs.
187
The mobility support in MOBIKE allows both parties to move, but does
188
not provide a "rendezvous" mechanism that would allow simultaneous
189
movement of both parties or discovery of the addresses when the
190
IKE_SA is first established. Therefore, MOBIKE is best suited for
191
situations where the address of at least one endpoint is relatively
192
stable and can be discovered using existing mechanisms such as DNS
195
MOBIKE allows both parties to be multihomed; however, only one pair
196
of addresses is used for an SA at a time. In particular, load
197
balancing is beyond the scope of this specification.
199
MOBIKE follows the IKEv2 practice where a response message is sent to
200
the same address and port from which the request was received. This
201
implies that MOBIKE does not work over address pairs that provide
202
only unidirectional connectivity.
204
Network Address Translators (NATs) introduce additional limitations
205
beyond those listed above. For details, refer to Section 2.3.
207
The base version of the MOBIKE protocol does not cover all potential
208
future use scenarios, such as transport mode, application to securing
209
SCTP, or optimizations desirable in specific circumstances. Future
210
extensions may be defined later to support additional requirements.
211
Please consult the MOBIKE design document [Design] for further
212
information and rationale behind these limitations.
214
1.3. Terminology and Notation
216
When messages containing IKEv2 payloads are described, optional
217
payloads are shown in brackets (for instance, "[FOO]"), and a plus
218
sign indicates that a payload can be repeated one or more times (for
219
instance, "FOO+"). To provide context, some diagrams also show what
220
existing IKEv2 payloads would typically be included in the exchanges.
221
These payloads are shown for illustrative purposes only; see [IKEv2]
222
for an authoritative description.
226
Eronen Standards Track [Page 4]
228
RFC 4555 MOBIKE Protocol June 2006
231
When this document describes updating the source/destination
232
addresses of an IPsec SA, it means updating IPsec-related state so
233
that outgoing Encapsulating Security Payload (ESP)/Authentication
234
Header (AH) packets use those addresses in the tunnel header.
235
Depending on how the nominal divisions between Security Association
236
Database (SAD), Security Policy Database (SPD), and Peer
237
Authorization Database (PAD) described in [IPsecArch] are actually
238
implemented, an implementation can have several different places that
241
In this document, the term "initiator" means the party who originally
242
initiated the first IKE_SA (in a series of possibly several rekeyed
243
IKE_SAs); "responder" is the other peer. During the lifetime of the
244
IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA
245
exchanges; in this case, the terms "exchange initiator" and "exchange
246
responder" are used. The term "original initiator" (which in [IKEv2]
247
refers to the party who started the latest IKE_SA rekeying) is not
248
used in this document.
250
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
251
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
252
document are to be interpreted as described in [KEYWORDS].
258
MOBIKE allows both parties to have several addresses, and there are
259
up to N*M pairs of IP addresses that could potentially be used. The
260
decision of which of these pairs to use has to take into account
261
several factors. First, the parties may have preferences about which
262
interface should be used due to, for instance, performance and cost
263
reasons. Second, the decision is constrained by the fact that some
264
of the pairs may not work at all due to incompatible IP versions,
265
outages in the network, problems at the local link at either end, and
268
MOBIKE solves this problem by taking a simple approach: the party
269
that initiated the IKE_SA (the "client" in a remote access VPN
270
scenario) is responsible for deciding which address pair is used for
271
the IPsec SAs and for collecting the information it needs to make
272
this decision (such as determining which address pairs work or do not
273
work). The other party (the "gateway" in a remote access VPN
274
scenario) simply tells the initiator what addresses it has, but does
275
not update the IPsec SAs until it receives a message from the
276
initiator to do so. This approach applies to the addresses in the
277
IPsec SAs; in the IKE_SA case, the exchange initiator can decide
278
which addresses are used.
282
Eronen Standards Track [Page 5]
284
RFC 4555 MOBIKE Protocol June 2006
287
Making the decision at the initiator is consistent with how normal
288
IKEv2 works: the initiator decides which addresses it uses when
289
contacting the responder. It also makes sense, especially when the
290
initiator is a mobile node: it is in a better position to decide
291
which of its network interfaces should be used for both upstream and
294
The details of exactly how the initiator makes the decision, what
295
information is used in making it, how the information is collected,
296
how preferences affect the decision, and when a decision needs to be
297
changed are largely beyond the scope of MOBIKE. This does not mean
298
that these details are unimportant: on the contrary, they are likely
299
to be crucial in any real system. However, MOBIKE is concerned with
300
these details only to the extent that they are visible in IKEv2/IPsec
301
messages exchanged between the peers (and thus need to be
302
standardized to ensure interoperability).
304
Many of these issues are not specific to MOBIKE, but are common with
305
the use of existing hosts in dynamic environments or with mobility
306
protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms
307
already exist or are being developed to deal with these issues. For
308
instance, link-layer and IP-layer mechanisms can be used to track the
309
status of connectivity within the local link [RFC2461]; movement
310
detection is being specified for both IPv4 and IPv6 in [DNA4],
313
Naturally, updating the addresses of IPsec SAs has to take into
314
account several security considerations. MOBIKE includes two
315
features designed to address these considerations. First, a "return
316
routability" check can be used to verify the addresses provided by
317
the peer. This makes it more difficult to flood third parties with
318
large amounts of traffic. Second, a "NAT prohibition" feature
319
ensures that IP addresses have not been modified by NATs, IPv4/IPv6
320
translation agents, or other similar devices. This feature is
321
enabled only when NAT Traversal is not used.
323
2.2. Example Protocol Exchanges
325
A simple MOBIKE exchange in a mobile scenario is illustrated below.
326
The notation is based on [IKEv2], Section 1.2. In addition, the
327
source/destination IP addresses and ports are shown for each packet:
328
here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by
329
the initiator and the responder.
338
Eronen Standards Track [Page 6]
340
RFC 4555 MOBIKE Protocol June 2006
344
----------- -----------
345
1) (IP_I1:500 -> IP_R1:500)
347
N(NAT_DETECTION_SOURCE_IP),
348
N(NAT_DETECTION_DESTINATION_IP) -->
350
<-- (IP_R1:500 -> IP_I1:500)
352
N(NAT_DETECTION_SOURCE_IP),
353
N(NAT_DETECTION_DESTINATION_IP)
355
2) (IP_I1:4500 -> IP_R1:4500)
356
HDR, SK { IDi, CERT, AUTH,
359
N(MOBIKE_SUPPORTED) } -->
361
<-- (IP_R1:4500 -> IP_I1:4500)
362
HDR, SK { IDr, CERT, AUTH,
365
N(MOBIKE_SUPPORTED) }
367
(Initiator gets information from lower layers that its attachment
368
point and address have changed.)
370
3) (IP_I2:4500 -> IP_R1:4500)
371
HDR, SK { N(UPDATE_SA_ADDRESSES),
372
N(NAT_DETECTION_SOURCE_IP),
373
N(NAT_DETECTION_DESTINATION_IP) } -->
375
<-- (IP_R1:4500 -> IP_I2:4500)
376
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
377
N(NAT_DETECTION_DESTINATION_IP) }
379
(Responder verifies that the initiator has given it a correct IP
382
4) <-- (IP_R1:4500 -> IP_I2:4500)
383
HDR, SK { N(COOKIE2) }
385
(IP_I2:4500 -> IP_R1:4500)
386
HDR, SK { N(COOKIE2) } -->
388
Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform
389
each other that they support MOBIKE. In step 3, the initiator
390
notices a change in its own address, and informs the responder about
394
Eronen Standards Track [Page 7]
396
RFC 4555 MOBIKE Protocol June 2006
399
this by sending an INFORMATIONAL request containing the
400
UPDATE_SA_ADDRESSES notification. The request is sent using the new
401
IP address. At this point, it also starts to use the new address as
402
a source address in its own outgoing ESP traffic. Upon receiving the
403
UPDATE_SA_ADDRESSES notification, the responder records the new
404
address and, if it is required by policy, performs a return
405
routability check of the address. When this check (step 4)
406
completes, the responder starts to use the new address as the
407
destination for its outgoing ESP traffic.
409
Another protocol run in a multihoming scenario is illustrated below.
410
In this scenario, the initiator has one address but the responder has
414
----------- -----------
415
1) (IP_I1:500 -> IP_R1:500)
417
N(NAT_DETECTION_SOURCE_IP),
418
N(NAT_DETECTION_DESTINATION_IP) -->
420
<-- (IP_R1:500 -> IP_I1:500)
422
N(NAT_DETECTION_SOURCE_IP),
423
N(NAT_DETECTION_DESTINATION_IP)
425
2) (IP_I1:4500 -> IP_R1:4500)
426
HDR, SK { IDi, CERT, AUTH,
429
N(MOBIKE_SUPPORTED) } -->
431
<-- (IP_R1:4500 -> IP_I1:4500)
432
HDR, SK { IDr, CERT, AUTH,
436
N(ADDITIONAL_IP4_ADDRESS) }
438
(The initiator suspects a problem in the currently used address pair
439
and probes its liveness.)
450
Eronen Standards Track [Page 8]
452
RFC 4555 MOBIKE Protocol June 2006
455
3) (IP_I1:4500 -> IP_R1:4500)
456
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
457
N(NAT_DETECTION_DESTINATION_IP) } -->
459
(IP_I1:4500 -> IP_R1:4500)
460
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
461
N(NAT_DETECTION_DESTINATION_IP) } -->
465
(Eventually, the initiator gives up on the current address pair and
466
tests the other available address pair.)
468
4) (IP_I1:4500 -> IP_R2:4500)
469
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
470
N(NAT_DETECTION_DESTINATION_IP) }
472
<-- (IP_R2:4500 -> IP_I1:4500)
473
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
474
N(NAT_DETECTION_DESTINATION_IP) }
476
(This worked, and the initiator requests the peer to switch to new
479
5) (IP_I1:4500 -> IP_R2:4500)
480
HDR, SK { N(UPDATE_SA_ADDRESSES),
481
N(NAT_DETECTION_SOURCE_IP),
482
N(NAT_DETECTION_DESTINATION_IP),
485
<-- (IP_R2:4500 -> IP_I1:4500)
486
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
487
N(NAT_DETECTION_DESTINATION_IP),
490
2.3. MOBIKE and Network Address Translation (NAT)
492
In some MOBIKE scenarios, the network may contain NATs or stateful
493
packet filters (for brevity, the rest of this document simply
494
describes NATs). The NAT Traversal feature specified in [IKEv2]
495
allows IKEv2 to work through NATs in many cases, and MOBIKE can
496
leverage this functionality: when the addresses used for IPsec SAs
497
are changed, MOBIKE can enable or disable IKEv2 NAT Traversal, as
500
Nevertheless, there are some limitations because NATs usually
501
introduce an asymmetry into the network: only packets coming from the
502
"inside" cause state to be created. This asymmetry leads to
506
Eronen Standards Track [Page 9]
508
RFC 4555 MOBIKE Protocol June 2006
511
restrictions on what MOBIKE can do. To give a concrete example,
512
consider a situation where both peers have only a single address, and
513
the initiator is behind a NAT. If the responder's address now
514
changes, it needs to send a packet to the initiator using its new
515
address. However, if the NAT is, for instance, of the common
516
"restricted cone" type (see [STUN] for one description of different
517
NAT types), this is not possible. The NAT will drop packets sent
518
from the new address (unless the initiator has previously sent a
519
packet to that address -- which it cannot do until it knows the
522
For simplicity, MOBIKE does not attempt to handle all possible NAT-
523
related scenarios. Instead, MOBIKE assumes that if NATs are present,
524
the initiator is the party "behind" the NAT, and the case where the
525
responder's addresses change is not fully supported (meaning that no
526
special effort is made to support this functionality). Responders
527
may also be unaware of NATs or specific types of NATs they are
528
behind. However, when a change has occurred that will cause a loss
529
of connectivity, MOBIKE responders will still attempt to inform the
530
initiator of the change. Depending on, for instance, the exact type
531
of NAT, it may or may not succeed. However, analyzing the exact
532
circumstances when this will or will not work is not done in this
535
3. Protocol Exchanges
537
3.1. Initial IKE Exchange
539
The initiator is responsible for finding a working pair of addresses
540
so that the initial IKE exchange can be carried out. Any information
541
from MOBIKE extensions will only be available later, when the
542
exchange has progressed far enough. Exactly how the addresses used
543
for the initial exchange are discovered is beyond the scope of this
544
specification; typical sources of information include local
545
configuration and DNS.
547
If either or both of the peers have multiple addresses, some
548
combinations may not work. Thus, the initiator SHOULD try various
549
source and destination address combinations when retransmitting the
552
3.2. Signaling Support for MOBIKE
554
Implementations that wish to use MOBIKE for a particular IKE_SA MUST
555
include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in
556
case of multiple IKE_AUTH exchanges, in the message containing the SA
562
Eronen Standards Track [Page 10]
564
RFC 4555 MOBIKE Protocol June 2006
567
The format of the MOBIKE_SUPPORTED notification is described in
570
3.3. Initial Tunnel Header Addresses
572
When an IPsec SA is created, the tunnel header IP addresses (and
573
port, if doing UDP encapsulation) are taken from the IKE_SA, not the
574
IP header of the IKEv2 message requesting the IPsec SA. The
575
addresses in the IKE_SA are initialized from the IP header of the
576
first IKE_AUTH request.
578
The addresses are taken from the IKE_AUTH request because IKEv2
579
requires changing from port 500 to 4500 if a NAT is discovered. To
580
simplify things, implementations that support both this specification
581
and NAT Traversal MUST change to port 4500 if the correspondent also
582
supports both, even if no NAT was detected between them (this way,
583
there is no need to change the ports later if a NAT is detected on
586
3.4. Additional Addresses
588
Both the initiator and responder MAY include one or more
589
ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in
590
the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the
591
message containing the SA payload). Here "ADDITIONAL_*_ADDRESS"
592
means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS
596
----------- -----------
597
HDR, SK { IDi, [CERT], [IDr], AUTH,
601
[N(ADDITIONAL_*_ADDRESS)+] } -->
603
<-- HDR, SK { IDr, [CERT], AUTH,
607
[N(ADDITIONAL_*_ADDRESS)+] }
609
The recipient stores this information, but no other action is taken
612
Although both the initiator and responder maintain a set of peer
613
addresses (logically associated with the IKE_SA), it is important to
614
note that they use this information for slightly different purposes.
618
Eronen Standards Track [Page 11]
620
RFC 4555 MOBIKE Protocol June 2006
623
The initiator uses the set of responder addresses as an input to its
624
address selection policy; it may, at some later point, decide to move
625
the IPsec traffic to one of these addresses using the procedure
626
described in Section 3.5. The responder normally does not use the
627
set of initiator addresses for anything: the addresses are used only
628
when the responder's own addresses change (see Section 3.6).
630
The set of addresses available to the peers can change during the
631
lifetime of the IKE_SA. The procedure for updating this information
632
is described in Section 3.6.
634
Note that if some of the initiator's interfaces are behind a NAT
635
(from the responder's point of view), the addresses received by the
636
responder will be incorrect. This means the procedure for changing
637
responder addresses described in Section 3.6 does not fully work when
638
the initiator is behind a NAT. For the same reason, the peers also
639
SHOULD NOT use this information for any other purpose than what is
640
explicitly described either in this document or a future
641
specification updating it.
643
3.5. Changing Addresses in IPsec SAs
645
In MOBIKE, the initiator decides what addresses are used in the IPsec
646
SAs. That is, the responder does not normally update any IPsec SAs
647
without receiving an explicit UPDATE_SA_ADDRESSES request from the
648
initiator. (As described below, the responder can, however, update
649
the IKE_SA in some circumstances.)
651
The reasons why the initiator wishes to change the addresses are
652
largely beyond the scope of MOBIKE. Typically, triggers include
653
information received from lower layers, such as changes in IP
654
addresses or link-down indications. Some of this information can be
655
unreliable: for instance, ICMP messages could be spoofed by an
656
attacker. Unreliable information SHOULD be treated only as a hint
657
that there might be a problem, and the initiator SHOULD trigger Dead
658
Peer Detection (that is, send an INFORMATIONAL request) to determine
659
if the current path is still usable.
661
Changing addresses can also be triggered by events within IKEv2. At
662
least the following events can cause the initiator to re-evaluate its
663
local address selection policy, possibly leading to changing the
666
o An IKEv2 request has been re-transmitted several times, but no
667
valid reply has been received. This suggests the current path is
674
Eronen Standards Track [Page 12]
676
RFC 4555 MOBIKE Protocol June 2006
679
o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS,
680
ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
681
received. This means the peer's addresses may have changed. This
682
is particularly important if the announced set of addresses no
683
longer contains the currently used address.
685
o An UNACCEPTABLE_ADDRESSES notification is received as a response
686
to address update request (described below).
688
o The initiator receives a NAT_DETECTION_DESTINATION_IP notification
689
that does not match the previous UPDATE_SA_ADDRESSES response (see
690
Section 3.8 for a more detailed description).
692
The description in the rest of this section assumes that the
693
initiator has already decided what the new addresses should be. When
694
this decision has been made, the initiator:
696
o Updates the IKE_SA with the new addresses, and sets the
697
"pending_update" flag in the IKE_SA.
699
o Updates the IPsec SAs associated with this IKE_SA with the new
700
addresses (unless the initiator's policy requires a return
701
routability check before updating the IPsec SAs, and the check has
702
not been done for this responder address yet).
704
o If the IPsec SAs were updated in the previous step: If NAT
705
Traversal is not enabled, and the responder supports NAT Traversal
706
(as indicated by NAT detection payloads in the IKE_SA_INIT
707
exchange), and the initiator either suspects or knows that a NAT
708
is likely to be present, enables NAT Traversal (that is, enables
709
UDP encapsulation of outgoing ESP packets and sending of NAT-
712
o If there are outstanding IKEv2 requests (requests for which the
713
initiator has not yet received a reply), continues retransmitting
714
them using the addresses in the IKE_SA (the new addresses).
716
o When the window size allows, sends an INFORMATIONAL request
717
containing the UPDATE_SA_ADDRESSES notification (which does not
718
contain any data), and clears the "pending_update" flag. The
719
request will be as follows:
730
Eronen Standards Track [Page 13]
732
RFC 4555 MOBIKE Protocol June 2006
736
----------- -----------
737
HDR, SK { N(UPDATE_SA_ADDRESSES),
738
[N(NAT_DETECTION_SOURCE_IP),
739
N(NAT_DETECTION_DESTINATION_IP)],
740
[N(NO_NATS_ALLOWED)],
743
o If a new address change occurs while waiting for the response,
744
starts again from the first step (and ignores responses to this
745
UPDATE_SA_ADDRESSES request).
747
When processing an INFORMATIONAL request containing the
748
UPDATE_SA_ADDRESSES notification, the responder:
750
o Determines whether it has already received a newer
751
UPDATE_SA_ADDRESSES request than this one (if the responder uses a
752
window size greater than one, it is possible that requests are
753
received out of order). If it has, a normal response message
754
(described below) is sent, but no other action is taken.
756
o If the NO_NATS_ALLOWED notification is present, processes it as
757
described in Section 3.9.
759
o Checks that the (source IP address, destination IP address) pair
760
in the IP header is acceptable according to local policy. If it
761
is not, replies with a message containing the
762
UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).
764
o Updates the IP addresses in the IKE_SA with the values from the IP
765
header. (Using the address from the IP header is consistent with
766
normal IKEv2, and allows IKEv2 to work with NATs without needing
767
unilateral self-address fixing [UNSAF].)
769
o Replies with an INFORMATIONAL response:
772
----------- -----------
773
<-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
774
N(NAT_DETECTION_DESTINATION_IP)],
777
o If necessary, initiates a return routability check for the new
778
initiator address (see Section 3.7) and waits until the check is
781
o Updates the IPsec SAs associated with this IKE_SA with the new
786
Eronen Standards Track [Page 14]
788
RFC 4555 MOBIKE Protocol June 2006
791
o If NAT Traversal is supported and NAT detection payloads were
792
included, enables or disables NAT Traversal.
794
When the initiator receives the reply:
796
o If an address change has occurred after the request was first
797
sent, no MOBIKE processing is done for the reply message because a
798
new UPDATE_SA_ADDRESSES is going to be sent (or has already been
799
sent, if window size greater than one is in use).
801
o If the response contains the UNEXPECTED_NAT_DETECTED notification,
802
the initiator processes the response as described in Section 3.9.
804
o If the response contains an UNACCEPTABLE_ADDRESSES notification,
805
the initiator MAY select another addresses and retry the exchange,
806
keep on using the previously used addresses, or disconnect.
808
o It updates the IPsec SAs associated with this IKE_SA with the new
809
addresses (unless this was already done earlier before sending the
810
request; this is the case when no return routability check was
813
o If NAT Traversal is supported and NAT detection payloads were
814
included, the initiator enables or disables NAT Traversal.
816
There is one exception to the rule that the responder never updates
817
any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If
818
the source address that the responder is currently using becomes
819
unavailable (i.e., sending packets using that source address is no
820
longer possible), the responder is allowed to update the IPsec SAs to
821
use some other address (in addition to initiating the procedure
822
described in the next section).
824
3.6. Updating Additional Addresses
826
As described in Section 3.4, both the initiator and responder can
827
send a list of additional addresses in the IKE_AUTH exchange. This
828
information can be updated by sending an INFORMATIONAL exchange
829
request message that contains either one or more
830
ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the
831
NO_ADDITIONAL_ADDRESSES notification.
833
If the exchange initiator has only a single IP address, it is placed
834
in the IP header, and the message contains the
835
NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has
836
several addresses, one of them is placed in the IP header, and the
837
rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.
842
Eronen Standards Track [Page 15]
844
RFC 4555 MOBIKE Protocol June 2006
847
The new list of addresses replaces the old information (in other
848
words, there are no separate add/delete operations; instead, the
849
complete list is sent every time these notifications are used).
851
The message exchange will look as follows:
854
----------- -----------
855
HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
856
[N(NO_ADDITIONAL_ADDRESSES)],
857
[N(NO_NATS_ALLOWED)],
860
<-- HDR, SK { [N(COOKIE2)] }
862
When a request containing an ADDITIONAL_IP4_ADDRESS,
863
ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
864
received, the exchange responder:
866
o Determines whether it has already received a newer request to
867
update the addresses (if a window size greater than one is used,
868
it is possible that the requests are received out of order). If
869
it has, a response message is sent, but the address set is not
872
o If the NO_NATS_ALLOWED notification is present, processes it as
873
described in Section 3.9.
875
o Updates the set of peer addresses based on the IP header and the
876
ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and
877
NO_ADDITIONAL_ADDRESSES notifications.
881
The initiator MAY include these notifications in the same request as
884
If the request to update the addresses is retransmitted using several
885
different source addresses, a new INFORMATIONAL request MUST be sent.
887
There is one additional complication: when the responder wants to
888
update the address set, the currently used addresses may no longer
889
work. In this case, the responder uses the additional address list
890
received from the initiator, and the list of its own addresses, to
891
determine which addresses to use for sending the INFORMATIONAL
892
request. This is the only time the responder uses the additional
893
address list received from the initiator.
898
Eronen Standards Track [Page 16]
900
RFC 4555 MOBIKE Protocol June 2006
903
Note that both peers can have their own policies about what addresses
904
are acceptable to use, and certain types of policies may simplify
905
implementation. For instance, if the responder has a single fixed
906
address, it does not need to process the ADDITIONAL_IP4_ADDRESS and
907
ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring
908
unrecognized status notifications, as already required in [IKEv2]).
909
Furthermore, if the initiator has a policy saying that only the
910
responder address specified in local configuration is acceptable, it
911
does not have to send its own additional addresses to the responder
912
(since the responder does not need them except when changing its own
915
3.7. Return Routability Check
917
Both parties can optionally verify that the other party can actually
918
receive packets at the claimed address. By default, this "return
919
routability check" SHOULD be performed. In environments where the
920
peer is expected to be well-behaved (many corporate VPNs, for
921
instance), or the address can be verified by some other means (e.g.,
922
a certificate issued by an authority trusted for this purpose), the
923
return routability check MAY be omitted.
925
The check can be done before updating the IPsec SAs, immediately
926
after updating them, or continuously during the connection. By
927
default, the return routability check SHOULD be done before updating
928
the IPsec SAs, but in some environments it MAY be postponed until
929
after the IPsec SAs have been updated.
931
Any INFORMATIONAL exchange can be used for return routability
932
purposes, with one exception (described later in this section): when
933
a valid response is received, we know the other party can receive
934
packets at the claimed address.
936
To ensure that the peer cannot generate the correct INFORMATIONAL
937
response without seeing the request, a new payload is added to
938
INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY
939
include a COOKIE2 notification, and if included, the recipient of an
940
INFORMATIONAL request MUST copy the notification as-is to the
941
response. When processing the response, the original sender MUST
942
verify that the value is the same one as sent. If the values do not
943
match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the
944
format of the COOKIE2 notification.)
954
Eronen Standards Track [Page 17]
956
RFC 4555 MOBIKE Protocol June 2006
959
The exception mentioned earlier is as follows: If the same
960
INFORMATIONAL request has been sent to several different addresses
961
(i.e., the destination address in the IKE_SA has been updated after
962
the request was first sent), receiving the INFORMATIONAL response
963
does not tell which address is the working one. In this case, a new
964
INFORMATIONAL request needs to be sent to check return routability.
966
3.8. Changes in NAT Mappings
968
IKEv2 performs Dead Peer Detection (DPD) if there has recently been
969
only outgoing traffic on all of the SAs associated with the IKE_SA.
971
In MOBIKE, these messages can also be used to detect if NAT mappings
972
have changed (for example, if the keepalive interval is too long, or
973
the NAT box is rebooted). More specifically, if both peers support
974
both this specification and NAT Traversal, the
975
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
976
notifications MAY be included in any INFORMATIONAL request; if the
977
request includes them, the responder MUST also include them in the
978
response (but no other action is taken, unless otherwise specified).
980
When the initiator is behind a NAT (as detected earlier using the
981
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
982
notifications), it SHOULD include these notifications in DPD messages
983
and compare the received NAT_DETECTION_DESTINATION_IP notifications
984
with the value from the previous UPDATE_SA_ADDRESSES response (or the
985
IKE_SA_INIT response). If the values do not match, the IP address
986
and/or port seen by the responder has changed, and the initiator
987
SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5. If the
988
initiator suspects that the NAT mapping has changed, it MAY also skip
989
the detection step and send UPDATE_SA_ADDRESSES immediately. This
990
saves one roundtrip if the NAT mapping has indeed changed.
992
Note that this approach to detecting NAT mapping changes may cause an
993
extra address update when the IKE_SA is rekeyed. This is because the
994
NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security
995
Parameter Indexes (SPIs), which change when performing rekeying.
996
This unnecessary update is harmless, however.
998
When MOBIKE is in use, the dynamic updates (specified in [IKEv2],
999
Section 2.23), where the peer address and port are updated from the
1000
last valid authenticated packet, work in a slightly different
1001
fashion. The host not behind a NAT MUST NOT use these dynamic
1002
updates for IKEv2 packets, but MAY use them for ESP packets. This
1003
ensures that an INFORMATIONAL exchange that does not contain
1004
UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
1005
used for, e.g., testing whether a particular path works.
1010
Eronen Standards Track [Page 18]
1012
RFC 4555 MOBIKE Protocol June 2006
1015
3.9. NAT Prohibition
1017
Basic IKEv2/IPsec without NAT Traversal support may work across some
1018
types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in
1019
tunnel mode. This is because the IKEv2 integrity checksum does not
1020
cover the addresses in the IP header. This may be considered a
1021
problem in some circumstances, because in some sense any modification
1022
of the IP addresses can be considered an attack.
1024
This specification addresses the issue by protecting the IP addresses
1025
when NAT Traversal has not been explicitly enabled. This means that
1026
MOBIKE without NAT Traversal support will not work if the paths
1027
contain NATs, IPv4/IPv6 translation agents, or other nodes that
1028
modify the addresses in the IP header. This feature is mainly
1029
intended for IPv6 and site-to-site VPN cases, where the
1030
administrators may know beforehand that NATs are not present, and
1031
thus any modification to the packet can be considered an attack.
1033
More specifically, when NAT Traversal is not enabled, all messages
1034
that can update the addresses associated with the IKE_SA and/or IPsec
1035
SAs (the first IKE_AUTH request and all INFORMATIONAL requests that
1036
contain any of the following notifications: UPDATE_SA_ADDRESSES,
1037
ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS,
1038
NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED
1039
notification. The exchange responder MUST verify that the contents
1040
of the NO_NATS_ALLOWED notification match the addresses in the IP
1041
header. If they do not match, a response containing an
1042
UNEXPECTED_NAT_DETECTED notification is sent. The response message
1043
is sent to the address and port that the corresponding request came
1044
from, not to the address contained in the NO_NATS_ALLOWED
1047
If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
1048
notification in response to its INFORMATIONAL request, it SHOULD
1049
retry the operation several times using new INFORMATIONAL requests.
1050
Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the
1051
IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several
1052
times, starting from a new IKE_SA_INIT request. This ensures that an
1053
attacker who is able to modify only a single packet does not
1054
unnecessarily cause a path to remain unused. The exact number of
1055
retries is not specified in this document because it does not affect
1056
interoperability. However, because the IKE message will also be
1057
rejected if the attacker modifies the integrity checksum field, a
1058
reasonable number here would be the number of retries that is being
1059
used for normal retransmissions.
1066
Eronen Standards Track [Page 19]
1068
RFC 4555 MOBIKE Protocol June 2006
1071
If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange
1072
responder MUST NOT use the contents of the NO_NATS_ALLOWED
1073
notification for any other purpose than possibly logging the
1074
information for troubleshooting purposes.
1078
IKEv2 Dead Peer Detection allows the peers to detect if the currently
1079
used path has stopped working. However, if either of the peers has
1080
several addresses, Dead Peer Detection alone does not tell which of
1081
the other paths might work.
1083
If required by its address selection policy, the initiator can use
1084
normal IKEv2 INFORMATIONAL request/response messages to test whether
1085
a certain path works. Implementations MAY do path testing even if
1086
the path currently being used is working to, for example, detect when
1087
a better (but previously unavailable) path becomes available.
1089
3.11. Failure Recovery and Timeouts
1091
In MOBIKE, the initiator is responsible for detecting and recovering
1094
To give the initiator enough time to detect the error, the responder
1095
SHOULD use relatively long timeout intervals when, for instance,
1096
retransmitting IKEv2 requests or deciding whether to initiate Dead
1097
Peer Detection. While no specific timeout lengths are required, it
1098
is suggested that responders continue retransmitting IKEv2 requests
1099
for at least five minutes before giving up.
1101
3.12. Dead Peer Detection
1103
MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but
1104
as addresses may change, it is not sufficient to just verify that the
1105
peer is alive, but also that it is synchronized with the address
1106
updates and has not, for instance, ignored an address update due to
1107
failure to complete return routability test. This means that when
1108
there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the
1109
addresses used in those packets and determine that they correspond to
1110
those that should be employed. If they do not, such packets SHOULD
1111
NOT be used as evidence that the peer is able to communicate with
1112
this node and or that the peer has received all address updates.
1122
Eronen Standards Track [Page 20]
1124
RFC 4555 MOBIKE Protocol June 2006
1129
This specification defines several new IKEv2 Notify payload types.
1130
See [IKEv2], Section 3.10, for a general description of the Notify
1133
4.1. Notify Messages - Error Types
1135
4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload
1137
The responder can include this notification in an INFORMATIONAL
1138
exchange response to indicate that the address change in the
1139
corresponding request message (which contained an UPDATE_SA_ADDRESSES
1140
notification) was not carried out.
1142
The Notify Message Type for UNACCEPTABLE_ADDRESSES is 40. The
1143
Protocol ID and SPI Size fields are set to zero. There is no data
1144
associated with this Notify type.
1146
4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload
1148
See Section 3.9 for a description of this notification.
1150
The Notify Message Type for UNEXPECTED_NAT_DETECTED is 41. The
1151
Protocol ID and SPI Size fields are set to zero. There is no data
1152
associated with this Notify type.
1154
4.2. Notify Messages - Status Types
1156
4.2.1. MOBIKE_SUPPORTED Notify Payload
1158
The MOBIKE_SUPPORTED notification is included in the IKE_AUTH
1159
exchange to indicate that the implementation supports this
1162
The Notify Message Type for MOBIKE_SUPPORTED is 16396. The Protocol
1163
ID and SPI Size fields are set to zero. The notification data field
1164
MUST be left empty (zero-length) when sending, and its contents (if
1165
any) MUST be ignored when this notification is received. This allows
1166
the field to be used by future versions of this protocol.
1168
4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify
1171
Both parties can include ADDITIONAL_IP4_ADDRESS and/or
1172
ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and
1173
INFORMATIONAL exchange request messages; see Section 3.4 and
1174
Section 3.6 for more detailed description.
1178
Eronen Standards Track [Page 21]
1180
RFC 4555 MOBIKE Protocol June 2006
1183
The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
1184
ADDITIONAL_IP6_ADDRESS are 16397 and 16398, respectively. The
1185
Protocol ID and SPI Size fields are set to zero. The data associated
1186
with these Notify types is either a four-octet IPv4 address or a
1187
16-octet IPv6 address.
1189
4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload
1191
The NO_ADDITIONAL_ADDRESSES notification can be included in an
1192
INFORMATIONAL exchange request message to indicate that the exchange
1193
initiator does not have addresses beyond the one used in the exchange
1194
(see Section 3.6 for more detailed description).
1196
The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399. The
1197
Protocol ID and SPI Size fields are set to zero. There is no data
1198
associated with this Notify type.
1200
4.2.4. UPDATE_SA_ADDRESSES Notify Payload
1202
This notification is included in INFORMATIONAL exchange requests sent
1203
by the initiator to update addresses of the IKE_SA and IPsec SAs (see
1206
The Notify Message Type for UPDATE_SA_ADDRESSES is 16400. The
1207
Protocol ID and SPI Size fields are set to zero. There is no data
1208
associated with this Notify type.
1210
4.2.5. COOKIE2 Notify Payload
1212
This notification MAY be included in any INFORMATIONAL request for
1213
return routability check purposes (see Section 3.7). If the
1214
INFORMATIONAL request includes COOKIE2, the exchange responder MUST
1215
copy the notification to the response message.
1217
The data associated with this notification MUST be between 8 and 64
1218
octets in length (inclusive), and MUST be chosen by the exchange
1219
initiator in a way that is unpredictable to the exchange responder.
1220
The Notify Message Type for this message is 16401. The Protocol ID
1221
and SPI Size fields are set to zero.
1223
4.2.6. NO_NATS_ALLOWED Notify Payload
1225
See Section 3.9 for a description of this notification.
1227
The Notify Message Type for this message is 16402. The notification
1228
data contains the IP addresses and ports from/to which the packet was
1229
sent. For IPv4, the notification data is 12 octets long and is
1234
Eronen Standards Track [Page 22]
1236
RFC 4555 MOBIKE Protocol June 2006
1240
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
1241
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1242
! Source IPv4 address !
1243
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1244
! Destination IPv4 address !
1245
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1246
! Source port ! Destination port !
1247
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1249
For IPv6, the notification data is 36 octets long and is defined as
1253
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
1254
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1256
! Source IPv6 address !
1259
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1261
! Destination IPv6 address !
1264
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1265
! Source port ! Destination port !
1266
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1268
The Protocol ID and SPI Size fields are set to zero.
1290
Eronen Standards Track [Page 23]
1292
RFC 4555 MOBIKE Protocol June 2006
1295
5. Security Considerations
1297
The main goals of this specification are to maintain the security
1298
offered by usual IKEv2 procedures and to counter mobility-related
1299
threats in an appropriate manner. This section describes new
1300
security considerations introduced by MOBIKE. See [IKEv2] for
1301
security considerations for IKEv2 in general.
1303
5.1. Traffic Redirection and Hijacking
1305
MOBIKE payloads relating to updating addresses are encrypted,
1306
integrity protected, and replay protected using the IKE_SA. This
1307
assures that no one except the participants can, for instance, give a
1308
control message to change the addresses.
1310
However, as with normal IKEv2, the actual IP addresses in the IP
1311
header are not covered by the integrity protection. This means that
1312
a NAT between the parties (or an attacker acting as a NAT) can modify
1313
the addresses and cause incorrect tunnel header (outer) IP addresses
1314
to be used for IPsec SAs. The scope of this attack is limited mainly
1315
to denial of service because all traffic is protected using IPsec.
1317
This attack can only be launched by on-path attackers that are
1318
capable of modifying IKEv2 messages carrying NAT detection payloads
1319
(such as Dead Peer Detection messages). By modifying the IP header
1320
of these packets, the attackers can lead the peers to believe a new
1321
NAT or a changed NAT binding exists between them. The attack can
1322
continue as long as the attacker is on the path, modifying the IKEv2
1323
messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms
1324
designed to detect NAT mapping changes will eventually recognize that
1325
the intended traffic is not getting through, and will update the
1326
addresses appropriately.
1328
MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
1329
detect modification, by outsiders, of the addresses in the IP header.
1330
When this notification is used, communication through NATs and other
1331
address translators is impossible, so it is sent only when not doing
1332
NAT Traversal. This feature is mainly intended for IPv6 and site-to-
1333
site VPN cases, where the administrators may know beforehand that
1334
NATs are not present.
1336
5.2. IPsec Payload Protection
1338
The use of IPsec protection on payload traffic protects the
1339
participants against disclosure of the contents of the traffic,
1340
should the traffic end up in an incorrect destination or be subject
1346
Eronen Standards Track [Page 24]
1348
RFC 4555 MOBIKE Protocol June 2006
1351
However, security associations originally created for the protection
1352
of a specific flow between specific addresses may be updated by
1353
MOBIKE later on. This has to be taken into account if the (outer) IP
1354
address of the peer was used when deciding what kind of IPsec SAs the
1355
peer is allowed to create.
1357
For instance, the level of required protection might depend on the
1358
current location of the VPN client, or access might be allowed only
1359
from certain IP addresses.
1361
It is recommended that security policies, for peers that are allowed
1362
to use MOBIKE, are configured in a manner that takes into account
1363
that a single security association can be used at different times
1364
through paths of varying security properties.
1366
This is especially critical for traffic selector authorization. The
1367
(logical) Peer Authorization Database (PAD) contains the information
1368
used by IKEv2 when determining what kind of IPsec SAs a peer is
1369
allowed to create. This process is described in [IPsecArch], Section
1370
4.4.3. When a peer requests the creation of an IPsec SA with some
1371
traffic selectors, the PAD must contain "Child SA Authorization Data"
1372
linking the identity authenticated by IKEv2 and the addresses
1373
permitted for traffic selectors. See also [Clarifications] for a
1374
more extensive discussion.
1376
It is important to note that simply sending IKEv2 packets using some
1377
particular address does not automatically imply a permission to
1378
create IPsec SAs with that address in the traffic selectors.
1379
However, some implementations are known to use policies where simply
1380
being reachable at some address X implies a temporary permission to
1381
create IPsec SAs for address X. Here "being reachable" usually means
1382
the ability to send (or spoof) IP packets with source address X and
1383
receive (or eavesdrop) packets sent to X.
1385
Using this kind of policies or extensions with MOBIKE may need
1386
special care to enforce the temporary nature of the permission. For
1387
example, when the peer moves to some other address Y (and is no
1388
longer reachable at X), it might be necessary to close IPsec SAs with
1389
traffic selectors matching X. However, these interactions are beyond
1390
the scope of this document.
1392
5.3. Denial-of-Service Attacks against Third Parties
1394
Traffic redirection may be performed not just to gain access to the
1395
traffic or to deny service to the peers, but also to cause a denial-
1396
of-service attack on a third party. For instance, a high-speed TCP
1397
session or a multimedia stream may be redirected towards a victim
1398
host, causing its communications capabilities to suffer.
1402
Eronen Standards Track [Page 25]
1404
RFC 4555 MOBIKE Protocol June 2006
1407
The attackers in this threat can be either outsiders or even one of
1408
the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers
1409
can be easily dealt with if the authentication performed in the
1410
initial IKEv2 negotiation can be traced to persons who can be held
1411
responsible for the attack. This may not be the case in all
1412
scenarios, particularly with opportunistic approaches to security.
1414
If the attack is launched by an outsider, the traffic flow would
1415
normally stop soon due to the lack of responses (such as transport
1416
layer acknowledgements). However, if the original recipient of the
1417
flow is malicious, it could maintain the traffic flow for an extended
1418
period of time, since it often would be able to send the required
1419
acknowledgements (see [Aura02] for more discussion).
1421
It should also be noted, as shown in [Bombing], that without ingress
1422
filtering in the attacker's network, such attacks are already
1423
possible simply by sending spoofed packets from the attacker to the
1424
victim directly. Furthermore, if the attacker's network has ingress
1425
filtering, this attack is largely prevented for MOBIKE as well.
1426
Consequently, it makes little sense to protect against attacks of
1427
similar nature in MOBIKE. However, it still makes sense to limit the
1428
amplification capabilities provided to attackers, so that they cannot
1429
use stream redirection to send a large number of packets to the
1430
victim by sending just a few packets themselves.
1432
This specification includes return routability tests to limit the
1433
duration of any "third party bombing" attacks by off-path (relative
1434
to the victim) attackers. The tests are authenticated messages that
1435
the peer has to respond to, and can be performed before the address
1436
change takes effect, immediately afterwards, or even periodically
1437
during the session. The tests contain unpredictable data, and only
1438
someone who has the keys associated with the IKE SA and has seen the
1439
request packet can properly respond to the test.
1441
The duration of the attack can also be limited if the victim reports
1442
the unwanted traffic to the originating IPsec tunnel endpoint using
1443
ICMP error messages or INVALID_SPI notifications. As described in
1444
[IKEv2], Section 2.21, this SHOULD trigger a liveness test, which
1445
also doubles as a return routability check if the COOKIE2
1446
notification is included.
1448
5.4. Spoofing Network Connectivity Indications
1450
Attackers may spoof various indications from lower layers and the
1451
network in an effort to confuse the peers about which addresses are
1452
or are not working. For example, attackers may spoof link-layer
1453
error messages in an effort to cause the parties to move their
1454
traffic elsewhere or even to disconnect. Attackers may also spoof
1458
Eronen Standards Track [Page 26]
1460
RFC 4555 MOBIKE Protocol June 2006
1463
information related to network attachments, router discovery, and
1464
address assignments in an effort to make the parties believe they
1465
have Internet connectivity when, in reality, they do not.
1467
This may cause use of non-preferred addresses or even denial of
1470
MOBIKE does not provide any protection of its own for indications
1471
from other parts of the protocol stack. These vulnerabilities can be
1472
mitigated through the use of techniques specific to the other parts
1473
of the stack, such as validation of ICMP errors [ICMPAttacks], link
1474
layer security, or the use of [SEND] to protect IPv6 Router and
1477
Ultimately, MOBIKE depends on the delivery of IKEv2 messages to
1478
determine which paths can be used. If IKEv2 messages sent using a
1479
particular source and destination addresses reach the recipient and a
1480
reply is received, MOBIKE will usually consider the path working; if
1481
no reply is received even after retransmissions, MOBIKE will suspect
1482
the path is broken. An attacker who can consistently control the
1483
delivery or non-delivery of the IKEv2 messages in the network can
1484
thus influence which addresses actually get used.
1486
5.5. Address and Topology Disclosure
1488
MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/
1489
ADDITIONAL_IP6_ADDRESS notifications reveal information about which
1490
networks the peers are connected to.
1492
For example, consider a host A with two network interfaces: a
1493
cellular connection and a wired Ethernet connection to a company LAN.
1494
If host A now contacts host B using IKEv2 and sends
1495
ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B
1496
receives additional information it might not otherwise know. If host
1497
A used the cellular connection for the IKEv2 traffic, host B can also
1498
see the company LAN address (and perhaps further guess that host A is
1499
used by an employee of that company). If host A used the company LAN
1500
to make the connection, host B can see that host A has a subscription
1501
from this particular cellular operator.
1503
These additional addresses can also disclose more accurate location
1504
information than just a single address. Suppose that host A uses its
1505
cellular connection for IKEv2 traffic, but also sends an
1506
ADDITIONAL_IP4_ADDRESS notification containing an IP address
1507
corresponding to, say, a wireless LAN at a particular coffee shop
1508
location. It is likely that host B can now make a much better guess
1509
at A's location than would be possible based on the cellular IP
1514
Eronen Standards Track [Page 27]
1516
RFC 4555 MOBIKE Protocol June 2006
1519
Furthermore, as described in Section 3.4, some of the addresses could
1520
also be private addresses behind a NAT.
1522
In many environments, disclosing address information is not a problem
1523
(and indeed it cannot be avoided if the hosts wish to use those
1524
addresses for IPsec traffic). For instance, a remote access VPN
1525
client could consider the corporate VPN gateway sufficiently
1526
trustworthy for this purpose. Furthermore, the
1527
ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are
1528
sent encrypted, so the addresses are not visible to eavesdroppers
1529
(unless, of course, they are later used for sending IKEv2/IPsec
1532
However, if MOBIKE is used in some more opportunistic approach, it
1533
can be desirable to limit the information that is sent. Naturally,
1534
the peers do not have to disclose any addresses they do not want to
1535
use for IPsec traffic. Also, as noted in Section 3.6, an initiator
1536
whose policy is to always use the locally configured responder
1537
address does not have to send any ADDITIONAL_IP4_ADDRESS/
1538
ADDITIONAL_IP6_ADDRESS payloads.
1540
6. IANA Considerations
1542
This document does not create any new namespaces to be maintained by
1543
IANA, but it requires new values in namespaces that have been defined
1544
in the IKEv2 base specification [IKEv2].
1546
This document defines several new IKEv2 notifications whose values
1547
have been allocated from the "IKEv2 Notify Message Types" namespace.
1549
Notify Messages - Error Types Value
1550
----------------------------- -----
1551
UNACCEPTABLE_ADDRESSES 40
1552
UNEXPECTED_NAT_DETECTED 41
1554
Notify Messages - Status Types Value
1555
------------------------------ -----
1556
MOBIKE_SUPPORTED 16396
1557
ADDITIONAL_IP4_ADDRESS 16397
1558
ADDITIONAL_IP6_ADDRESS 16398
1559
NO_ADDITIONAL_ADDRESSES 16399
1560
UPDATE_SA_ADDRESSES 16400
1562
NO_NATS_ALLOWED 16402
1564
These notifications are described in Section 4.
1570
Eronen Standards Track [Page 28]
1572
RFC 4555 MOBIKE Protocol June 2006
1577
This document is a collaborative effort of the entire MOBIKE WG. We
1578
would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo
1579
Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti,
1580
Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann,
1581
Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld,
1582
Maureen Stillman, Shinta Sugimoto, Hannes Tschofenig, and Sami
1583
Vaarala. This document also incorporates ideas and text from earlier
1584
MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen],
1585
[MOPO], and [SMOBIKE], and the MOBIKE design document [Design].
1589
8.1. Normative References
1591
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2)
1592
Protocol", RFC 4306, December 2005.
1594
[IPsecArch] Kent, S. and K. Seo, "Security Architecture for the
1595
Internet Protocol", RFC 4301, December 2005.
1597
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1598
Requirement Levels", RFC 2119, March 1997.
1600
8.2. Informative References
1602
[AddrMgmt] Dupont, F., "Address Management for IKE version 2",
1603
Work in Progress, November 2005.
1605
[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of
1606
Internet Location Management", Proc. 18th Annual
1607
Computer Security Applications Conference (ACSAC),
1610
[Bombing] Dupont, F., "A note about 3rd party bombing in
1611
Mobile IPv6", Work in Progress, December 2005.
1613
[Clarifications] Eronen, P. and P. Hoffman, "IKEv2 Clarifications
1614
and Implementation Guidelines", Work in Progress,
1617
[DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
1618
Network Attachment in IPv4 (DNAv4)", RFC 4436,
1626
Eronen Standards Track [Page 29]
1628
RFC 4555 MOBIKE Protocol June 2006
1631
[DNA6] Narayanan, S., Daley, G., and N. Montavont,
1632
"Detecting Network Attachment in IPv6 - Best
1633
Current Practices for hosts", Work in Progress,
1636
[Design] Kivinen, T. and H. Tschofenig, "Design of the
1637
MOBIKE protocol", Work in Progress, January 2006.
1639
[ICMPAttacks] Gont, F., "ICMP attacks against TCP", Work in
1640
Progress, October 2005.
1642
[Kivinen] Kivinen, T., "MOBIKE protocol", Work in Progress,
1645
[MIP4] Perkins, C., "IP Mobility Support for IPv4",
1646
RFC 3344, August 2002.
1648
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
1649
Support in IPv6", RFC 3775, June 2004.
1651
[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2
1652
(MOPO-IKE)", Work in Progress, February 2005.
1654
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
1655
Discovery for IP Version 6 (IPv6)", RFC 2461,
1658
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
1659
"SEcure Neighbor Discovery (SEND)", RFC 3971,
1662
[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and
1663
Multihoming Extensions for IKEv2 (SMOBIKE)",
1664
Work in Progress, March 2004.
1666
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R.
1667
Mahy, "STUN - Simple Traversal of User Datagram
1668
Protocol (UDP) Through Network Address Translators
1669
(NATs)", RFC 3489, March 2003.
1671
[UNSAF] Daigle, L., "IAB Considerations for UNilateral
1672
Self-Address Fixing (UNSAF) Across Network Address
1673
Translation", RFC 3424, November 2002.
1682
Eronen Standards Track [Page 30]
1684
RFC 4555 MOBIKE Protocol June 2006
1687
Appendix A. Implementation Considerations
1689
A.1. Links from SPD Cache to Outbound SAD Entries
1691
[IPsecArch], Section 4.4.2, says that "For outbound processing, each
1692
SAD entry is pointed to by entries in the SPD-S part of the SPD
1693
cache". The document does not specify how exactly this "pointing" is
1694
done, since this is an implementation detail that does not have to be
1697
However, it is clear that the links between the SPD cache and the SAD
1698
have to be done correctly to ensure that outbound packets are sent
1699
over the right SA. Some implementations are known to have problems
1702
In particular, simply storing the (remote tunnel header IP address,
1703
remote SPI) pair in the SPD cache is not sufficient, since the pair
1704
does not always uniquely identify a single SAD entry. For instance,
1705
two hosts behind the same NAT can accidentally happen to choose the
1706
same SPI value. The situation can also occur when a host is assigned
1707
an IP address previously used by some other host, and the SAs
1708
associated with the old host have not yet been deleted by Dead Peer
1709
Detection. This may lead to packets being sent over the wrong SA or,
1710
if the key management daemon ensures the pair is unique, denying the
1711
creation of otherwise valid SAs.
1713
Storing the remote tunnel header IP address in the SPD cache may also
1714
complicate the implementation of MOBIKE, since the address can change
1715
during the lifetime of the SA. Thus, we recommend implementing the
1716
links between the SPD cache and the SAD in a way that does not
1717
require modification when the tunnel header IP address is updated by
1720
A.2. Creating Outbound SAs
1722
When an outbound packet requires IPsec processing but no suitable SA
1723
exists, a new SA will be created. In this case, the host has to
1724
determine (1) who is the right peer for this SA, (2) whether the host
1725
already has an IKE_SA with this peer, and (3) if no IKE_SA exists,
1726
the IP address(es) of the peer for contacting it.
1728
Neither [IPsecArch] nor MOBIKE specifies how exactly these three
1729
steps are carried out. [IPsecArch], Section 4.4.3.4, says:
1738
Eronen Standards Track [Page 31]
1740
RFC 4555 MOBIKE Protocol June 2006
1743
For example, assume that IKE A receives an outbound packet
1744
destined for IP address X, a host served by a security gateway.
1745
RFC 2401 [RFC2401] and this document do not specify how A
1746
determines the address of the IKE peer serving X. However, any
1747
peer contacted by A as the presumed representative for X must be
1748
registered in the PAD in order to allow the IKE exchange to be
1749
authenticated. Moreover, when the authenticated peer asserts that
1750
it represents X in its traffic selector exchange, the PAD will be
1751
consulted to determine if the peer in question is authorized to
1754
In step 1, there may be more than one possible peer (e.g., several
1755
security gateways that are allowed to represent X). In step 3, the
1756
host may need to consult a directory such as DNS to determine the
1757
peer IP address(es).
1759
When performing these steps, implementations may use information
1760
contained in the SPD, the PAD, and possibly some other
1761
implementation-specific databases. Regardless of how exactly the
1762
steps are implemented, it is important to remember that IP addresses
1763
can change, and that an IP address alone does not always uniquely
1764
identify a single IKE peer (for the same reasons as why the
1765
combination of the remote IP address and SPI does not uniquely
1766
identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1
1767
and 2 it may be easier to identify the "right peer" using its
1768
authenticated identity instead of its current IP address. However,
1769
these implementation details are beyond the scope of this
1774
Pasi Eronen (editor)
1775
Nokia Research Center
1777
FIN-00045 Nokia Group
1780
EMail: pasi.eronen@nokia.com
1794
Eronen Standards Track [Page 32]
1796
RFC 4555 MOBIKE Protocol June 2006
1799
Full Copyright Statement
1801
Copyright (C) The Internet Society (2006).
1803
This document is subject to the rights, licenses and restrictions
1804
contained in BCP 78, and except as set forth therein, the authors
1805
retain all their rights.
1807
This document and the information contained herein are provided on an
1808
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1809
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1810
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1811
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1812
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1813
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1815
Intellectual Property
1817
The IETF takes no position regarding the validity or scope of any
1818
Intellectual Property Rights or other rights that might be claimed to
1819
pertain to the implementation or use of the technology described in
1820
this document or the extent to which any license under such rights
1821
might or might not be available; nor does it represent that it has
1822
made any independent effort to identify any such rights. Information
1823
on the procedures with respect to rights in RFC documents can be
1824
found in BCP 78 and BCP 79.
1826
Copies of IPR disclosures made to the IETF Secretariat and any
1827
assurances of licenses to be made available, or the result of an
1828
attempt made to obtain a general license or permission for the use of
1829
such proprietary rights by implementers or users of this
1830
specification can be obtained from the IETF on-line IPR repository at
1831
http://www.ietf.org/ipr.
1833
The IETF invites any interested party to bring to its attention any
1834
copyrights, patents or patent applications, or other proprietary
1835
rights that may cover technology that may be required to implement
1836
this standard. Please address the information to the IETF at
1841
Funding for the RFC Editor function is provided by the IETF
1842
Administrative Support Activity (IASA).
1850
Eronen Standards Track [Page 33]
added
removed
doc/standards/rfc4555.txt
