Add compile option to disable internal handling of fatal signals
[strongswan.git] / doc / standards / rfc4555.txt
1
2
3
4
5
6
7 Network Working Group                                     P. Eronen, Ed.
8 Request for Comments: 4555                                         Nokia
9 Category: Standards Track                                      June 2006
10
11
12             IKEv2 Mobility and Multihoming Protocol (MOBIKE)
13
14 Status of This Memo
15
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.
21
22 Copyright Notice
23
24    Copyright (C) The Internet Society (2006).
25
26 Abstract
27
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
36    working.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 Eronen                      Standards Track                     [Page 1]
59 \f
60 RFC 4555                    MOBIKE Protocol                    June 2006
61
62
63 Table of Contents
64
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
103
104
105
106
107
108
109
110
111
112
113
114 Eronen                      Standards Track                     [Page 2]
115 \f
116 RFC 4555                    MOBIKE Protocol                    June 2006
117
118
119 1.  Introduction
120
121 1.1.  Motivation
122
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.
132
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.
138
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
147    such a mechanism.
148
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
160    VPN.
161
162
163
164
165
166
167
168
169
170 Eronen                      Standards Track                     [Page 3]
171 \f
172 RFC 4555                    MOBIKE Protocol                    June 2006
173
174
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
180    other parties.
181
182 1.2.  Scope and Limitations
183
184    This document focuses on the main scenario outlined above and
185    supports only tunnel mode IPsec SAs.
186
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
193    (see Section 3.1).
194
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.
198
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.
203
204    Network Address Translators (NATs) introduce additional limitations
205    beyond those listed above.  For details, refer to Section 2.3.
206
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.
213
214 1.3.  Terminology and Notation
215
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.
223
224
225
226 Eronen                      Standards Track                     [Page 4]
227 \f
228 RFC 4555                    MOBIKE Protocol                    June 2006
229
230
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
239    have to be updated.
240
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.
249
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].
253
254 2.  Protocol Overview
255
256 2.1.  Basic Operation
257
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
266    so on.
267
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.
279
280
281
282 Eronen                      Standards Track                     [Page 5]
283 \f
284 RFC 4555                    MOBIKE Protocol                    June 2006
285
286
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
292    downstream traffic.
293
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).
303
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],
311    [DNA6], and so on.
312
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.
322
323 2.2.  Example Protocol Exchanges
324
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.
330
331
332
333
334
335
336
337
338 Eronen                      Standards Track                     [Page 6]
339 \f
340 RFC 4555                    MOBIKE Protocol                    June 2006
341
342
343       Initiator                  Responder
344      -----------                -----------
345    1) (IP_I1:500 -> IP_R1:500)
346       HDR, SAi1, KEi, Ni,
347            N(NAT_DETECTION_SOURCE_IP),
348            N(NAT_DETECTION_DESTINATION_IP)  -->
349
350                             <--  (IP_R1:500 -> IP_I1:500)
351                                  HDR, SAr1, KEr, Nr,
352                                       N(NAT_DETECTION_SOURCE_IP),
353                                       N(NAT_DETECTION_DESTINATION_IP)
354
355    2) (IP_I1:4500 -> IP_R1:4500)
356       HDR, SK { IDi, CERT, AUTH,
357                 CP(CFG_REQUEST),
358                 SAi2, TSi, TSr,
359                 N(MOBIKE_SUPPORTED) }  -->
360
361                             <--  (IP_R1:4500 -> IP_I1:4500)
362                                  HDR, SK { IDr, CERT, AUTH,
363                                            CP(CFG_REPLY),
364                                            SAr2, TSi, TSr,
365                                            N(MOBIKE_SUPPORTED) }
366
367    (Initiator gets information from lower layers that its attachment
368    point and address have changed.)
369
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) }  -->
374
375                             <-- (IP_R1:4500 -> IP_I2:4500)
376                                 HDR, SK { N(NAT_DETECTION_SOURCE_IP),
377                                      N(NAT_DETECTION_DESTINATION_IP) }
378
379    (Responder verifies that the initiator has given it a correct IP
380    address.)
381
382    4)                       <-- (IP_R1:4500 -> IP_I2:4500)
383                                 HDR, SK { N(COOKIE2) }
384
385       (IP_I2:4500 -> IP_R1:4500)
386       HDR, SK { N(COOKIE2) }  -->
387
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
391
392
393
394 Eronen                      Standards Track                     [Page 7]
395 \f
396 RFC 4555                    MOBIKE Protocol                    June 2006
397
398
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.
408
409    Another protocol run in a multihoming scenario is illustrated below.
410    In this scenario, the initiator has one address but the responder has
411    two.
412
413       Initiator                  Responder
414      -----------                -----------
415    1) (IP_I1:500 -> IP_R1:500)
416       HDR, SAi1, KEi, Ni,
417            N(NAT_DETECTION_SOURCE_IP),
418            N(NAT_DETECTION_DESTINATION_IP)  -->
419
420                             <--  (IP_R1:500 -> IP_I1:500)
421                                  HDR, SAr1, KEr, Nr,
422                                       N(NAT_DETECTION_SOURCE_IP),
423                                       N(NAT_DETECTION_DESTINATION_IP)
424
425    2) (IP_I1:4500 -> IP_R1:4500)
426       HDR, SK { IDi, CERT, AUTH,
427                 CP(CFG_REQUEST),
428                 SAi2, TSi, TSr,
429                 N(MOBIKE_SUPPORTED) }  -->
430
431                             <--  (IP_R1:4500 -> IP_I1:4500)
432                                  HDR, SK { IDr, CERT, AUTH,
433                                            CP(CFG_REPLY),
434                                            SAr2, TSi, TSr,
435                                            N(MOBIKE_SUPPORTED),
436                                            N(ADDITIONAL_IP4_ADDRESS) }
437
438    (The initiator suspects a problem in the currently used address pair
439    and probes its liveness.)
440
441
442
443
444
445
446
447
448
449
450 Eronen                      Standards Track                     [Page 8]
451 \f
452 RFC 4555                    MOBIKE Protocol                    June 2006
453
454
455    3) (IP_I1:4500 -> IP_R1:4500)
456       HDR, SK { N(NAT_DETECTION_SOURCE_IP),
457                 N(NAT_DETECTION_DESTINATION_IP) }  -->
458
459       (IP_I1:4500 -> IP_R1:4500)
460       HDR, SK { N(NAT_DETECTION_SOURCE_IP),
461                 N(NAT_DETECTION_DESTINATION_IP) }  -->
462
463       ...
464
465    (Eventually, the initiator gives up on the current address pair and
466    tests the other available address pair.)
467
468    4) (IP_I1:4500 -> IP_R2:4500)
469       HDR, SK { N(NAT_DETECTION_SOURCE_IP),
470                 N(NAT_DETECTION_DESTINATION_IP) }
471
472                             <--  (IP_R2:4500 -> IP_I1:4500)
473                                  HDR, SK { N(NAT_DETECTION_SOURCE_IP),
474                                       N(NAT_DETECTION_DESTINATION_IP) }
475
476    (This worked, and the initiator requests the peer to switch to new
477    addresses.)
478
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),
483                 N(COOKIE2) }  -->
484
485                             <--  (IP_R2:4500 -> IP_I1:4500)
486                                  HDR, SK { N(NAT_DETECTION_SOURCE_IP),
487                                       N(NAT_DETECTION_DESTINATION_IP),
488                                       N(COOKIE2) }
489
490 2.3.  MOBIKE and Network Address Translation (NAT)
491
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
498    needed.
499
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
503
504
505
506 Eronen                      Standards Track                     [Page 9]
507 \f
508 RFC 4555                    MOBIKE Protocol                    June 2006
509
510
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
520    address).
521
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
533    document.
534
535 3.  Protocol Exchanges
536
537 3.1.  Initial IKE Exchange
538
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.
546
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
550    IKE_SA_INIT request.
551
552 3.2.  Signaling Support for MOBIKE
553
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
557    payload).
558
559
560
561
562 Eronen                      Standards Track                    [Page 10]
563 \f
564 RFC 4555                    MOBIKE Protocol                    June 2006
565
566
567    The format of the MOBIKE_SUPPORTED notification is described in
568    Section 4.
569
570 3.3.  Initial Tunnel Header Addresses
571
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.
577
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
584    some other path).
585
586 3.4.  Additional Addresses
587
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
593    notification.
594
595       Initiator                  Responder
596      -----------                -----------
597       HDR, SK { IDi, [CERT], [IDr], AUTH,
598                 [CP(CFG_REQUEST)]
599                 SAi2, TSi, TSr,
600                 N(MOBIKE_SUPPORTED),
601                 [N(ADDITIONAL_*_ADDRESS)+] }  -->
602
603                             <--  HDR, SK { IDr, [CERT], AUTH,
604                                            [CP(CFG_REPLY)],
605                                            SAr2, TSi, TSr,
606                                            N(MOBIKE_SUPPORTED)
607                                            [N(ADDITIONAL_*_ADDRESS)+] }
608
609    The recipient stores this information, but no other action is taken
610    at this time.
611
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.
615
616
617
618 Eronen                      Standards Track                    [Page 11]
619 \f
620 RFC 4555                    MOBIKE Protocol                    June 2006
621
622
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).
629
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.
633
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.
642
643 3.5.  Changing Addresses in IPsec SAs
644
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.)
650
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.
660
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
664    addresses.
665
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
668       no longer working.
669
670
671
672
673
674 Eronen                      Standards Track                    [Page 12]
675 \f
676 RFC 4555                    MOBIKE Protocol                    June 2006
677
678
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.
684
685    o  An UNACCEPTABLE_ADDRESSES notification is received as a response
686       to address update request (described below).
687
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).
691
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:
695
696    o  Updates the IKE_SA with the new addresses, and sets the
697       "pending_update" flag in the IKE_SA.
698
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).
703
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-
710       Keepalive packets).
711
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).
715
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:
720
721
722
723
724
725
726
727
728
729
730 Eronen                      Standards Track                    [Page 13]
731 \f
732 RFC 4555                    MOBIKE Protocol                    June 2006
733
734
735       Initiator                  Responder
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)],
741                 [N(COOKIE2)] } -->
742
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).
746
747    When processing an INFORMATIONAL request containing the
748    UPDATE_SA_ADDRESSES notification, the responder:
749
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.
755
756    o  If the NO_NATS_ALLOWED notification is present, processes it as
757       described in Section 3.9.
758
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).
763
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].)
768
769    o  Replies with an INFORMATIONAL response:
770
771       Initiator                  Responder
772      -----------                -----------
773                             <--  HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
774                                       N(NAT_DETECTION_DESTINATION_IP)],
775                                       [N(COOKIE2)] }
776
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
779       completed.
780
781    o  Updates the IPsec SAs associated with this IKE_SA with the new
782       addresses.
783
784
785
786 Eronen                      Standards Track                    [Page 14]
787 \f
788 RFC 4555                    MOBIKE Protocol                    June 2006
789
790
791    o  If NAT Traversal is supported and NAT detection payloads were
792       included, enables or disables NAT Traversal.
793
794    When the initiator receives the reply:
795
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).
800
801    o  If the response contains the UNEXPECTED_NAT_DETECTED notification,
802       the initiator processes the response as described in Section 3.9.
803
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.
807
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
811       required).
812
813    o  If NAT Traversal is supported and NAT detection payloads were
814       included, the initiator enables or disables NAT Traversal.
815
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).
823
824 3.6.  Updating Additional Addresses
825
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.
832
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.
838
839
840
841
842 Eronen                      Standards Track                    [Page 15]
843 \f
844 RFC 4555                    MOBIKE Protocol                    June 2006
845
846
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).
850
851    The message exchange will look as follows:
852
853       Initiator                  Responder
854      -----------                -----------
855       HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
856                 [N(NO_ADDITIONAL_ADDRESSES)],
857                 [N(NO_NATS_ALLOWED)],
858                 [N(COOKIE2)] }  -->
859
860                             <--  HDR, SK { [N(COOKIE2)] }
861
862    When a request containing an ADDITIONAL_IP4_ADDRESS,
863    ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
864    received, the exchange responder:
865
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
870       updated.
871
872    o  If the NO_NATS_ALLOWED notification is present, processes it as
873       described in Section 3.9.
874
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.
878
879    o  Sends a response.
880
881    The initiator MAY include these notifications in the same request as
882    UPDATE_SA_ADDRESSES.
883
884    If the request to update the addresses is retransmitted using several
885    different source addresses, a new INFORMATIONAL request MUST be sent.
886
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.
894
895
896
897
898 Eronen                      Standards Track                    [Page 16]
899 \f
900 RFC 4555                    MOBIKE Protocol                    June 2006
901
902
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
913    address).
914
915 3.7.  Return Routability Check
916
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.
924
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.
930
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.
935
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.)
945
946
947
948
949
950
951
952
953
954 Eronen                      Standards Track                    [Page 17]
955 \f
956 RFC 4555                    MOBIKE Protocol                    June 2006
957
958
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.
965
966 3.8.  Changes in NAT Mappings
967
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.
970
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).
979
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.
991
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.
997
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.
1006
1007
1008
1009
1010 Eronen                      Standards Track                    [Page 18]
1011 \f
1012 RFC 4555                    MOBIKE Protocol                    June 2006
1013
1014
1015 3.9.  NAT Prohibition
1016
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.
1023
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.
1032
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
1045    notification.
1046
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.
1060
1061
1062
1063
1064
1065
1066 Eronen                      Standards Track                    [Page 19]
1067 \f
1068 RFC 4555                    MOBIKE Protocol                    June 2006
1069
1070
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.
1075
1076 3.10.  Path Testing
1077
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.
1082
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.
1088
1089 3.11.  Failure Recovery and Timeouts
1090
1091    In MOBIKE, the initiator is responsible for detecting and recovering
1092    from most failures.
1093
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.
1100
1101 3.12.  Dead Peer Detection
1102
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.
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122 Eronen                      Standards Track                    [Page 20]
1123 \f
1124 RFC 4555                    MOBIKE Protocol                    June 2006
1125
1126
1127 4.  Payload Formats
1128
1129    This specification defines several new IKEv2 Notify payload types.
1130    See [IKEv2], Section 3.10, for a general description of the Notify
1131    payload.
1132
1133 4.1.  Notify Messages - Error Types
1134
1135 4.1.1.  UNACCEPTABLE_ADDRESSES Notify Payload
1136
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.
1141
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.
1145
1146 4.1.2.  UNEXPECTED_NAT_DETECTED Notify Payload
1147
1148    See Section 3.9 for a description of this notification.
1149
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.
1153
1154 4.2.  Notify Messages - Status Types
1155
1156 4.2.1.  MOBIKE_SUPPORTED Notify Payload
1157
1158    The MOBIKE_SUPPORTED notification is included in the IKE_AUTH
1159    exchange to indicate that the implementation supports this
1160    specification.
1161
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.
1167
1168 4.2.2.  ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify
1169         Payloads
1170
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.
1175
1176
1177
1178 Eronen                      Standards Track                    [Page 21]
1179 \f
1180 RFC 4555                    MOBIKE Protocol                    June 2006
1181
1182
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.
1188
1189 4.2.3.  NO_ADDITIONAL_ADDRESSES Notify Payload
1190
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).
1195
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.
1199
1200 4.2.4.  UPDATE_SA_ADDRESSES Notify Payload
1201
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
1204    Section 3.5).
1205
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.
1209
1210 4.2.5.  COOKIE2 Notify Payload
1211
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.
1216
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.
1222
1223 4.2.6.  NO_NATS_ALLOWED Notify Payload
1224
1225    See Section 3.9 for a description of this notification.
1226
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
1230    defined as follows:
1231
1232
1233
1234 Eronen                      Standards Track                    [Page 22]
1235 \f
1236 RFC 4555                    MOBIKE Protocol                    June 2006
1237
1238
1239                            1                   2                   3
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       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1248
1249    For IPv6, the notification data is 36 octets long and is defined as
1250    follows:
1251
1252                            1                   2                   3
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       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1255       !                                                               !
1256       !                      Source IPv6 address                      !
1257       !                                                               !
1258       !                                                               !
1259       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1260       !                                                               !
1261       !                   Destination IPv6 address                    !
1262       !                                                               !
1263       !                                                               !
1264       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1265       !          Source port          !       Destination port        !
1266       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1267
1268    The Protocol ID and SPI Size fields are set to zero.
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290 Eronen                      Standards Track                    [Page 23]
1291 \f
1292 RFC 4555                    MOBIKE Protocol                    June 2006
1293
1294
1295 5.  Security Considerations
1296
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.
1302
1303 5.1.  Traffic Redirection and Hijacking
1304
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.
1309
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.
1316
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.
1327
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.
1335
1336 5.2.  IPsec Payload Protection
1337
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
1341    to eavesdropping.
1342
1343
1344
1345
1346 Eronen                      Standards Track                    [Page 24]
1347 \f
1348 RFC 4555                    MOBIKE Protocol                    June 2006
1349
1350
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.
1356
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.
1360
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.
1365
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.
1375
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.
1384
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.
1391
1392 5.3.  Denial-of-Service Attacks against Third Parties
1393
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.
1399
1400
1401
1402 Eronen                      Standards Track                    [Page 25]
1403 \f
1404 RFC 4555                    MOBIKE Protocol                    June 2006
1405
1406
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.
1413
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).
1420
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.
1431
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.
1440
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.
1447
1448 5.4.  Spoofing Network Connectivity Indications
1449
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
1455
1456
1457
1458 Eronen                      Standards Track                    [Page 26]
1459 \f
1460 RFC 4555                    MOBIKE Protocol                    June 2006
1461
1462
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.
1466
1467    This may cause use of non-preferred addresses or even denial of
1468    service.
1469
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
1475    Neighbor Discovery.
1476
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.
1485
1486 5.5.  Address and Topology Disclosure
1487
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.
1491
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.
1502
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
1510    address alone.
1511
1512
1513
1514 Eronen                      Standards Track                    [Page 27]
1515 \f
1516 RFC 4555                    MOBIKE Protocol                    June 2006
1517
1518
1519    Furthermore, as described in Section 3.4, some of the addresses could
1520    also be private addresses behind a NAT.
1521
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
1530    traffic).
1531
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.
1539
1540 6.  IANA Considerations
1541
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].
1545
1546    This document defines several new IKEv2 notifications whose values
1547    have been allocated from the "IKEv2 Notify Message Types" namespace.
1548
1549       Notify Messages - Error Types     Value
1550       -----------------------------     -----
1551       UNACCEPTABLE_ADDRESSES            40
1552       UNEXPECTED_NAT_DETECTED           41
1553
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
1561       COOKIE2                           16401
1562       NO_NATS_ALLOWED                   16402
1563
1564    These notifications are described in Section 4.
1565
1566
1567
1568
1569
1570 Eronen                      Standards Track                    [Page 28]
1571 \f
1572 RFC 4555                    MOBIKE Protocol                    June 2006
1573
1574
1575 7.  Acknowledgements
1576
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].
1586
1587 8.  References
1588
1589 8.1.  Normative References
1590
1591    [IKEv2]           Kaufman, C., "Internet Key Exchange (IKEv2)
1592                      Protocol", RFC 4306, December 2005.
1593
1594    [IPsecArch]       Kent, S. and K. Seo, "Security Architecture for the
1595                      Internet Protocol", RFC 4301, December 2005.
1596
1597    [KEYWORDS]        Bradner, S., "Key words for use in RFCs to Indicate
1598                      Requirement Levels", RFC 2119, March 1997.
1599
1600 8.2.  Informative References
1601
1602    [AddrMgmt]        Dupont, F., "Address Management for IKE version 2",
1603                      Work in Progress, November 2005.
1604
1605    [Aura02]          Aura, T., Roe, M., and J. Arkko, "Security of
1606                      Internet Location Management",  Proc. 18th Annual
1607                      Computer Security Applications Conference (ACSAC),
1608                      December 2002.
1609
1610    [Bombing]         Dupont, F., "A note about 3rd party bombing in
1611                      Mobile IPv6", Work in Progress, December 2005.
1612
1613    [Clarifications]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications
1614                      and Implementation Guidelines", Work in Progress,
1615                      February 2006.
1616
1617    [DNA4]            Aboba, B., Carlson, J., and S. Cheshire, "Detecting
1618                      Network Attachment in IPv4 (DNAv4)", RFC 4436,
1619                      March 2006.
1620
1621
1622
1623
1624
1625
1626 Eronen                      Standards Track                    [Page 29]
1627 \f
1628 RFC 4555                    MOBIKE Protocol                    June 2006
1629
1630
1631    [DNA6]            Narayanan, S., Daley, G., and N. Montavont,
1632                      "Detecting Network Attachment in IPv6 - Best
1633                      Current Practices for hosts", Work in Progress,
1634                      October 2005.
1635
1636    [Design]          Kivinen, T. and H. Tschofenig, "Design of the
1637                      MOBIKE protocol", Work in Progress, January 2006.
1638
1639    [ICMPAttacks]     Gont, F., "ICMP attacks against TCP", Work in
1640                      Progress, October 2005.
1641
1642    [Kivinen]         Kivinen, T., "MOBIKE protocol", Work in Progress,
1643                      February 2004.
1644
1645    [MIP4]            Perkins, C., "IP Mobility Support for IPv4",
1646                      RFC 3344, August 2002.
1647
1648    [MIP6]            Johnson, D., Perkins, C., and J. Arkko, "Mobility
1649                      Support in IPv6", RFC 3775, June 2004.
1650
1651    [MOPO]            Eronen, P., "Mobility Protocol Options for IKEv2
1652                      (MOPO-IKE)", Work in Progress, February 2005.
1653
1654    [RFC2461]         Narten, T., Nordmark, E., and W. Simpson, "Neighbor
1655                      Discovery for IP Version 6 (IPv6)", RFC 2461,
1656                      December 1998.
1657
1658    [SEND]            Arkko, J., Kempf, J., Zill, B., and P. Nikander,
1659                      "SEcure Neighbor Discovery (SEND)", RFC 3971,
1660                      March 2005.
1661
1662    [SMOBIKE]         Eronen, P. and H. Tschofenig, "Simple Mobility and
1663                      Multihoming Extensions for IKEv2 (SMOBIKE)",
1664                      Work in Progress, March 2004.
1665
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.
1670
1671    [UNSAF]           Daigle, L., "IAB Considerations for UNilateral
1672                      Self-Address Fixing (UNSAF) Across Network Address
1673                      Translation", RFC 3424, November 2002.
1674
1675
1676
1677
1678
1679
1680
1681
1682 Eronen                      Standards Track                    [Page 30]
1683 \f
1684 RFC 4555                    MOBIKE Protocol                    June 2006
1685
1686
1687 Appendix A.  Implementation Considerations
1688
1689 A.1.  Links from SPD Cache to Outbound SAD Entries
1690
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
1695    standardized.
1696
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
1700    in this area.
1701
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.
1712
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
1718    MOBIKE.
1719
1720 A.2.  Creating Outbound SAs
1721
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.
1727
1728    Neither [IPsecArch] nor MOBIKE specifies how exactly these three
1729    steps are carried out.  [IPsecArch], Section 4.4.3.4, says:
1730
1731
1732
1733
1734
1735
1736
1737
1738 Eronen                      Standards Track                    [Page 31]
1739 \f
1740 RFC 4555                    MOBIKE Protocol                    June 2006
1741
1742
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
1752       represent X.
1753
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).
1758
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
1770    specification.
1771
1772 Author's Address
1773
1774    Pasi Eronen (editor)
1775    Nokia Research Center
1776    P.O. Box 407
1777    FIN-00045 Nokia Group
1778    Finland
1779
1780    EMail: pasi.eronen@nokia.com
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794 Eronen                      Standards Track                    [Page 32]
1795 \f
1796 RFC 4555                    MOBIKE Protocol                    June 2006
1797
1798
1799 Full Copyright Statement
1800
1801    Copyright (C) The Internet Society (2006).
1802
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.
1806
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.
1814
1815 Intellectual Property
1816
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.
1825
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.
1832
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
1837    ietf-ipr@ietf.org.
1838
1839 Acknowledgement
1840
1841    Funding for the RFC Editor function is provided by the IETF
1842    Administrative Support Activity (IASA).
1843
1844
1845
1846
1847
1848
1849
1850 Eronen                      Standards Track                    [Page 33]
1851 \f