Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 3344

IP Mobility Support for IPv4

Pages: 99
Obsoletes:  3220
Obsoleted by:  5944
Updated by:  46364721
Part 4 of 4 – Pages 73 to 99
First   Prev   None

ToP   noToC   RFC3344 - Page 73   prevText

5. Security Considerations

The mobile computing environment is potentially very different from the ordinary computing environment. In many cases, mobile computers will be connected to the network via wireless links. Such links are particularly vulnerable to passive eavesdropping, active replay attacks, and other active attacks.

5.1. Message Authentication Codes

Home agents and mobile nodes MUST be able to perform authentication. The default algorithm is HMAC-MD5 [23], with a key size of 128 bits. The foreign agent MUST also support authentication using HMAC-MD5 and key sizes of 128 bits or greater, with manual key distribution. Keys with arbitrary binary values MUST be supported. The "prefix+suffix" use of MD5 to protect data and a shared secret is considered vulnerable to attack by the cryptographic community. Where backward compatibility with existing Mobile IP implementations that use this mode is needed, new implementations SHOULD include keyed MD5 [41] as one of the additional authentication algorithms for use when producing and verifying the authentication data that is supplied with Mobile IP registration messages, for instance in the extensions specified in sections 3.5.2, 3.5.3, and 3.5.4. More authentication algorithms, algorithm modes, key distribution methods, and key sizes MAY also be supported for all of these extensions.

5.2. Areas of Security Concern in this Protocol

The registration protocol described in this document will result in a mobile node's traffic being tunneled to its care-of address. This tunneling feature could be a significant vulnerability if the registration were not authenticated. Such remote redirection, for
ToP   noToC   RFC3344 - Page 74
   instance as performed by the mobile registration protocol, is widely
   understood to be a security problem in the current Internet if not
   authenticated [2].  Moreover, the Address Resolution Protocol (ARP)
   is not authenticated, and can potentially be used to steal another
   host's traffic.  The use of "Gratuitous ARP" (Section 4.6) brings
   with it all of the risks associated with the use of ARP.

5.3. Key Management

This specification requires a strong authentication mechanism (keyed MD5) which precludes many potential attacks based on the Mobile IP registration protocol. However, because key distribution is difficult in the absence of a network key management protocol, messages with the foreign agent are not all required to be authenticated. In a commercial environment it might be important to authenticate all messages between the foreign agent and the home agent, so that billing is possible, and service providers do not provide service to users that are not legitimate customers of that service provider.

5.4. Picking Good Random Numbers

The strength of any authentication mechanism depends on several factors, including the innate strength of the authentication algorithm, the secrecy of the key used, the strength of the key used, and the quality of the particular implementation. This specification requires implementation of keyed MD5 for authentication, but does not preclude the use of other authentication algorithms and modes. For keyed MD5 authentication to be useful, the 128-bit key must be both secret (that is, known only to authorized parties) and pseudo-random. If nonces are used in connection with replay protection, they must also be selected carefully. Eastlake, et al. [14] provides more information on generating pseudo-random numbers.

5.5. Privacy

Users who have sensitive data that they do not wish others to see should use mechanisms outside the scope of this document (such as encryption) to provide appropriate protection. Users concerned about traffic analysis should consider appropriate use of link encryption. If absolute location privacy is desired, the mobile node can create a tunnel to its home agent. Then, datagrams destined for correspondent nodes will appear to emanate from the home network, and it may be more difficult to pinpoint the location of the mobile node. Such mechanisms are all beyond the scope of this document.
ToP   noToC   RFC3344 - Page 75

5.6. Ingress Filtering

Many routers implement security policies such as "ingress filtering" [15] that do not allow forwarding of packets that have a Source Address which appears topologically incorrect. In environments where this is a problem, mobile nodes may use reverse tunneling [27] with the foreign agent supplied care-of address as the Source Address. Reverse tunneled packets will be able to pass normally through such routers, while ingress filtering rules will still be able to locate the true topological source of the packet in the same way as packets from non-mobile nodes.

5.7. Replay Protection for Registration Requests

The Identification field is used to let the home agent verify that a 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). 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.7.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. Unless specified differently in the
ToP   noToC   RFC3344 - Page 76
   security association between the nodes, a default value of 7 seconds
   MAY be used to limit the time difference.  This value SHOULD be
   greater than 3 seconds.  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 [26].  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 an authorization-enabling
   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, 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.
ToP   noToC   RFC3344 - Page 77

5.7.2. Replay Protection using Nonces

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 [14]. 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. IANA Considerations

Mobile IP specifies several new number spaces for values to be used in various message fields. These number spaces include the following: - Mobile IP message types sent to UDP port 434, as defined in section 1.8.
ToP   noToC   RFC3344 - Page 78
      -  types of extensions to Registration Request and Registration
         Reply messages (see sections 3.3 and 3.4, and also consult [27,
         29, 6, 7, 12])

      -  values for the Code in the Registration Reply message (see
         section 3.4, and also consult [27, 29, 6, 7, 12])

      -  Mobile IP defines so-called Agent Solicitation and Agent
         Advertisement messages.  These messages are in fact Router
         Discovery messages [10] augmented with mobile-IP specific
         extensions.  Thus, they do not define a new name space, but do
         define additional Router Discovery extensions as described
         below in Section 6.2.  Also see Section 2.1 and consult [7,

   There are additional Mobile IP numbering spaces specified in [7].

   Information about assignment of mobile-ip numbers derived from
   specifications external to this document is given by IANA at  From that URL, follow the
   hyperlinks to [M] within the "Directory of General Assigned Numbers",
   and subsequently to the specific section for "Mobile IP Numbers".

6.1. Mobile IP Message Types

Mobile IP messages are defined to be those that are sent to a message recipient at port 434 (UDP or TCP). The number space for Mobile IP messages is specified in Section 1.8. Approval of new extension numbers is subject to Expert Review, and a specification is required [30]. The currently standardized message types have the following numbers, and are specified in the indicated sections. Type Name Section ---- -------------------------------------------- --------- 1 Registration Request 3.3 3 Registration Reply 3.4

6.2. Extensions to RFC 1256 Router Advertisement

RFC 1256 defines two ICMP message types, Router Advertisement and Router Solicitation. Mobile IP defines a number space for extensions to Router Advertisement, which could be used by protocols other than Mobile IP. The extension types currently standardized for use with Mobile IP have the following numbers.
ToP   noToC   RFC3344 - Page 79
   Type  Name                                             Reference
   ----  --------------------------------------------     ---------
   0     One-byte Padding                                 2.1.3
   16    Mobility Agent Advertisement                     2.1.1
   19    Prefix-Lengths                                   2.1.2

   Approval of new extension numbers for use with Mobile IP is subject
   to Expert Review, and a specification is required [30].

6.3. Extensions to Mobile IP Registration Messages

The Mobile IP messages, specified within this document, and listed in sections 1.8 and 6.1, may have extensions. Mobile IP message extensions all share the same number space, even if they are to be applied to different Mobile IP messages. The number space for Mobile IP message extensions is specified within this document. Approval of new extension numbers is subject to Expert Review, and a specification is required [30]. Type Name Reference ---- -------------------------------------------- --------- 0 One-byte Padding 32 Mobile-Home Authentication 3.5.2 33 Mobile-Foreign Authentication 3.5.3 34 Foreign-Home Authentication 3.5.4

6.4. Code Values for Mobile IP Registration Reply Messages

The Mobile IP Registration Reply message, specified in section 3.4, has a Code field. The number space for the Code field values is also specified in Section 3.4. The Code number space is structured according to whether the registration was successful, or whether the foreign agent denied the registration request, or lastly whether the home agent denied the registration request, as follows: 0-8 Success Codes 9-63 No allocation guidelines currently exist 64-127 Error Codes from the Foreign Agent 128-192 Error Codes from the Home Agent 193-255 No allocation guidelines currently exist Approval of new Code values requires Expert Review [30].
ToP   noToC   RFC3344 - Page 80

7. Acknowledgments

Special thanks to Steve Deering (Xerox PARC), along with Dan Duchamp and John Ioannidis (JI) (Columbia University), for forming the working group, chairing it, and putting so much effort into its early development. Columbia's early Mobile IP work can be found in [18, 19, 17]. Thanks also to Kannan Alaggapan, Greg Minshall, Tony Li, Jim Solomon, Erik Nordmark, Basavaraj Patil, and Phil Roberts 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), - Samita Chakrabarti (Sun Microsystems) - Ken Imboden (Candlestick Networks, Inc.) - Dave Johnson (Carnegie Mellon University), - Frank Kastenholz (FTP Software), - Anders Klemets (KTH), - Chip Maguire (KTH), - Alison Mankin (ISI) - Andrew Myles (Macquarie University), - Thomas Narten (IBM) - Al Quirt (Bell Northern Research), - Yakov Rekhter (IBM), and - Fumio Teraoka (Sony). - Alper Yegin (NTT DoCoMo) 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 in the later revisions preceding RFC 2002 is due to Jim Solomon and Dave Johnson. Thanks to Greg Minshall (Novell), Phil Karn (Qualcomm), Frank Kastenholz (FTP Software), and Pat Calhoun (Sun Microsystems) for their generous support in hosting interim Working Group meetings. Sections 1.10 and 1.11, which specify new extension formats to be used with aggregatable extension types, were included from a specification document (entitled "Mobile IP Extensions Rationalization (MIER)", which was written by
ToP   noToC   RFC3344 - Page 81
      -  Mohamed M.Khalil, Nortel Networks
      -  Raja Narayanan, nVisible Networks
      -  Haseeb Akhtar, Nortel Networks
      -  Emad Qaddoura, Nortel Networks

   Thanks to these authors, and also for the additional work on
   MIER, which was contributed by Basavaraj Patil, Pat Calhoun, Neil
   Justusson, N. Asokan, and Jouni Malinen.
ToP   noToC   RFC3344 - Page 82

A. Patent Issues

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. The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

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 [24], 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) [42] and its Internet Protocol Control Protocol (IPCP) [25], 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.
ToP   noToC   RFC3344 - Page 83
   PPP extensions for Mobile IP have been specified in RFC 2290 [44].
   Please consult that document for additional details for how to handle
   care-of address assignment from PPP in a more efficient manner.

C. TCP Considerations

C.1. TCP Timers

When high-delay (e.g. SATCOM) or low-bandwidth (e.g. High-Frequency Radio) links are in use, some TCP stacks may have insufficiently adaptive (non-standard) retransmission timeouts. There may be spurious retransmission timeouts, even when the link and network are actually operating properly, but just with a high delay 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 follow the algorithms in RFC 2988 [31] when implementing TCP retransmission timers. Vendors of systems designed for low-bandwidth, high-delay links should consult RFCs 2757 and 2488 [28, 1]. Designers of applications targeted to operate on 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 [21]. 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 [21] 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. [5]. TCP approaches to the problem of handling errors that might interfere with congestion management are discussed in documents from the [pilc] working group [3, 9]. While such approaches are beyond the scope of this document, they illustrate that providing performance transparency to mobile nodes involves understanding mechanisms outside the network layer. Problems introduced by higher media error rates also indicate the need to avoid designs which systematically drop packets; such designs might otherwise be considered favorably when making engineering tradeoffs.
ToP   noToC   RFC3344 - Page 84

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: An authorization-enabling extension (e.g., 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 [13] 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:
ToP   noToC   RFC3344 - Page 85
      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
        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
        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: An authorization-enabling extension (e.g., the Mobile-Home Authentication Extension)
ToP   noToC   RFC3344 - Page 86

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".

F. Interoperability Considerations

This document specifies revisions to RFC 2002 that are intended to improve interoperability by resolving ambiguities contained in the earlier text. Implementations that perform authentication according to the new more precisely specified algorithm would be interoperable with earlier implementations that did what was originally expected for producing authentication data. That was a major source of non- interoperability before. However, this specification does have new features that, if used, would cause interoperability problems with older implementations. All features specified in RFC 2002 will work with the new implementations, except for V-J compression [20]. The following list details some of the possible areas of compatibility problems that may be experienced by nodes conforming to this revised specification, when attempting to interoperate with nodes obeying RFC 2002. - A client that expects some of the newly mandatory features (like reverse tunneling) from a foreign agent would still be interoperable as long as it pays attention to the `T' bit.
ToP   noToC   RFC3344 - Page 87
      -  Mobile nodes that use the NAI extension to identify themselves
         would not work with old mobility agents.

      -  Mobile nodes that use a zero home address and expect to receive
         their home address in the Registration Reply would not work
         with old mobility agents.

      -  Mobile nodes that attempt to authenticate themselves without
         using the Mobile-Home authentication extension will be unable
         to successful register with their home agent.

   In all of these cases, a robust and well-configured mobile node is
   very likely to be able to recover if it takes reasonable actions upon
   receipt of a Registration Reply with an error code indicating the
   cause for rejection.  For instance, if a mobile node sends a
   registration request that is rejected because it contains the wrong
   kind of authentication extension, then the mobile node could retry
   the registration with a mobile-home authentication extension, since
   the foreign agent and/or home agent in this case will not be
   configured to demand the alternative authentication data.

G. Changes since RFC 2002

This section details differences between the original Mobile IP base specification (RFC 2002 and ff.) that have been made as part of this revised protocol specification for Mobile IP.

G.1. Major Changes

- Specification for Destination IP address of Registration Reply transmitted from Foreign Agent, to avoid any possible transmission to IP address - Specification of two new formats for Mobile IP extensions, according to the ideas contained in MIER. - Specification that the SPI of the MN-HA authentication extension is to be used as part of the data over which the authentication algorithm must be computed. - Eliminated Van-Jacobson Compression feature - Specification that foreign agents MAY send advertisements at a rate faster than once per second, but chosen so that the advertisements do not burden the capacity of the local link. For simplicity, the foreign agent now MAY send advertisements at an interval less than 1/3 the advertised ICMP Lifetime.
ToP   noToC   RFC3344 - Page 88
      -  Specification that foreign agents SHOULD support reverse
         tunneling, and home agents MUST support decapsulation of
         reverse tunnels.

      -  Changed the preconfiguration requirements in section 3.6 for
         the mobile node to reflect the capability, specified in RFC
         2794 [6], for the mobile node to identify itself by using its
         NAI, and then getting a home address from the Registration

      -  Changed section so that a foreign agent is not required
         to discard Registration Replies that have a Home Address field
         that does not match any pending Registration Request.

      -  Allowed registrations to be authenticated by use of a security
         association between the mobile node and a suitable
         authentication entity acceptable to the home agent.  Defined
         "Authorization-enabling Extension" to be an authentication
         extension that makes a registration message acceptable to the
         recipient.  This is needed according to specification in [6].

      -  Mandated that HMAC-MD5 be used instead of the "prefix+suffix"
         mode of MD5 as originally mandated in RFC 2002.

      -  Specified that the mobile node SHOULD take the first care-of
         address in a list offered by a foreign agent, and MAY try each
         subsequent advertised address in turn if the attempted
         registrations are rejected by the foreign agent

      -  Clarification that a mobility agent SHOULD only put its own
         addresses into the initial (i.e., not mobility-related) list of
         routers in the mobility advertisement.  RFC 2002 suggests that
         a mobility agent might advertise other default routers.

      -  Specification that a mobile node MUST ignore reserved bits in
         Agent Advertisements, as opposed to discarding such
         advertisements.  In this way, new bits can be defined later,
         without affecting the ability for mobile nodes to use the
         advertisements even when the newly defined bits are not
         understood.  Furthermore, foreign agents can set the `R' bit to
         make sure that new bits are handled by themselves instead of
         some legacy mobility agent.

      -  Specification that the foreign agent checks to make sure that
         the indicated home agent address does not belong to any of its
         network interfaces before relaying a Registration Request.  If
ToP   noToC   RFC3344 - Page 89
         the check fails, and the foreign agent is not the mobile node's
         home agent, then the foreign agent rejects the request with
         code 136 (unknown home agent address).

      -  Specification that, while they are away from the home network,
         mobile nodes MUST NOT broadcast ARP packets to find the MAC
         address of another Internet node.  Thus, the (possibly empty)
         list of Router Addresses from the ICMP Router Advertisement
         portion of the message is not useful for selecting a default
         router, unless the mobile node has some means not involving
         broadcast ARP and not specified within this document for
         obtaining the MAC address of one of the routers in the list.
         Similarly, in the absence of unspecified mechanisms for
         obtaining MAC addresses on foreign networks, the mobile node
         MUST ignore redirects to other routers on foreign networks.

      -  Specification that a foreign agent MUST NOT use broadcast ARP
         for a mobile node's MAC address on a foreign network.  It may
         obtain the MAC address by copying the information from an Agent
         Solicitation or a Registration Request transmitted from a
         mobile node.

      -  Specification that a foreign agent's ARP cache for the mobile
         node's IP address MUST NOT be allowed to expire before the
         mobile node's visitor list entry expires, unless the foreign
         agent has some way other than broadcast ARP to refresh its MAC
         address associated to the mobile node's IP address.

      -  At the end of section 4.6, clarified that a home agent MUST NOT
         make any changes to the way it performs proxy ARP after it
         rejects an invalid deregistration request.

      -  In section 4.2.3, specification that multihomed home agents
         MUST use the the address sent to the mobile node in the home
         agent field of the registration reply as the source address in
         the outer IP header of the encapsulated datagram.

      -  Inserted 'T' bit into its proper place in the Registration
         Request message format (section 3.3).

G.2. Minor Changes

- Allowed registration replies to be processed by the mobile node, even in the absence of any Mobile-Home Authentication extension, when containing rejection code by the foreign agent.
ToP   noToC   RFC3344 - Page 90
      -  Specification that the foreign agent MAY configure a maximum
         number of pending registrations that it is willing to maintain
         (typically 5).  Additional registrations SHOULD then be
         rejected by the foreign agent with code 66.  The foreign agent
         MAY delete any pending Registration Request after the request
         has been pending for more than 7 seconds; in this case, the
         foreign agent SHOULD reject the Request with code 78
         (registration timeout).

      -  Relaxation of the requirement that, when a mobile node has
         joined a multicast group at the router on the foreign network,
         the mobile node MUST use its home address as the source IP
         address for multicast packets,

      -  Clarification that a mobility agent MAY use different settings
         for each of the 'R', 'H', and 'F' bits on different network

      -  Replacement of the terminology "recursive tunneling" by the
         terminology "nested tunneling".

      -  Specification that the mobile node MAY use the IP source
         address of an agent advertisement as its default router

      -  Clarification that keys with arbitrary binary values MUST be
         supported as part of mobility security associations.

      -  Specification that the default value may be chosen as 7
         seconds, for allowable time skews between a home agent and
         mobile node using timestamps for replay protection.  Further
         specification that this value SHOULD be greater than 3 seconds.

      -  Specification that Registration Requests with the 'D' bit set
         to 0, and specifying a care-of address not offered by the
         foreign agent, MUST be rejected with code 77 (invalid care-of

      -  Clarification that the foreign agent SHOULD consider its own
         maximum value when handling the Lifetime field of the
         Registration Reply.

      -  Clarification that the home agent MUST ignore the 'B' bit (as
         opposed to rejecting the Registration Request) if it does not
         support broadcasts.
ToP   noToC   RFC3344 - Page 91
      -  Advice about the impossibility of using dynamic home agent
         discovery in the case when routers change the IP destination
         address of a datagram from a subnet-directed broadcast address
         to before injecting it into the destination

      -  Clarified that when an Agent Advertisement is unicast to a
         mobile node, the specific IP home address of a mobile node MAY
         be used as the destination IP address.

      -  Included a reference to RFC 2290 within appendix B, which deals
         with PPP operation.

      -  Created IANA Considerations section

      -  In section 3.8.3, clarified that a home agent SHOULD arrange
         the selection of a home address for a mobile node when the
         Registration Reply contains a zero Home Address.

G.3. Changes since revision 04 of RFC2002bis

This section lists the changes between this version (...-06.txt) and the previous version (...-04.txt) of the document. This section can be deleted by the RFC editor. - Noted that HMAC-MD5 should be considered for use in place of the "prefix+suffix" mode of MD5 as originally mandated in RFC 2002. - Included a reference to RFC 2290 within appendix B, which deals with PPP operation. - Revamped IANA Considerations section - Revamped Changes section - Replaced Patents section with wording mandated from RFC 2026. - Updated citations.
ToP   noToC   RFC3344 - Page 92

H. Example Messages

H.1. Example ICMP Agent Advertisement Message Format

0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Addrs |Addr Entry Size| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference Level[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference Level[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 16 | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Lifetime |R|B|H|F|M|G|r|T| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Optional Extensions : : .... ...... ...... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP   noToC   RFC3344 - Page 93

H.2. Example Registration Request Message Format

The UDP header is followed by the Mobile IP fields shown below: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 |S|B|D|M|G|r|T|x| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Non-Auth Extensions for HA ... | | ( variable length ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =32 | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (cont..) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : MN-HA Authenticator ( variable length ) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Optional Non-Auth Extensions for FA ......... : Optional MN-FA Authentication Extension... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP   noToC   RFC3344 - Page 94

H.3. Example Registration Reply Message Format

The UDP header is followed by the Mobile IP fields shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional HA Non-Auth Extensions ... | | ( variable length ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =32 | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (cont...) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : MN-HA Authenticator ( variable length ) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Optional Extensions used by FA......... : Optional MN-FA Authentication Extension... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


[1] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999. [2] S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. ACM Computer Communications Review, 19(2), March 1989. [3] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies", RFC 3135, June 2001. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
ToP   noToC   RFC3344 - Page 95
   [5]   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.

   [6]   Calhoun P. and C. Perkins, "Mobile IP Network Access Identifier
         Extension for IPv4", RFC 2794, January 2000.

   [7]   Calhoun, P. and C. Perkins, "Mobile IP Foreign Agent
         Challenge/Response Extension", RFC 3012, December 2000.

   [8]   Cong, D., Hamlen, M. and C. Perkins, "The Definitions of
         Managed Objects for IP Mobility Support using SMIv2", RFC 2006,
         October 1996.

   [9]   Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N.
         Vaidya, "End-to-end Performance Implications of Links with
         Errors", BCP 50, RFC 3155, August 2001.

   [10]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
         September 1991.

   [11]  Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
         1112, August 1989.

   [12]  Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-
         Specific Extensions", RFC 3115, April 2001.

   [13]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
         March 1997.

   [14]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
         Recommendations for Security", RFC 1750, December 1994.

   [15]  Ferguson P. and D. Senie, "Network Ingress Filtering: Defeating
         Denial of Service Attacks which employ IP Source Address
         Spoofing", BCP 38, RFC 2827, May 2000.

   [16]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
         Routing Encapsulation (GRE)", RFC 1701, October 1994.

   [17]  J. Ioannidis.  Protocols for Mobile Internetworking.  PhD
         Dissertation - Columbia University in the City of New York,
         July 1993.
ToP   noToC   RFC3344 - Page 96
   [18]  John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr.  IP-
         Based Protocols for Mobile Internetworking.  In Proceedings of
         the SIGCOMM '91 Conference:  Communications Architectures &
         Protocols, pages 235--245, September 1991.

   [19]  John Ioannidis and Gerald Q. Maguire Jr.  The Design and
         Implementation of a Mobile Internetworking Architecture.  In
         Proceedings of the Winter USENIX Technical Conference, pages
         489--500, January 1993.

   [20]  Jacobson, V., "Compressing TCP/IP headers for low-speed serial
         links", RFC 1144, February 1990.

   [21]  Jacobson, V., "Congestion Avoidance and Control.  In
         Proceedings, SIGCOMM '88 Workshop, pages 314--329.  ACM Press,
         August 1988.  Stanford, CA.

   [22]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
         November 1998.

   [23]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [24]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
         RFC 2863, June 2000.

   [25]  McGregor, G., "The PPP Internet Protocol Control Protocol
         (IPCP)", RFC 1332, May 1992.

   [26]  Mills, D., "Network Time Protocol (Version 3) Specification,
         Implementation", RFC 1305, March 1992.

   [27]  Montenegro, G., "Reverse Tunneling for Mobile IP (revised)",
         RFC 3024, January 2001.

   [28]  Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N.
         Vaidya, "Long Thin Networks", RFC 2757, January 2000.

   [29]  Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
         Mobile IP", RFC 2356, June 1998.

   [30]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", RFC 2434, October 1998.

   [31]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
         Timer", RFC 2988, November 2000.
ToP   noToC   RFC3344 - Page 97
   [32]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October

   [33]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

   [34]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
         October 1996.

   [35]  Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile
         IP", Work in Progress, July 2001.

   [36]  Plummer, D., "Ethernet Address Resolution Protocol: Or
         converting network protocol addresses to 48.bit Ethernet
         address for transmission on Ethernet hardware", STD 37, RFC
         826, November 1982.

   [37]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August

   [38]  Postel, J., "Internet Protocol", STD 5, RFC 791, September

   [39]  Postel, J., "Multi-LAN Address Resolution", RFC 925, October

   [40]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
         1700, October 1994.

   [41]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April

   [42]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
         1661, July 1994.

   [43]  Solomon, J., "Applicability Statement for IP Mobility Support"
         RFC 2005, October 1996.

   [44]  Solomon J. and S. Glass, "Mobile-IPv4 Configuration Option for
         PPP IPCP", RFC 2290, February 1998.

   [45]  Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols"
         Addison-Wesley, Reading, Massachusetts, 1994.
ToP   noToC   RFC3344 - Page 98

Authors' Addresses

The working group can be contacted via the current chairs: Basavaraj Patil Nokia 6000 Connection Dr. Irving, TX. 75039 USA Phone: +1 972-894-6709 EMail: Phil Roberts Megisto Corp. Suite 120 20251 Century Blvd Germantown MD 20874 USA Phone: +1 847-202-9314 EMail: Questions about this memo can also be directed to the editor: Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: Fax: +1 650 625-2502
ToP   noToC   RFC3344 - Page 99
Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.