mobility binding, the mobile node SHOULD re-register with the home
agent by sending an Registration Request. This lets the HA know
about the new NAT mapping and restores connectivity between mobile
node and home agent.
Having established a new mobility binding, the mobile node MAY use a
shorter keepalive interval than before the NAT mapping was lost; in
particular, the mobile node MAY deviate from the keepalive interval
assigned by the home agent. If the binding loss continues to occur,
the mobile node may shorten the keepalive interval each time it re-
registers, in order to end up with a keepalive interval that is
sufficient to keep the NAT mapping alive. The strategy used to
arrive at a keepalive interval when a NAT mapping is lost is
implementation dependent. However, the mobile node MUST NOT use a
keepalive less than 10 seconds.
Note that the above discussion only applies when the mobile node is
re-registering through the same router, and thus presumably through
the same NAT device that lost a NAT mapping earlier. If the MN moves
and still finds itself behind a NAT, it SHOULD return to its original
keepalive interval (the default value, or as assigned by the home
agent) and it SHOULD NOT do any keepalive interval compensation
unless it discovers a loss of NAT mapping in the new environment.
The home agent MUST NOT attempt to detect or compensate for NAT
binding loss by dynamically changing the keepalive interval assigned
in the Registration Reply; the home agent does not have enough
information to do this reliably and should thus not do it at all.
The mobile node is in a much better position to determine when a NAT
mapping has actually been lost. Note also that a MN is allowed to
let a NAT mapping expire if the MN no longer needs connectivity.
The discussion above does only in a limited sense apply to a foreign
agent which is situated behind a NAT and using MIP UDP tunnelling.
In this case, it is a matter of permanently configuring the FA to use
a keepalive interval which is lower than the NAT mapping lifetime,
rather than trying to dynamically adapt to the binding lifetimes of
different NATs.
4.11 Co-located registration through FA
This section summarizes the protocol details which have been
necessary in order to handle and support the case when a mobile node
registers with a co-located address through a foreign agent, due to
the FA advertisements having the 'R' bit set. It gives background
information, but lists no new requirements.
When a mobile registers a co-located care-of address through an FA,
the registration request which reaches the HA will have a different
care-of address in the registration request compared to the source
address in the registration request IP-header. If the registration
request also contains a UDP Tunnel Request Extension, the HA will
erroneously set up a UDP tunnel, which will go to the FA instead of
the MN. For this reason, as mentioned in Section 4.4, the mobile
node must not include a UDP Tunnel Request Extension in the
registration if it is registering a co-located address through an FA
which does not have the 'U' bit set in its advertisements.
In order to still be able to use MIP UDP tunnelling in this case,
foreign agents which are situated behind a NAT are encouraged to send
advertisements which have the 'U' bit set, as described in Section
3.4.
If the FA advertisement has the 'U' bit set, indicating that it is
behind a NAT, and also the 'R' bit set, and the mobile node wishes to
use a co-located care-of address, it MUST set the 'R' flag in the UDP
Tunnel Request Extension, in order to inform the HA of the situation
so that it may act appropriately, as described in Section 4.4.
Because the UDP tunnel is now taking another path than the
registration requests, the home agent, when handling registrations of
this type, must wait till the arrival of the first keepalive packet
before it can set up the tunnel to the correct address and port. To
reduce the possibility of tunnel hijacking by sending a keepalive
with a phony source address, it is required that only the port of the
keepalive packet may be different from that of the registration
request; the source address must be the same. This means that if the
FA and MN are communicating with the HA through different NATs, the
connection will fail.
5. Implementation Issues
5.1 Movement Detection and Private Address Aliasing
In providing a mobile node with a mechanism for NAT traversal of
Mobile IP traffic, we expand the address space where a mobile node
may function and acquire care-of addresses. With this comes a new
problem of movement detection and address aliasing. We here have a
case which may not occur frequently, but is mentioned for
completeness:
Since private networks use overlapping address spaces, they may be
mistaken for one another in some situations; this is referred to as
private address aliasing in this document. For this reason, it may
be necessary for mobile nodes implementing this specification to
monitor the link layer address(es) of the gateway(s) used for sending
packets. A change in the link layer address indicates probable
movement to a new network, even if the IP address remains reachable
using the new link layer address.
For instance, a mobile node may obtain the co-located care-of address
10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP
from network #1. It then moves to network #2, which uses an
identical addressing scheme. The only difference for the mobile node
is the gateway's link layer address. The mobile node should store
the link layer address it initially obtains for the gateway (using
ARP, for instance). The mobile node may then detect changes in the
link layer address in successive ARP exchanges as part of its
ordinary movement detection mechanism.
In rare cases the mobile nodes may not be able to monitor the link
layer address of the gateway(s) it is using, and may thus confuse one
point of attachment with another. This specification does not
explicitly address this issue. The potential traffic blackout caused
by this situation may be limited by ensuring that the mobility
binding lifetime is short enough; the re-registration caused by
expiration of the mobility binding fixes the problem (see Section
5.2).
5.2 Mobility Binding Lifetime
When responding to a registration request with a registration reply,
the home agent is allowed to decrease the lifetime indicated in the
registration request, as covered in RFC3344 [10]. When using UDP
tunnelling, there are some cases where a short lifetime is
beneficial.
First, if the NAT mapping maintained by the NAT device is dropped, a
connection blackout will arise. New packets sent by the mobile node
(or the foreign agent) will establish a new NAT mapping, which the
home agent will not recognize until a new mobility binding is
established by a new registration request.
A second case where a short lifetime is useful is related to the
aliasing of private network addresses. In case the mobile node is
not able to detect mobility and ends up behind a new NAT device (as
described in Section 5.1), a short lifetime will ensure that the
traffic blackout will not be exceedingly long, and is terminated by a
re-registration.
The definition of "short lifetime" in this context is dependent on
the requirements of the usage scenario. Suggested maximum lifetime
returned by the home agent is 60 seconds, but in case the
abovementioned scenarios are not considered a problem, longer
lifetimes may of course be used.
6. Security Considerations
The ordinary Mobile IP security mechanisms are also used with the NAT
traversal mechanism described in this document. However, there is
one noticeable change: the NAT traversal mechanism requires that the
HA trust unauthenticated address (and port) fields possibly modified
by NATs.
Relying on unauthenticated address information when forming or
updating a mobility binding leads to several redirection attack
vulnerabilities. In essence, an attacker may do what NATs do, i.e.,
modify addresses and ports and thus cause traffic to be redirected to
a chosen address. The same vulnerabilities apply to both MN-HA and
FA-HA NAT traversal.
In more detail: without a NAT, the care-of address in the
registration request will be directly used by the HA to send traffic
back to the MN (or the FA), and the care-of address is protected by
the MN-HA (or FA-HA) authentication extension. When communicating
across a NAT, the effective care-of address from the HA point of view
is that of the NAT, which is not protected by any authentication
extension, but inferred from the apparent IP source address of
received packets. This means that by using the mobile IP
registration extensions described in this document to enable
traversal of NATs, one is opening oneself up to having the care-of
address of a MN (or a FA) maliciously changed by an attacker.
Some, but not all, of the attacks could be alleviated to some extent
by using a simple routability check. However, this document does not
specify such a mechanism for simplicity reasons and because the
mechanism would not protect against all redirection attacks. To
limit the duration of such redirection attacks, it is RECOMMENDED to
use a conservative (that is, short) mobility binding lifetime when
using the NAT traversal mechanism specified in this document.
The known security issues are described in the sections that follow.
6.1 Traffic Redirection Vulnerabilities
6.1.1 Manipulation of the Registration Request Message
An attacker on the route between the mobile node (or foreign agent)
and the home agent may redirect mobility bindings to a desired
address simply by modifying the IP and UDP headers of the
Registration Request message. Having modified the binding, the
attacker no longer needs to listen to (or manipulate) the traffic.
The redirection is in force until the mobility binding expires or the
mobile node re-registers.
This vulnerability may be used by an attacker to read traffic
destined to a mobile node, and to send traffic impersonating the
mobile node. The vulnerability may also be used to redirect traffic
to a victim host in order to cause denial-of-service on the victim.
The only defense against this vulnerability is to have a short time
between re-registrations, which limits the duration of the
redirection attack after the attacker has stopped modifying
registration messages.
6.1.2 Sending a Bogus Keepalive Message
When registering through an FA using a co-located care-of address,
another redirection vulnerability opens up. Having exchanged
Registration Request/Reply messages with the HA through the FA, the
MN is expected to send the first keepalive message to the HA, thus
finalizing the mobility binding (the binding will remain in a "half
bound" state until the keepalive is received).
Having observed a Registration Request/Reply exchange, an attacker
may send a bogus keepalive message assuming that the mobility binding
is in the "half bound" state. This opens up a similar redirection
attack as discussed in Section 6.1.1. Note, however, that the
attacker does not need to be able to modify packets in flight; simply
being able to observe the Registration Request/Reply message exchange
is sufficient to mount the attack.
With this in mind, the home agent MUST NOT accept a keepalive message
from a different source IP address than where the Registration
Request came from, as specified in Section 4.6. This requirement
limits the extent of the attack to redirecting the traffic to a bogus
UDP port, while the IP address must remain the same as in the initial
Registration Request.
The only defenses against this vulnerability are: (1) to have a short
time between re-registrations, which limits the duration of the
redirection attack after the attacker has stopped sending bogus
keepalive messages, and (2) to minimize the time the binding is in a
"half bound" state by having the mobile node send the first keepalive
message immediately after receiving an affirmative registration
reply.
6.2 Use of IPsec
If the intermediate network is considered insecure, it is recommended
that IPsec be used to protect user data traffic. However, IPsec does
not protect against the redirection attacks described previously,
other than to protect confidentiality of hijacked user data traffic.
The NAT traversal mechanism described in this document allows all
IPsec-related traffic to go through NATs without any modifications to
IPsec. In addition, the IPsec security associations do not need to
be re-established when the mobile node moves.
6.3 Firewall Considerations
This document does not specify a general firewall traversal
mechanism. However, the mechanism makes it possible to use only a
single address and a port for all MN-HA (or FA-HA) communication.
Furthermore, using the same port for the MIP UDP tunnelled traffic as
for control messages makes it quite probable that if a MIP
registration can reach the home agent, MIP tunnelling and reverse
tunnelling using the described mechanism will also work.
7. UNSAF Considerations
The mechanism described in this document is not an "UNilateral Self-
Address Fixing" (UNSAF) mechanism. Although the mobile node makes no
attempt to determine or use the NAT translated address, the mobile
node through the registration process does attempt to keep the NAT
mapping alive through refresh messages. This section attempts to
address issues that may be raised through this usage through the
framework of the unsaf considerations IAB document [13].
1. Precise definition.
This proposal extends the Mobile IP v4 registration process to
work across intervening NATs. The Home Agent detects the presence
of the NAT by examining the source address in the packet header
and comparing it with the address contained in the registration
message.
The NAT address and port detected by the home agent are not
exported or communicated to any other node anywhere.
2. Exit strategy.
This mechanism will go out of use as IPv6 and Mobile IP v6 is
deployed, obviating the need for MIPv4 NAT traversal.
It can also be noted that this mechanism makes no changes to the
base MIPv4 protocol which makes it dependent on the presence of
NATs or the current extensions - i.e., no additional protocol
changes would be needed if NATs were to go away.
3. Issues making systems more brittle.
The specific issue which is relevant here is that the effective
care-of address (being the source address in the IP header
received by the HA) is not protected by the Mobile IP
authentication extension, and therefore may be spoofed. This is
discussed in some detail in Section 6, Security Considerations.
4. Requirements for longer term solutions.
The trivial long term solution is a transition to an environment
where NATs are not required. The most obvious such environment
would be an IPv6 based internet.
In the presence of NATs, an improved solution would require
* the ability to discover the translations done by each NAT along
the route
* the ability to validate the authority of each NAT to do those
translations
* communicating as part of the signed registration request the
address of the NAT closest to the HA, for use as the effective
care-of address from the viewpoint of the HA.
* configuration of all intermediate NATs to accept only packets
from the neighbour NATs.
5. Impact on existing, deployed NATs.
One precursor of the mechanism described here has been used
successfully across deployed NATs in Sweden, Germany, England,
Japan and the USA, without necessitating neither adjustments of
the NATs in question, nor adjustment of any protocol parameters.
At the time of writing, little experience exist with the exact
implementation proposed in this document, but effort has been put
into making this mechanism even more robust and adaptive than its
precursors.
With respect to the base Mobile IP specification, the impact of
this document is that an increased frequency of registration
requests is recommended from a security perspective when the NAT
traversal mechanism is used.
8. IANA Considerations
The numbers for the extensions defined in this document have been
taken from the numbering space defined for Mobile IP messages,
registration extensions and error codes defined in RFC3344 [10].
This document proposes one new message, two new extensions and a new
error code that require type numbers and an error code value that
have been assigned by IANA. The two new extensions also introduce
two new sub-type numbering spaces to be managed by IANA.
Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request
Extension. The type number for this extension is 144. This
extension introduces a new sub-type numbering space where the value 0
has been assigned to this extension. Approval of new Tunnel Request
Extension sub-type numbers is subject to Expert Review, and a
specification is required [7].
Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply
Extension. The type value for this extension is 44. This extension
introduces a new sub-type numbering space where the value 0 has been
assigned to this extension. Approval of new Tunnel Reply Extension
sub-type numbers is subject to Expert Review, and a specification is
required [7].
Section 3.3 defines a new Mobile IP message, the Tunnel Data message.
The type value for this message is 4.
Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL:
"Requested UDP tunnel encapsulation unavailable", from the numbering
space for values defined for use with the Code field of Mobile IP
Registration Reply Messages. Code number 142 has been assigned from
the subset "Error Codes from the Home Agent".
The values for the Next Header field in the MIP Tunnel Data Message
(Section 3.3) shall be the same as those used for the Protocol field
of the IP header [2], and requires no new number assignment.
9. Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights (www.ietf.org/ipr.html).
10. Acknowledgements
Much of the text in Section 4.2 has been taken almost verbatim from
RFC2003, IP Encapsulation within IP [4].
Adding support for the FA case was suggested by George Tsirtsis and
Frode B. Nilsen. Roy Jose pointed out a problem with binding
updates, and Frode, Roy and George pointed out that there are cases
where triangular routes may work, and suggested that reverse
tunnelling need not be mandatory. Roy and Qiang Zhang drew attention
to a number of sections which needed to be corrected or stated more
clearly.
Phil Roberts helped remove a number of rough edges. Farid Adrangi
pointed out the DoS issue now covered in Security Considerations
(Section 6). Francis Dupont's helpful comments made us extend the
Security Considerations section to make it more comprehensive and
clear. Milind Kulkarni and Madhavi Chandra pointed out the required
match between the FA source and care-of addresses when the mechanism
is used by an FA, and also contributed a number of clarifications to
the text.
Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and
Timo Aalto at Netseal and Hans Sjostrand, Fredrik Johansson and Erik
Liden at ipUnplugged. They have read and re-read the text, and
contributed many valuable corrections and insights.
11. Normative References
[1] Postel, J., "User Datagram Protocol", STD 6, RFC768, August
1980.
[2] Postel, J., "Internet Protocol", STD 5, RFC791, September 1981.
[3] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
Encapsulation (GRE)", RFC1701, October 1994.
[4] Perkins, C., "IP Encapsulation within IP", RFC2003, October
1996.
[5] Perkins, C., "Minimal Encapsulation within IP", RFC2004,
October 1996.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
[8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC2784, March 2000.
[9] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC
3024, January 2001.
[10] Perkins, C., "IP Mobility Support for IPv4", RFC3344, August
2002.
12. Informative References
[11] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC2663, August 1999.
[12] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC3022, January 2001.
[13] Daigle, L., Editor, and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF)", RFC3424, November 2002.
13. Authors' Addresses
Henrik Levkowetz
ipUnplugged AB
Arenavagen 23
Stockholm S-121 28
SWEDEN
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Sami Vaarala
Netseal
Niittykatu 6
Espoo 02201
FINLAND
Phone: +358 9 435 310
EMail: sami.vaarala@iki.fi
14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.