Dynamics - HUT Mobile IP v0.6 Dan Forsberg TECHNICAL DOCUMENT Jari T. Malinen 29 October 1999 Jouni K. Malinen Tom Weckström Helsinki University of Technology Dynamics - HUT Mobile IP Technical Document technical-document.txt Status of This Memo Work in progress, send comments to dynamics@cs.hut.fi. Abstract This document describes a hierarchical version of the RFC 2002 Mobile IP [5] which distributes functionalities of the mobility agents closer to the mobile node (MN). It uses a selected subset of principles described in the TEP [1], and REGKEY [7] drafts. The protocol uses simple messages close to those in the basic protocol providing transparent downwards compatibility with RFC 2002. A flexible, conformance-preserving message extension format is used. The system enables increased performance needed for fast handoffs and scalability by localization of the location updates. Private addresses can be used in the foreign agent (FA) hierarchy while not D. Forsberg et al. Expires 29 April 2000 [Page 1] Technical Document Dynamics - HUT Mobile IP 29 October 1999 revealing it to the MN providing a privacy of hierarchy. The protocol also provides security against man-in-the-middle attacks between the MN - Home Agent (HA), HA - FA, FA - FA, or FA - MN. This document describes the concepts used, the system architecture, and the protocol extensions used. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Functional Description . . . . . . . . . . . . . . . . . 4 3.1 Signaling . . . . . . . . . . . . . . . . . . . . . 4 3.2 Security Overview . . . . . . . . . . . . . . . . . 6 3.3 Session Key Management . . . . . . . . . . . . . . 7 3.4 Hierarchy Transparency . . . . . . . . . . . . . . 8 3.5 Protocol Robustness . . . . . . . . . . . . . . . . 8 4. Protocol Extensions . . . . . . . . . . . . . . . . . . 9 4.1 Agent Discovery . . . . . . . . . . . . . . . . . . 10 4.2 Registration . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17 1. Introduction There have been many recent suggestions to extend Mobile IP to better scale to frequent location updates [2,3]. These are basically of three kinds: implementational improvements involving buffering and different kind of fine tuning; routing and other protocol based solutions with, e.g. multicasting and broadcasting, and improvements to the Mobile IP protocol itself. We propose a solution that does not restrict the number of levels in the hierarchy, builds only on the three elementary elements of Mobile IP: the MN, FA, and HA, uses messages nearly as simple as the RFC 2002 while maintaining security and hierarchy transparency, does not use multicasting or buffering for soft handoffs while packet loss due to the protocol is minimal, and is downwards compatible with the RFC 2002. All this is implemented in the Dynamics - HUT Mobile IP version 0.5, in http://www.cs.hut.fi/Research/Dynamics. D. Forsberg et al. Expires 29 April 2000 [Page 2] Technical Document Dynamics - HUT Mobile IP 29 October 1999 2. Concepts ------ | HA | ------ | (Internet) | ------- | HFA | ------- / \ ------- ------- | IFA | | FA2 | ------- ------- / \ / \ ------- ------- ------- ------- | FA3 | | LFA | | FA5 | | FA6 | ------- ------- ------- ------- \ \ ------ | MN | ------ Figure 1: Mobility Agent Hierarchy We use a concept of FA hierarchies. Figure 1 illustrates an example FA hierarchy. In our implementation, it is possible to configure trees of FAs. These trees are statically configured so that each FA knows its children. This brings up new roles for FAs within the foreign networks. The Highest Foreign Agent (HFA) is the root of the FA hierarchy in an organization. The Lowest Foreign Agents (LFAs) are those closest to the MN on a path from the MN to the HA. These are typically the leaves of the FA tree, though not necessarily, like in Figure 1 where e.g. IFA or HFA may also become LFA. Intermediate Foreign Agents (IFAs) are those located between the LFAs and the HFA on the path for the encapsulated IP packets from the HA to the MN. As the MN moves, it changes its point of attachment, the LFA, thus changing also the path from the HA to the MN. The lowest FA that belongs to both the old and the new path is called the Switching Foreign Agent (SFA). The classification of FAs is only conceptual. The same software implementation is used for the FA functionality, no matter what the position and role of the FA in question. This is vital for the D. Forsberg et al. Expires 29 April 2000 [Page 3] Technical Document Dynamics - HUT Mobile IP 29 October 1999 implementation, for the hierarchy might collapse so that HFA, IFAs and LFA are all the same, resulting in a single FA as in RFC 2002. 3. Functional Description 3.1 Signaling Figure 2 illustrates registration procedure in a foreign network when the registration reaches up to the HA, which is very similar to the case with every location update in a RFC 2002 compliant system. MN New LFA HFA HA | \ | | | Agent Solicitation | \ | | | | \ | | | | \ | | | | / | | | Agent Advertisement | / | | | | / | | | | / | | | ---------------------------------------------- | \ | | | Registration Request | \ | | | | \ | | | | \ | | | | | \ | | | | \ | | | | \ | | | | \ | | | | | \ | | | | \ | | | | \ | | | | \ | ---------------------------------------------- | | | / | Registration Reply | | | / | | | | / | | | | / | | | / | | | | / | | | | / | | | | / | | | / | | | | / | | | | / | | | | / | | | D. Forsberg et al. Expires 29 April 2000 [Page 4] Technical Document Dynamics - HUT Mobile IP 29 October 1999 Figure 2: Registration in a new foreign network MN may have a preconfigured co-located Care-of-address (co-loc COA) that belongs to the same subnet as the LFAs. MN gets the co-loc COA via DHCP [9] or by manual configuration. With this address MN is able to communicate with other hosts in the same subnet such as printers and Domain Name Servers [8]. Figure 3 shows a localized example when the MN moves in a network that already knows something about it. When the MN moves, in an agent advertisement from a nearby LFA it gets the suggested lifetime of a possible connection, and an Internet-visible IP address, the Care-of- address (COA) as described in RFC 2002, which is the Internet-visible IP address of the HFA in the hierarchical case. MN then sends a Mobile IP registration request message to the new LFA. The new LFA creates an unconfirmed mobility binding for the new MN in its area and forwards the registration request upwards to the next higher IFA. MN Old LFA New LFA SFA HA | +------> | | | Agent Solicitation | \ | \ | | | | \ | \ | | | | \ | \ | | | | / | / | | | Agent Advertisement | / | / | | | | / | / | | | | / <----/ | | | ----------------------------------------------------- | -------> | | | Registration Request | | \ | | | | | \ | | | | | \ | | | | | | \ | | | | | \ | | | | | \ | | | | | \ | | ----------------------------------------------------- | | | / | | Registration Reply | | | / | | | | | / | | | | | / | | | | / | | | | | / | | | | | / | | | |<-------/ | | | ---------------------------------------------------- | | | / | | Tear down D. Forsberg et al. Expires 29 April 2000 [Page 5] Technical Document Dynamics - HUT Mobile IP 29 October 1999 | | | / | | | | | / | | | |<-------/ | | Figure 3: Location update in an already-visited foreign network At some point, when the registration request is being forwarded from FA to another upwards the hierarchy, the request message arrives at the SFA. The SFA detects that the requesting MN already has a mobility binding, but the request is coming from a different lower FA than what was marked to the mobility binding. That is, the SFA detects that the MN is trying to change its point of attachment, its LFA. The SFA replies to the MN with a registration reply message [5, Chap. 3] containing the remaining lifetime of the mobility binding of that particular MN in the SFA. This creates an illusion for a standard Mobile IP MN that the HA has answered to its registration request. This functionality brings a part of the HA functionality down to FAs. When detecting a movement of the MN, the SFA takes care of informing the lower part of the old path that the MN has moved. The SFA sends a tear down message which is a conventional Mobile IP registration reply message with a specific type field and tunnel lifetime marked to zero. This is a new functionality not included in RFC 2002. The tear down is needed to prevent a situation in which a FA receiving a registration request from the MN is not aware of the changes made to the path higher in the hierarchy. This would result in the FA replying to the MN and not sending the registration request upwards even though it should. This behavior would leave the hierarchy in an inconsistent state. The signaling associated with the local location updates is illustrated in Figure 3. The figure shows the two extra messages that the SFA sends upon location update: the registration reply and the tear down message. 3.2 Security Overview The system supports secure signaling through authentication, replay protection and IP address based configuration mechanisms. A separate session key management protocol and a specific extension are used to support secure localized location updates in the FA hierarchy. MN and HA have a preconfigured shared secret that they use to authenticate each other. A Security Parameter Index (SPI) must be defined for every MN. It is used for indexing the security D. Forsberg et al. Expires 29 April 2000 [Page 6] Technical Document Dynamics - HUT Mobile IP 29 October 1999 association at the HA [5]. The association includes the preconfigured shared secret key. Keyed MD5 [5] is used as the authentication algorithm and it determines the message authentication code (MAC) by using a secure hash of the key and the message. A FA may have optional security associations with other FAs and the HFA similarly with the HA. If the security association exists the session key can be encrypted with the help of the shared secret and thus man-in-the-middle style attacks can be prevented. If no security association is set for a certain FA-FA or HFA-HA pair, public key encryption (RSA) is used. Currently, only the use of MD5 based key distribution protects the system from man-in-the-middle style attacks. The current use of RSA provides security only against passive attackers that cannot manipulate messages in transit. Timestamps or nonces are used for replay attack protection and message sequence detection between MN and HA. A specific extension is used to implement sequence number based replay protection between FAs and MN in localized location updates. Nonces and timestamps are protected by the Mobile-Home Authentication Extension [5, Section 3.5.2], and sequence number by a session key based authentication extension. Additionally, HAs and FAs may restrict the allowed signaling partners (MNs or FAs) based on a host address or network address and network mask. 3.3 Session Key Management The HA acts as a session key distributor for the FA hierarchy and MN. Session key management protocol is used to distribute the session key into the MN's registered path that includes HA, FAs between and MN. When the MN registers with the HA, each FA sends in the registration request its RSA public key to the next higher FA, and the HFA correspondingly to the HA. If security associations exists between the FAs, the HFA, and the HA, RSA public key management is not used. The HA then generates a session key from pseudo-random data with MD5 and the shared secret. This key is sent in two copies in the registration reply: one for the HFA, encrypted with its RSA public key or its shared secret, and one for the MN encrypted with the MN's shared secret. When the HFA receives the registration reply it decrypts the session key, and encodes it with the next lower level FA's public key or shared secret. This is repeated down the path to the MN. The MN in turn can decrypt its copy of the key with its own shared secret. When a local location update occurs, the FAs in the old path already D. Forsberg et al. Expires 29 April 2000 [Page 7] Technical Document Dynamics - HUT Mobile IP 29 October 1999 know the session key for the tunnel, so the important FA for the local authentication is the SFA. When the point of attachment for the MN changes it authenticates itself with the target FA by computing a MAC for the signaling message using the session key. The MAC is then sent to the FA along with the registration request, and as before each FA along the new path sends its own public key to the next higher FA or uses the preconfigured security association. When the SFA receives the registration request it checks the MAC with its own session key. If the MAC is correct, the SFA sends a registration reply to the MN. In the registration reply it includes the session key encrypted with the next lower FA's public key or shared secret, and recursively downwards. This way the FAs in the new path will get the session key for the tunnel. If the MAC was incorrect (i.e. SFA and MN had different session keys), the request is forwarded upwards to be authenticated by some of the higher FAs or HA if the session key based MAC is not recognized in the FA hierarchy. 3.4 Hierarchy Transparency The selected design enables use of private addresses in the FA hierarchy. The only public address must be that of the HFA, and it is an internal matter of the tunneling hierarchy, what intermediate carrier intranets are used to connect and identify lower FAs. This enables the use of deep private intranet structures in construction of the FA hierarchies. Since the messages do not reveal the internal structure of the FA hierarchy, it is possible to hide this with some extra support from the routing nodes. To block the traceroute, and the ICMP echo Record Route option, we need to use dynamic firewalling in the LFAs so that these packets get filtered. Also, to suppress the traceroute from seeing the intermediate addresses, we force TTL to 64 in the outer header of the IP-IP encapsulation [6], instead of copying the TTL from that in the inner header. Still, the depth of the hierarchy may be probed. 3.5 Protocol Robustness Since the Mobile IP uses short and efficient request-reply message exchanges, and no delivery order of messages are guaranteed, there is non-determinism in the overall operation of a Mobile IP system. When we use hierarchical topology, we may need to change segments of tunnel paths atomically. The tunnel endpoints are manipulated by two different, asynchronously running FAs on separate hosts so their combined operations are not atomic. Thus, it requires thoroughness to get a system that behaves correctly and maintains consistent state in the FA hierarchy. Only D. Forsberg et al. Expires 29 April 2000 [Page 8] Technical Document Dynamics - HUT Mobile IP 29 October 1999 such a system does not miss packets due to signaling. Careful local ordering of events in individual FAs, with help of advanced rule-based routing, soft handoffs with lazy deletion of old tunnels, and prioritizing signaling packets before data packets are methods used to minimize packet loss due to non-determinism. By this way, protocol can be made to be robust enough without sacrificing efficiency by introducing functional extensions to protocols for ordering events, as is done with protocols that introduce fault tolerance. So robustness is achieved by careful design and by idempotence of most messages, that is, we can repeat most messages without breaking down the protocol operation. 4. Protocol Extensions The protocol is divided into agent discovery and registration as in RFC 2002. However, some new extensions are used, but in a way that a RFC 2002 compliant mobility agent can cooperate with a hierarchical system. All the following extensions have a similar header. The purpose of this header is to make it possible to use prototype systems that will remain interoperable with RFC 2002 compliant implementations. The extensions use two extensions types (of which only one is currently used). The (currently unreserved) types are 127 (for extensions that cause whole registration message to be dropped if the extension is unknown) and 255 (only this extension is ignored if it is unknown and rest of the message is handled) [5, Chap. 1.9]. The header of the vendor extensions is following 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 | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | ( Version ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 127 or 255 (not reserved) Indicates the particular type of Extension. Length Indicates the length (in bytes) of the data fields within this Extension. The length does NOT include the Type and Length bytes. Vendor ID 1 D. Forsberg et al. Expires 29 April 2000 [Page 9] Technical Document Dynamics - HUT Mobile IP 29 October 1999 Indicates the original user of the extension, in this case, number 1 stands for Dynamics. Subtype Indicates a type as the Type field in normal extensions. Version Indicates a protocol version to support future versions of the protocol in a compatible manner. Not in key or authentication extensions. This type of extensions could also be used in development of other Mobile IP additions, e.g. security protocols. The first three fields of the header (Type, Length, and Vendor ID) are fixed to provide interoperability. Subtype and Version are the selected subdivision of the vendor extension in Dynamics, but each vendor could select its own method of using the extension after Vendor ID field. 4.1 Agent Discovery The agent discovery closely resembles that in RFC 2002. The agent solicitation is as in RFC 2002. The agent advertisement also, except for the advertised FA care-of addresses. Only the address of the HFA is advertised as it has the only IP address in the visited network that needs to be reachable in the Internet and that must be added to the registration request by MN. Optional agents could be included, but are not used. A Dynamics extension in the agent advertisement contains a flexible vendor extension that can be used for multiple purposes. It is as follows 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 | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Version |T| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dynamics agent advertisement extension Type 255 (not reserved) Indicates the particular type of Extension. Length 6 Indicates the length (in bytes) of the data fields within this Extension. The length does NOT include the Type and Length bytes. D. Forsberg et al. Expires 29 April 2000 [Page 10] Technical Document Dynamics - HUT Mobile IP 29 October 1999 Vendor ID 1 Indicates the original user of the extension, in this case, number 1 stands for Dynamics. Subtype 1 Indicates a type as the Type field in normal extensions. Version 1 Indicates a protocol version to support future versions of the protocol in a compatible manner. Bit T Indicates FA's support for triangle tunneling. Reserved These are currently sent as zero; ignored on reception. 4.2 Registration The registration also closely resembles that described in RFC 2002. The registration request is as in RFC 2002 except for a Dynamics vendor extension for registration, which is as follows 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 | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Version |T| Reserved | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dynamics registration options extension Type 255 (not reserved) Indicates the particular type of Extension. Length 9 Indicates the length (in bytes) of the data fields within this Extension. The length does NOT include the Type and Length bytes. Vendor ID 1 Indicates the original user of the extension, in this case, number 1 stands for Dynamics. Subtype 2 Indicates a type as the Type field in normal extensions. D. Forsberg et al. Expires 29 April 2000 [Page 11] Technical Document Dynamics - HUT Mobile IP 29 October 1999 Version 1 Indicates a protocol version to support future versions of the protocol in a compatible manner. Bit T Indicates tear down message. Reserved These are currently sent as zero; ignored on reception. Sequence Is a constantly growing, unique sequence number for the request, issued by the MN, from which the FA can identify that the request is the most recent one and not a replayed old request. The counter in MN can be reset to zero when the session key changes. The registration request contains a key request extension as defined in the REGKEY [7], in the message sent by the MN, and sent upwards by the FA. If the use of public key cryptography is defined, for FA this is a public key request, which looks as follows 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 | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | SPI .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... SPI | FA public key .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... FA public key continued .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dynamics FA public key request extension Type 255 (not reserved) Indicates the particular type of Extension. Length Indicates the length (in bytes) of the data fields within this Extension. The length does NOT include the Type and Length bytes. Vendor ID 1 Indicates the original user of the extension, in this case, number 1 stands for Dynamics. Subtype 4 D. Forsberg et al. Expires 29 April 2000 [Page 12] Technical Document Dynamics - HUT Mobile IP 29 October 1999 Indicates a type as the Type field in normal extensions. SPI Security Parameters Index An index identifying the security context. SPI values 0 through 255 are reserved. FA public key The public key of the FA. Currently only RSA is supported. The registration reply contains a key reply extension as defined in the REGKEY [7], in the message sent downwards to the FA, and then to the MN. If public keys are used, this is a public key reply for the FA, which looks as follows 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 | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | SPI .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... SPI | RSA encrypted session key ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... RSA encrypted session key continued .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dynamics FA public key reply extension Type 255 (not reserved) Indicates the particular type of Extension. Length Indicates the length (in bytes) of the data fields within this Extension. The length does NOT include the Type and Length bytes. Vendor ID 1 Indicates the original user of the extension, in this case, number 1 stands for Dynamics. Subtype 8 Indicates a type as the Type field in normal extensions. SPI Security Parameters Index An index identifying the security context. SPI values 0 through 255 are reserved. D. Forsberg et al. Expires 29 April 2000 [Page 13] Technical Document Dynamics - HUT Mobile IP 29 October 1999 RSA encrypted session key The session key encrypted with the public key of the FA. If a shared secret is configured for the FA and its upper FA or HA a keyed MD5 based key distribution is used [7, Chap 3.1]. A similar extension is used by MN to request the session key from the HA. 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 | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | SPI .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... SPI continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dynamics FA/MN key request extension Type 255 (not reserved) Indicates the particular type of Extension. Length 8 Indicates the length (in bytes) of the data fields within this Extension. The length does NOT include the Type and Length bytes. Vendor ID 1 Indicates the original user of the extension, in this case, number 1 stands for Dynamics. Subtype 3 (FA key request) or 5 (MN key request) Indicates a type as the Type field in normal extensions. SPI Security Parameters Index An index identifying the security context. SPI values 0 through 255 are reserved. Shared secret based key request is replied with following key reply 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 | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | SPI .... | D. Forsberg et al. Expires 29 April 2000 [Page 14] Technical Document Dynamics - HUT Mobile IP 29 October 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... SPI | Keyed MD5 based encrypted ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | session key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dynamics FA/MN key reply extension Type 255 (not reserved) Indicates the particular type of Extension. Length 8 + 16 = 24 Indicates the length (in bytes) of the data fields within this Extension. The length does NOT include the Type and Length bytes. Vendor ID 1 Indicates the original user of the extension, in this case, number 1 stands for Dynamics. Subtype 7 (FA key reply) or 6 (MN key reply) Indicates a type as the Type field in normal extensions. SPI Security Parameters Index An index identifying the security context. SPI values 0 through 255 are reserved. Keyed MD5 based encrypted session key The session key encrypted with keyed MD5 [7, Chap 3.1]. The hierarchy brings a need for couple of new authentication extensions. One can be used between two FAs like the Mobile-Home, Mobile-Foreign, and Foreign-Home Authentication Extensions [5, Chap. 3.5]. The other is used for authenticating the MN in the FA organization. It is calculated using the session key as the shared secret. 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 | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | SPI .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... SPI | Authenticator .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D. Forsberg et al. Expires 29 April 2000 [Page 15] Technical Document Dynamics - HUT Mobile IP 29 October 1999 Dynamics FA->FA / session key authentication extension Type 255 (not reserved) Indicates the particular type of Extension. Length 8 + length of authenticator Indicates the length (in bytes) of the data fields within this Extension. The length does NOT include the Type and Length bytes. Vendor ID 1 Indicates the original user of the extension, in this case, number 1 stands for Dynamics. Subtype 9 (FA->FA auth.) or 10 (Session key based auth.) Indicates a type as the Type field in normal extensions. SPI Security Parameters Index An index identifying the security context. SPI values 0 through 255 are reserved. Authenticator Variable length authenticator (only MD5 is currently used, so this is 128 bits) 5. Acknowledgements We would like to thank Prof. Mikko Tiusanen for his thorough guidance and many comments. Also we would like to thank Prof. Hannu Kari for his many comments, including the original initiative to build the hierarchical tunneling system. Asokan we would like to thank for his enlightening comments on security. Finally, we would like to thank Björn Andersson, Jari Hautio, and Kimmo Mustonen for their active participation in implementing the system. References [1] P. Calhoun, G. Montenegro, and C. Perkins. "Tunnel Establishment Protocol". Internet draft (expired), draft-ietf-mobileip-calhoun- tep-01.txt, March 1998. [2] P. Calhoun, A. Casati, T. Hiller, O. McCann, C. Perkins, and J. Wang. "Transparent Hierarchical Mobility Agents (THEMA)". Internet draft (work in progress), draft-mccann-thema-00.txt, March 1999. [3] K. El Malki, N. Fikouras, and S. Cvetkovic. "Fast Handoff Method for Real-time Traffic over Scaleable Mobile IP Networks". D. Forsberg et al. Expires 29 April 2000 [Page 16] Technical Document Dynamics - HUT Mobile IP 29 October 1999 Internet draft (work in progress), draft-elmalki-mobileip-fast- handoffs-01.txt, June 1999. [4] G. Montenegro, Editor. "Reverse Tunneling for Mobile IP". RFC 2344, May 1998. [5] C. Perkins, Editor. "IP Mobility Support". RFC 2002, October 1996. [6] C. Perkins. "IP Encapsulation within IP". RFC 2003, October 1996. [7] C. Perkins, and D.B. Johnson. "Registration Keys for Route Optimization". Internet draft (expired), draft-ietf-mobileip- regkey-00.txt, November 1997. [8] P. V. Mockapetris, "Domain names -- implementation and specification". RFC 1035, November 1987. [9] R. Droms, "Dynamic Host Configuration Protocol". RFC 2131, March 1997. Authors' Addresses Dan Forsberg Helsinki University of Technology Spektri Kvintti Building, Rm 1138 Metsänneidonkuja 12 FIN-02150 Espoo Finland email: dforsber@cs.hut.fi phone: +358 9 451 5180 fax: +358 9 451 5351 Jari T. Malinen Helsinki University of Technology Spektri Kvintti Building, Rm 1134 Metsänneidonkuja 12 FIN-02150 Espoo Finland email: jtm@cs.hut.fi phone: +358 9 451 4774 fax: +358 9 451 5351 Jouni K. Malinen Helsinki University of Technology D. Forsberg et al. Expires 29 April 2000 [Page 17] Technical Document Dynamics - HUT Mobile IP 29 October 1999 Spektri Kvintti Building, Rm 1124 Metsänneidonkuja 12 FIN-02150 Espoo Finland email: jkmaline@cc.hut.fi Tom Weckström Helsinki University of Technology Otakaari 20 B 39 FIN-02150 Espoo Finland email: tweckstr@cc.hut.fi D. Forsberg et al. Expires 29 April 2000 [Page 18]