Internet DRAFT - draft-cho-nemo-mr-registration
draft-cho-nemo-mr-registration
NEMO Working Group Seongho Cho
Internet Draft Jongkeun Na
Document: draft-cho-nemo-mr-registration- Chongkwon Kim
00.txt Seoul National University
Expires: October 2004 Sungjin Lee
Hyunjung Kang
Changhoi Koo
Samsung Electronics
April 2004
Neighbor MR Authentication and Registration Mechanism in Multihomed
Mobile Networks
draft-cho-nemo-mr-registration-00
Status of this Memo
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 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.
This Internet-Draft will expire on October 26, 2004.
Abstract
In multihomed mobile networks, multiple Mobile Routers can be
deployed to provide fault recovery or load sharing. Also, each Mobile
Router (MR) can have a bi-directional tunnel with its own Home Agent
(HA). In this multihomed mobile network scenario, the neighbor root
MR can replace or share the operation of another MR. Therefore, MRs
should cooperate with each other to provide session continuity or
load sharing. We present an authentication and registration mechanism
without introducing extra signaling messages. Using the Return
Cho, et al. Expires - October 2004 [Page 1]
Internet Draft Neighbor MR Authentication and Registration April 2004
Routability procedure of Mobile IPv6 and the Binding Update message
with the neighbor MR registration option, the MR can authenticate and
register the neighbor MR to its own HA. And the HA can use this
registered neighbor MR information to provide fault recovery or load
sharing.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. Related Multihoming Scenarios and Problem Definition...........4
4. Tunnel Alteration Scenarios....................................4
4.1 Link Failure...............................................4
4.2 MR Failure.................................................4
4.3 Dynamic Load Sharing or Bi-casting.........................5
5. Neighbor MR Authentication and Registration....................5
5.1 Neighbor MRs Discovery.....................................5
5.2 Neighbor MR Authentication using Return Routability........5
5.3 Neighbor MR Registration with the Binding Update Message...6
6. Additional Data Structure for Multihoming......................7
6.1 Neighbor MR List for Mobile Router.........................7
6.2 Neighbor MR List for Home Agent............................7
7. Additional Messages to NEMO Basic Support Protocol.............7
7.1 Neighbor MR Registration Option............................7
7.2 Binding Acknowledgement Status.............................9
8. Conclusion.....................................................9
9. Security Considerations........................................9
Acknowledgement...................................................9
A. HA-based Tunnel Recovery Mechanism............................10
References.......................................................10
Author's Addresses...............................................11
1. Introduction
In multihomed mobile networks, multiple MRs can be used to provide
fault recovery or load sharing [6]. To support these properties, each
MR should cooperate with neighbor MRs. For fault recovery, each MR
should substitute the other MR in case of MR failure. And for load
sharing, the HA should dynamically make a tunnel through any MR in
the multihomed mobile network.
Cho, et al. Expires - October 2004 [Page 2]
Internet Draft Neighbor MR Authentication and Registration April 2004
To provide fault recovery, the nested tunnel recovery mechanism [3]
was introduced. In case of the egress link failure of the MR, the MR
can be allocated the new Care-of-Address (CoA) from the neighbor root
MR and make another tunnel through the nested tunnel. From this
solution, however, the previous session can be continued only in case
of link failure. In case of MR failure, the neighbor MR can not
cooperate with each other without any previous neighbor information.
Related threats are already treated at the multihoming threat
analysis draft [10]. To solve the tunnel failure problem, the
neighbor MR authentication and registration mechanism is needed. This
registration mechanism can be applied tunnel recovery, dynamic load
sharing, or bi-casting.
In this document, we introduce the neighbor MR authentication and
registration mechanism using Return Routability Procedure and Binding
Update message. Compared to the NEMO basic support protocol [2], we
only introduce the Neighbor MR Registration Option in Binding Update
message as a mobility option. This solution is quite simple and can
be applied to solve various problems, like not only link failure, but
MR failure, load sharing, or bi-casting by the HA.
Also, we present a possible solution, named as a HA-based Tunnel
Recovery Mechanism in multihomed mobile networks at Section A. After
detecting the broken tunnel, the HA can initiate the tunnel recovery
with an alternative MR. Also, this mechanism can be applied to the
dynamic load sharing or bi-casting. For load sharing or bi-casting,
the HA can make another tunnel with a neighbor MR.
2. Terminology
It is assumed that readers are familiar with NEMO terminology
described in [3, 7], and the terms described in [2, 6].
The neighbor MR
In this document, we only consider the MR which has a connection
to the fixed Internet. This MR is defined as a root MR at the
terminology draft [7]. Therefore, the neighbor MR is also the root
MR at the same multihomed mobile network with a connection to the
fixed Internet.
The neighbor HA
We define the neighbor HA which is a correspond HA of the neighbor
MR. The MR has a secure association with its own HA, but the
neighbor MR does not have any relation with another HA. Originally,
the neighbor HA is not known to other MRs.
The neighbor MR information
Cho, et al. Expires - October 2004 [Page 3]
Internet Draft Neighbor MR Authentication and Registration April 2004
In this document, we define the neighbor MR information which can
be acquired from the neighbor MR or neighbor HA. This MR
information is the Home Address, Care-of Address, and Mobile
Network Prefix.
3. Related Multihoming Scenarios and Problem Definition
In this draft, we are focusing on (N, N, 1) and (N, N, N) cases in
multihoming issue draft [3]. From the view of problem oriented
approach in the multihoming issue draft, the DoubleBed case can be
this class. In this case, some related threats are identified in
threat analysis draft [8, 9, 10]. In these multihomed mobile networks,
the sub mobile network can join and leave dynamically. The MR should
authenticate and register neighbor MRs to provide fault recovery and
load sharing. In some situation, MRs can be manually configured by
the network administrators especially if MRs are in the same
administrative domain. However, it is highly desirable for mobile
routers to discover alternate MRs automatically for greater
flexibility. Therefore, the dynamic authentication and registration
mechanism is crucial.
4. Tunnel Alteration Scenarios
In this section, we discuss tunnel alteration scenarios. To provide
fault recovery, broken tunnel scenarios should be considered. Broken
tunnel scenarios can be classified as link failure and MR failure.
And for load sharing or bi-casting, non-associated MRs and HAs pair
should be able to make the bi-directional tunnel dynamically. By
classifying the broken tunnel cases and reviewing the load sharing,
we identify the reason of neighbor MR registration.
4.1 Link Failure
Usually, the MR uses the wireless channel as an access channel for
the mobility support. This wireless channel has unreliability because
of channel error, blackout, or handover. From these factors, sudden
link failure can be happen. Even though the wireless channel is not
broken, in case of highly degraded channel, an alternative link can
be cost effective. In this case, this high-loss channel can be
treated as a broken link.
4.2 MR Failure
The MR itself can have a problem, like an operating system bug,
packet queue overflow, the lack of CPU cycle, data structure overflow,
power supply problem, etc. Sudden hardware failures can happen, and
Cho, et al. Expires - October 2004 [Page 4]
Internet Draft Neighbor MR Authentication and Registration April 2004
this problem affects whole network nodes in the mobile network. These
node problems can cause sudden service suspension.
And, the MR is easy to expose to malicious attacks. Because of the
mobility, the MR can be a target of any kinds of Denial-of-Service
attacks. And detecting attacks is much harder than that of fixed
nodes. Because the MR usually uses the wireless channel, the wireless
link itself is more vulnerable for attacks. Especially, the MR can
experience DoS attacks, like packet flooding, data structure attack
using malicious requests or reflected Denial-of-Service attacks.
In these cases, the MR cannot activate the alternative tunnel
recovery. Therefore, sessions using the previous tunnel cannot be
recovered after failure.
4.3 Dynamic Load Sharing or Bi-casting
To support dynamic load sharing, non-associated MRs and HAs should
cooperate with each other. For traffic from the mobile network, each
MR can share its traffic load with neighbor MRs. In that case, each
MR should have the neighbor MR information. For the traffic from the
outside network, the need for load sharing through HAs can exist. If
this traffic sharing is done from the HA side, HAs should share
neighbor MRs’ information in the same mobile network. Using this
information, neighbor HA can make a bi-directional tunnel with the
alternative MR.
5. Neighbor MR Authentication and Registration
In this section, we present our Neighbor MR Authentication and
Registration Mechanism. Our mechanism consists of Neighbor MRs
Discovery, neighbor MR Authentication using Return Routability
Procedure, and neighbor MRs Registration using Binding Update message.
5.1 Neighbor MRs Discovery
By listening Router Advertisement (RA) messages on the *ingress*
interface, the MR can get information of neighbor MRs. This Router
Advertisement can be initiated from the explicit Router Solicitation
(RS) message. The root MR which is at the visiting network should
response to this RS message from the ingress interface. And the
responding RA message should contain its own Home Address and Mobile
Network Prefix as an option. From this neighbor discovery process,
the MR can acquire neighbor MR's information, like Home Address (HoA),
Care-of-Address (CoA), and Mobile Network Prefix (MNP).
5.2 Neighbor MR Authentication using Return Routability
Cho, et al. Expires - October 2004 [Page 5]
Internet Draft Neighbor MR Authentication and Registration April 2004
After acquiring the neighbor MR information, the MR can authenticate
the received neighbor MR information. Because the MR operates both as
the Mobile Node (MN) of Mobile IPv6 (MIPv6) [1] and the MR of NEMO
basic support protocol, the MR can operate as a MN to the neighbor MR.
As a MN of MIPv6, the MR initiates the Return Routability procedure
with the neighbor MR. Using the Home Test and Care-of Test, the MR
can authenticate its own HoA and CoA to the neighbor MR. Therefore,
after the mutual Return Routability procedure, each MR can
authenticate the neighbor MRs which are discovered from the RA
message.
5.3 Neighbor MR Registration with the Binding Update Message
After the above Return Routability procedure finished successfully,
the MR can register the neighbor MRs with Binding Update message.
With an option noted as the Neighbor MR Registration Option, the MR
registers acquired neighbor MRs’ HoA, CoA, MNP to its own HA. This
registration is periodically repeated as the BU sent. From this
periodic registration, the HA can keep the last neighbor MRs list.
An example is explained in Figure 1. From the neighbor discovery
process, MR2 can get the neighbor MR information from the RA message.
Here, the RS process can be optional. After neighbor discovery, MR2
initiates Home Test Init message and Care-of Test Init message for
the Return Routability test. Of course, MR1 also initiates the Return
Routability procedure. From this mutual Return Routability test, each
MR can authenticate the neighbor MR information. If the Return
Routability test is failed, MR1 may discard the neighbor information.
If the Return Routability test is succeeded, MR1 update this neighbor
MR information to the Neighbor MR List and sends the Binding Update
message with the Neighbor MR Registration option. After receiving BU
from MR1, HA1 updates the neighbor MR information to the Neighbor MR
List. And HA1 sends the Binding Acknowledgement.
MR1 MR2 HA1 HA2
|[<- RS -] | | |
| - RA -> | | |
| | --- Home Test Init ---> |
| <--- Home Test Init --- |
| <------- | (Care-of Test Init) |
| -------> | (Care-of Test) | |
| --- Home Test ---> |
| |<--- Home Test - |
| -BU w/ neighbor MR reg opt-> | |
| <- Binding Acknowledgement - | |
Figure 1 Neighbor MRs Registration
Cho, et al. Expires - October 2004 [Page 6]
Internet Draft Neighbor MR Authentication and Registration April 2004
6. Additional Data Structure for Multihoming
6.1 Neighbor MR List for Mobile Router
The Mobile Router keeps the Neighbor MR List. In this Neighbor MR
List, the HA address, the HoA, CoA, and MNP pairs of neighbor MRs are
kept. The HA address can be obtained from the Home Test of the Return
Routability procedure. And other information is obtained and verified
from the above authentication and registration process. This neighbor
MR list of the MR can be used when the data packet is received from
the neighbor HA. After receiving the IP-in-IP encapsulated packet,
the MR can verify by checking whether the outer packet's source
address is the HA address of the neighbor Mobile Router and the inner
packet’ destination address belongs to the MNP.
This neighbor MR List should be updated from the periodic Router
Advertisement message.
6.2 Neighbor MR List for Home Agent
The Home Agent keeps the Neighbor MR List of the multihomed MR. In
this Neighbor MR List, the HoA, CoA, and MNP pairs of the neighbor MR
should be kept. This neighbor MR list can be used when the data
tunnel are recovered or the traffics are shared with the neighbor MR.
In case of a tunnel recovery, the MR can select the alternative MR
from this Neighbor MR List. Using the CoA of neighbor MR, the HA can
make a bi-directional tunnel with the alternative MR. In case of load
sharing, the HA can verify the bi-directional tunnel which comes from
the neighbor MR or HA, for the outbound and inbound traffic
respectively. After receiving the load-shared IP-in-IP encapsulated
packet, the Home Agent can verify by checking whether the outer
packet's source address is the HA address or the neighbor MR and the
inner packets's destination address belongs to the MNP.
This neighbor MR List should be updated from the periodic Binding
Update message.
7. Additional Messages to NEMO Basic Support Protocol
7.1 Neighbor MR Registration Option
This Neighbor MR Registration Option is included in the Binding
Update message as a mobility option to register the neighbor MR.
There could be multiple Neighbor MR Registration Options if there
exist multiple MRs at the mobile network. The Neighbor MR
Registration Option has an alignment requirement.
Figure 2 shows the Neighbor MR Registration Option format.
Cho, et al. Expires - October 2004 [Page 7]
Internet Draft Neighbor MR Authentication and Registration April 2004
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 | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8 bit unsigned integer indicating the length in octets of the
option excluding the type and length fields. Set to 50.
Reserved
This field is unused for now. The value MUST be initialized to
zero by the sender, and MUST be ignored by the receiver.
Prefix Length
8 bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option.
Cho, et al. Expires - October 2004 [Page 8]
Internet Draft Neighbor MR Authentication and Registration April 2004
Home Address
A 16 byte field contains the Home Address of the Neighbor MR.
Home Address
A 16 byte field contains the Care-of Address of the Neighbor MR.
Mobile Network Prefix
A 16 byte field contains the Mobile Network Prefix of the Neighbor
MR.
7.2 Binding Acknowledgement Status
This document also introduces the following new Binding
Acknowledgement status value.
144 Neighbor MR Registration failed
This message is used to notify the failed neighbor MR registration.
If the HA cannot provide the functionality of managing Neighbor MR
List or wants to deny the registration request, the Binding
Acknowledgement can be returned with this status value.
8. Conclusion
In this draft, we propose a Neighbor MR Authentication and
Registration mechanism for multihomed mobile networks without new
signaling message. Using Return Routability procedure of MIPv6 and
Binding Update with a new option of NEMO basic support protocol, the
MR can authenticate and register neighbor MRs to its own HA. This
solution is quite simple and can be applied to solve various problems,
like not only link failure, but MR failure, load sharing, or bi-
casting by the HA.
9. Security Considerations
Related security problems are treated at the draft, "Threats for
Multi-homed Mobile Networks" [10]. Similar threats are also mentioned
at other drafts [8, 9].
Acknowledgement
Cho, et al. Expires - October 2004 [Page 9]
Internet Draft Neighbor MR Authentication and Registration April 2004
A. HA-based Tunnel Recovery Mechanism
We also consider the HA-based Tunnel Recovery Mechanism using above
registered neighbor MR information. This mechanism consists of the
broken tunnel detection, the tunnel recovery request/response process,
and tunnel recovery by the neighbor MR.
There already exists some tunnel availability test from the HA. The
multihoming issue draft [3] considers "tunnel liveness". Basically,
the periodic Binding Update and Binding Acknowledgement exchange can
check the tunnel liveness. By sending binding updates regularly with
shorter livetime value, the HA can check the tunnel liveness. This
however may be overhead because the Binding Update message SHOULD be
encrypted. And another kinds of method is "tunnel heartbeats". If
there exists no data packets exchange, small probe packets can be
exchanged between the HA and the MR for shorter period of binding
updates. Using this mechanism, the HA can detect the broken tunnel
caused by either link failure or MR failure. This active probing can
be used for more reliable tunnel liveness.
After detecting the tunnel failure, the HA can select the neighbor MR
from the Neighbor MR List to recover the previous tunnel. This tunnel
can be nested through the neighbor HA if we apply the NEMO Basic
Support protocol. Also, this tunnel can be directly delivered to the
neighbor MR using any route optimization mechanism. The HA sends the
Tunnel Recovery Request message to the selected neighbor MR. Tunnel
Recovery Request include the HA's IP Address, MR's Home Address, and
Mobile Network Prefix. And the neighbor MR can verify the request by
checking own Neighbor MR List. If the HA requests the tunneling for
the valid neighbor MR, then it decides whether it can serve the
request or not. And it responds to the HA with the Tunnel Recovery
Response message.
If the HA is approved to make a recovered tunnel with the neighbor MR,
the HA can detour packets to the neighbor MR. And the MR can check
the bi-directional tunnel by checking the outer packet's source
address and the inner packet's destination address. If tunneled
packets are valid, then tunneled packets can be decapsulated and
delivered to the destination node.
References
[1] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6.
Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in
progress). June 2003.
[2] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. thubert,
"Network Mobility (NEMO) Basic Support Protocol," draft-ietf-
nemo-basic-support-02.txt (work in progress), May 2003.
Cho, et al. Expires - October 2004 [Page 10]
Internet Draft Neighbor MR Authentication and Registration April 2004
[3] C. Ng, J. Charbon, and E. Paik, "Multihoming Issues in Network
Mobility Support," draft-ng-nemo-multihoming-issues-03.txt (work
in progress), Feb 2004.
[4] J. Charbon, C-W. Ng, K. Mitsuya, and T. Ernst, "Evaluating Multi-
homing Support in NEMO Basic Solution," draft-charbon-nemo-
multihoming-evaluation-00.txt (work in progress), Jul 2003.
[5] E. K. Paik, H. S. Cho, and T. Ernst, "Multihomed Mobile Networks
Problem Statements," draft-paik-nemo-multihoming-problem-00.txt
(work in progress), Oct 2003.
[6] T. Ernst, N. Montavont, R. Wakikawa, E. Paik, C. Ng, K.
Kuladinithi, and T. Noel, "Goals and Benefits of Multihoming,"
draft-multihoming-generic-goals-and-benefits-00.txt (work in
progress), Feb 2004.
[7] T. Ernst, H. Lach, "Network Mobility Support Terminology," draft-
ietf-nemo-terminology-00.txt (work in progress), May 2003.
[8] S. Jung, F. Zhao, F. Wu, H. Kim and S. Sohn, "Threat Analysis for
NEMO," Internet Draft, IETF draft-jung-nemo-threat-analysis-01.txt,
(work in progress), Oct 2003
[9] A. Petrescu, A. Olivereau, C. Janreteau, H.-Y. Lach, "Threats for
Basic Network Mobility Support (NEMO threats)," draft-petrescu-
nemo-threats-01.txt, (work in progress), Jan 2004.
[10] S. Cho, J. Na, C. Kim, S. Lee, H. Kang, C. Koo, "Threat for
Multi-homed Mobile Networks," draft-cho-nemo-threat-multihoming-
00, (work in progress), Feb 2004.
Author's Addresses
Seongho Cho
Seoul National University
School of CSE, Seoul National University,
San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea.
Phone: +82-2-884-3936
Email: shcho@popeye.snu.ac.kr
Jongkeun Na
Seoul National University
School of CSE, Seoul National University,
San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea.
Phone: +82-2-884-3936
Email: jkna@popeye.snu.ac.kr
Cho, et al. Expires - October 2004 [Page 11]
Internet Draft Neighbor MR Authentication and Registration April 2004
Chongkwon Kim
Seoul National University
School of CSE, Seoul National University,
San 56-1, Shillim dong, Gwanak gu, Seoul, 151-744, Korea.
Phone: +82-2-884-3936
Email: ckim@popeye.snu.ac.kr
Sungjin Lee
Global Standards & Research Team
Telecommunication R&D Center,
Samsung Electronics, KOREA
Email : steve.lee@samsung.com
Hyunjeong Kang
Global Standards & Research Team
Telecommunication R&D Center,
Samsung Electronics, KOREA
Email : hyunjeong.kang@samsung.com
Changhoi Koo
Global Standards & Research Team
Telecommunication R&D Center,
Samsung Electronics, KOREA
Email : chkoo@samsung.com
Cho, et al. Expires - October 2004 [Page 12]
