+----------------+
===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations
Figure 3: Framework
Please note that Figure 3 illustrates an example of how a MOBIKE
implementation could work. It serves illustrative purposes only.
5. Design Considerations
This section discusses aspects affecting the design of the MOBIKE
protocol.
5.1. Choosing Addresses
One of the core aspects of the MOBIKE protocol is the selection of
the address for the IPsec packets we send. Choosing addresses for
the IKEv2 request is a somewhat separate problem. In many cases,
they will be the same (and in some design choice they will always be
the same and could be forced to be the same by design).
5.1.1. Inputs and Triggers
How address changes are triggered is largely beyond the scope of
MOBIKE. The triggers can include changes in the set of addresses,
various link-layer indications, failing dead peer detection, and
changes in preferences and policies. Furthermore, there may be less
reliable sources of information (such as lack of IPsec packets and
incoming ICMP packets) that do not trigger any changes directly, but
rather cause Dead Peer Detection (DPD) to be scheduled earlier and,
if it fails, it might cause a change of the preferred address.
These triggers are largely the same as for other mobility protocols
such as Mobile IP, and they are beyond the scope of MOBIKE.
5.1.2. Connectivity
There can be two kinds of connectivity "failures": local failures and
path failures. Local failures are problems locally at a MOBIKE peer
(e.g., an interface error). Path failures are a property of an
address pair and failures of nodes and links along this path. MOBIKE
does not support unidirectional address pairs. Supporting them would
require abandoning the principle of sending an IKEv2 reply to the
address from which the request came. MOBIKE decided to deal only
with bidirectional address pairs. It does consider unidirectional
address pairs as broken and does not use them, but the connection
between peers will not break even if unidirectional address pairs are
present, provided there is at least one bidirectional address pair
MOBIKE can use.
Note that MOBIKE is not concerned about the actual path used; it
cannot even detect if some path is unidirectionally operational if
the same address pair has some other unidirectional path back.
Ingress filters might still cause such path pairs to be unusable, and
in that case MOBIKE will detect that there is no operational address
pair.
In a sense having both an IPv4 and an IPv6 address is basically a
case of partial connectivity (putting both an IPv4 and an IPv6
address in the same IP header does not work). The main difference is
that it is known beforehand; there is no need to discover that an
IPv4/IPv6 combination does not work.
5.1.3. Discovering Connectivity
To detect connectivity, the MOBIKE protocol needs to have a mechanism
to test connectivity. If a MOBIKE peer receives a reply, it can be
sure about the existence of a working (bidirectional) address pair.
If a MOBIKE peer does not see a reply after multiple retransmissions,
it may assume that the tested address pair is broken.
The connectivity tests require congestion problems to be taken into
account because the connection failure might be caused by congestion.
The MOBIKE protocol should not make the congestion problem worse by
sending many DPD packets.
5.1.4. Decision Making
One of the main questions in designing the MOBIKE protocol was who
makes the decisions how to fix a situation when failure is detected,
e.g., symmetry vs. asymmetry in decision making. Symmetric decision
making (i.e., both peers can make decisions) may cause the different
peers to make different decisions, thus causing asymmetric upstream/
downstream traffic. In the mobility case, it is desirable that the
mobile peer can move both upstream and downstream traffic to some
particular interface, and this requires asymmetric decision making
(i.e. only one peer makes decisions).
Working with stateful packet filters and NATs is easier if the same
address pair is used in both upstream and downstream directions.
Also, in common cases, only the peer behind NAT can actually perform
actions to recover from the connectivity problems, as the other peer
might not be able to initiate any connections to the peer behind NAT.
5.1.5. Suggested Approach
The working group decided to select a method whereby the initiator
will decide which addresses are used. As a consequence, the outcome
is always the same for both parties. It also works best with NATs,
as the initiator is most likely the node that is located behind a
NAT.
5.2. NAT Traversal (NAT-T)
5.2.1. Background and Constraints
Another core aspect of MOBIKE is the treatment of different NATs and
Network Address Port Translations (NAPTs). In IKEv2 the tunnel
header IP addresses are not sent inside the IKEv2 payloads, and thus
there is no need to do unilateral self-address fixing (UNSAF
[RFC3424]). The tunnel header IP addresses are taken from the outer
IP header of the IKE packets; thus, they are already processed by the
NAT.
The NAT detection payloads are used to determine whether the
addresses in the IP header were modified by a NAT along the path.
Detecting a NAT typically requires UDP encapsulation of IPsec ESP
packets to be enabled, if desired. MOBIKE is not to change how IKEv2
NAT-T works in particular, any kind of UNSAF or explicit interaction
with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [WIP-Sti06]) is
beyond the scope of the MOBIKE protocol. The MOBIKE protocol will
need to define how MOBIKE and NAT-T are used together.
The NAT-T support should also be optional. If the IKEv2
implementation does not implement NAT-T, as it is not required in
some particular environment, implementing MOBIKE should not require
adding support for NAT-T either.
The property of being behind NAT is actually a property of the
address pair and thereby of the path taken by a packet. Thus, one
peer can have multiple IP addresses, and some of those might be
behind NAT and some might not.
5.2.2. Fundamental Restrictions
There are some cases that cannot be carried out within MOBIKE. One
of those cases is when the party "outside" a symmetric NAT changes
its address to something not known by the other peer (and the old
address has stopped working). It cannot send a packet containing the
new addresses to the peer because the NAT does not contain the
necessary state. Furthermore, since the party behind the NAT does
not know the new IP address, it cannot cause the NAT state to be
created.
This case could be solved using some rendezvous mechanism outside
IKEv2, but that is beyond the scope of MOBIKE.
5.2.3. Moving behind a NAT and Back
The MOBIKE protocol should provide a mechanism whereby a peer that is
initially not behind a NAT can move behind NAT when a new preferred
address is selected. The same effect might be accomplished with the
change of the address pair if more than one path is available (e.g.,
in the case of a multi-homed host). An impact for the MOBIKE
protocol is only caused when the currently selected address pair
causes MOBIKE packets to traverse a NAT.
Similarly, the MOBIKE protocol provides a mechanism to detect when a
NATed path is changed to a non-NATed path with the change of the
address pair.
As we only use one address pair at time, effectively the MOBIKE peer
is either behind NAT or not behind NAT, but each address change can
change this situation. Because of this, and because the initiator
always chooses the addresses, it is enough to send keepalive packets
only to that one address pair.
Enabling NAT-T involves a few different things. One is to enable the
UDP encapsulation of ESP packets. Another is to change the IKE SA
ports from port 500 to port 4500. We do not want to do unnecessary
UDP encapsulation unless there is really a NAT between peers, i.e.,
UDP encapsulation should only be enabled when we actually detect NAT.
On the other hand, as all implementations supporting NAT-T must be
able to respond to port 4500 all the time, it is simpler from the
protocol point of view to change the port numbers from 500 to 4500
immediately upon detecting that the other end supports NAT-T. This
way it is not necessary to change ports after we later detected NAT,
which would have caused complications to the protocol.
If we changed the port only after we detected NAT, then the responder
would not be able to use the IKE and IPsec SAs immediately after
their address is changed to be behind NAT. Instead, it would need to
wait for the next packet from the initiator to see what IP and port
numbers are used after the initiator changed its port from 500 to
4500. The responder would also not be able to send anything to the
initiator before the initiator sent something to the responder. If
we do the port number changing immediately after the IKE_SA_INIT and
before IKE_AUTH phase, then we get the rid of this problem.
5.2.4. Responder behind a NAT
MOBIKE can work in cases where the responder is behind a static NAT,
but the initiator would need to know all the possible addresses to
which the responder can move. That is, the responder cannot move to
an address which is not known by the initiator, in case initiator
also moves behind NAT.
If the responder is behind a NAPT, then it might need to communicate
with the NAT to create a mapping so the initiator can connect to it.
Those external firewall pinhole opening mechanisms are beyond the
scope of MOBIKE.
In case the responder is behind NAPT, then finding the port numbers
used by the responder is outside the scope of MOBIKE.
5.2.5. NAT Prevention
One new feature created by MOBIKE is NAT prevention. If we detect
NAT between the peers, we do not allow that address pair to be used.
This can be used to protect IP addresses in cases where the
configuration knows that there is no NAT between the nodes (for
example IPv6, or fixed site-to-site VPN). This avoids any
possibility of on-path attackers modifying addresses in headers.
This feature means that we authenticate the IP address and detect if
they were changed. As this is done on purpose to break the
connectivity if NAT is detected, and decided by the configuration,
there is no need to do UNSAF processing.
5.2.6. Suggested Approach
The working group decided that MOBIKE uses NAT-T mechanisms from the
IKEv2 protocol as much as possible, but decided to change the dynamic
address update (see [RFC4306], Section 2.23, second to last
paragraph) for IKEv2 packets to "MUST NOT" (it would break path
testing using IKEv2 packets; see Section 6.2). The working group
also decided only to send keepalives to the current address pair.
5.3. Scope of SA Changes
Most sections of this document discuss design considerations for
updating and maintaining addresses in the database entries that
relate to an IKE SA. However, changing the preferred address also
affects the entries of the IPsec SA database. The outer tunnel
header addresses (source and destination IP addresses) need to be
modified according to the current path to allow the IPsec protected
data traffic to travel along the same path as the MOBIKE packets. If
the MOBIKE messages and the IPsec protected data traffic travel along
a different path, then NAT handling is severely complicated.
The basic question is then how the IPsec SAs are changed to use the
new address pair (the same address pair as the MOBIKE signaling
traffic). One option is that when the IKE SA address is changed, all
IPsec SAs associated with it are automatically moved along with it to
a new address pair. Another option is to have a separate exchange to
move the IPsec SAs separately.
If IPsec SAs should be updated separately, then a more efficient
format than the Notify payload is needed to preserve bandwidth. A
Notify payload can only store one Security Parameter Index (SPI) per
payload. A separate payload could have a list of IPsec SA SPIs and
the new preferred address. If there is a large number of IPsec SAs,
those payloads can be quite large unless list of ranges of SPI values
are supported. If we automatically move all IPsec SAs when the IKE
SA moves, then we only need to keep track of which IKE SA was used to
create the IPsec SA, and fetch the IP addresses from the IKE SA,
i.e., there is no need to store IP addresses per IPsec SA. Note that
IKEv2 [RFC4306] already requires the implementations to keep track of
which IPsec SAs are created using which IKE SA.
If we do allow the address set of each IPsec SA to be updated
separately, then we can support scenarios where the machine has fast
and/or cheap connections and slow and/or expensive connections and
wants to allow moving some of the SAs to the slower and/or more
expensive connection, and prevent the move, for example, of the news
video stream from the WLAN to the GPRS link.
On the other hand, even if we tie the IKE SA update to the IPsec SA
update, we can create separate IKE SAs for this scenario. For
example, we create one IKE SA that has both links as endpoints, and
it is used for important traffic; then we create another IKE SA which
has only the fast and/or cheap connection, which is used for that
kind of bulk traffic.
The working group decided to move all IPsec SAs implicitly when the
IKE SA address pair changes. If more granular handling of the IPsec
SA is required, then multiple IKE SAs can be created one for each set
of IPsec SAs needed.
5.4. Zero Address Set Functionality
One of the features that is potentially useful is for the peer to
announce that it will now disconnect for some time, i.e., it will not
be reachable at all. For instance, a laptop might go to suspend
mode. In this case, it could send address notification with zero new
addresses, which would mean that it will not have any valid addresses
anymore. The responder would then acknowledge that notification and
could then temporarily disable all SAs and therefore stop sending
traffic. If any of the SAs get any packets, they are simply dropped.
This could also include some kind of ACK spoofing to keep the TCP/IP
sessions alive (or simply setting the TCP/IP keepalives and timeouts
large enough not to cause problems), or it could simply be left to
the applications, e.g., allow TCP/IP sessions to notice if the link
is broken.
The local policy could then indicate how long the peer should allow
remote peers to remain disconnected.
From a technical point of view, this would provide following two
features:
o There is no need to transmit IPsec data traffic. IPsec-protected
data can be dropped, which saves bandwidth. This does not provide
a functional benefit, i.e., nothing breaks if this feature is not
provided.
o MOBIKE signaling messages are also ignored. The IKE SA must not
be deleted, and the suspend functionality (realized with the zero
address set) may require the IKE SA to be tagged with a lifetime
value since the IKE SA should not be kept alive for an undefined
period of time. Note that IKEv2 does not require that the IKE SA
has a lifetime associated with it. In order to prevent the IKE SA
from being deleted, the dead-peer detection mechanism needs to be
suspended as well.
Due to its complexity and no clear requirement for it, it was decided
that MOBIKE does not support this feature.
5.5. Return Routability Check
Changing the preferred address and subsequently using it for
communication is associated with an authorization decision: Is a peer
allowed to use this address? Does this peer own this address? Two
mechanisms have been proposed in the past to allow a peer to
determine the answer to these questions:
o The addresses a peer is using are part of a certificate.
[RFC3554] introduced this approach. If the other peer is, for
example, a security gateway with a limited set of fixed IP
addresses, then the security gateway may have a certificate with
all the IP addresses appearing in the certificate.
o A return routability check is performed by the remote peer before
the address is updated in that peer’s Security Association
Database. This is done in order to provide a certain degree of
confidence to the remote peer that the local peer is reachable at
the indicated address.
Without taking an authorization decision, a malicious peer can
redirect traffic towards a third party or a black hole.
A MOBIKE peer should not use an IP address provided by another MOBIKE
peer as a current address without computing the authorization
decision. If the addresses are part of the certificate, then it is
not necessary to execute the return routability check. The return
routability check is a form of authorization check, although it
provides weaker guarantees than the inclusion of the IP address as a
part of a certificate. If multiple addresses are communicated to the
remote peer, then some of these addresses may be already verified.
Finally, it would be possible not to execute return routability
checks at all. In case of indirect change notifications (i.e.,
something we notice from the network, not from the peer directly), we
only move to the new preferred address after successful dead-peer
detection (i.e., a response to a DPD test) on the new address, which
is already a return routability check. With a direct notification
(i.e., notification from the other end directly) the authenticated
peer may have provided an authenticated IP address (i.e., inside IKE
encrypted and authenticated payload; see Section 5.2.5). Thus, it is
would be possible simply to trust the MOBIKE peer to provide a proper
IP address. In this case, a protection against an internal attacker
(i.e., the authenticated peer forwarding its traffic to the new
address) would not provided. On the other hand, we know the identity
of the peer in that case. There might be problems when extensions
are added to IKEv2 that do not require authentication of end points
(e.g., opportunistic security using anonymous Diffie-Hellman).
There is also a policy issue of when to schedule a return routability
check. Before moving traffic? After moving traffic?
The basic format of the return routability check could be similar to
dead-peer detection, but potential attacks are possible if a return
routability check does not include some kind of a nonce. In these
attacks, the valid end point could send an address update
notification for a third party, trying to get all the traffic to be
sent there, causing a denial-of-service attack. If the return
routability check does not contain any nonce or other random
information not known to the other peer, then the other peer could
reply to the return routability checks even when it cannot see the
request. This might cause a peer to move the traffic to a location
where the original recipient cannot be reached.
The IKEv2 NAT-T mechanism does not perform return routability checks.
It simply uses the last seen source IP address used by the other peer
as the destination address to which response packets are to be sent.
An adversary can change those IP addresses and can cause the response
packets to be sent to a wrong IP address. The situation is self-
fixing when the adversary is no longer able to modify packets and the
first packet with an unmodified IP address reaches the other peer.
Mobility environments make this attack more difficult for an
adversary since the attack requires the adversary to be located
somewhere on the individual paths ({CoA1, ..., CoAn} towards the
destination IP address), to have a shared path, or, if the adversary
is located near the MOBIKE client, to follow the user mobility
patterns. With IKEv2 NAT-T, the genuine client can cause third-party
bombing by redirecting all the traffic pointed to him to a third
party. As the MOBIKE protocol tries to provide equal or better
security than IKEv2 NAT-T mechanism, it should protect against these
attacks.
There may be return routability information available from the other
parts of the system too (as shown in Figure 3), but the checks done
may have a different quality. There are multiple levels for return
routability checks:
o None; no tests.
o A party willing to answer the return routability check is located
along the path to the claimed address. This is the basic form of
return routability check.
o There is an answer from the tested address, and that answer was
authenticated and integrity- and replay-protected.
o There was an authenticated and integrity- and replay-protected
answer from the peer, but it is not guaranteed to originate at the
tested address or path to it (because the peer can construct a
response without seeing the request).
The return routability checks do not protect against third-party
bombing if the attacker is along the path, as the attacker can
forward the return routability checks to the real peer (even if those
packets are cryptographically authenticated).
If the address to be tested is carried inside the MOBIKE payload,
then the adversary cannot forward packets. Thus, third-party
bombings are prevented (see Section 5.2.5).
If the reply packet can be constructed without seeing the request
packet (for example, if there is no nonce, challenge, or similar
mechanism to show liveness), then the genuine peer can cause third-
party bombing, by replying to those requests without seeing them at
all.
Other levels might only provide a guarantee that there is a node at
the IP address that replied to the request. There is no indication
as to whether or not the reply is fresh or whether or not the request
may have been transmitted from a different source address.
5.5.1. Employing MOBIKE Results in Other Protocols
If MOBIKE has learned about new locations or verified the validity of
a remote address through a return routability check, can this
information be useful for other protocols?
When the basic MOBIKE VPN scenario is considered, the answer is no.
Transport and application layer protocols running inside the VPN
tunnel are unaware of the outer addresses or their status.
Similarly, IP-layer tunnel termination at a gateway rather than a
host endpoint limits the benefits for "other protocols" that could be
informed -- all application protocols at the other side are unaware
of IPsec, IKE, or MOBIKE.
However, it is conceivable that future uses or extensions of the
MOBIKE protocol make such information distribution useful. For
instance, if transport mode MOBIKE and SCTP were made to work
together, it would potentially be useful for SCTP dynamic address
reconfiguration [WIP-Ste06] to learn about the new addresses at the
same time as MOBIKE. Similarly, various IP-layer mechanisms may make
use of the fact that a return routability check of a specific type
has been performed. However, care should be exercised in all these
situations.
[WIP-Cro04] discusses the use of common locator information pools in
a IPv6 multi-homing context; it assumes that both transport and IP-
layer solutions are used in order to support multi-homing, and that
it would be beneficial for different protocols to coordinate their
results in some way, for instance, by sharing throughput information
of address pairs. This may apply to MOBIKE as well, assuming it
coexists with non-IPsec protocols that are faced with the same or
similar multi-homing choices.
Nevertheless, all of this is outside the scope of the current MOBIKE
base protocol design and may be addressed in future work.