Mobile IP and the IETF Charles E. Perkins
[email protected] SUN Microsystems, Mountain View, CA, USA
Introduction At the 43rd IETF mobile-ip working group meeting in Orlando, there were a number of new developments of importance. In fact, the meeting was much too short to actually do justice to the list of subjects, and we could have made good use of a second working group meeting. The following topics were covered:
private addresses Cellular IP, regionalized registration Ericsson’s telephony requirements draft Mobile IPv6 RAT mobile PPP/L2TP
In addition, there were two BOFs (Birds of a Feather sessions) of related interest, named AAA and PILC. AAA stands for Authentication, Authorization, and Accounting, and has clear applications for roaming telephone customers. PILC stands for Performance Implications of Link Characteristics, and is partly an outgrowth of a recent effort by wireless providers to find ways to improve the performance of TCP (and, to a lesser extent, IP) over wireless media.
I.
Mobile IP Working Group
Since private address spaces are so important in the corporate enterprise environment, and soon to be within the mobile cellular telephone environment, it seems prudent for Mobile IP to be able to handle the cases where a home agent, a foreign agent, or a mobile node may have a home address which is not a globally routable IP address. While this might seem obvious, work along these directions hasn’t received sufficient attention within the working group. My belief is that enabling use of private address spaces should be added as a work item to the mobile-ip working group charter. Making the necessary changes, according to at least one proposal described next, will require some fairly substantial changes to the commonly accepted model of Mobile IP. Suppose first that the mobile node has a private home address. Then it’s reasonable to assume that the home agent has a private address; clearly it’s on the same network as the mobile node’s private address. Thus, registration requests cannot (from the outside Internet) be sent directly to the home agent at the home agent’s private address. Instead, we must postulate that the registration requests are sent to some other global IP address. That alternate global address may or may not be assigned to a network interface of the home agent; if not, then we have to assume some means by which registration requests are forwarded from a global IP address to the private address of the home agent. Define a surrogate home agent to be the entity that owns the global IP address receiving the registration requests (and, correspondingly, returning the registration reply messages). Somehow, the mobile node has to find the global address of the surrogate home agent before it begins to 8
travel. Simple ways by which this can be done include a new extension to the service advertisements beaconed by the home agent, or alternatively by manual configuration. Suppose instead that the foreign agent has a private careof address. The logical implication of this would be that the care-of address should not be made known to the mobile node, since the mobile node may often have restricted (or no) visibility into the foreign private address space. This was not envisioned during the Mobile IP protocol design, and only makes sense when there is some alternative method for guaranteeing the integrity of the mobile node’s registration request. The difficulty arises because the mobile node has to be sure that its home agent (or, if the home agent has a private address, its surrogate home agent) can tunnel packets to the foreign domain and subsequently to the mobile node, protecting against traffic redirection by a malicious entity, all without the mobile node knowing its actual care-of address within the private address space of the foreign agent. The hardest piece of the puzzle involves the delivery of tunneled packets to the mobile node. Coming across the Internet, the tunnel destination may be a global IP address which is not the care-of address of the mobile node. The tunnel source address may be the surrogate home agent. And, finally, there may be two mobile nodes at the same foreign agent with the same private home address, because network nodes in two different domains may, by chance, have the same private IP address. In that case, the foreign agent has to disambiguate the mobile nodes by using their MAC addresses, and it seems that the most likely way the foreign agent can make the choice is on the basis of the tunnel header’s source IP address. This is assuming the use of IP-within-IP tunnels; if GRE has been negotiated, or if another (non-standard) tunneling mechanism in use, then the foreign agent could demultiplex depending upon the value of a tunnel-ID. This column isn’t the place for protocol details, but at least two design teams have work in progress, and one can expect new Internet Drafts and further discussion at the next IETF meeting in Minneapolis. Discussions with telephone companies have led us to follow up our previous TEP [3] design with more mechanisms for localizing movements in a foreign domain. These localized mechanisms (called regionalized registrations) allow a mobile node to move about in the foreign domain without requiring notification of the mobile node’s home agent (and the attendant cross-Internet delays). There is an interesting interplay between regionalized registration and the use of private address spaces. Not too much changes on the home side, because the surrogate home agent would be used one way or the other. On the foreign side, however, there is a big change. Whereas before the mobile node could determine which foreign agent should be the target of a regionalized registration request, when the foreign agents have private addresses this is no longer possible. Andras Valko from Columbia University made a presentation about ”Cellular IP”, another proposal for handling local
Mobile Computing and Communications Review, Volume 3, Number 1
mobility without requiring the mobile node to send Mobile IP registration requests back to the home agent. With Cellular IP, the mobility agents make use of paging protocols and two route tables (one called a paging cache, the other a routing cache) to track a mobile node within the foreign domain. The mobile node only has to use Mobile IP upon its first appearance within the foreign domain. Subsequently, the mobility agents follow the movement of the mobile node, essentially by installing host routes at each forwarding point. The presumption is that the foreign domain, the number mobile nodes, and the rate of movement for the mobile nodes is small enough so that maintaining enough host routes will not exceed the processing capabilities of the routers. These considerations also apply (albeit to a lesser extent) to other schemes for localizing registration requests. The mobility agents implementing Cellular IP track the mobile node by monitoring data packets as they emanate from the mobile node along the path through the gateway to the Cellular IP domain out to the global Internet. One possible consequence of using snooping for this operation (instead of explicit registration) is that other nodes may be able to disrupt the routing cache by spoofing the IP address of the mobile node. A completely different kind of discussion, but still related to cellular telephony, was given by Martin K¨orling, from a recent draft for UMTS/IMT-2000 requirements [7] put together by a team at Ericsson. The team has taken a close look at what is needed for the proposed new generation of cellular telephones (IMT-2000), and compared the requirements against what has been described by the Mobile IP extensions for DIAMETER [4, 5], described last month in this column. Their perspective is that new cellular services will be offered initially by GPRS, which is the first phase of IMT-2000, but as IMT2000 evolves it would be appropriate for cellular telephony standards to merge with Internet mobility standards. They like the use of DIAMETER because it explicitly provides for ”inter-domain” mobility in a way that is more naturally suited for use between cellular domains managed by different operating companies. Their draft discusses the needs for private addresses, regionalized registration, and proposes the use of NAIs (Network Access Identifiers) [1], as they have been standardized within the IETF roamops working group. Finally, they discuss the possibilities for setting up home agents in foreign domains, to reduce overall Mobile IP registration requirements, and tunnel-IDs for use with private networks. The latest Mobile IPv6 [8] revisions were presented by Dave Johnson from CMU. Dave has managed to solve all the technical issues raised during the last two IETF meetings, and the latest revision has gone to Working Group last call. I don’t think there will be any substantial resistance against promulgating this protocol document to Proposed Standard. The most recent changes to the protocol include the following:
Mobile IPv6 destination options can now have data in sub-options within the option data field. There are currently two sub-options defined: a Unique Identifier suboption for use with Binding Request and Binding Update options, and a Home Agents List sub-option for use with Binding Acknowledgements. Using sub-options clears the way for easier future expansion of the protocol if needed. Mobile Computing and Communications Review, Volume 3, Number 1
The use and semantics of the list of home agents has been clarified, and each home agent can have multiple global addresses represented in a way so that all of the addresses are known to correspond to a single home agent. Processing of the Home Address option was clarified. The Home Address option is, in a way, the most important, because it is the only one that is absolutely required to be implemented by every IPv6 network node. Of course, we’d also like all IPv6 nodes to implement Binding Update processing, and they ”SHOULD” do so. These revisions are pretty much incremental except for the new layout enabled by use of the sub-options. Thus, the protocol really remains, by and large, the same as before. While there was no presentation made at the Orlando meeting, an Internet Draft entitled ”Security Considerations for Mobility and Firewalls” has been released by Jim Binkley and John Richardson that merits close attention [2]. The authors make many astute observations about the security exposures represented by tunneling protocols, of which Mobile IP is a prime example, although their observations also apply to multicast protocols and multiprotocol transport. The difficulty is especially pronounced when tunneling through firewalls, because then the tunnel endpoint has to agree to protect the intranet security to the same degree as the administration expects from the firewall. Accomplishing that feat is not at all impossible, but a great deal of care is required. One of the main points of the draft is that any tunnel endpoint has to have very explicit control over the decapsulated traffic, and that the tunnel endpoint has to be sure that the decapsulated traffic is forwarded only for the reasons related to setting up the tunnel in the first place. This may require the presence of authentication headers in every tunneled data packet. Lastly, there were presentations about how to do mobile networking using NAT units, and using L2TP. The RAT (reverse address translation) [9] using NAT and new extensions to the Mobile IP registration messages, was described briefly in the last column. The presentation describing the use of L2TP was made by Mooi Chuah (Bell Labs), and taken from an Internet Draft entitled Mobile PPP (MPPP) [6] from the PPP extensions working group. The main thesis of MPPP is that L2TP is becoming a widely deployed protocol on mobile clients, and by creating certain network entities to handle new L2TP extensions, the mobile client can arrange to have its PPP session state move with it at each new point of attachment. This essentially boils down to being a (virtual) layer 2 mobility scheme, and should be seriously considered by the mobile-ip working group.
II. BOFs The AAA BOF was important, because it may contain the key ingredient towards deployment of Mobile IP over multiple provider domains. Current Mobile IP deployments typically do not span trust boundaries, because there hasn’t been any clear agreement about how network administrators from unrelated enterprises could agree to assure mutual security, and compensate each other for resource utilization, when enabling connections for mobile computers. AAA (i.e., Radius, and now DIAMETER) can fix this problem. The AAA BOF in 9
Chicago hosted quite a few presentations, one of which was directly related to Mobile IP. The Orlando AAA BOF was more focussed on setting up the creation of a AAA working group. There seemed to be very rough consensus that a working group was needed; some speakers indicated their skepticism that security should be wrapped up into AAA, but many other speakers pointed out good reasons why no separation should be made. PILC (Performance Implications of Link Characteristics) was of direct interest to wireless aficionados. Many of the characteristics of wireless links are known to interact poorly with current TCP/IP stacks, including:
[8] D. Johnson and C. Perkins. Mobility Support in IPv6. draft-ietf-mobileip-ipv6-07.txt, Nov. 1998. (work in progress). [9] W. T. Teo, S. W. Yeow, and R. Singh. Reverse Twice Network Address Translators (RAT). draft-teoyeow-mip-rat01.txt, 1998. (work in progress).
ACM SIGMOBILE Call for Logos!
Low/Variable Bandwidth Bandwidth Long/Variable Delay High B/W-delay product Link Layer Flow Control High Error Rates Unidirectional/asymmetric connectivity non-transitive links (break the subnet model) intermittent outages small MTU links
ACM SIGMOBILE (http://www.acm.org/sigmobile/ ), is inviting participation in a Logo Design Competition. We are looking for an exciting logo (and slogan) that best represents our vibrant mobile computing and networking community. Some criteria that you should keep in mind include:
The area directors take the position that work within the IETF should not be targeted at specific media, but instead at a class of media that could be characterized by a well-defined set of characteristics. For instance, high error rates may indicate the need for some particular improvements to TCP. Or, they may not! On this subject, opinions differ widely, depending upon the particular expert consulted.
References [1] B. Aboba and M. A. Beadles. The network access identifier. draft-ietf-roamops-nai-12.txt, 1998. (work in progress). [2] J. Binkley and J. Richardson. Security Considerations for Mobility and Firewalls. draft-binkrich-mobisec-00.txt, 1998. (work in progress). [3] P. Calhoun and C. Perkins. Tunnel Establishment Protocol (TEP). draft-ietf-mobileip-calhoun-tep-00.txt, Dec. 1997. (work in progress). [4] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP Extensions. draft-calhoun-diameter-mobileip-01.txt, 1998. (work in progress). [5] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent Challenge/Response Extension. draft-ietf-mobileipchallenge-00.txt, 1998. (work in progress).
1. The logo must be cool. You should design the logo with a goal that it will be used by SIGMOBILE for at least 10 years. 2. The logo must be unique. It is your responsibility to not send us a logo that belongs to someone else. 3. The logo must be printable. We encourage the use of colors in your logo, however, the logo should still reflect it’s original intentions in greyscale since we won’t always have the luxury of printing/displaying in color (particularly when we are mobile!). You may submit your entries to
[email protected], in almost any format, as an attachment. You may also submit more than one entry. The deadline for submittal is March 15th. A committee consisting of the ACM SIGMOBILE Executive Committee members and other active members will decide on the winning entry. The winner will be notified by early April. The winner’s name will be announced during the opening ceremonies of MobiCom’99 (Seattle, Washington) and his or her name, bio and picture along with the logo will be published in an upcoming issue of ACM MC 2 R. ACM and ACM SIGMOBILE will have full ownership rights of the winning logo and consequently will have the right to make changes as needed. ACM and SIGMOBILE plans to use this logo on its letterhead, web page, and other items as it sees fit. The non-winning entries will be discarded and will not be returned. Further information is available at: http://www.ece.orst.edu/singh/logo.html
[6] M. C. Chuah, D. Grosser, G. Rai, and J. Teplitsky. Mobile PPP (MPPP). draft-ietf-pppext-mppp-00.txt, 1998. (work in progress). [7] E. Gustafsson, A. Herlitz, A. Jonsson, and M. Korling. UMTS/IMT-2000 and Mobile IP/DIAMETER Harmonization. draft-gustafsson-mobileip-imt-2000-00.txt, 1998. (work in progress). 10
Mobile Computing and Communications Review, Volume 3, Number 1
