INTERNET-DRAFT J. Manner draft-manner-lmmp-00.txt October, 2004 Expires: April, 2004 The Local Mobility Management Protocol (LMMP) IPR Statement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Status of this Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments to this draft should be sent to the IRTF mobopts-mailing list at mobopts@irtf.org Abstract Mobile IP (MIP) is the well-known protocol to handle the mobility of IP-based mobile nodes (MN). However, MIP has some drawbacks, including high latency in updates during a handover, and the need for infrastructure in the home networks of MNs. To enhance the mobility of nodes within a single domain, an access network (AN), several local mobility (also called micro mobility) management protocols have been suggested. All these protocols have their strengths and drawbacks. The deployment of these protocols is a chicken and egg problem, since both the AN and the MNs must support the same protocol. This draft presents a new protocol that can be used to replace the communication between the AN and the MNs in the existing local mobility management schemes. The protocol hides from MNs the AN-internal mobility management mechanisms and, therefore, allows MNs to log in to and roam within any AN regardless of the local mobility scheme used. Manner et al Expires March 2005 [Page 1] Internet-Draft Mobility Related Terminology October 2004 Table of Contents 1 Introduction ................................................. 2 2 The LMM Protocol ............................................. 3 2.1 Protocol Messages .......................................... 4 2.2 Protocol Operation ......................................... 6 2.3 Message encoding ........................................... 9 2.4 Security Issues ............................................ 11 2.5 Integration with Existing LMM Schemes ...................... 13 2.6 Open Issues ................................................ 14 3 Conclusions .................................................. 15 4 Security Considerations ...................................... 15 5 IANA Considerations .......................................... 15 6 Normative References ......................................... 16 7 Informative References ....................................... 16 8 Authors' Addresses ........................................... 17 1. Introduction The management of the mobility of IP-based end hosts has been a popular research topic for many years. The most well-known mobility management protocol is Mobile IP (MIP). Mobile IP is not a perfect solution, and has, for example, latency issues when mobile nodes (MN) undergo handovers. These shortcomings have triggered work towards localizing the mobility management of MNs. Local mobility management (LMM) protocols seek to enhance the mobility of MNs within the local domain, and hide the movement of MNs from correspondent nodes. These protocols operate within the access network (AN), and between access routers (AR) and MNs. The various schemes can be roughly divided in two groups, protocols based on MIP, and standalone protocols. The former group includes protocols like Hierarchical Mobile IP [HIPV6], and Fast MIP [FASTV6]. The latter group includes protocols, such as, Cellular IP [CIP,CIPV6], the Edge Mobility Architecture (EMA) [EMA], and the BRAIN Candidate Micro Mobility Protocol (BCMP) [BCMP]. The Handoff-Aware Wireless Access Internet Infrastructure (HAWAII) [HAWAII] belongs to both groups. All these protocols take a different approach in how mobility of an end host is handled in an access network. The differences can be seen in the general operation of the protocols, the algorithms and logic they use, and, most of all, on the messages needed to support the mechanisms. From the point of view of deployment, the current situation is far from satisfactory. Obviously, all access networks could deploy MIP and it's extensions, but not all administrative domains want to do that, and the deployment of MIP also expects, although does not really mandate, the deployment of Home Agenst in the MN's home network. The security framework for MIP is somewhat complex, and Network Address Translators, and internet firewalls cause problems, too. With a local mobility management scheme, both the MNs and the AN must implement the same protocol to handle the mobility. The question now is, which protocol should be used? All the mentioned protocols have their weaknesses and strengths, and are suitable for different Manner et al Expires March 2005 [Page 2] Internet-Draft Mobility Related Terminology October 2004 networks and user base. In order to deploy LMM, MNs and ANs must both implement more than one protocol. Moreover, when a new MN requests services from an AN, the parties must be able to agree on the LMM protocol used. The deployment of LMM would be much easier if there would be a unified protocol between the access network and the MNs. This would allow the access network operator to deploy the LMM protocol that best suits the network. The MNs would have a standard way to log into any access network and request services, including the management of the mobility of the MN. Moreover, a unified protocol allows experimenting with different access network internal LMM protocols without requiring changes to MNs. This draft presents the Local Mobility Management Protocol (LMMP) that works between the ARs and MNs. This specification updates [LMMP]. With this protocol MNs can log into an AN, and undergo handovers in a controlled manner. The design of LMMP is based on an analysis of existing LMM schemes, and the messages they pass between ARs and MNs. The set of protocol messages available in LMMP is intentionally large in order to accommodate different LMM schemes within ANs. The AN-internal operations triggered by LMMP messages depend on the AN. 2. The LMM Protocol The Local Mobility Management Protocol (LMMP) is meant to replace the communication over the wireless link in existing LMM schemes. The basic operation of the LMM schemes within the AN remain. When LMMP is integrated with an existing LMM scheme, not all the functions available in LMMP need to be implemented by the AN, as for instance, IP paging, or all authentication mechanisms discussed later in this draft. MNs must implement the whole specification. LMMP supports network- and mobile-initiated handovers, planned and unplanned handovers, re-initialization of MNs, and paging. An unplanned mobile-initiated handover is the basic case, but the network can also suggest or force the MN to do a handover. The new location can be left unspecified, or the network can indicate a target. Planned handovers can be performed if the network or the mobile node have the information about the next point of attachment, for example, using a Candidate Access Router Discovery mechanism [CARD]. A central design issue is LMMP is the session identifier (SID). Almost all messages carry a SID. The SID is used to refer to the session established between the MN and the AN for the whole duration the MN stays in the AN. The IP address assigned to the MN may change, but the SID remains. How the SID is chosen depends on how the AN operates, for example, it could be done by a mobility anchor point (MAP), an AAA server, or some other centralized entity. The support for paging introduces a paging area ID (PID), which is Manner et al Expires March 2005 [Page 3] Internet-Draft Mobility Related Terminology October 2004 used to define paging areas. An MN belongs to one paging area at a time, and can (must) change areas when it moves within the AN. When the MN is paged, paging messages need only be broadcast within the paging area the MN belongs to. 2.1. Protocol Messages The LMMP includes 15 message types. Individual messages are used to log into the network, to log out, to initiate and execute a handover, and to send acknowledgments and asynchronous messages, such as, routing and paging refresh. LMMP messages are sent as a new ICMP Mobility type. 1) Login: the primary function is to manage the IP addresses allocated to MNs. The message is sent by the MN and may include authentication-related information. 2) Login Ack: is used to confirm a successful login procedure. The message carries a session identifier, and may also carry a new IP address that the MN must assign to its interface, the intervals for routing and paging refresh, the paging area ID, and authentication- related data. 3) Logout: used to log out in a co-ordinated fashion from the network. Both the MN or the AR can send this message to initiate the logout procedure. 4) Init Handover: is used by either the AR or the MN to inform the other party that a handover should or must happen. The message may carry information relevant to choosing the new point of attachment, for example, a link layer address of the new point of attachment, the IP address of the new access router, or an IEEE 802.11 wireless LAN network name (ESSID). 5) Handover: is sent by the MN to the new access router to inform that it just handed over from another point of attachment. The message may carry the IP address of the previous access router, and optionally the paging area ID the MN belongs to. 6) Re-Init: is used to re-initialize the local mobility management information at the MN. The message may carry a new IP address for the MN, new routing and paging refresh intervals, and a new paging area ID. The message can either suggest or force the MN to re-initialize its data structures. 7) Re-Init Done: is used to confirm the update of the mobility management information at the MN. 8) Routing Refresh: certain access networks may require that the MNs periodically inform of themselves, that they still require the IP connectivity. If paging is used, the message is also an answer to a paging query when the MN is in idle mode. Manner et al Expires March 2005 [Page 4] Internet-Draft Mobility Related Terminology October 2004 9) Paging Refresh: is used to refresh paging information in the access network. 10) Paging Query: is used to trigger an MN in idle state to update its local mobility management state in order to start receiving downlink data packets. The update is done with a Routing refresh message. The paging query is broadcast from ARs to MNs. 11) AR Advertisement: is used to broadcast information about the access network to mobile nodes. The advertisements may carry IDs of one or more paging areas the AR belongs to, information about how the MN must configure an initial IP address, and information about what authentication method is used in the login procedure, if any. 12) Key Exchange Request: used in a built-in key exchange mechanism if no other mechanism is available. This is discussed in Section 2.4. 13) Key Exchange Reply: used in a built-in key exchange mechanism if no other mechanism is available. This is discussed in Section 2.4. 14) Ack: is used to acknowledge a message received. The message carries the sequence number of the message being acknowledged. 15) Error: is used to report error situations. If IP-level authentication is required, each message also carries relevant authentication data. The information carried by the AR advertisement can also be broadcast with IP router advertisements. Table 1 provides a summary of the LMMP messages and the payloads they carry. Manner et al Expires March 2005 [Page 5] Internet-Draft Mobility Related Terminology October 2004 Table 1: Summary of LMMP messages and their payloads. Message Sender Payload --------------------------------------------------------------------- Login MN Optional authentication- and key-exchange data Login Ack AR New SID, optional IP address, PID, routing and paging refresh intervals, and key-exchange data Logout MN/AR SID, optional authentication data Init Handover MN/AR SID, optional IP/L2 address of new AR/AP, IEEE 802.11 ESSID etc., authentication data Handover MN SID, IP of old AR, optional authentication data Re-Init AR SID, optional IP address, PID, routing and paging refresh intervals Re-Init Done AR SID, optional IP address, paging area ID, routing and paging refresh intervals Routing refresh MN SID Paging refresh MN SID, PID Paging query AR SID AR adv. AR Login and authentication information, optional paging and routing refresh intervals, and PID Key Exchange MN Public key of MN Request Key Exchange AR Nonce N1, public key of AR Reply Ack MN/AR SID, Sequence number of the received message Error MN/AR SID, Error code 2.2. Protocol Operation Access routers periodically transmit AR advertisements. These messages give new MNs necessary information about how to log in to the network, namely how to configure an initial IP address and what authentication method is used. The advertisement may also carry one or more paging area identifiers. With this information an MN can start the login procedure. In an IPv4 AN, the advertisements may instruct the MNs to use the link-local address auto-configuration mechanism, DHCP, or to use their home address in the login procedure. An IPv6-enabled MN could use the IPv6 stateless address auto- configuration, DHCPv6, or the home address. The LMMP login procedure is presented in Figure 1, and the controlled logout procedure is presented in Figure 2. The LMM protocol deployed within the AN must also support a timeout-based logout, where data structures related to an MN are removed if the MN has disappeared, e.g., a soft-state location tracking, the routing state, has expired. The network can also send the logout message to force the MN to loose its connectivity. Manner et al Expires March 2005 [Page 6] Internet-Draft Mobility Related Terminology October 2004 [MN] [AR] | | | <-------- AR Advertisement ------- | | | | ------------- Login -------------> | | | | | | <----------- Login ACK ----------- | | Figure 1: Login procedure [MN] [AR] | | ------------- Logout ------------> | | | | | | <-------------- ACK -------------- | | Figure 2: Logout procedure [MN] [OAR] [NAR] | | | <------- Init Handover ------- | | | | -------------- ACK ----------> | | | | | [link handover] | | | --------------- Handover -------------> | | | | <--------------- ACK ------------------ | | Figure 3: Planned-handover procedure initiated by the network Figure 3 shows the messaging when the network initiates a planned handover. The AR sends the MN the IP address of the new Ar (NAR), and the L2 address, ESSID, or any other information necessary to make a succesful link layer handover. The MN acknowledges this information, makes the link layer handover, and sends a Handover message to the NAR. The NAR acknowledges and accepts the handover with an Ack message. Figure 4 presents the messaging for an unplanned handover. Here, the MN does not know the IP address of the AR controlling the AP. Thus, it must first wait for an AR Advertisement. After receiving the advertisement, and the IP address of the NAR, it can send the Manner et al Expires March 2005 [Page 7] Internet-Draft Mobility Related Terminology October 2004 Handover message. The AR answers with an Ack. [MN] [OAR] [NAR] | | [link handover] | | | | <--------- AR Advertisement ----------- | | --------------- Handover -------------> | | | | <--------------- ACK ------------------ | | Figure 4: Unplanned-handover procedure A Re-Init message includes the same fields as a Login Ack message. The message can indicate that the MN must or should update its data structures. If the update is mandatory, the MN changes its data structures and replies with the Re-Init Done message. If the IP address assigned to the MN changes, many things can happen as a consequence, for example, Session Initiation Protocol-based sessions will need to issue a Re-Invite to the new IP address, Datagram Congestion Control Protocol-based transfers must send a Move message, and UDP- and TCP-based transfers can be kept running with MIP binding updates - without MIP these transfers would be closed, and must be re-started. The re-initialization can also be delayed, for example, until all existing transfers have concluded. This kind of feature would be needed, for example, with the BCMP protocol. The more the MN moves away from its original BCMP anchor point, the more the routing paths become sub-optimal. Therefore, in order to optimize routing, the MN should at some point in time switch to a new anchor point and start to use an IP address that belongs to this new anchor. Figure 5 shows the messaging for a suggested re-initialization of the MN. [MN] [AR] | | | <----------- Re-Init ------------- | | | | -------------- Ack --------------> | | | | | [Change configuration some time] | | | | | ----------- Re-Init Ack ---------> | | | Figure 5: Suggested re-initialization of MN Manner et al Expires March 2005 [Page 8] Internet-Draft Mobility Related Terminology October 2004 The LMMP protocol also includes messages for refreshing routing entries and for IP paging. The need for the MN to refresh the routing states in the network depends on the access network, thus, this function may not be needed in all networks. The LMMP specification includes a basic IP paging functionality. The paging areas may be overlapping, which means that one AR may belong to several paging areas at the same time. During the login, the paging area field of the Login Ack tells the MN its initial paging area. While the MN is in idle mode it periodically sends Paging refresh messages. If the MN goes through a handover and enters a paging area with a new identifier (noticed from the AR Adv), it will also send a paging refresh with a new PID, which updates the paging information within the AN. When the network has data packets destined to the MN and does not have accurate location information, the MN is paged. The mechanism to do this paging within the AN is out of scope of this specification, but once an AR wants to reach the MN, it sends a Paging query message to the MN. The query may be sent as unicast or broadcast. Only one MN has the indicated SID, and is able to verity the authenticity of the message. The MN responds with a routing refresh. 2.3. Message encoding LMM messages are carried as payload in the new ICMP Mobility Type. Within the ICMP message, each LMM message carries a main header, and one or more suboptions. LMM Main header, 8 octets: bits 0 7 8 23 24 31 +----------------------------------+ | Type | Len |Reserved| +----------------------------------+ | Sequence Number | +----------------------------------+ If Type is "Re-INIT", then the Reserved-field gives the re-initiation type as 0x0 being "suggested", and 0x01 means forced. Generic suboption header, 4 octects + n x 4 octets: bits 0 7 8 23 24 31 +----------------------------------+ | Type | Len |Reserved| +----------------------------------+ | Suboption payload... | | 0-n x 4 octets | +----------------------------------+ Manner et al Expires March 2005 [Page 9] Internet-Draft Mobility Related Terminology October 2004 Current LMM message types in the LMM main header: #define LMM_LOGIN 1 #define LMM_LOGIN_ACK 2 #define LMM_LOGOUT 3 #define LMM_INIT_HO 4 #define LMM_HO 5 #define LMM_REINIT 6 #define LMM_REINIT_DONE 7 #define LMM_R_REFRESH 8 (routing refresh) #define LMM_P_REFRESH 9 (paging refresh) #define LMM_P_QUERY 10 #define LMM_AR_ADV 11 #define LMM_KEY_X_REQ 12 #define LMM_KEY_X_REP 13 #define LMM_ACK 14 #define LMM_ERROR 15 Current suboption types: #define LMM_SUB_SID 1 #define LMM_SUB_IP4 2 #define LMM_SUB_IP6 3 #define LMM_SUB_AUTH 4 #define LMM_SUB_ACKNUM 5 #define LMM_SUB_R_INT 6 (routing refresh interval) #define LMM_SUB_P_INT 7 (paging refresh interval) #define LMM_SUB_P_ID 8 (paging area ID) #define LMM_SUB_OLD_AR4 9 #define LMM_SUB_OLD_AR6 10 #define LMM_SUB_NEW_AR4 11 #define LMM_SUB_NEW_AR6 12 #define LMM_SUB_NEW_MAC 13 (new link layer address) #define LMM_SUB_NEW_ESSID 14 (new ESSID for handover) #define LMM_SUB_PUB_KEY 15 #define LMM_SUB_NONCE1 16 #define LMM_SUB_NONCE2 17 #define LMM_SUB_SHARED_KEY 18 #define LMM_SUB_ERROR 19 #define LMM_SUB_CONFIG 20 Paylods of suboptions SID: - 32 bit Session ID in network byte-order Ack: - 32 bit sequence number in network byte-order MAC: - Reserved field gives MAC type, e.g. 802.11[abg] - n octets of MAC address + padding - len gives the length of the address, padding is n%4 octets Manner et al Expires March 2005 [Page 10] Internet-Draft Mobility Related Terminology October 2004 ESSID: - n octets giving the ESSID + padding with 0x00 - len gives the length of the name, padding is n%4 octets IP4: - 32 bit IPv4 address in network byte-order IP6: - 128 bit IPv6 address PUB_KEY: - reserved-field gives the type of the public key - n octets giving public key - len gives the length of the key, padding is n%4 octets SHARED_KEY: - n octets giving shared key - len gives the length of the key, padding is n%4 octets NONCE1/2: - n octets giving a nonce - len gives the length of the nonce, padding is n%4 octets AUTH: - Reserved field gives the MAC type, e.g. HMAC-MD5 or HMAC-SHA256 - n octets of MAC data - len gives the length of the MAC, padding is n%4 octets R/PREFRESH: - 32 bit giving the interval in seconds in network byte-order P_ID: - 32 bit paging area ID in network byte-order CONFIG: - reserved field gives the configuration as follows: o Authentication mode are four right-most bits: - 0x00, no authentication - 0x01, LMM-internal authentication mode - 0x02, PANA o IP address configuration are four left-most bits: - 0x01, use the Home Address in the Login message - 0x02, use stateless address auto-configuration - 0x04, use DHCP ERROR: - Reserved field gives an 8 bit warning or error code 2.4. Security Issues The LMMP protocol includes many functions that are critical to secure. A minimal function is the ability to authenticate messages sent, so that third parties are not able to masquerade as the AR or Manner et al Expires March 2005 [Page 11] Internet-Draft Mobility Related Terminology October 2004 as the MN, and send malicious messages, for example, a logout message. Currently, we can identify three schemes to secure the LMMP signaling. The first option would be to use a separate authentication protocol, such as, the Protocol for Carrying Authentication for Network Access (PANA) [PANA] [PANA-USAGE], prior to allowing the MN to log in to the network. PANA is the most recent IETF effort to define a common link-layer independent transport protocol for Extensible Authentication Protocol (EAP) [EAP] to enable network access authentication between clients and access networks. PANA can carry any authentication method that can be specified as an EAP method. The mechanism also allows negotiating all keying material for use with securing LMMP exchanges. PANA seems a promising effort, and it would be quite useless to define a separate mechanism just for the use of LMMP. If PANA is not needed and the wireless link is secured through link layer specific mechanisms, the second option would to use LMMP without any IP-layer authentication. This would be possible, for example, with a secure IEEE 802.11 wireless LAN. The third option would be to use the following hybrid IP-layer key distribution scheme built from [NEEDHAM] and [CIPV6]. Public key cryptography is used to secure the key exchange between the MN and AR. During this handshake, a per-session shared secret key is built (SK_an-mn). This key is used to authenticate all further messages belonging to the same LMMP session. The scheme requires that each AR has its own public (PK_ar) and secret key (SK_ar), the MNs all have their own public (PK_mn) and secret key (SK_mn), and there exists a secret key shared by all ARs in the access network (SK_an). The operation of the scheme is the following (Figure 6): 1. When an MN wants to log in to the network, it must first listen for an AR advertisement. 2. Once it gets the advertisement, it can deduce that the internal authentication mechanism is being used, and notes the IP address of the AR. It then sends its PK_mn to the AR in a Key Exchange Request. 3. When the AR receives the message, it chooses a nonce N_1, adds its own PK_ar, encrypts these two pieces of information with the received PK_mn, and sends these then to the MN in a Key Exchange Reply. 4. When the MN receives this message, it decrypts N_1 with its own SK_mn, chooses a second nonce N_2, encrypts both nonces with PK_mn in a Login message, and sends it to the AR. 5. When the AR receives the Login, it can decrypt N_1 and N_2 using SK_ar, and verify N_1. During the login procedure, a session ID (SID) is chosen for this MN. The AR, a MAP, or some other centralized entity then calculates an MD5 hash from {SK_an,SID}. This is the secret key SK_an-mn shared between the MN and the AN. SK_an-mn and the nonce N_2 are then encrypted using PK_mn, and sent to the MN in Manner et al Expires March 2005 [Page 12] Internet-Draft Mobility Related Terminology October 2004 the Login Ack message. 6. Finally, the MN can verify the nonce N_2 received in the Login Ack. [MN] [AR] | | | <------- AR Adv [AUTH=LMMP] ------ [1] | | | | ------- Key Ex-Req [PK_mn] ------> | [2] | | | | | <--- Key Ex-Rep [N_1, PK_ar] ----- [3] | | | | -------- Login [N_1,N_2] --------> | [4] | | | | | <- Login Ack [SID,SK_an-mn,N_2] -- [5] | | [Verify N_2] | [6] | | Figure 6: The LMM key-exchange mechanism Further LMMP messages belonging to this session carry a Message Authentication Code (MAC) calculated from all the LMMP fields with a key exchanged previously. If the presented third option is used, the authentication is calculated with SK_an-mn. When the MN makes handovers and appears under a new AR, the new AR can extract the unencrypted SID from the message, calculate by itself the SK_an-mn, and verify the authenticity of the message. 2.5. Integration with Existing LMM Schemes Integration of LMMP with existing LMM schemes, such as CIP or BCMP, would be quite straightforward. A CIP-based AN would need the ARs to be modified, but the core of the AN would remain. The biggest change would be the addition of the concept of a session identifier, and the key exchange. A basic LMMP-CIP implementation would not need to implement the re-initialization of an MN, and the network-initiated handover. The messaging in BCMP is already quite close to LMMP, and, thus, only requires minor modifications. The most significant change would be to replace the BCMP authentication method with the LMMP key exchange. The LMMP messaging would also fulfill quite well the requirements and functions defined in the EMA framework. The HAWAII scheme, on the other hand, would need much more work, as it relies on MIP messages. Manner et al Expires March 2005 [Page 13] Internet-Draft Mobility Related Terminology October 2004 2.6. Open Issues The following issues, in no particular order, are still somewhat open: - A more thorough analysis about how the protocol could be integrated with PANA is needed. - It would be interesting to integrate LMMP with the IETF Context Transfer [CT] and Candidate Access Router Discovery [CARD] protocols. - There is much international research done around mobile networks. The Login message could be extended to allow requesting more than one IP address or a subnet prefix for nodes within the mobile network. A single SID could be used by a mobile router to refer to the session established for managing the mobility of the whole subnetwork. - After having been paged, the MN answers with a routing refresh. Originally it was a Handover. The reason to do this is that a routing refresh does not need to be acked, a handover message does. Consider that if the routing refresh message is lost, the network will just send new paging queries, until a routing refresh is succesfully received at the AR. If the MN would send a HO, and it is lost, the network and the MN would have a retransmission timer set, and, thus, both would be sending new messages. This perhaps needs more analysis, for example: Consider the scenario, where the wireless link is unrealiabe, the paging query retransmission timer is 5 seconds, and a handover refresh timer would be a fixed 1 second. Now, if the reply to the paging query has a hard time getting through, * in the current case, the AN will re-broadcast the query every 5 seconds, which consumes in overall (paging_query_size * links_in_paging_area) number of octets every 5 seconds, or * in the second case, the resources consumed is the previous, but the MN will re-send the Handover message every second (consumes resources on that link only), which could lead in a faster update. One could set the timers very differently, and argue for both ways to reply to a paging query, in terms of latency of getting the MN paged succesfully, and the number of octets consumed in the AN. Actually, there should be no problem answering with either messages to a paging query. - What happens, when an AR is said to handover somewhere, but it does not know whether the new location is within the same AD, thus, will the same auth-key work? Should it try just an authenticated Handover as an answer to an AR Adv? If it gets as reply that the MAC calculation failed, it needs to re-enter the key exchange and loging phase. - In the un-planned handover case, if the internal authentication Manner et al Expires March 2005 [Page 14] Internet-Draft Mobility Related Terminology October 2004 mechanism is used, the MN can send a Handover with the old AR IP address. The new AR will receive the message, and, although not targeted to itself, should be able to verify the MAC and answer with an Ack. The MN can deduce that if it gets an Ack, that is authenticated, from a new AR address, it will change its default router (AR) address. - When paging cache expires, the network could send a broadcast warning the MN. However, to which IP address could this warning be sent? Should the MN be paged just in case it is still alive? - The encoding of the public key needs more thought. Currently RSA keys are used, and the encoding is [32-bit 'e' term in network byte order] [n bits of term 'n'] 3. Conclusions This draft presented a design for a universal local mobility management messaging between mobile nodes and access network access routers. The LMMP protocol only discussed the messaging over the wireless link, and leaves out the messaging within the access network. This allows experimenting with different access network internal LMM schemes. An initial prototype open source Linux implementation of the LMMP messaging is available. The code is divided into a library, and two applications, one client application to run on MNs, and the application for ARs. The code is very premature, but is available from http://www.cs.helsinki.fi/u/jmanner/ 4. Security Considerations The LMMP protocol raises many security issues, similar issues than in any mobility management protocol. The very basic function that is needed is the ability to authenticate the LMM messages belonging to a certain session. Without authentication, any node could send LMMP messages to others on the same link, and, e.g., force them to log out of the AN. Section 2.4 discussed several methods to support authentication and key exchange within LMMP. The main problem in the authentication process is that the IP address assigned to the MN may change, which works against most of the IP security protocols. Thus, the security framework used must not be tied to the notion of a permanent IP address. 5. IANA Considerations Should this protocol be put forward, IANA needs to assign the sub- code in the ICMP Mobility Type for the LMMP messaging, as well as, Manner et al Expires March 2005 [Page 15] Internet-Draft Mobility Related Terminology October 2004 all the message option and suboption types. 6. Normative References NONE. 7. Informative References [EAP] L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, and H. Levkowetz, "Extensible authentication protocol EAP". Internet draft (work in progress), February 2004, (draft-ietf-eap-rfc2284bis-09). [BCMP] Costas Boukis, Nikos Georganopoulos, and Hamid Aghvami, "A hardware implementation of BCMP mobility protocol for IPv6 networks". In Proceedings on the IEEE GLOBECOM, December 2003. [CIP] A. T. Campbell, J. Gomez, S. Kim, Z. Tyranyi, C-Y Wan, and A. Valko, Design, implementation and evaluation of cellular IP. IEEE Personal Communications, 7:42--49, August 2000. [PANA] Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, and Alper Yegin, "Protocol for carrying authentication for network access (PANA)". Internet draft (work in progress), February 2004, (draft-ietf-pana-pana-03). [FASTV6] Rajeev Koodli, "Fast handovers for mobile IPv6". Internet draft (work in progress), October 2003, (draft-ietf-mipshop-fast- mipv6-00). [CARD] Marco Liebsch, Ajoy Singh, Hemand Chaskar, and Daichi Funato, "Candidate access router discovery". Internet draft (work in progress), September 2003, (draft-ietf-seamoby-card-protocol-04). [CT] J. Loughney, M. Nakhjiri, C. Perkins, and R. Koodli, "Context transfer protocol". Internet draft (work in progress), October 2003, (draft-ietf-seamoby-ctp-05). [NEEDHAM] R. Needham and M. Schroeder, "Using encryption for authentication in large networks of computers." Communications of the ACM, December 1978. [PANA-USAGE] Yoshihiro Ohba, Subir Das, Basavaraj Patil, Hesham Soliman, and Alper Yegin, "Problem statement and usage scenarios for PANA". Internet draft (work in progress), April 2003, (draft-ietf- pana-usage-scenarios-06). [EMA] A. O'Neill, G. Tsirtsis, and S. Corson, "Edge mobility architecture". Internet draft (work in progress), July 2000, (draft- oneill-ema-02.txt). [HAWAII] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, and S.Y. Wang, "HAWAII: a domain-based approach for supporting mobility in Manner et al Expires March 2005 [Page 16] Internet-Draft Mobility Related Terminology October 2004 wide-area wireless networks". In Proceedings of the Seventh International Conference on Network Protocols (ICNP), pages 283 - 292, 1999. [CIPV6] Z. Shelby, D. Gatzounas, A. Campbell, and C. Wan, "Cellular IPv6". Internet draft (work in progress), November 2000. (draft- shelby-seamoby-cellularipv6-00). [HMIPV6] Hesham Soliman, Claude Castelluccia, Karim El-Malki, and Ludovic Bellier, "Hierarchical MIPv6 mobility management". Internet draft (work in progress), February 2004. (draft-ietf-mipshop- hmipv6-01.txt). [LMMP] Jukka Manner, Tapio Suihko, Kimmo Raatikainen, "Unified Local Mobility Management", Workshop on Challenges of Mobility 2004, Organised in the scope of IFIP WCC 2004 Toulouse, France August 27, 2004. 8. Authors' Addresses Jukka Manner Department of Computer Science University of Helsinki P.O. Box 68 FIN-00014 HELSINKI Finland Voice: +358-9-191-51298 Fax: +358-9-191-51120 E-Mail: jmanner@cs.helsinki.fi Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Manner et al Expires March 2005 [Page 17]