Internet DRAFT - draft-hong-mip6-multihoming-scenarios
draft-hong-mip6-multihoming-scenarios
MIP6 Working Group SeungSun Hong
Internet Draft Fan Zhao
Expires: January 12, 2005 S. Felix, Wu
UC Davis
Souhwan Jung
Soongsil Univ.
HyunGon Kim
ETRI
July 12, 2004
UC Davis
Multihoming Scenarios with Multiple Home Agents in Mobile IPv6
draft-hong-mip6-multihoming-scenarios-00.txt
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 January, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes the multihoming issues in Mobile IP networks.
It specifies the basic multihoming scenario, a mobile node is multihomed
to multiple home agents within an AS, then describes the multihoming
method for this basic scenario. The principle of the multihoming method in
this document is that multiple home agents share security associations
established between a mobile node and a home agent. By sharing security
associations among home agents who serve the same home link, we can reduce
the burden of MN to manage the HA list. This document points out technical
issues related to sharing security associations among home agents and
specifies possible solutions for them. Also, this document describes how
to extend the basic multihoming method to more complicated multihoming
cases such as multiple home agents in different AS.
S. Hong, et al Expires January 2005 [Page 1]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
1. Introduction
1.1 Motivations
Multihoming, using multiple connectivities to multiple ISPs
simultaneously, provides more reliable and robust network connectivity to
customer networks by supporting fault-tolerance, load-sharing. However,
supporting multihoming in Mobile IP is more complicated matter because
there are invariably many multihoming scenarios in Mobile IP.
Wakikawa, et al [5] proposed the HAHA protocol which includes multiple
home agents activation scenario. In HAHA protocol, the MN must keep track
of the home agents who have its binding information to verify the source
address of tunneled packets. In addition, MN must establish an independent
SA with each HA to receive to tunneled packets from multiple home agents,
which increases the burden of MN to manage security association (SA)
database.
This document describes several multihoming scenarios in Mobile IP. These
scenarios considers the same situation as the multiple Home Agents (HA)
activation scenario in HAHA protocol, but they have different assumptions
from those in the HAHA protocol. The multihoming scenarios in this
document only considers the case that MN only has one HA address, so MN
feels like it is communicating with a single HA. Another difference from
the HAHA protocol, the MN only maintains one SA for multiple HAs by
allowing multiple HAs to share SAs established between the primary HA and
the MN. This document describes these multihoming scenarios and specifies
technical issues in supporting these multihoming scenarios. In addition,
the document provides possible solutions for technical problems in
supporting multi-homed MN in Mobile IP network.
1.2 Assumptions
Designing a comprehensive multihoming architecture for various multihoming
scenarios is important, however, it is a difficult task to achieve because
of its complexity. In this section, we make a few assumptions to limit the
scope of the multihoming scenario and reduce the complexity of new
multihoming architecture in the given scenario. Removing these assumptions
does not mean that the architecture would fail to support mobility for
multihomed MNs. It simply requires replacing each assumptions with a
specific scheme which has the same functionalities as the following
assumptions.
(Assumption 1) MN accesses multiple HAs using a single IP addresses: The
simplest way to remove this assumption is providing the HA list to MN.
That is, if MN has knowledge about IP addresses of HAs, it can select its
preferred HA based on the list. However, this solution is not transparent
to MN because it requires an extra function to manage the HA list. This
assumption is applicable across the document unless we specify a different
assumption.
S. Hong, et al Expires January 2005 [Page 2]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
(Assumption 2) MN has only one active CoA at a time: Whenever MN visits
new network, it receives new COA. Thus, it is possible for MN to have
multiple CoAs. There are many scenarios that may lead to multiple CoAs for
MN, as described in [1]. This document assumes one active CoA for MN
because it is more common case in Mobile IP network.
(Assumption 3) There exist trust relations among HAs: Since this document
supports multiple HAs, it requires inter-HA communications. Without a
certain level of trust relations among HAs, the new multihoming
architecture can easily be compromised. This document provide a inter-HA
protocol, the extension of the HAHA protocol, to provide the trust
relations among HAs.
2. Basic multihoming scenario - multiple HAs within a single AS
The purpose of composing a basic scenario is to decide the scope of basic
multihoming architecture and to specify how this basic architecture does
support multi-homed MNs. The basic scenario considers the case that MN is
multihomed to multiple HAs in different home links within a single AS. The
fundamental differences of this basic scenario from the HAHA protocol are:
(1) multiple HAs are accessable using one HA address, (2) multiple HAs
share security associations established between MN and the primary HA. The
goal of this multihoming configuration is to provide HA redundancy for MN.
AS 001 (192.168.1.0/24)
+-----------------------------------+
| +------+ +------+ |
| | HA 2 |============| HA 3 | |
| +------+ +------+ |
| + = = + |
| + = = + |
| + = +------+ = + |
| + =| HA 1 |= + |
| + +--++--+ + |
+-----------+----++----+------------+
+ ++ +
+++ Bidirectional + ++ +
+++ IPsec tunnel +------+-++-+------+
| +------+ | Visiting network
+++ Unidirectional | |Router| | 10.10.10/24
IPsec tunnel | +------+ |
| + ++ + |
=== Secure inter-HA | +------+ | HA : 192.168.1.254
communication channel | | MN |<------- HN : 192.168.1.0/24
| +------+ | HoA: 192.168.1.100
+------------------+ CoA: 10.10.10.100
Figure 1. The architecture for the basic multihoming scenario
S. Hong, et al Expires January 2005 [Page 3]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
Figure 1 illustrates an example of basic multihoming scenario. In this
scenario, we have three HAs which are located at different links within a
single AS. Each HA advertises the same network prefix for MN's home link
via the IGP routing protocol. The metric/cost used for these advertisement
can be statistically configured on HA or dynamically be MN which sending a
kind of priority information to each HA [6]. In addition, the AS routers
where the home links are located also advertises BGP messages to the
Internet.
A MN, whose home address (HoA) is 192.168.1.100, visits a network
10.10.10/24, and receives a care-of-address, 10.10.10.100. The MN sends
out the Binding Update (BU) message to its home link with setting the
destination address, 192.168.1.254 reserved for HAs (We assume that the
MN's HoA is already registered). When the BU message is reached to AS 1,
it will be routed to one of HAs according to IGP routing policy. the HA
who receives the BU message from the MN becomes the primary HA for that
MN. In this example, we assume the home link where HA 1 is on is the best
route, so HA 1 is the primary HA for the MN. When HA 1 receives the BU
message, it updates the binding information on its Binding Information
Cache and sends out the Binding Information Update messages to other HAs
at different link.
The primary HA (HA 1) sends the BU acknowledgment message back to the MN,
and invokes the IKE security association (SA) negotiation if necessary. If
the current SA between HA and MN is revoked or expired, the primary HA
should invoke the IKE SA negotiation. If SA for a specific MN has been
updated, the primary HA should send out the SA Information Update message
to other HAs. All HAs that receive the SA Information Update message
should confirm the reception of the message using the SA Information
acknowledgment.
When the MN finishes updating binding information and SA information (if
necessary), it can communicate with multiple HAs using multiple
bidirectional tunnels. Conceptually, the MN feels like that it is
exchanging packets with only its primary HA. That is, all outbound packets
from MN are routed to the primary HA because it is the best route to the
home link, and all inbound packets from multiple HAs are tunneled to the
MN with one HA source address.
The benefits of the basic multihoming scenario is that we can reduce the
burden of MN to maintain the HA list and SA database. Since the MN can
access multiple HAs using one HA address and multiple HAs share SAs, the
MN does not have to maintain HA list to track HAs who have its binding
information and SA information. If the MN should establish SA with each
HA, the burden to manage SA database would increase. Furthermore, if the
Key Management Mobility Capability (K) bit in the BU message is cleared,
HA should re-establish SA between MN and HA. It is obvious that IKE SA
renegotiation per BU dramatically increases the burden of MN.
There are several technical issues in supporting this basic multihoming
scenario, including inconsistent IPsec sequence number and additional
inter-HA communications. The following section describes these technical
issues and possible solutions for them.
S. Hong, et al Expires January 2005 [Page 4]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
3. Technical issues in implementing basic scenario
The basic principle of the basic multihoming scenario is that multiple HAs
share SA established between MN and its primary HA. However, there are
several technical issues in implementing this basic multihoming scenario.
This subsection describes these technical issues and suggests possible
solutions to deal with these issues.
3.1 Inconsistent IPsec sequence number
The IPsec sequence number is an unsigned 32-bit counter which
monotonically increments by one for each IPsec packet [2,3]. This field is
mandatory and always present even if the anti-replay service for a
specific SA is disabled. In addition, the sender's and receiver's counters
are initialized to 0 when an SA is established, and the transmitted
sequence number must never be allowed to cycle. That, if all sequence
numbers are used, the sender's and receiver's counters must be reset to 0
by establishing new SA and key.
If multiple HAs are allowed to share the same SA, it is difficult to
synchronize IPsec sequence number among tunneled packets by them. That is,
if multiple HAs initially set their IPsec sequence numbers to 0 and
independently increase their sequence number by one, then an HA would
repeat the sequence number sent by other HA. This packet with repeated
IPsec sequence number by different HA is still considered as the replayed
and discard at MN.
To cope with inconsistent IPsec sequence number among multiple senders, we
provide additional information, the original IP address of HA, for MN to
separate the IPsec packet stream from each HA. All HAs are accessible from
MN using the reserved HA address, but each HA should have its original IP
address to be attached to the home link. Each HA who shares the same SA adds
its original IP address information to the destination option header in
the outer header of tunneled packet [8]. To do this, we define the
ORIGIN_IP destination option.
When MN receives the inbound tunneled packets, it checks the ORIGIN_IP
option in the destination option header to extract the original ip address
of the sender HA. Based on the original HA address, the MN can split the
IPsec tunneled streams into an individual stream from each HA.
Additionally, to avoid unnecessary examination of the destination option
header for the non-multihomed MN, the primary HA must notify whether the
MN is multihomed or not. For this purpose, we define the multi-homed (M)
bit and use in the BU acknowledgment message. If M bit is set (using one
bit from reserved field), it indicates that the MN is multihomed to
multiple HAs.
S. Hong, et al Expires January 2005 [Page 5]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
3.2 Inter-HA protocol
Because the basic multihoming scenario assumes multiple HAs who share
SA information, inter-HA protocol is required to synchronize binding and
SA information among HAs. The Inter-HA protocol can be categorized into
three parts, which are synchronizing binding information, synchronizing SA
information, and HA failure detection and recovery. Most messages except
synchronizing SA information in this section are equivalent to those
defined in HAHA protocol [5]. All the message described in this section
must be authenticated and encrypted using the IPsec ESP mode.
3.2.1 Synchronizing binding information
There are two possible ways in synchronizing binding information. First,
HA can request Binding Cache information for a specific MN to its primary
HA. In this case, the HA that wants Binding Cache information sends out the
Binding Information Request message to the primary HA for the MN. When the
primary HA for the MN receives the Binding Information request message, it
replies with the Binding information update message. In this case, the
sender of the Binding Information update message copies the identifier
field from the request message.
The second is that the primary HA for a specific MN sends out the Binding
Information Update message to other HAs on the HA list whenever there is
the change in its Binding Information Cache. So, if MN registers a new CoA
to the primary HA, it sends out new binding information of the MN to other
HAs in order to synchronize binding information among them. The Binding
Information update message has the same format as the Binding update
request message, but it sets the identifier field with random number and
also use the Binding Cache Entry Information option [5].
When a HA receives the solicited or unsolicited Binding Information update
message, it confirms with the Binding Information acknowledgment message
3.2.2 Synchronizing SA information
Along with synchronizing binding information, synchronizing SA information
is a critical task to share SA information among multiple HAs. The
procedure of synchronizing SA information is very similar to that of
binding information except it requires an additional SA Information renew
request message.
HA can request the SA information for a specific MN to the primary HA
using the SA information request message. This message also has 16 bit
non-zero identifier field to identity the sender of the request message.
When the primary HA receives the SA Information request message, it
replies with the SA information update message.
In this case, the primary HA copies the identifier field from the request
message and store SA entry
information in the message.
S. Hong, et al Expires January 2005 [Page 6]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
On the other hand, HA can send out the SA Information update message in
the same manner as the Binding Information update message when there is
the change in SA Information for a specific MN by reestablishing SA due to
SA revocation or expiration. In this case, the primary HA sets random
number in the identifier field. When other HAs receive the SA Information
update message, it replies with the SA Information acknowledgment message.
Since multiple HA shares SAs, it is possible that one HA used all IPsec
sequence numbers earlier than other HAs. If that HA is the primary one, it
reestablishes new SA for MN and sends out the SA Information update
message. However, the HA is not primary HA, then it sends the SA
Information renew request message to the primary HA for that SA. When the
primary HA receives this message, it renew SA Information with the MN
and sends out the SA Information update message to other HAs.
3.3.3 HA failure detection and recovery
There are two possible methods to detect HA failure. First, HA can detect
the failure of other HAs by sending an application-level keepalive message
to other HAs on a regular basis. If an HA does not respond to these
messages consecutively, the sender HA of this message marks the HA entry
as invalid.
The second method is to use the HA HELLO message defined in [5]. HA
regularly sends out these HA HELLO messages to inform other HAs of
activeness of the sender HA of these messages. So, if an HA does not
receive these message several times in a row, it marks the HA entry as
invalid.
Recovering from HA failure in the basic scenario is relatively simple
because HAs share SA information. Even when an HA detects the failure of
one of HAs, it still sends out incoming traffic to the MN because it has
the SA information for the MN. However, if the failed HA is the primary HA
for MN, the outgoing traffic from MN will experience delay until the
IGP settles down new paths to other HAs. Once the new routes to an
alternate HA are available, the MN is able to keep sending out tunneled
packets with the same SA before the failure without re-establishing SA
information. In addition, if the failed HA is the primary HA for the MN
and the SA for MN should be renegotiated, the HA receiving the outbound
traffic from the MN checks if the primary HA for the MN is marked as
invalid. If yes, it takes over the primary HA position for the MN by
sending out the primary HA switch message as defined in [5].
To make this work, A HA must know all other HAs located in different links
beforehand by manually configured on each HA.
S. Hong, et al Expires January 2005 [Page 7]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
4. Extended scenarios - multiple HAs in different AS
In this section we extends the basic scenario to support multiple HAs in
different AS.
4.1 Multiple HAs in different AS with one HoA
This scenario considers the case that MN's home links are distributed in
different AS. The MN still can access the its home network in different
AS using one HoA. In practice, this scenario represents the global HA
distribution that multiple HAs are distributed globally irrespective of
routing domains to support the global access for their mobile customers.
The goal of this multi-homing scenario is to provide HA redundancy and
kind of a route optimization.
+-----+ +-----+
| CN1 | === : secure inter-HA communication | CN2 |
+-*-^-+ +-^-*-+
* * * *
* * AS 1(192.168.1/24) AS 2(192.168.1/24) * *
+---*-*-------------------+ +-------------------*-*---+
| +-V-*----+ +--------+ | | +--------+ +----*-V-+ |
| | HA 1-1 |===| HA 1-2 |==============| HA 2-1 |===| HA 2-2 | |
| +--+-^---+ +--------+ | | +--------+ +---^-+--+ |
+----+-+------------------+ +------------------+-+----+
+ + + +
+ + + +
+ +++++++++++++++++++++++++ ++++++++++++++++++++++++ +
+++++++++++++++++++++++++ + + ++++++++++++++++++++++++
+ + + +
+------+-+-+-+------+ VN : 10.10.10/24
***> : non-ipsec | +V-+-+-V-+ | HN : 192.168.1/24
data traffic | | MN |<----- HoA: 192.168.1.100
+++> : ipsec tunneled | +--------+ | CoA: 10.10.10.100
data traffic +-------------------+ HA : 192.168.1.254
Figure 2. Extended multihoming scenario: multiple HAs in different AS.
They are accessable using one HA address.
Figure 2 illustrates an example of the extended multihoming scenario. As
shown in Figure 2, each AS supports multiple home links for MN as defined
in the basic scenario in section 2, and these ASs support multiple HAs
globally distributed in different routing domain by advertising the same
network prefix of MN's home network (192.169.1/24). The rest of Internet
will use the closest HA to communicate with the MN according to the BGP
routing policy.
S. Hong, et al Expires January 2005 [Page 8]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
The benefit of this architecture is that the inbound traffic to the MN is
always going to be the cheapest HA according to the BGP policy of the CN
domain. For the outbound traffic from the MN is also going to be the cheapest
HA (the primary HA) to the visiting network, but it does not mean the
cheapest path to the CN. To provide a kind of route optimization for the
outbound traffic from the MN, we need the inter-HA communications. That is,
if other HA can provide the better route path to the CN than that of the
primary HA, it can issue the primary HA switch message to the current
primary HA.
The technical issue in this extended scenario is that multiple ASs should
advertise the same network prefix for MN's home link. These announcements
can be deleted by the mechanisms to cope with "route hijacking". Carbon,
et al [6] and Savola [7] pointed out this issue and showed the possible
solutions. In theory, all prefixes advertised by anyone should be available
in the route registry (e.g., Internet Route Registry (IRR))to examine
multihoming for a specific prefix.
4.2 Multiple HAs in different AS with multiple HoAs
Another extended multihoming scenario is that multiple HAs are distributed
in different AS, but MN has multiple HoAs, may be one for each AS. This
scenario is the typical example of site-multihoming. This scenario is
likely that we have the combination of multiple basic scenario. That is,
the configuration of each AS are identical to that of the basic scenario.
Since HAs within an AS do not interfere with those in other AS, no change
in the basic scenario is required. Also, the HA in one AS does not have to
communicate with one in other HA, no inter-HA communication between them
is necessary.
S. Hong, et al Expires January 2005 [Page 9]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
5. Security considerations
To protect all the messages between multiple HAs, the HA should use the
IPsec ESP mode to authenticate and encrypt inter-HA messages.
Since multiple HAs share SA information established between the MN and its
primary HA, the primary HA should authenticate the other HAs who serves
the same MN to prevent a malicious HA from launching attacks. Whenever a
new HA is introduced to serve the same network prefix, other HAs should
verify if this new HA is authenticated and authorized for the service.
Since this multihoming scenario needs trust relations among HAs who serve
the same home link, the mechanism to isolate the compromised HA when they
detects it is necesary.
For further security considerations, please refer to [4].
References
[1] N. Montavont, R. Wakikawa, T. Ernst, and T. Noel, "Problem statement
for multihomed mobile nodes," IETF Mobile IP Working Group, Internet-
Draft, Work expired, October 2003.
[2] S. Kent and R. Atkinson, "RFC:2402: IP authentication header," IETF
Network working group, November 1998.
[3] S. Kent and R. Atkinson, "RFC 2406: IP encapsulation security payload
(ESP)," IETF Network working group, November 1998.
[4] D, Johnson, C. Perkins, and J. Arkko, "RFC 3775: Mobility support in
IPv6," IETF Network working group, June 2004.
[5] R. Wakikawa, V. Devarapalli, and P. Thubert, "Inter Home Agent
Protocol (HAHA)," IETF MIP6/NEMO Working group, Internet-Draft, Work in
progress, February 2004.
[6] J. Charbon, C-W, NG, K. Mitsuya, and T. Ernst, "Evaluating multihoming
support in NEMO basic solution," IETF NEMO working group, Internet-Draft,
Work expired, July 2003.
[7] P. Salova, "Examining site multihoming in finnish networks," Master's
thesis, Helsinki University of Technology, April 2003.
[8] S. Deering, R. Hinden, "RFC 2460: Internet Protocol, Version 6
(IPv6)," IETF Network working group, December 1998.
S. Hong, et al Expires January 2005 [Page 10]
Internet-Draft Multihoming scenario in mipv6 12 July 2004
Authors' Addresses
SeungSun Hong
Department of Computer Science
University of California, Davis
One Shield Avenue
Davis, CA 95616
USA
Phone: +1-530-752-3128
EMail: shong@ucdavis.edu
Fan Zhao
Department of Computer Science
University of California, Davis
One Shield Avenue
Davis, CA 95616
USA
Phone: +1-530-752-3128
EMail: fanzhao@ucdavis.edu
Felix Wu
Department of Computer Science
University of California, Davis
One Shield Avenue
Davis, CA 95616
USA
Phone: +1-530-754-7070
EMail: wu@cs.ucdavis.edu
Souhwan Jung
Soongsil University
1-1, Sangdo-dong, Dongjak-ku
Seoul 156-743
KOREA
Phone: +82-2-820-0714
EMail: souhwanj@ssu.ac.kr
HyunGon Kim
Network Security Department
ETRI
161 Kajong-Dong, Yusong-Gu
Taejon 305-600
KOREA
Phone: +82-42-860-5428
Email: hyungon@etri.re.kr
Hong, et al. [Page 11]
Internet Draft Supporting Multi-sender SA July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
S. Hong, et al Expires January 2005 [Page 11]
