for the initial exchange are discovered is beyond the scope of this
specification; typical sources of information include local
configuration and DNS.
If either or both of the peers have multiple addresses, some
combinations may not work. Thus, the initiator SHOULD try various
source and destination address combinations when retransmitting the
IKE_SA_INIT request.
3.2. Signaling Support for MOBIKE
Implementations that wish to use MOBIKE for a particular IKE_SA MUST
include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in
case of multiple IKE_AUTH exchanges, in the message containing the SA
payload).
The format of the MOBIKE_SUPPORTED notification is described in
Section 4.
3.3. Initial Tunnel Header Addresses
When an IPsec SA is created, the tunnel header IP addresses (and
port, if doing UDP encapsulation) are taken from the IKE_SA, not the
IP header of the IKEv2 message requesting the IPsec SA. The
addresses in the IKE_SA are initialized from the IP header of the
first IKE_AUTH request.
The addresses are taken from the IKE_AUTH request because IKEv2
requires changing from port 500 to 4500 if a NAT is discovered. To
simplify things, implementations that support both this specification
and NAT Traversal MUST change to port 4500 if the correspondent also
supports both, even if no NAT was detected between them (this way,
there is no need to change the ports later if a NAT is detected on
some other path).
3.4. Additional Addresses
Both the initiator and responder MAY include one or more
ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in
the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the
message containing the SA payload). Here "ADDITIONAL_*_ADDRESS"
means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS
notification.
Initiator Responder
----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)]
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_*_ADDRESS)+] } -->
<-- HDR, SK { IDr, [CERT], AUTH,
[CP(CFG_REPLY)],
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED)
[N(ADDITIONAL_*_ADDRESS)+] }
The recipient stores this information, but no other action is taken
at this time.
Although both the initiator and responder maintain a set of peer
addresses (logically associated with the IKE_SA), it is important to
note that they use this information for slightly different purposes.
The initiator uses the set of responder addresses as an input to its
address selection policy; it may, at some later point, decide to move
the IPsec traffic to one of these addresses using the procedure
described in Section 3.5. The responder normally does not use the
set of initiator addresses for anything: the addresses are used only
when the responder’s own addresses change (see Section 3.6).
The set of addresses available to the peers can change during the
lifetime of the IKE_SA. The procedure for updating this information
is described in Section 3.6.
Note that if some of the initiator’s interfaces are behind a NAT
(from the responder’s point of view), the addresses received by the
responder will be incorrect. This means the procedure for changing
responder addresses described in Section 3.6 does not fully work when
the initiator is behind a NAT. For the same reason, the peers also
SHOULD NOT use this information for any other purpose than what is
explicitly described either in this document or a future
specification updating it.
3.5. Changing Addresses in IPsec SAs
In MOBIKE, the initiator decides what addresses are used in the IPsec
SAs. That is, the responder does not normally update any IPsec SAs
without receiving an explicit UPDATE_SA_ADDRESSES request from the
initiator. (As described below, the responder can, however, update
the IKE_SA in some circumstances.)
The reasons why the initiator wishes to change the addresses are
largely beyond the scope of MOBIKE. Typically, triggers include
information received from lower layers, such as changes in IP
addresses or link-down indications. Some of this information can be
unreliable: for instance, ICMP messages could be spoofed by an
attacker. Unreliable information SHOULD be treated only as a hint
that there might be a problem, and the initiator SHOULD trigger Dead
Peer Detection (that is, send an INFORMATIONAL request) to determine
if the current path is still usable.
Changing addresses can also be triggered by events within IKEv2. At
least the following events can cause the initiator to re-evaluate its
local address selection policy, possibly leading to changing the
addresses.
o An IKEv2 request has been re-transmitted several times, but no
valid reply has been received. This suggests the current path is
no longer working.
o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS,
ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
received. This means the peer’s addresses may have changed. This
is particularly important if the announced set of addresses no
longer contains the currently used address.
o An UNACCEPTABLE_ADDRESSES notification is received as a response
to address update request (described below).
o The initiator receives a NAT_DETECTION_DESTINATION_IP notification
that does not match the previous UPDATE_SA_ADDRESSES response (see
Section 3.8 for a more detailed description).
The description in the rest of this section assumes that the
initiator has already decided what the new addresses should be. When
this decision has been made, the initiator:
o Updates the IKE_SA with the new addresses, and sets the
"pending_update" flag in the IKE_SA.
o Updates the IPsec SAs associated with this IKE_SA with the new
addresses (unless the initiator’s policy requires a return
routability check before updating the IPsec SAs, and the check has
not been done for this responder address yet).
o If the IPsec SAs were updated in the previous step: If NAT
Traversal is not enabled, and the responder supports NAT Traversal
(as indicated by NAT detection payloads in the IKE_SA_INIT
exchange), and the initiator either suspects or knows that a NAT
is likely to be present, enables NAT Traversal (that is, enables
UDP encapsulation of outgoing ESP packets and sending of NAT-
Keepalive packets).
o If there are outstanding IKEv2 requests (requests for which the
initiator has not yet received a reply), continues retransmitting
them using the addresses in the IKE_SA (the new addresses).
o When the window size allows, sends an INFORMATIONAL request
containing the UPDATE_SA_ADDRESSES notification (which does not
contain any data), and clears the "pending_update" flag. The
request will be as follows:
Initiator Responder
----------- -----------
HDR, SK { N(UPDATE_SA_ADDRESSES),
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
o If a new address change occurs while waiting for the response,
starts again from the first step (and ignores responses to this
UPDATE_SA_ADDRESSES request).
When processing an INFORMATIONAL request containing the
UPDATE_SA_ADDRESSES notification, the responder:
o Determines whether it has already received a newer
UPDATE_SA_ADDRESSES request than this one (if the responder uses a
window size greater than one, it is possible that requests are
received out of order). If it has, a normal response message
(described below) is sent, but no other action is taken.
o If the NO_NATS_ALLOWED notification is present, processes it as
described in Section 3.9.
o Checks that the (source IP address, destination IP address) pair
in the IP header is acceptable according to local policy. If it
is not, replies with a message containing the
UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).
o Updates the IP addresses in the IKE_SA with the values from the IP
header. (Using the address from the IP header is consistent with
normal IKEv2, and allows IKEv2 to work with NATs without needing
unilateral self-address fixing [UNSAF].)
o Replies with an INFORMATIONAL response:
Initiator Responder
----------- -----------
<-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(COOKIE2)] }
o If necessary, initiates a return routability check for the new
initiator address (see Section 3.7) and waits until the check is
completed.
o Updates the IPsec SAs associated with this IKE_SA with the new
addresses.
o If NAT Traversal is supported and NAT detection payloads were
included, enables or disables NAT Traversal.
When the initiator receives the reply:
o If an address change has occurred after the request was first
sent, no MOBIKE processing is done for the reply message because a
new UPDATE_SA_ADDRESSES is going to be sent (or has already been
sent, if window size greater than one is in use).
o If the response contains the UNEXPECTED_NAT_DETECTED notification,
the initiator processes the response as described in Section 3.9.
o If the response contains an UNACCEPTABLE_ADDRESSES notification,
the initiator MAY select another addresses and retry the exchange,
keep on using the previously used addresses, or disconnect.
o It updates the IPsec SAs associated with this IKE_SA with the new
addresses (unless this was already done earlier before sending the
request; this is the case when no return routability check was
required).
o If NAT Traversal is supported and NAT detection payloads were
included, the initiator enables or disables NAT Traversal.
There is one exception to the rule that the responder never updates
any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If
the source address that the responder is currently using becomes
unavailable (i.e., sending packets using that source address is no
longer possible), the responder is allowed to update the IPsec SAs to
use some other address (in addition to initiating the procedure
described in the next section).
3.6. Updating Additional Addresses
As described in Section 3.4, both the initiator and responder can
send a list of additional addresses in the IKE_AUTH exchange. This
information can be updated by sending an INFORMATIONAL exchange
request message that contains either one or more
ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the
NO_ADDITIONAL_ADDRESSES notification.
If the exchange initiator has only a single IP address, it is placed
in the IP header, and the message contains the
NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has
several addresses, one of them is placed in the IP header, and the
rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.
The new list of addresses replaces the old information (in other
words, there are no separate add/delete operations; instead, the
complete list is sent every time these notifications are used).
The message exchange will look as follows:
Initiator Responder
----------- -----------
HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
[N(NO_ADDITIONAL_ADDRESSES)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
<-- HDR, SK { [N(COOKIE2)] }
When a request containing an ADDITIONAL_IP4_ADDRESS,
ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
received, the exchange responder:
o Determines whether it has already received a newer request to
update the addresses (if a window size greater than one is used,
it is possible that the requests are received out of order). If
it has, a response message is sent, but the address set is not
updated.
o If the NO_NATS_ALLOWED notification is present, processes it as
described in Section 3.9.
o Updates the set of peer addresses based on the IP header and the
ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and
NO_ADDITIONAL_ADDRESSES notifications.
o Sends a response.
The initiator MAY include these notifications in the same request as
UPDATE_SA_ADDRESSES.
If the request to update the addresses is retransmitted using several
different source addresses, a new INFORMATIONAL request MUST be sent.
There is one additional complication: when the responder wants to
update the address set, the currently used addresses may no longer
work. In this case, the responder uses the additional address list
received from the initiator, and the list of its own addresses, to
determine which addresses to use for sending the INFORMATIONAL
request. This is the only time the responder uses the additional
address list received from the initiator.
Note that both peers can have their own policies about what addresses
are acceptable to use, and certain types of policies may simplify
implementation. For instance, if the responder has a single fixed
address, it does not need to process the ADDITIONAL_IP4_ADDRESS and
ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring
unrecognized status notifications, as already required in [IKEv2]).
Furthermore, if the initiator has a policy saying that only the
responder address specified in local configuration is acceptable, it
does not have to send its own additional addresses to the responder
(since the responder does not need them except when changing its own
address).
3.7. Return Routability Check
Both parties can optionally verify that the other party can actually
receive packets at the claimed address. By default, this "return
routability check" SHOULD be performed. In environments where the
peer is expected to be well-behaved (many corporate VPNs, for
instance), or the address can be verified by some other means (e.g.,
a certificate issued by an authority trusted for this purpose), the
return routability check MAY be omitted.
The check can be done before updating the IPsec SAs, immediately
after updating them, or continuously during the connection. By
default, the return routability check SHOULD be done before updating
the IPsec SAs, but in some environments it MAY be postponed until
after the IPsec SAs have been updated.
Any INFORMATIONAL exchange can be used for return routability
purposes, with one exception (described later in this section): when
a valid response is received, we know the other party can receive
packets at the claimed address.
To ensure that the peer cannot generate the correct INFORMATIONAL
response without seeing the request, a new payload is added to
INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY
include a COOKIE2 notification, and if included, the recipient of an
INFORMATIONAL request MUST copy the notification as-is to the
response. When processing the response, the original sender MUST
verify that the value is the same one as sent. If the values do not
match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the
format of the COOKIE2 notification.)
The exception mentioned earlier is as follows: If the same
INFORMATIONAL request has been sent to several different addresses
(i.e., the destination address in the IKE_SA has been updated after
the request was first sent), receiving the INFORMATIONAL response
does not tell which address is the working one. In this case, a new
INFORMATIONAL request needs to be sent to check return routability.
3.8. Changes in NAT Mappings
IKEv2 performs Dead Peer Detection (DPD) if there has recently been
only outgoing traffic on all of the SAs associated with the IKE_SA.
In MOBIKE, these messages can also be used to detect if NAT mappings
have changed (for example, if the keepalive interval is too long, or
the NAT box is rebooted). More specifically, if both peers support
both this specification and NAT Traversal, the
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
notifications MAY be included in any INFORMATIONAL request; if the
request includes them, the responder MUST also include them in the
response (but no other action is taken, unless otherwise specified).
When the initiator is behind a NAT (as detected earlier using the
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
notifications), it SHOULD include these notifications in DPD messages
and compare the received NAT_DETECTION_DESTINATION_IP notifications
with the value from the previous UPDATE_SA_ADDRESSES response (or the
IKE_SA_INIT response). If the values do not match, the IP address
and/or port seen by the responder has changed, and the initiator
SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5. If the
initiator suspects that the NAT mapping has changed, it MAY also skip
the detection step and send UPDATE_SA_ADDRESSES immediately. This
saves one roundtrip if the NAT mapping has indeed changed.
Note that this approach to detecting NAT mapping changes may cause an
extra address update when the IKE_SA is rekeyed. This is because the
NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security
Parameter Indexes (SPIs), which change when performing rekeying.
This unnecessary update is harmless, however.
When MOBIKE is in use, the dynamic updates (specified in [IKEv2],
Section 2.23), where the peer address and port are updated from the
last valid authenticated packet, work in a slightly different
fashion. The host not behind a NAT MUST NOT use these dynamic
updates for IKEv2 packets, but MAY use them for ESP packets. This
ensures that an INFORMATIONAL exchange that does not contain
UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
used for, e.g., testing whether a particular path works.
3.9. NAT Prohibition
Basic IKEv2/IPsec without NAT Traversal support may work across some
types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in
tunnel mode. This is because the IKEv2 integrity checksum does not
cover the addresses in the IP header. This may be considered a
problem in some circumstances, because in some sense any modification
of the IP addresses can be considered an attack.
This specification addresses the issue by protecting the IP addresses
when NAT Traversal has not been explicitly enabled. This means that
MOBIKE without NAT Traversal support will not work if the paths
contain NATs, IPv4/IPv6 translation agents, or other nodes that
modify the addresses in the IP header. This feature is mainly
intended for IPv6 and site-to-site VPN cases, where the
administrators may know beforehand that NATs are not present, and
thus any modification to the packet can be considered an attack.
More specifically, when NAT Traversal is not enabled, all messages
that can update the addresses associated with the IKE_SA and/or IPsec
SAs (the first IKE_AUTH request and all INFORMATIONAL requests that
contain any of the following notifications: UPDATE_SA_ADDRESSES,
ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS,
NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED
notification. The exchange responder MUST verify that the contents
of the NO_NATS_ALLOWED notification match the addresses in the IP
header. If they do not match, a response containing an
UNEXPECTED_NAT_DETECTED notification is sent. The response message
is sent to the address and port that the corresponding request came
from, not to the address contained in the NO_NATS_ALLOWED
notification.
If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
notification in response to its INFORMATIONAL request, it SHOULD
retry the operation several times using new INFORMATIONAL requests.
Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the
IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several
times, starting from a new IKE_SA_INIT request. This ensures that an
attacker who is able to modify only a single packet does not
unnecessarily cause a path to remain unused. The exact number of
retries is not specified in this document because it does not affect
interoperability. However, because the IKE message will also be
rejected if the attacker modifies the integrity checksum field, a
reasonable number here would be the number of retries that is being
used for normal retransmissions.
If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange
responder MUST NOT use the contents of the NO_NATS_ALLOWED
notification for any other purpose than possibly logging the
information for troubleshooting purposes.
3.10. Path Testing
IKEv2 Dead Peer Detection allows the peers to detect if the currently
used path has stopped working. However, if either of the peers has
several addresses, Dead Peer Detection alone does not tell which of
the other paths might work.
If required by its address selection policy, the initiator can use
normal IKEv2 INFORMATIONAL request/response messages to test whether
a certain path works. Implementations MAY do path testing even if
the path currently being used is working to, for example, detect when
a better (but previously unavailable) path becomes available.
3.11. Failure Recovery and Timeouts
In MOBIKE, the initiator is responsible for detecting and recovering
from most failures.
To give the initiator enough time to detect the error, the responder
SHOULD use relatively long timeout intervals when, for instance,
retransmitting IKEv2 requests or deciding whether to initiate Dead
Peer Detection. While no specific timeout lengths are required, it
is suggested that responders continue retransmitting IKEv2 requests
for at least five minutes before giving up.
3.12. Dead Peer Detection
MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but
as addresses may change, it is not sufficient to just verify that the
peer is alive, but also that it is synchronized with the address
updates and has not, for instance, ignored an address update due to
failure to complete return routability test. This means that when
there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the
addresses used in those packets and determine that they correspond to
those that should be employed. If they do not, such packets SHOULD
NOT be used as evidence that the peer is able to communicate with
this node and or that the peer has received all address updates.
4. Payload Formats
This specification defines several new IKEv2 Notify payload types.
See [IKEv2], Section 3.10, for a general description of the Notify
payload.
4.1. Notify Messages - Error Types
4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload
The responder can include this notification in an INFORMATIONAL
exchange response to indicate that the address change in the
corresponding request message (which contained an UPDATE_SA_ADDRESSES
notification) was not carried out.
The Notify Message Type for UNACCEPTABLE_ADDRESSES is 40. The