5.5.2. Return Routability Failures
If the return routability check fails, we need to tear down the IKE
SA if we are using IKEv2 INFORMATIONAL exchanges to send return
routability checks. On the other hand, return routability checks can
only fail permanently if there was an attack by the other end; thus,
tearing down the IKE SA is a suitable action in that case.
There are some cases, where the return routability check temporarily
fails, that need to be considered here. In the first case, there is
no attacker, but the selected address pair stops working immediately
after the address update, before the return routability check.
What happens is that the initiator performs the normal address
update; it succeeds, and then the responder starts a return
routability check. If the address pair has broken down before that,
the responder will never get back the reply to the return routability
check. The responder might still be using the old IP address pair,
which could still work.
The initiator might be still seeing traffic from the responder, but
using the old address pair. The initiator should detect that this
traffic is not using the latest address pair, and after a while it
should start dead peer detection on the current address pair. If
that fails, then it should find a new working address pair and update
addresses to that. The responder should notice that the address pair
was updated after the return routability check was started and change
the ongoing return routability check to use the new address pair.
The result of that return routability check needs to be discarded as
it cannot be trusted; the packets were retransmitted to a different
IP address. So normally the responder starts a new return
routability check afterward with the new address pair.
The second case is where there is an attacker along the path
modifying the IP addresses. The peers will detect this as NAT and
will enable NAT-T recovery of changes in the NAT mappings. If the
attacker is along the path long enough for the return routability
check to succeed, then the normal recovery of changes in the NAT
mappings will take care of the problem. If the attacker disappears
before return routability check is finished, but after the update, we
have a case similar to the last. The only difference is that now the
dead peer detection started by the initiator will succeed because the
responder will reply to the addresses in the headers, not the current
address pair. The initiator will then detect that the NAT mappings
are changed, and it will fix the situation by doing an address
update.
The important thing for both of these cases is that the initiator
needs to see that the responder is both alive and synchronized with
initiator address pair updates. That is, it is not enough that the
responder is sending traffic to an initiator; it must also be using
the correct IP addresses before the initiator can believe it is alive
and synchronized. From the implementation point of view, this means
that the initiator must not consider packets having wrong IP
addresses as packets that prove the other end is alive, i.e., they do
not reset the dead peer detection timers.
5.5.3. Suggested Approach
The working group selected to use IKEv2 INFORMATIONAL exchanges as a
return routability check, but included a random cookie to prevent
redirection by an authenticated attacker. Return routability checks
are performed by default before moving the traffic. However, these
tests are optional. Nodes may also perform these tests upon their
own initiative at other times.
It is worth noting that the return routability check in MOBIKE is
different from Mobile IPv6 [RFC3775], which does not perform return
routability operations between the mobile node and its home agent at
all.
5.6. IPsec Tunnel or Transport Mode
The current MOBIKE design is focused only on the VPN type usage and
tunnel mode. Transport mode behavior would also be useful and might
be discussed in future documents.
6. Protocol Details
6.1. Indicating Support for MOBIKE
In order for MOBIKE to function, both peers must implement the MOBIKE
extension of IKEv2. If one of the peers does not support MOBIKE,
then, whenever an IP address changes, IKEv2 will have to be re-run in
order to create a new IKE SA and the respective IPsec SAs. In
MOBIKE, a peer needs to be confident that its address change messages
are understood by the other peer. If these messages are not
understood, it is possible that connectivity between the peers is
lost.
One way to ensure that a peer receives feedback on whether its
messages are understood by the other peer is to use IKEv2 messaging
for MOBIKE and to mark some messages as "critical". According to the
IKEv2 specification, either such messages have to be understood by
the receiver, or an error message has to be returned to the sender.
A second way to ensure receipt of the above-mentioned feedback is by
using Vendor ID payloads that are exchanged during the initial IKEv2
exchange. These payloads would then indicate whether or not a given
peer supports the MOBIKE protocol.
A third approach would use the Notify payload to indicate support of
MOBIKE extension. Such Notify payloads are also used for indicating
NAT traversal support (via NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP payloads).
Both a Vendor ID and a Notify payload may be used to indicate the
support of certain extensions.
Note that a MOBIKE peer could also attempt to execute MOBIKE
opportunistically with the critical bit set when an address change
has occurred. The drawback of this approach is, however, that an
unnecessary message exchange is introduced.
Although Vendor ID payloads and Notify payloads are technically
equivalent, Notify payloads are already used in IKEv2 as a capability
negotiation mechanism. Hence, Notify payloads are used in MOBIKE to
indicate support of MOBIKE protocol.
Also, as the information of the support of MOBIKE is not needed
during the IKE_SA_INIT exchange, the indication of the support is
done inside the IKE_AUTH exchange. The reason for this is the need
to keep the IKE_SA_INIT messages as small as possible so that they do
not get fragmented. IKEv2 allows that the responder can do stateless
processing of the first IKE_SA_INIT packet and request a cookie from
the other end if it is under attack. To mandate the responder to be
able to reassemble initial IKE_SA_INIT packets would not allow fully
stateless processing of the initial IKE_SA_INIT packets.
6.2. Path Testing and Window size
As IKEv2 has a window of outgoing messages, and the sender is not
allowed to violate that window (meaning that if the window is full,
then the sender cannot send packets), it can cause some complications
to path testing. Another complication created by IKEv2 is that once
the message is created and sent to the other end, it cannot be
modified in its future retransmissions. This makes it impossible to
know what packet actually reached the other end first. We cannot use
IP headers to find out which packet reached the other end first
because if the responder gets retransmissions of the packet it has
already processed and replied to (and those replies might have been
lost due unidirectional address pair), it will retransmit the
previous reply using the new address pair of the request. Because of
this, it might be possible that the responder has already used the IP
address information from the header of the previous packet, and the
reply packet ending up at the initiator has a different address pair.
Another complication comes from NAT-T. The current IKEv2 document
says that if NAT-T is enabled, the node not behind NAT SHOULD detect
if the IP address changes in the incoming authenticated packets and
update the remote peers’ addresses accordingly. This works fine with
NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs
the ability to probe other address pairs without breaking the old
one.
One approach to fix this would be to add a completely new protocol
that is outside the IKE SA message id limitations (window code),
outside identical retransmission requirements, and outside the
dynamic address updating of NAT-T.
Another approach is to make the protocol so that it does not violate
window restrictions and does not require changing the packet on
retransmissions, and change the dynamic address updating of NAT-T to
"MUST NOT" for IKE SA packets if MOBIKE is used. In order not to
violate window restrictions, the addresses of the currently ongoing
exchange need to be changed to test different paths. In order not to
require that the packet be changed after it is first sent requires
that the protocol restart from the beginning in case the packet was
retransmitted to different addresses (because the sender does not
know which packet the responder got first, i.e., which IP addresses
it used).
The working group decided to use normal IKEv2 exchanges for path
testing and decided to change the dynamic address updating of NAT-T
to MUST NOT for IKE SA packets; a new protocol outside of IKEv2 was
not adopted.
6.3. Message Presentation
The IP address change notifications can be sent either via an
informational exchange already specified in IKEv2, or via a MOBIKE-
specific message exchange. Using an informational exchange has the
main advantage that it is already specified in the IKEv2 protocol and
implementations can already incorporate the functionality.
Another question is the format of the address update notifications.
The address update notifications can include multiple addresses, of
which some may be IPv4 and some IPv6 addresses. The number of
addresses is most likely going to be limited in typical environments
(with less than 10 addresses). The format may need to indicate a
preference value for each address. The format could either contain a
preference number that determines the relative order of the addresses
or could simply be an ordered list of IP addresses. If using
preference numbers, then two addresses can have the same preference
value; an ordered list avoids this situation.
Load balancing is currently outside the scope of MOBIKE; however,
future work might include support for it. The selected format needs
to be flexible enough to include additional information in future
versions of the protocol (e.g., to enable load balancing). This may
be realized with an reserved field, which can later be used to store
additional information. As other information may arise that may have
to be tied to an address in the future, a reserved field seems like a
prudent design in any case.
There are two basic formats that place IP address lists into a
message. One includes each IP address as separate payload (where the
payload order indicates the preference order, or the payload itself
might include the preference number). Alternatively, we can put the
IP address list as one payload to the exchange, and that one payload
will then have an internal format that includes the list of IP
addresses.
Having multiple payloads, each one carrying one IP address, makes the
protocol probably easier to parse, as we can already use the normal
IKEv2 payload parsing procedures. It also offers an easy way for the
extensions, as the payload probably contains only the type of the IP
address (or the type is encoded to the payload type), and the IP
address itself. As each payload already has a length field
associated to it, we can detect if there is any extra data after the
IP address. Some implementations might have problems parsing more
than a certain number of IKEv2 payloads, but if the sender sends them
in the most preferred first, the receiver can only use the first
addresses it was willing to parse.
Having all IP addresses in one big MOBIKE-specified internal format
provides more compact encoding and keeps the MOBIKE implementation
more concentrated to one module.
Another choice is which type of payloads to use. IKEv2 already
specifies a Notify payload. It includes some extra fields (SPI size,
SPI, protocol, etc.), which gives 4 bytes of the extra overhead, and
there is the notification data field, which could include the
MOBIKE-specific data.
Another option would be to have a custom payload type, which would
then include the information needed for the MOBIKE protocol.
The working group decided to use IKEv2 Notify payloads, and put only
one data item per notify. There will be one Notify payload for each
item to be sent.
6.4. Updating Address Set
Because the initiator decides all address updates, the initiator
needs to know all the addresses used by the responder. The responder
also needs that list in case it happens to move to an address not
known by the initiator, and it needs to send an address update
notification to the initiator. It might need to try different
addresses for the initiator.
MOBIKE could send the whole peer address list every time any of the
IP addresses change (addresses are added or removed, the order
changes, or the preferred address is updated) or an incremental
update. Sending incremental updates provides more compact packets
(meaning we can support more IP addresses), but on the other hand
this approach has more problems in the synchronization and packet
reordering cases. That is, incremental updates must be processed in
order, but for full updates we can simply use the most recent one and
ignore old ones, even if they arrive after the most recent one (IKEv2
packets have a message ID that is incremented for each packet; thus,
it is easy to know the sending order).
The working group decided to use a protocol format where both ends
send a full list of their addresses to the other end, and that list
overwrites the previous list. To support NAT-T, the IP addresses of
the received packet are considered as one address of the peer, even
when they are not present in the list.
7. Security Considerations
As all the packets are already authenticated by IKEv2, there is no
risk that any attackers would undetectedly modify the contents of the
packets. The IP addresses in the IP header of the packets are not
authenticated; thus, the protocol defined must take care that they
are only used as an indication that something might be different, and
that they do not cause any direct actions, except when doing NAT
traversal.
An attacker can also spoof ICMP error messages in an effort to
confuse the peers about which addresses are not working. At worst,
this causes denial of service and/or the use of non-preferred
addresses.
One type of attack that needs to be taken care of in the MOBIKE
protocol is the bombing attack type. See [RFC4225] and [Aur02] for
more information about flooding attacks.
See the security considerations section of [RFC4555] for more
information about security considerations of the actual protocol.
8. Acknowledgements
This document is the result of discussions in the MOBIKE working
group. The authors would like to thank Jari Arkko, Pasi Eronen,
Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld,
James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch,
Udo Schilcher, Tom Henderson, Andreas Pashalidis, and Maureen
Stillman for their input.
We would like to particularly thank Pasi Eronen for tracking open
issues on the MOBIKE mailing list. He helped us make good progress
on the document.
9. References
9.1. Normative references
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
9.2. Informative References
[Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
Location Management", In Proc. 18th Annual Computer
Security Applications Conference, pages 78-87, Las
Vegas, NV USA, December 2002.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
Stewart, "On the Use of Stream Control Transmission
Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and
E. Nordmark, "Mobile IP Version 6 Route Optimization
Security Design Background", RFC 4225, December 2005.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[WIP-Ark06] Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming", Work in
Progress, June 2006.
[WIP-Cro04] Crocker, D., "Framework for Common Endpoint Locator
Pools", Work in Progress, February 2004.
[WIP-Nik06] Nikander, P., "End-Host Mobility and Multihoming with
the Host Identity Protocol", Work in Progress,
June 2006.
[WIP-Ste06] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", Work in Progress,
June 2006.
[WIP-Sti06] Stiemerling, M., Tschofenig, H., Aoun, C., and E.
Davies, "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", Work in Progress, June 2006.
Authors’ Addresses
Tero Kivinen
Safenet, Inc.
Fredrikinkatu 47
HELSINKI FI-00100
FI
EMail: kivinen@safenet-inc.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).