One document matched: draft-dommety-mobileip-anchor-handoff-00.txt
INTERNET DRAFT Gopal Dommety
Category: Standards Track cisco Systems
Title: draft-dommety-mobileip-anchor-handoff-00.txt
March 2000
Expires October 2000
Local and Indirect Registration for Anchoring Handoffs
draft-dommety-mobileip-anchor-handoff-00.txt
Status of this Memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and 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.
Abstract
In wide area deployment, the handoff latencies due to latencies in
Mobile IP registrations, delay incurred due to setting up of dynamic
keys, and latencies in setting up secure Tunnels could be high. This
document proposes enchantments to reduce the latencies involved in
such handoffs. It proposes enhancements to facilitate local
registration, anchoring, and global indirect registration.
1. Introduction
In wide area deployment, the handoff latencies of the current mobileip
could be high. In a mobile environment, it is very important to limit
the delay experienced in communication when a mobile moves from base
station\access point to another. This document proposes enchantments
to reduce the latencies involved in a handoff. It proposes
enhancements to facilitate local registration, anchoring, and global
indirect registration.
1.1 Problem Description
Handoff latencies could involve delays due to the following:
1. Message Exchange Between HA and FA: Mobile IP Message
traversal from FA to the HA and back.
2. Establishment of Secure Tunnels between FA and HA: In order
to secure traffic destined to/generated by a mobile, encryption of
data is being considered. Typically, this encryption is will be done
by setting up an IP Sec Tunnel using IKE. Latency in performing IKE
and creating an IP Sec Tunnel contributes to the latency experianced
by the user during handoffs.
3. Establishment of security keys between FA and HA: For the
HA and FA to authenticate each other, a shared key is used to compute
FA-HA AE (Authentication Extension). Also a shared key (a different or
the same as one used for FA-HA AE) might need to be established if IKE
with shared Key is being used to establish IP Sec Tunnel. These Keys
can be statically configured or dynamically established. If the Keys
are established dynamically, these keys have to be established before
the handoff can be completed (Keys can be generated using some form of
KDC). The key generation involves considerable delays during
handoffs. Another alternative is to use PKI authenticating Mobile IP
entities or during IKE negotiations, this also introduces considerable
delay. These delays also contribute to the latency experianced by the
user.
It is desirable to reduce or eliminate these latencies during
handoffs. In order to reduce or eliminate the above mentioned
latencies, this draft proposes Anchoring of tunnels at the old FA
(Anchor FA). To facilitate anchoring, this document introduces two
types of registrations Local Registration and Indirect Global
Registration. These mechanisms can be used to quickly perform a
handoff and later perform a global registration if required.
2. Overview
2.1 Network Model
The network model being considered is illustrated in Fig 1.
+----------------------------------+ +----------------+
| Visited | | Home |
| Network | | Network |
| | | |
| +------+ +-------+ | | +------+ |
| | | | | | | | | |
| | MN |-------------| FA1 |-------------------------| HA | |
| | | | | | | | | |
| +------+ +-------+ | | +------+ |
| | | |
| | +----------------+
| +-------+ |
| | FA2 | |
| | | |
| | | |
| +-------+ |
+----------------------------------+
Fig 1: Network Model
2.2. Mobile IP Registration (referred to as Global Registration in this draft)
The Current Mobile IP registration[1] is illustrate in Fig 2. It is
referred to as Global Registration.
+----------------------------------+ +----------------+
| Visited | | Home |
| Network | | Network |
| | | |
| +------+ +-------+ | | +------+ |
| | | 1 | |************************ | | |
| | MN |------------>| FA1 |----------2------------->| HA | |
| | |<------------| |<---------3--------------| | |
| +------+ 4 +-------+*************************+------+ |
| | Secure | |
| | Tunnel +----------------+
| +-------+ |
| | FA2 | |
| | | |
| | | |
| +-------+ |
+----------------------------------+
Fig 2. Global Registration
Messages 1,2: Registration Request
Messages 3,4: Registration Reply
2.3 Local Registration
During the Global Registration process, the MN authenticates to the
HA. During this process IPsec tunnel could be established between the
HA and FA to secure the users data. It is possible by the use of a KDC
or other mechanisims to establish a shared Key between MN-FA.
After a successful Global Registration, the FA acts as an AnchorFA for
future registrations. If during the global registration a shared-key
is established between MN and FA or there exists another mechanisim
(e.g. using PKI) for the FA to authenticate the MN, a local
registration can be performed when the MN moves within the same
domain. Local Registration is authenticated by the AnchorFA as
illustrated in Figure 3. On successful registration, a tunnel is
established between the AnchorFA and the New Visiting FA to tunnel
packets to and from the Mobile. Note that the assumption here is that
there is a mechanisim for the AnchorFA to authenticate the MN. This
solution mandates a Shared Key between every two FAs in a domain.
By performing Local Registration latencies due to components 1, 2 and 3
described in Section 1.1 are avoided.
+----------------------------------+ +----------------+
| Visited | | Home |
| Network | | Network |
| | | |
| Anchor | | |
| +-------+ | | +------+ |
| | |*************************| | |
| | FA1 | | | | HA | |
| | |*************************| | |
| +-------+ | Secure Tunnel | +------+ |
| ^ | | | |
| 2| 3| | +----------------+
| | V |
| +------+ +-------+ |
| | | 1 | | |
| | MN |------------>| FA2 | |
| | |<------------| | |
| +------+ 4 +-------+ |
+----------------------------------+
Fig 3: Local Registration
Messages 1,2: Registration Request
Messages 3,4: Registration Reply
2.4 Global Indirect Registration
If there does not exist a direct way for the AnchorFA to authenticate
the MN (For Example, a Shared Key between the MN and AnchorFA was not
established), an Indirect Global Registration as illustrated in Fig 4
can be performed to avoid the latencies due to components 2 and 3
mentioned in Section 1.1.
+----------------------------------+ +----------------+
| Visited | | Home |
| Network | | Network |
| | | |
| Anchor | | |
| +-------+ | | +------+ |
| | |************************ | | |
| | FA1 |----------3------------->| HA | |
| | |<---------4--------------| | |
| +-------+************************ +------+ |
| ^ | |Secure Tunnel | |
| 2| |5 | +----------------+
| | V |
| +------+ +-------+ |
| | | 1 | | |
| | MN |------------>| FA2 | |
| | |<------------| | |
| +------+ 6 +-------+ |
+----------------------------------+
Fig 4: Global Indirect Registration
Messages 1,2,3: Registration Request
Messages 4,5,6: Registration Reply
3. Extensions
3.1 Anchor Advertisement Extension
This section defines a new extension to the Router Discovery
Protocol [2] for use by foreign agents in a domain to advertise the
Zone ID to which the FA belongs to. The Zone ID Information is used by
Mobile (MN) to determine if it has changed Zones.
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 | Reg-Type | Zone ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Anchor Advertisement Extension
Type TDB (To be assigned by IANA)
Length Length in bytes of this extension, not including the
Type and Length bytes.
Reg-Type
GLOBAL_REG 0x0
LOCAL_REG 0x1
GLOBAL_INDIRECT_REG 0x2
Zone ID A Globally unique value used to identify the Zone.
If an FA has a Zone ID in the IRDP message, then it MUST support at
least one of local registration or Indirect Global registration.
3.2 Anchor Registration Extension
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 | Reg-Type | Resrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AnchorFA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zone ID.........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Anchor Registration Extension
Type TDB (To be assigned by IANA).
Length Length in bytes of this extension, not including the
Type and Length bytes.
Reg-Type
GLOBAL_REG 0x0
LOCAL_REG 0x1
GLOBAL_INDIRECT_REG 0x2
Resrvd Currently set to 0. To be used for future enhancements.
Zone ID A Globally unique value used to identify the Zone.
3.3 Authentication Extensions
The procedures described in this document require two new
authentication extensions, FA-AnchorFA Authentication Extension and
MN-AnchorFA Authentication Extension. Generalized Mobile IP
Authentication Extension as defined in [3] 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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: The Generalized Mobile IP Authentication Extension
Type 36 (not skippable) (see [1])
Subtype a number assigned to identify the kind of
endpoints or characteristics of the particular
authentication strategy
Length 4 plus the number of bytes in the Authenticator;
MUST be at least 20.
SPI Security Parameters Index
Authenticator The variable length Authenticator field
In this document, two subtypes are defined:
2 (TDB) FA-AnchorFA Authentication Extension
3 (TD) MN-AnchorFA Authentication Extension
4. Processing Considerations
4.1 Initial Registration
The Initial registration when a MN enter a different Zone, it preforms
a registration as specified in RFC 2002[1](referred to as Global
Registration). Additional in order to perform Local or Indirect
registration in the future Foreign Agent CoA option should be used
[1]. The MN remembers the FA (to be used as the AnchorFA) and
the Zone ID, and the lifetime (also referred to as global registration
lifetime)
4.2 Local Registration
Local registration is illustrated in Fig 3. This section give the
details of processing by the mobile IP entities.
4.2.1 MN processing
The MN is allowed to perform a Local Registration if it has previously
performed a Global Registration with a FA in the current Zone and
global lifetime that was granted has not expired. The MN sends a
Mobile IP registration to the FA with the following fields:
-Lifetime is set to the lesser of the remaining lifetime of
the last global registration and the one advertised by this FA.
-Currently only timestamp-based reply protection is supported
and timestamp-based replay protection is followed as specified in RFC
2002.
-CoA field set to the address of the FA or Collocated CoA and
sets the D bit appropriately. Home Agent and Home Address fields are
set according to RFC 2002 [1].
-MN-AnchorFA AE (Authentication Extension) is mandatory and is
used in place of MN-HA AE.
-Anchor Registration Extension is included before the
MH-AnchorFA AE. The Reg_Type field is set to LOCAL_REG. Other Fields are
set appropriately.
4.2.2 FA processing
FA on receipt of the Registration Request from the MN processes the
Request as Specified in RFC 2002[1] and additionally:
1. Checks the Zone ID: If it does not match its Zone ID,
Registration Reject with error code of INVALID_ZONEID is sent to the
Mobile.
2. Check for Unsupported Registration Type Request. If the MN
requests a Registration Type not advertised by the FA, a registration
reject with UNSUPPORTED_REG_TYPE is sent to the Mobile.
3. For Local Registration FA-AnchorFA AE is Mandatory. It is
computed in place of the FA-HA AE.
4. Sends the Registration Message to AnchorFA (instead of HA
as in a Global Registration [1] ).
On receiving a successful Registration Reply from the AnchorFA, if
the MN is using Foreign Agent CoA, the appropriate tunnel is created
to the AnchorFA (instead of to HA as in the Global Registration). The
FA also updates the lifetime as specified in RFC 2002[1]. In case of a
Registration Reject the FA performs processing as specified in
RFC 2002[1] and also relays the error codes for INVALID_ZONEID and
UNSUPPORTED_REG_TYPE.
4.2.3 AnchorFA processing
AnchorFA on receipt of the Registration Request from the FA processes
the Request as a HA as specified in RFC 2002[1] and additionally:
1. Checks the Zone ID: If it does not match its Zone ID,
Registration Reject with error code of INVALID_ZONEID is sent to the
FA.
2. Check for Unsupported Registration Type Request. If the MN
requests a Registration Type not supported, a registration reject with
UNSUPPORTED_REG_TYPE is sent to the FA.
3. If FA-AnchorFA AE is missing or fails authentication then
Registration Reject is sent to the FA with an FA_FAILED_AUTHENTICATION
Code.
4. If MN-AnchorFA AE is missing or fails authentication then
Registration is Rejected with MN_FAILED_AUTHNETICATION Code.
5. Registration Lifetime requested has to be less than the
remaining global registration lifetime, other wise the lifetime is
field is updated to the remaining global registration lifetime.
6. If the MN has not previously performed global registration
with the AnchorFA with global registered lifetime remaining, the
registration is rejected with MN_UNKNOWN error code.
On successful registration, the AnchorFA sends a registration reply.
The reply is formed similar to how a HA would [1]. Additionally:
1. Anchor Registration Extension is included before the
MN-AnchorFA AE. This extension is copied from the Registration Request.
2. Lifetime field is set to be lesser of the the remaining
global registration lifetime, the requested value, and a configured
value (for providing the option of forcing global registration within a
given time).
3. For Registration Reply in a Local Registration, FA-AnchorFA
AE is Mandatory. It is computed in place of the FA-HA AE [1].
4. MN-AnchorFA AE is mandatory and is used in place of MN-HA
AE [1].
On successful registration the AnchorFA creates an appropriate tunnel
to the CoA and sets up routing such that datagrams that arrive
destined to this mobile from HA-AnchorFA tunnel is tunneled to the
via the AnchorFA-FA tunnel. If reverse tunneling is set, then the
datagrams that come from the FA-AnchorFA tunnel and generated by this
mobile (source address of the Mobile) are tunneled to the HA.
4.3 Global Indirect Registration
Global Indirect Registration is illustrated in Fig 4. This section
give the details of processing by the mobile IP entities.
4.3.1 MN processing
The MN is allowed to perform a Global Indirect Registration if it has
previously performed a Global Registration with a FA in the current
Zone. The registration request considerations are similar to the
considerations in the case of Local Registrations. The differences
with the Local Registrations are as follows:
- Only Foreign Agent CoA option is valid with Global Indirect
Registration. and CoA is set to AnchorFA.
- MN-HA AE is mandatory
- AnchorFA-MN Authentication Extension is optional
- Lifetime is chosen a recommended in RFC 2002 [1].
- Both timestamp-based and nonce based reply protection is supported.
-Anchor Registration Extension is included before the
MN-AnchorFA AE. The Reg_Type field is set to GLOBAL_INDIRECT_REG.
4.3.2 FA processing
The processing performed is similar to the processing done during
Local Registration. Note that in this case only Foreign Agent CoA
option is chosen and the AnchorFA is set as the CoA. In this
registration option the also AnchorFA-FA AE is mandatory.
4.3.3 AnchorFA processing
AnchorFA on receipt of the Registration Request from the FA processes
the Request as a FA would process according to RFC 2002 [1] and additionally:
1. Checks the Zone ID: If it does not match its Zone ID,
Registration Reject with error code of INVALID_ZONEID is sent to the
FA.
2. Check for Unsupported Registration Type Request. If the MN
requests a Registration Type not supported, a registration reject with
UNSUPPORTED_REG_TYPE is sent to the FA.
3. If FA-AnchorFA AE is missing or fails authentication then
Registration Reject is sent to the FA with an FA_FAILED_AUTHENTICATION
Code.
4. MN-AnchorFA AE is optional and if present and fails
authentication then Registration is Rejected with
MN_FAILED_AUTHNETICATION Code.
5. If the MN has not previously performed global registration
with the AnchorFA with global registered lifetime remaining, the
registration is rejected with MN_UNKNOWN error code.
If the Registration Request is not denied it is sent to the HA with
the following:
1. FA-HA AE can be used optionally
On receipt of a registration reply. If the registration is rejected
the reject is relayed with mandatory AnchorFA-FA AE and optional
MN-AnchorFA AE.
If registration was accepted by the HA, the Anchor updates the Global Registration lifetime for this mobile and ,sends a registration
reply. The reply is relayed to the FA with the following additions:
1. Anchor Registration Extension is included before the
FA-AnchorFA AE. This extension is copied from the Registration Request.
2. HA_FA AE in the reply message from the HA if present is
authenticated and removed.
3. FA-AnchorFA AE is Mandatory. It is computed in place of the
FA-HA AE [1].
4. MN-AnchorFA AE is optional.
On successful registration the AnchorFA creates an appropriate tunnel
to the CoA and sets up routing such that datagrams that arrive
destined to this mobile from HA-AnchorFA tunnel is tunneled to the
via the AnchorFA-FA tunnel. If reverse tunneling is set, then the
datagrams that come from the FA-AnchorFA tunnel and generated by this
mobile (source address of the Mobile) are tunneled to the HA.
4.3.4 HA processing
Does regular HA processing.
5. Error Codes
The Following error codes are to be defined:
INVALID_ZONEID TBD
UNSUPPORTED_REG_TYPE TBD
MN_UNKNOWN TBD
6. Intellectual Property Right Notice
Cisco may have IPR on material contained in this draft. Upon
approval by the IESG of the relevant Internet standards track
specification and if any patents issue to Cisco or its subsidiaries
with claims that are necessary for practicing this standard, any
party will be able to obtain the right to implement, use and
distribute the technology or works when implementing, using or
distributing technology based upon the specific specification(s)
under openly specified, reasonable, non-discriminatory terms.
7. IANA Considerations
The Anchor Registration Extension defined in Section 3.2 is Mobile IP
registration extension as defined in RFC 2002 [1]. IANA should
assign a Type value consistent with this number space.
The Mobile IP Anchor Advertisement extension defined in section 3.1 is
taken from the numbering space defined for Mobile IP [1]
extensions to the ICMP Router Advertisements [2]. The numbers, 36 and
132, for the Generalized Authentication extension
The Code values defined in Section 5 are error codes as defined in
RFC 2002 [1]. IANA should assign values to these codes consistent
with this number space.
A new number space is being created for enumerating subtypes of the
Generalized Authentication extension [3]. The AnchorFA-FA AE and
AnchorFA-MN AE Subtypes are to be taken from this numbering space.
8. Acknowledgments
The author would like to thank Kent Leung for his
suggestions and helpful discussion.
9. References
[1] C. Perkins. IP Mobility Support. Request for Comments
(Proposed Standard) 2002, Internet Engineering Task Force,
October 1996.
[2] S. Deering. ICMP Router Discovery Messages. Request for
Comments (Proposed Standard) 1256, Internet Engineering Task
Force, September 1991.
[3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent
Challenge/Response Extension.
draft-ietf-mobileip-challenge-09.txt, Feb 2000. (work in
progress).
[4] Eva Gustafsson, et. al. Mobile IP Regional Tunnel Management.
draft-ietf-mobileip-reg-tunnel-01.txt, August 1999.
[5] K. El Malki, et. al. Fast Handoff Method for Real-Time Traffic
over Scaleable Mobile IP Networks.
draft-elmalki-mobileip-fast-handoffs-01.txt, June 1999.
Dommety [Page 4]
Internet Draft
Author Information
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: gdommety@cisco.com
Dommety Local and Indirect Registration for Anchoring Handoffs March 2000
Appendix
The following enhancements will be considered in the future:
1. Option of Forcing Global Registration
Perform Global Registration Immediately
Perform Global Registration Next time.
2. Buffering issues during handoffs
3. Simultaneous Bindings at HA and AnchorFA
4. Private addressing: For private addressing GRE with Key has to be used.
5. Authorization from HA for performing Local Registrations
6. Overlapping Zones
7. Time offset enhancement extensions -This gives a hint of the
time offset between the FA and the MN to the mobile during global
registration. This can be used to successfully register at the
AnchorFA for Local Registration.
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 | Reservd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Time Difference +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAFTECH AB 2003-2026 | 2026-04-23 04:22:14 |