Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type.
4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload
See Section 3.9 for a description of this notification.
The Notify Message Type for UNEXPECTED_NAT_DETECTED is 41. The
Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type.
4.2. Notify Messages - Status Types
4.2.1. MOBIKE_SUPPORTED Notify Payload
The MOBIKE_SUPPORTED notification is included in the IKE_AUTH
exchange to indicate that the implementation supports this
specification.
The Notify Message Type for MOBIKE_SUPPORTED is 16396. The Protocol
ID and SPI Size fields are set to zero. The notification data field
MUST be left empty (zero-length) when sending, and its contents (if
any) MUST be ignored when this notification is received. This allows
the field to be used by future versions of this protocol.
4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify
Payloads
Both parties can include ADDITIONAL_IP4_ADDRESS and/or
ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and
INFORMATIONAL exchange request messages; see Section 3.4 and
Section 3.6 for more detailed description.
The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
ADDITIONAL_IP6_ADDRESS are 16397 and 16398, respectively. The
Protocol ID and SPI Size fields are set to zero. The data associated
with these Notify types is either a four-octet IPv4 address or a
16-octet IPv6 address.
4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload
The NO_ADDITIONAL_ADDRESSES notification can be included in an
INFORMATIONAL exchange request message to indicate that the exchange
initiator does not have addresses beyond the one used in the exchange
(see Section 3.6 for more detailed description).
The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399. The
Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type.
4.2.4. UPDATE_SA_ADDRESSES Notify Payload
This notification is included in INFORMATIONAL exchange requests sent
by the initiator to update addresses of the IKE_SA and IPsec SAs (see
Section 3.5).
The Notify Message Type for UPDATE_SA_ADDRESSES is 16400. The
Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type.
4.2.5. COOKIE2 Notify Payload
This notification MAY be included in any INFORMATIONAL request for
return routability check purposes (see Section 3.7). If the
INFORMATIONAL request includes COOKIE2, the exchange responder MUST
copy the notification to the response message.
The data associated with this notification MUST be between 8 and 64
octets in length (inclusive), and MUST be chosen by the exchange
initiator in a way that is unpredictable to the exchange responder.
The Notify Message Type for this message is 16401. The Protocol ID
and SPI Size fields are set to zero.
4.2.6. NO_NATS_ALLOWED Notify Payload
See Section 3.9 for a description of this notification.
The Notify Message Type for this message is 16402. The notification
data contains the IP addresses and ports from/to which the packet was
sent. For IPv4, the notification data is 12 octets long and is
defined as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Destination IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For IPv6, the notification data is 36 octets long and is defined as
follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Source IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Destination IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol ID and SPI Size fields are set to zero.
5. Security Considerations
The main goals of this specification are to maintain the security
offered by usual IKEv2 procedures and to counter mobility-related
threats in an appropriate manner. This section describes new
security considerations introduced by MOBIKE. See [IKEv2] for
security considerations for IKEv2 in general.
5.1. Traffic Redirection and Hijacking
MOBIKE payloads relating to updating addresses are encrypted,
integrity protected, and replay protected using the IKE_SA. This
assures that no one except the participants can, for instance, give a
control message to change the addresses.
However, as with normal IKEv2, the actual IP addresses in the IP
header are not covered by the integrity protection. This means that
a NAT between the parties (or an attacker acting as a NAT) can modify
the addresses and cause incorrect tunnel header (outer) IP addresses
to be used for IPsec SAs. The scope of this attack is limited mainly
to denial of service because all traffic is protected using IPsec.
This attack can only be launched by on-path attackers that are
capable of modifying IKEv2 messages carrying NAT detection payloads
(such as Dead Peer Detection messages). By modifying the IP header
of these packets, the attackers can lead the peers to believe a new
NAT or a changed NAT binding exists between them. The attack can
continue as long as the attacker is on the path, modifying the IKEv2
messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms
designed to detect NAT mapping changes will eventually recognize that
the intended traffic is not getting through, and will update the
addresses appropriately.
MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
detect modification, by outsiders, of the addresses in the IP header.
When this notification is used, communication through NATs and other
address translators is impossible, so it is sent only when not doing
NAT Traversal. This feature is mainly intended for IPv6 and site-to-
site VPN cases, where the administrators may know beforehand that
NATs are not present.
5.2. IPsec Payload Protection
The use of IPsec protection on payload traffic protects the
participants against disclosure of the contents of the traffic,
should the traffic end up in an incorrect destination or be subject
to eavesdropping.
However, security associations originally created for the protection
of a specific flow between specific addresses may be updated by
MOBIKE later on. This has to be taken into account if the (outer) IP
address of the peer was used when deciding what kind of IPsec SAs the
peer is allowed to create.
For instance, the level of required protection might depend on the
current location of the VPN client, or access might be allowed only
from certain IP addresses.
It is recommended that security policies, for peers that are allowed
to use MOBIKE, are configured in a manner that takes into account
that a single security association can be used at different times
through paths of varying security properties.
This is especially critical for traffic selector authorization. The
(logical) Peer Authorization Database (PAD) contains the information
used by IKEv2 when determining what kind of IPsec SAs a peer is
allowed to create. This process is described in [IPsecArch], Section
4.4.3. When a peer requests the creation of an IPsec SA with some
traffic selectors, the PAD must contain "Child SA Authorization Data"
linking the identity authenticated by IKEv2 and the addresses
permitted for traffic selectors. See also [Clarifications] for a
more extensive discussion.
It is important to note that simply sending IKEv2 packets using some
particular address does not automatically imply a permission to
create IPsec SAs with that address in the traffic selectors.
However, some implementations are known to use policies where simply
being reachable at some address X implies a temporary permission to
create IPsec SAs for address X. Here "being reachable" usually means
the ability to send (or spoof) IP packets with source address X and
receive (or eavesdrop) packets sent to X.
Using this kind of policies or extensions with MOBIKE may need
special care to enforce the temporary nature of the permission. For
example, when the peer moves to some other address Y (and is no
longer reachable at X), it might be necessary to close IPsec SAs with
traffic selectors matching X. However, these interactions are beyond
the scope of this document.
5.3. Denial-of-Service Attacks against Third Parties
Traffic redirection may be performed not just to gain access to the
traffic or to deny service to the peers, but also to cause a denial-
of-service attack on a third party. For instance, a high-speed TCP
session or a multimedia stream may be redirected towards a victim
host, causing its communications capabilities to suffer.
The attackers in this threat can be either outsiders or even one of
the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers
can be easily dealt with if the authentication performed in the
initial IKEv2 negotiation can be traced to persons who can be held
responsible for the attack. This may not be the case in all
scenarios, particularly with opportunistic approaches to security.
If the attack is launched by an outsider, the traffic flow would
normally stop soon due to the lack of responses (such as transport
layer acknowledgements). However, if the original recipient of the
flow is malicious, it could maintain the traffic flow for an extended
period of time, since it often would be able to send the required
acknowledgements (see [Aura02] for more discussion).
It should also be noted, as shown in [Bombing], that without ingress
filtering in the attacker’s network, such attacks are already
possible simply by sending spoofed packets from the attacker to the
victim directly. Furthermore, if the attacker’s network has ingress
filtering, this attack is largely prevented for MOBIKE as well.
Consequently, it makes little sense to protect against attacks of
similar nature in MOBIKE. However, it still makes sense to limit the
amplification capabilities provided to attackers, so that they cannot
use stream redirection to send a large number of packets to the
victim by sending just a few packets themselves.
This specification includes return routability tests to limit the
duration of any "third party bombing" attacks by off-path (relative
to the victim) attackers. The tests are authenticated messages that
the peer has to respond to, and can be performed before the address
change takes effect, immediately afterwards, or even periodically
during the session. The tests contain unpredictable data, and only
someone who has the keys associated with the IKE SA and has seen the
request packet can properly respond to the test.
The duration of the attack can also be limited if the victim reports
the unwanted traffic to the originating IPsec tunnel endpoint using
ICMP error messages or INVALID_SPI notifications. As described in
[IKEv2], Section 2.21, this SHOULD trigger a liveness test, which
also doubles as a return routability check if the COOKIE2
notification is included.
5.4. Spoofing Network Connectivity Indications
Attackers may spoof various indications from lower layers and the
network in an effort to confuse the peers about which addresses are
or are not working. For example, attackers may spoof link-layer
error messages in an effort to cause the parties to move their
traffic elsewhere or even to disconnect. Attackers may also spoof
information related to network attachments, router discovery, and
address assignments in an effort to make the parties believe they
have Internet connectivity when, in reality, they do not.
This may cause use of non-preferred addresses or even denial of
service.
MOBIKE does not provide any protection of its own for indications
from other parts of the protocol stack. These vulnerabilities can be
mitigated through the use of techniques specific to the other parts
of the stack, such as validation of ICMP errors [ICMPAttacks], link
layer security, or the use of [SEND] to protect IPv6 Router and
Neighbor Discovery.
Ultimately, MOBIKE depends on the delivery of IKEv2 messages to
determine which paths can be used. If IKEv2 messages sent using a
particular source and destination addresses reach the recipient and a
reply is received, MOBIKE will usually consider the path working; if
no reply is received even after retransmissions, MOBIKE will suspect
the path is broken. An attacker who can consistently control the
delivery or non-delivery of the IKEv2 messages in the network can
thus influence which addresses actually get used.
5.5. Address and Topology Disclosure
MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/
ADDITIONAL_IP6_ADDRESS notifications reveal information about which
networks the peers are connected to.
For example, consider a host A with two network interfaces: a
cellular connection and a wired Ethernet connection to a company LAN.
If host A now contacts host B using IKEv2 and sends
ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B
receives additional information it might not otherwise know. If host
A used the cellular connection for the IKEv2 traffic, host B can also
see the company LAN address (and perhaps further guess that host A is
used by an employee of that company). If host A used the company LAN
to make the connection, host B can see that host A has a subscription
from this particular cellular operator.
These additional addresses can also disclose more accurate location
information than just a single address. Suppose that host A uses its
cellular connection for IKEv2 traffic, but also sends an
ADDITIONAL_IP4_ADDRESS notification containing an IP address
corresponding to, say, a wireless LAN at a particular coffee shop
location. It is likely that host B can now make a much better guess
at A’s location than would be possible based on the cellular IP
address alone.
Furthermore, as described in Section 3.4, some of the addresses could
also be private addresses behind a NAT.
In many environments, disclosing address information is not a problem
(and indeed it cannot be avoided if the hosts wish to use those
addresses for IPsec traffic). For instance, a remote access VPN
client could consider the corporate VPN gateway sufficiently
trustworthy for this purpose. Furthermore, the
ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are
sent encrypted, so the addresses are not visible to eavesdroppers
(unless, of course, they are later used for sending IKEv2/IPsec
traffic).
However, if MOBIKE is used in some more opportunistic approach, it
can be desirable to limit the information that is sent. Naturally,
the peers do not have to disclose any addresses they do not want to
use for IPsec traffic. Also, as noted in Section 3.6, an initiator
whose policy is to always use the locally configured responder
address does not have to send any ADDITIONAL_IP4_ADDRESS/
ADDITIONAL_IP6_ADDRESS payloads.
6. IANA Considerations
This document does not create any new namespaces to be maintained by
IANA, but it requires new values in namespaces that have been defined
in the IKEv2 base specification [IKEv2].
This document defines several new IKEv2 notifications whose values
have been allocated from the "IKEv2 Notify Message Types" namespace.
Notify Messages - Error Types Value
----------------------------- -----
UNACCEPTABLE_ADDRESSES 40
UNEXPECTED_NAT_DETECTED 41
Notify Messages - Status Types Value
------------------------------ -----
MOBIKE_SUPPORTED 16396
ADDITIONAL_IP4_ADDRESS 16397
ADDITIONAL_IP6_ADDRESS 16398
NO_ADDITIONAL_ADDRESSES 16399
UPDATE_SA_ADDRESSES 16400
COOKIE2 16401
NO_NATS_ALLOWED 16402
These notifications are described in Section 4.
7. Acknowledgements
This document is a collaborative effort of the entire MOBIKE WG. We
would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo
Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti,
Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann,
Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld,
Maureen Stillman, Shinta Sugimoto, Hannes Tschofenig, and Sami
Vaarala. This document also incorporates ideas and text from earlier
MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen],
[MOPO], and [SMOBIKE], and the MOBIKE design document [Design].
8. References
8.1. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[IPsecArch] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
8.2. Informative References
[AddrMgmt] Dupont, F., "Address Management for IKE version 2",
Work in Progress, November 2005.
[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of
Internet Location Management", Proc. 18th Annual
Computer Security Applications Conference (ACSAC),
December 2002.
[Bombing] Dupont, F., "A note about 3rd party bombing in
Mobile IPv6", Work in Progress, December 2005.
[Clarifications] Eronen, P. and P. Hoffman, "IKEv2 Clarifications
and Implementation Guidelines", Work in Progress,
February 2006.
[DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436,
March 2006.
[DNA6] Narayanan, S., Daley, G., and N. Montavont,
"Detecting Network Attachment in IPv6 - Best
Current Practices for hosts", Work in Progress,
October 2005.
[Design] Kivinen, T. and H. Tschofenig, "Design of the
MOBIKE protocol", Work in Progress, January 2006.
[ICMPAttacks] Gont, F., "ICMP attacks against TCP", Work in
Progress, October 2005.
[Kivinen] Kivinen, T., "MOBIKE protocol", Work in Progress,
February 2004.
[MIP4] Perkins, C., "IP Mobility Support for IPv4",
RFC 3344, August 2002.
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2
(MOPO-IKE)", Work in Progress, February 2005.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005.
[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and
Multihoming Extensions for IKEv2 (SMOBIKE)",
Work in Progress, March 2004.
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R.
Mahy, "STUN - Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators
(NATs)", RFC 3489, March 2003.
[UNSAF] Daigle, L., "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
Appendix A. Implementation Considerations
A.1. Links from SPD Cache to Outbound SAD Entries
[IPsecArch], Section 4.4.2, says that "For outbound processing, each
SAD entry is pointed to by entries in the SPD-S part of the SPD
cache". The document does not specify how exactly this "pointing" is
done, since this is an implementation detail that does not have to be
standardized.
However, it is clear that the links between the SPD cache and the SAD
have to be done correctly to ensure that outbound packets are sent