One document matched: draft-manner-lmmp-00.txt
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] | PAFTECH AB 2003-2026 | 2026-04-23 20:16:37 |