M O must share a security association and be able to use Message Src dest proto Digest 5(RFC 1321)with 128-bit keys to create unforge- X MH I? Pa avload Encapsulatated diagram able digital signatures for registration requests. The signa- ture is computed by performing MD5s one-way hash algo Src Dest Proto Src Dest Proto rithm over all the data within the registration message header Home HA CoM 4 or 55 X MH? Payload and the extensions that precede the signature To secure the registration request, each request must con- tain unique data so that two different registrations will in practical terms never have the same MD5 hash. Otherwise the protocol would be susceptible to replay attacks in which a malicious node could record valid registrations for later Foreign replay, effectively disrupting the ability of the home agent agent to tunnel to the current care-of address of the mobile node at that later time. To ensure this does not happen, Mobile Src Dest proto IP includes within the registration message a special identi- LX? Payload fication field that changes with every new registration. The obile mode exact semantics of the identification field depend on sever- Figure 2. Tunneling operations in Mobile IP al details, which are described at greater length in the pro tocol specification. Briefly, there are two main ways to make the identification field unique. As Figure 1 shows, in Mobile IP foreign agents are mostly One is to use a timestamp; then each new registration will passive, relaying registration requests and replies back and have a later timestamp and thus differ from previous regis- forth between the home agent and the mobile node, doing trations. The other is to cause the identification to be a mostly what they are told. The foreign agent also decapsulates pseudorandom number, with enough bits of randomness, it traffic from the home agent and forwards it to the mobile is highly unlikely that two independently chosen values for node. Note that foreign agents do not have to authen the identification field will be the same. When randomness is ticate themselves to the mobile node or home agent. a bogus sed, Mobile IP defines a method that protects both the reg. foreign agent could impersonate a real foreign agent simply istration request and reply from replay, and calls for 32 bits by following protocol and offering agent advertisements to of randomness in the identification field. If the mobile node the mobile node. The bogus agent could, for instance, then and the home agent get too far out of synchronization for the refuse to forward decapsulated packets to the mobile node use of timestamps, or if they lose track of the expected ran- when they were received. However, the result is no worse than dom numbers, the home agent will reject the registration if any node were tricked into using the wrong default router request and include information to allow resynchronization which is possible using unauthenticated router advertisements within the reply. Using random numbers instead of time- as specified in RFC 1256 stamps avoids problems stemming from attacks on the nTP protocol that might cause the mobile node to lose time syn- Automatic home agent discovery. When the mobile chronization with the home agent or to issue authenticated node cannot contact its home agent, Mobile Ip has a mech- registration requests for some future time that could be used anism that lets the mobile node try to register with another by a malicious node to subvert a future registration. unknown home agent on its home network. This method The identification field is also used by the foreign agent to of automatic home agent discovery works by using a broad match pending registration requests to registration replies cast IP address instead of the home agents IP address as the when they arrive at the home agent and to subsequently be target for the registration request. When the broadcast pack- able to relay the reply to the mobile node. The foreign agent et gets to the home network, other home agents on the net- also stores other information for pending registrations, work will send a rejection to the mobile node; however, their including the mobile node's home address, the mobile nodes rejection notice will contain their address for the mobile Media Access Layer(MAC)address, the source port num- node to use in a freshly attempted registration message. Note ber for the registration request from the mobile node, the that the broadcast is not an Internet-wide broadcast, but a registration lifetime proposed by the mobile node, and the directed broadcast that reaches only IP nodes on the home home agent's address. The foreign agent can limit registra- network tion lifetimes to a configurable value that it puts into its agent advertisements. The home agent can reduce the reg. Tunneling to the Care-of Address istration lifetime, which it includes as part of the registra- Figure 2 shows the tunneling operations in Mobile IP. The tion reply, but it can never increase it. default encapsulation mechanism that must be supported IEEE INTERNET COMPUTING http://computer.org/internet/JanUaRy.fEbruAry1998must share a security association and be able to use Message Digest 5 (RFC 1321) with 128-bit keys to create unforge￾able digital signatures for registration requests.13 The signa￾ture is computed by performing MD5’s one-way hash algo￾rithm over all the data within the registration message header and the extensions that precede the signature. To secure the registration request, each request must con￾tain unique data so that two different registrations will in practical terms never have the same MD5 hash. Otherwise, the protocol would be susceptible to replay attacks, in which a malicious node could record valid registrations for later replay, effectively disrupting the ability of the home agent to tunnel to the current care-of address of the mobile node at that later time. To ensure this does not happen, Mobile IP includes within the registration message a special identi￾fication field that changes with every new registration. The exact semantics of the identification field depend on sever￾al details, which are described at greater length in the pro￾tocol specification.1 Briefly, there are two main ways to make the identification field unique. One is to use a timestamp; then each new registration will have a later timestamp and thus differ from previous regis￾trations. The other is to cause the identification to be a pseudorandom number; with enough bits of randomness, it is highly unlikely that two independently chosen values for the identification field will be the same. When randomness is used, Mobile IP defines a method that protects both the reg￾istration request and reply from replay, and calls for 32 bits of randomness in the identification field. If the mobile node and the home agent get too far out of synchronization for the use of timestamps, or if they lose track of the expected ran￾dom numbers, the home agent will reject the registration request and include information to allow resynchronization within the reply. Using random numbers instead of time￾stamps avoids problems stemming from attacks on the NTP protocol that might cause the mobile node to lose time syn￾chronization with the home agent or to issue authenticated registration requests for some future time that could be used by a malicious node to subvert a future registration. The identification field is also used by the foreign agent to match pending registration requests to registration replies when they arrive at the home agent and to subsequently be able to relay the reply to the mobile node. The foreign agent also stores other information for pending registrations, including the mobile node’s home address, the mobile node’s Media Access Layer (MAC) address, the source port num￾ber for the registration request from the mobile node, the registration lifetime proposed by the mobile node, and the home agent’s address. The foreign agent can limit registra￾tion lifetimes to a configurable value that it puts into its agent advertisements. The home agent can reduce the reg￾istration lifetime, which it includes as part of the registra￾tion reply, but it can never increase it. As Figure 1 shows, in Mobile IP foreign agents are mostly passive, relaying registration requests and replies back and forth between the home agent and the mobile node, doing mostly what they are told. The foreign agent also decapsulates traffic from the home agent and forwards it to the mobile node. Note that foreign agents do not have to authen￾ticate themselves to the mobile node or home agent. A bogus foreign agent could impersonate a real foreign agent simply by following protocol and offering agent advertisements to the mobile node. The bogus agent could, for instance, then refuse to forward decapsulated packets to the mobile node when they were received. However, the result is no worse than if any node were tricked into using the wrong default router, which is possible using unauthenticated router advertisements as specified in RFC 1256.9 Automatic home agent discovery. When the mobile node cannot contact its home agent, Mobile IP has a mech￾anism that lets the mobile node try to register with another unknown home agent on its home network. This method of automatic home agent discovery works by using a broad￾cast IP address instead of the home agent’s IP address as the target for the registration request. When the broadcast pack￾et gets to the home network, other home agents on the net￾work will send a rejection to the mobile node; however, their rejection notice will contain their address for the mobile node to use in a freshly attempted registration message. Note that the broadcast is not an Internet-wide broadcast, but a directed broadcast that reaches only IP nodes on the home network. Tunneling to the Care-of Address Figure 2 shows the tunneling operations in Mobile IP. The default encapsulation mechanism that must be supported MOBILE IP 63 IEEE INTERNET COMPUTING http://computer.org/internet/ JANUARY • FEBRUARY 1998 . Src Dest Proto X MH ? Payload Src Dest Proto X MH ? Payload Src Dest Proto Src Dest Proto HA COM 4 or 55 X MH ? Payload Home agent Foreign agent Encapsulatated diagram Mobile mode Figure 2. Tunneling operations in Mobile IP