registration message has been freshly generated by the mobile node,
not replayed by an attacker from some previous registration. Two
methods are described in this section: timestamps (mandatory) and
"nonces" (optional). All mobile nodes and home agents MUST implement
timestamp-based replay protection. These nodes MAY also implement
nonce-based replay protection (but see Appendix A.2 for a patent that
may apply to nonce-based replay protection).
The style of replay protection in effect between a mobile node and
its home agent is part of the mobile security association. A mobile
node and its home agent MUST agree on which method of replay
protection will be used. The interpretation of the Identification
field depends on the method of replay protection as described in the
subsequent subsections.
Whatever method is used, the low-order 32 bits of the Identification
MUST be copied unchanged from the Registration Request to the Reply.
The foreign agent uses those bits (and the mobile node's home
address) to match Registration Requests with corresponding replies.
The mobile node MUST verify that the low-order 32 bits of any
Registration Reply are identical to the bits it sent in the
Registration Request.
The Identification in a new Registration Request MUST NOT be the same
as in an immediately preceding Request, and SHOULD NOT repeat while
the same security context is being used between the mobile node and
the home agent. Retransmission as in Section 3.6.3 is allowed.
5.6.1. Replay Protection using Timestamps
The basic principle of timestamp replay protection is that the node
generating a message inserts the current time of day, and the node
receiving the message checks that this timestamp is sufficiently
close to its own time of day. Obviously the two nodes must have
adequately synchronized time-of-day clocks. As with any messages,
time synchronization messages may be protected against tampering by
an authentication mechanism determined by the security context
between the two nodes.
If timestamps are used, the mobile node MUST set the Identification
field to a 64-bit value formatted as specified by the Network Time
Protocol [13]. The low-order 32 bits of the NTP format represent
fractional seconds, and those bits which are not available from a
time source SHOULD be generated from a good source of randomness.
Note, however, that when using timestamps, the 64-bit Identification
used in a Registration Request from the mobile node MUST be greater
than that used in any previous Registration Request, as the home
agent uses this field also as a sequence number. Without such a
sequence number, it would be possible for a delayed duplicate of an
earlier Registration Request to arrive at the home agent (within the
clock synchronization required by the home agent), and thus be
applied out of order, mistakenly altering the mobile node's current
registered care-of address.
Upon receipt of a Registration Request with a valid Mobile-Home
Authentication Extension, the home agent MUST check the
Identification field for validity. In order to be valid, the
timestamp contained in the Identification field MUST be close enough
to the home agent's time of day clock and the timestamp MUST be
greater than all previously accepted timestamps for the requesting
mobile node. Time tolerances and resynchronization details are
specific to a particular mobility security association.
If the timestamp is valid, the home agent copies the entire
Identification field into the Registration Reply it returns the Reply
to the mobile node. If the timestamp is not valid, the home agent
copies only the low-order 32 bits into the Registration Reply, and
supplies the high-order 32 bits from its own time of day. In this
latter case, the home agent MUST reject the registration by returning
Code 133 (identification mismatch) in the Registration Reply.
As described in Section 3.6.2.1, the mobile node MUST verify that the
low-order 32 bits of the Identification in the Registration Reply are
identical to those in the rejected registration attempt, before using
the high-order bits for clock resynchronization.
5.6.2. Replay Protection using Nonces
Implementors of this optional mechanism should examine Appendix A.2
for a patent that may be applicable to nonce-based replay protection.
The basic principle of nonce replay protection is that node A
includes a new random number in every message to node B, and checks
that node B returns that same number in its next message to node A.
Both messages use an authentication code to protect against
alteration by an attacker. At the same time node B can send its own
nonces in all messages to node A (to be echoed by node A), so that it
too can verify that it is receiving fresh messages.
The home agent may be expected to have resources for computing
pseudo-random numbers useful as nonces [7]. It inserts a new nonce
as the high-order 32 bits of the identification field of every
Registration Reply. The home agent copies the low-order 32 bits of
the Identification from the Registration Request message into the
low-order 32 bits of the Identification in the Registration Reply.
When the mobile node receives an authenticated Registration Reply
from the home agent, it saves the high-order 32 bits of the
identification for use as the high-order 32 bits of its next
Registration Request.
The mobile node is responsible for generating the low-order 32 bits
of the Identification in each Registration Request. Ideally it
should generate its own random nonces. However it may use any
expedient method, including duplication of the random value sent by
the home agent. The method chosen is of concern only to the mobile
node, because it is the node that checks for valid values in the
Registration Reply. The high-order and low-order 32 bits of the
identification chosen SHOULD both differ from their previous values.
The home agent uses a new high-order value and the mobile node uses a
new low-order value for each registration message. The foreign agent
uses the low-order value (and the mobile host's home address) to
correctly match registration replies with pending Requests (Section
3.7.1).
If a registration message is rejected because of an invalid nonce,
the Reply always provides the mobile node with a new nonce to be used
in the next registration. Thus the nonce protocol is self-
synchronizing.
6. Acknowledgments
Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp
and John Ioannidis (JI) (Columbia), for forming the working group,
chairing it, and putting so much effort into its early development.
Thanks also to Kannan Alaggapan, Greg Minshall, and Tony Li for their
contributions to the group while performing the duties of
chairperson, as well as for their many useful comments.
Thanks to the active members of the Mobile IP Working Group,
particularly those who contributed text, including (in alphabetical
order)
- Ran Atkinson (Naval Research Lab),
- Dave Johnson (Carnegie Mellon University),
- Frank Kastenholz (FTP Software),
- Anders Klemets (KTH),
- Chip Maguire (KTH),
- Andrew Myles (Macquarie University),
- Al Quirt (Bell Northern Research),
- Yakov Rekhter (IBM), and
- Fumio Teraoka (Sony).
Thanks to Charlie Kunzinger and to Bill Simpson, the editors who
produced the first drafts for of this document, reflecting the
discussions of the Working Group. Much of the new text of this memo
is due to Jim Solomon and Dave Johnson.
Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), and Frank
Kastenholz (FTP Software) for their generous support in hosting
interim Working Group meetings.
A. Patent Issues
As of the time of publication, the IETF had been made aware of two
patents that may be relevant to implementors of the protocol
described in this technical specification.
A.1. IBM Patent #5,159,592
Charles Perkins, editor of this memo, is sole inventor of U.S. Patent
No. 5,159,592, assigned to IBM. In a letter dated May 30, 1995, IBM
brought this patent to the attention of the IETF, stating that this
patent "relates to the Mobile IP." We understand that IBM did not
intend to assert that any particular implementation of Mobile IP
would or would not infringe the patent, but rather that IBM was
meeting what it viewed as a duty to disclose information that could
be relevant to the process of adopting a standard.
Based on a review of the claims of the patent, IETF believes that a
system of registering an address obtained from a foreign agent, as
described in the document, would not necessarily infringe any of the
claims of the patent; and that a system in which an address is
obtained elsewhere and then registered can be implemented without
necessarily infringing any claims of the patent. Accordingly, our
view is that the proposed protocol can be implemented without
necessarily infringing the Perkins Patent.
Parties considering adopting this protocol must be aware that some
specific implementations, or features added to otherwise non-
infringing implementations, may raise an issue of infringement with
respect to this patent or to some other patent.
This statement is for the IETF's assistance in its standard-setting
procedure, and should not be relied upon by any party as an opinion
or guarantee that any implementation it might make or use would not
be covered by the Perkins Patent and any other patents. In
particular, IBM might disagree with the interpretation of this patent
described herein.
A.2. IBM Patent #5,148,479
This patent, also assigned to IBM, may be relevant to those who
implement nonce-based replay protection as described in Section
5.6.2. Note that nonce-based replay protection is an optional
feature of this specification. Timestamp-based replay protection, on
the other hand, (Section 5.6.1) is a requirement of this
specification.
B. Link-Layer Considerations
The mobile node MAY use link-layer mechanisms to decide that its
point of attachment has changed. Such indications include the
Down/Testing/Up interface status [11], and changes in cell or
administration. The mechanisms will be specific to the particular
link-layer technology, and are outside the scope of this document.
The Point-to-Point-Protocol (PPP) [22] and its Internet Protocol
Control Protocol (IPCP) [12], negotiates the use of IP addresses.
The mobile node SHOULD first attempt to specify its home address, so
that if the mobile node is attaching to its home network, the
unrouted link will function correctly. When the home address is not
accepted by the peer, but a transient IP address is dynamically
assigned to the mobile node, and the mobile node is capable of
supporting a co-located care-of address, the mobile node MAY register
that address as a co-located care-of address. When the peer
specifies its own IP address, that address MUST NOT be assumed to be
a foreign agent care-of address or the IP address of a home agent.
C. TCP Considerations
C.1. TCP Timers
Most hosts and routers which implement TCP/IP do not permit easy
configuration of the TCP timer values. When high-delay (e.g.,
SATCOM) or low-bandwidth (e.g., High-Frequency Radio) links are in
use, the default TCP timer values in many systems may cause
retransmissions or timeouts, even when the link and network are
actually operating properly with greater than usual delays because of
the medium in use. This can cause an inability to create or maintain
TCP connections over such links, and can also cause unneeded
retransmissions which consume already scarce bandwidth. Vendors are
encouraged to make TCP timers more configurable. Vendors of systems
designed for the mobile computing markets should pick default timer
values more suited to low-bandwidth, high-delay links. Users of
mobile nodes should be sensitive to the possibility of timer-related
difficulties.
C.2. TCP Congestion Management
Mobile nodes often use media which are more likely to introduce
errors, effectively causing more packets to be dropped. This
introduces a conflict with the mechanisms for congestion management
found in modern versions of TCP [9]. Now, when a packet is dropped,
the correspondent node's TCP implementation is likely to react as if
there were a source of network congestion, and initiate the slow-
start mechanisms [9] designed for controlling that problem. However,
those mechanisms are inappropriate for overcoming errors introduced
by the links themselves, and have the effect of magnifying the
discontinuity introduced by the dropped packet. This problem has
been analyzed by Caceres, et al. [3]; there is no easy solution
available, and certainly no solution likely to be installed soon on
all correspondent nodes. While this problem is beyond the scope of
this document, it does illustrate that providing performance
transparency to mobile nodes involves understanding mechanisms
outside the network layer. It also indicates the need to avoid
designs which systematically drop packets; such designs might
otherwise be considered favorably when making engineering tradeoffs.
D. Example Scenarios
This section shows example Registration Requests for several common
scenarios.
D.1. Registering with a Foreign Agent Care-of Address
The mobile node receives an Agent Advertisement from a foreign agent
and wishes to register with that agent using the advertised foreign
agent care-of address. The mobile node wishes only IP-in-IP
encapsulation, does not want broadcasts, and does not want
simultaneous mobility bindings:
IP fields:
Source Address = mobile node's home address
Destination Address = copied from the IP source address of the
Agent Advertisement
Time to Live = 1
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=0,D=0,M=0,G=0
Lifetime = the Registration Lifetime copied from the
Mobility Agent Advertisement Extension of the
Router Advertisement message
Home Address = the mobile node's home address
Home Agent = IP address of mobile node's home agent
Care-of Address = the Care-of Address copied from the
Mobility Agent Advertisement Extension of the
Router Advertisement message
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home Authentication Extension
D.2. Registering with a Co-Located Care-of Address
The mobile node enters a foreign network that contains no foreign
agents. The mobile node obtains an address from a DHCP server [6]
for use as a co-located care-of address. The mobile node supports
all forms of encapsulation (IP-in-IP, minimal encapsulation, and
GRE), desires a copy of broadcast datagrams on the home network, and
does not want simultaneous mobility bindings:
IP fields:
Source Address = care-of address obtained from DHCP server
Destination Address = IP address of home agent
Time to Live = 64
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=1,D=1,M=1,G=1
Lifetime = 1800 (seconds)
Home Address = the mobile node's home address
Home Agent = IP address of mobile node's home agent
Care-of Address = care-of address obtained from DHCP server
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home Authentication Extension
D.3. Deregistration
The mobile node returns home and wishes to deregister all care-of
addresses with its home agent.
IP fields:
Source Address = mobile node's home address
Destination Address = IP address of home agent
Time to Live = 1
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=0,D=0,M=0,G=0
Lifetime = 0
Home Address = the mobile node's home address
Home Agent = IP address of mobile node's home agent
Care-of Address = the mobile node's home address
Identification = Network Time Protocol timestamp or Nonce
Extensions:
The Mobile-Home Authentication Extension
E. Applicability of Prefix Lengths Extension
Caution is indicated with the use of the Prefix Lengths Extension
over wireless links, due to the irregular coverage areas provided by
wireless transmitters. As a result, it is possible that two foreign
agents advertising the same prefix might indeed provide different
connectivity to prospective mobile nodes. The Prefix-Lengths
Extension SHOULD NOT be included in the advertisements sent by agents
in such a configuration.
Foreign agents using different wireless interfaces would have to
cooperate using special protocols to provide identical coverage in
space, and thus be able to claim to have wireless interfaces situated
on the same subnetwork. In the case of wired interfaces, a mobile
node disconnecting and subsequently connecting to a new point of
attachment, may well send in a new Registration Request no matter
whether the new advertisement is on the same medium as the last
recorded advertisement. And, finally, in areas with dense
populations of foreign agents it would seem unwise to require the
propagation via routing protocols of the subnet prefixes associated
with each individual wireless foreign agent; such a strategy could
lead to quick depletion of available space for routing tables,
unwarranted increases in the time required for processing routing
updates, and longer decision times for route selection if routes
(which are almost always unnecessary) are stored for wireless
"subnets".
References
[1] Atkinson, R., "IP Authentication Header", RFC1826, August 1995.
[2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite.
ACM Computer Communications Review, 19(2), March 1989.
[3] Ramon Caceres and Liviu Iftode. Improving the Performance
of Reliable Transport Protocols in Mobile Computing
Environments. IEEE Journal on Selected Areas in Communications,
13(5):850--857, June 1995.
[4] Deering, S., Editor, "ICMP Router Discovery Messages",
RFC1256, September 1991.
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC1112, August 1989.
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
October 1993.
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Requirements for Security", RFC1750, December 1994.
[8] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC1701, October 1994.
[9] Van Jacobson. Congestion Avoidance and Control. In Proceedings
of the SIGCOMM '88 Symposium: Communications Architectures &
Protocols, pages 314--329, August 1988.
[10] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC1144, February 1990.
[11] McCloghrie, K., and F. Kastenholz, "Evolution of the
Interfaces Group of MIB-II", RFC1573, January 1994.
[12] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC1332, May 1992.
[13] Mills, D., "Network Time Protocol (Version 3):
Specification, Implementation and Analysis", RFC1305, March
1992.
[14] Perkins, C., "IP Encapsulation within IP", RFC2003,
October 1996.
[15] Perkins, C., "Minimal Encapsulation within IP", RFC2004,
October 1996.
[16] Plummer, D., "An Ethernet Address Resolution Protocol:
Or Converting Network Protocol Addresses to 48.bit Ethernet
Addresses for Transmission on Ethernet Hardware", STD 37,
RFC826, November 1982.
[17] Postel, J., "User Datagram Protocol", STD 6, RFC768, August
1980.
[18] Postel, J., "Multi-LAN Address Resolution", RFC925, October
1984.
[19] Postel, J., Editor, "Internet Protocol", STD 5, RFC791,
September 1981.
[20] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC1700, October 1994.
[21] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321,
April 1992.
[22] Simpson, W., Editor, "The Point-to-Point Protocol
(PPP)", STD 51, RFC1661, July 1994.
[23] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The
Protocols. Addison-Wesley, Reading, Massachusetts, 1994.
Editor's Address
Questions about this memo can also be directed to the editor:
Charles Perkins
Room H3-D34
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work: +1-914-784-7350
Fax: +1-914-784-6205
EMail: perk@watson.ibm.com
The working group can be contacted via the current chair:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL 60196
Work: +1-847-576-2753
EMail: solomon@comm.mot.com