NEMO Working Group Jongkeun Na
Internet Draft Seongho Cho
Expires: March 2004 Chongkwon Kim
Seoul National University
Sunjin Lee
Hyunjeong Kang
Changhoi Koo
Samsung Electronics
September 2003
Secure Nested Tunnels Optimization using Nested Path Information
draft-na-nemo-nested-path-info-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.
Abstract
This document addresses how to securely achieve the nested tunnels
optimization using nested path information that reflects the
optimized path from Top Level Mobile Router(TLMR) to Mobile
Router(MR) in nested mobile networks. The solution is based on
Reverse Routing Header(RRH) idea and the concern of security
Na, et al. Expires - March 2004 [Page 1]
Internet Draft Nested Path Information September 2003
problem in RRH. By carefully taking a look at the simplicity of
Routing Header Type 2 routing mechanism and the complexity of
Access Router Option(ARO) based solution to get rid of the threat
of possible attack for RRH, the proposed solution has been
considered to preserve the efficiency of RRH without the lack of
security.
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.
Na, et al. Expires - March 2004 [Page 2]
Internet Draft Nested Path Information September 2003
Table of Contents
1. Introduction.................................................4
2. Terminology..................................................5
3. Overview of Operation........................................6
3.1 Reverse Packet Delivery(MR3 -> HA3).....................7
3.2 Forward Packet Delivery(HA3 -> MR3).....................8
4. Extensions..................................................10
4.1 Neighbor Discovery Extensions..........................10
4.2 MIPv6 Extensions.......................................11
4.3 MR Extension...........................................14
4.4 HA Extension...........................................15
5. Further Route Optimization..................................17
5.1 MN-HA Tunnel Optimization in Mobile Networks...........17
5.2 MN-CN Route Optimization in Mobile Networks............17
6. Security Considerations.....................................18
6.1 NPI Authenticity.......................................18
6.2 How to avoid the spoofing attack.......................18
6.3 The existence of fake MR...............................18
References.....................................................19
Acknowledgments................................................20
Authors' Addresses.............................................20
Na, et al. Expires - March 2004 [Page 3]
Internet Draft Nested Path Information September 2003
1. Introduction
NEMO Basic Support Solution[15] would suppose to support
transparent mobility to mobile network nodes(MNNs) in mobile
networks by using MR-HA bi-directional tunneling. However, if
multiple mobile networks are nested, that brings an routing
overhead to us which is well known as "pinball" routing problem[14].
So, it needs to avoid routing overhead like this because we can
easily imagine the applications of nested mobile networks such as
NEMO in public transportations e.g. train, bus, airplane. In [4]
and [5], the nested routing problem has been broadly touched but in
general still not acceptable we think.
To get generally acceptable solution for this problem, this
document addresses how to securely achieve the nested tunnels
optimization using nested path information that reflects the
optimized path from Top Level Mobile Router(TLMR) to Mobile
Router(MR) in nested mobile networks. The solution is based on
Reverse Routing Header(RRH)[4] idea and the concern of spoofing
attack(or redirect attack) from [5]. By carefully taking a look at
the simplicity of Routing Header Type 2 routing mechanism and the
complexity of Access Router Option(ARO) solution to get rid of the
threat of possible attack for RRH, the proposed solution has been
considered to preserve the efficiency of RRH without the lack of
security.
In proposed solution, MR uses Nested Path Information(NPI) to
inform the optimized routing path of its HA. It discovers NPI in RA
sent from its Access Router(AR) and deliver that information to its
HA through BU. Unlike RRH of [4], NPI cannot be modified or forged
by the intermediate ARs. In case of the existence of fake AR on the
nested path, Of course, false NPI information may be used by AR.
It's impossible that there is unauthenticated fake AR if only
network access control properly applied. But, although it's
possible, the fake AR would not get any reward for such an
impersonating if the HA-MR tunnel could be protected by IPSEC and
the integrity of NPI also additionally protected by Authentication
Header[8]. In section 6, the security considerations will be more
mentioned.
Na, et al. Expires - March 2004 [Page 4]
Internet Draft Nested Path Information September 2003
2. Terminology
It is assumed that readers are familiar with NEMO terminology
described in [2][14], and the terms described in [4][5]. In
addition, we define a few of terms used in describing the operation
of our solution.
Nested Path Information (NPI)
A form of array of IPv6 global addresses that are the
addresses of Mobile Routers on the nested path which means
from TLMR to any nested MR in nested mobile networks.
RO-enabled
That is a similar with "NEMO-enabled" used in [ARO]. Simply,
any tunnel that applied with the scheme of route
optimization proposed by this document is referred to a "RO-
enabled" tunnel.
Nested Path Option (NP Option)
New type of option added in Router Advertisement to discover
NPI in nested mobile networks. That information is flowed
from TLMR to downward by relaying of each AR.
Nested Routing Path Option (NRP Option)
New type of mobility option used in BU message. That carries
NPI to Home Agent(HA).
Na, et al. Expires - March 2004 [Page 5]
Internet Draft Nested Path Information September 2003
3. Overview of Operation
We use the nested mobile network example as following Fig.1.
+---------------------+
| Internet |---CN
+---------------|-----+
/ Access Router
HA3 |
======*====== {RA[NPO:1:MR1-CoA]}
MR1(TLMR)
|
====*==============================*==========
MR2 {RA[NPO:2:MR1-CoA|MR2-CoA]} MR4 {RA[NPO:2:MR1-CoA|MR4-CoA]}
| |
=======*==== =====================?====
MR3 {RA[NPO:3:MR1-CoA|MR2-CoA|MR3-CoA]} VMN
|
====|=======|===== <--- MONET3
LFN LMN
Fig.1 An example nested Mobile Network
In this example, we would have three bi-directional nested tunnels
by using NEMO Basic Solution if any nested tunnel optimization not
applied.
-----------.
--------/ /-----------.
-------/ | | /---------
CN -----( - - | - - - | - - - | - - - | - - -(----- LFN
_HA3-------\ | | \--------- MR3
_HA2--------\ \----------- MR2
_HA1----------- MR1
With the proposed solution, we can get one optimized tunnel as
follows. From the following optimized tunnel, we can see that our
solution's optimized result is same with one in [4].
----------------------------------------------
CN -----(|- - - - - - - - - - - - - - - - - - - - -|||(----- LFN
HA3---------------------------------------------- MR3
MR1 MR2
No receiving RA with NP Option in the access link gets MR1 know
that it is TLMR of nested mobile networks. As in Fig.1, MR1 sends
periodically RA with NP Option to its ingress link. MR2 and MR3
each relays its RA with modified NP Option, in which IPv6 global
address of the egress interface is appended, to ingress links.
Na, et al. Expires - March 2004 [Page 6]
Internet Draft Nested Path Information September 2003
Through the NP Option relay of MRs, MR3 results in getting know the
nested path such like MR1-CoA->MR2-CoA->MR3-CoA, the path to TLMR
from MR3.
MR3 can start extended Binding Update(BU) with HA3 for the route
optimization after getting NPI from RA with NP Option. MR3 uses NRP
Option, newly introduced mobility option to securely carry NPI to
HA3. This kind of BU with NRP Option makes it possible that the
nested tunnels optimization between MR3 and HA3. Basically, BU/BACK
message is exchanged to HA3 through normal nested tunnels. MR3_HA
receiving BU with NRP Option makes new Binding Cache(BC) entry with
NPI and RO-enabled tunnel-interface for forward tunneling. With
receiving successful BACK, MR3 also sets up the RO-enabled tunnel
interface for reverse tunneling. In RO-enabled tunnel interfaces
each created in MR3 and HA3 through MIPv6 BU/BACK exchange, NPI is
effectively used in routing that optimizing the nested tunnels.
After the establishment of RO-enabled bi-directional tunnel, MR3
can forward the packets from its ingress interfaces to RO-enabled
reverse tunnel interface and HA3 can do the packets destined to
MONET3 to RO-enabled forward tunnel interface. For details, the
following subsections describe the procedure of reverse and forward
packet delivery using the RO-enabled tunnel.
3.1 Reverse Packet Delivery(MR3 -> HA3)
In order to forward the packets sent from ingress side to HA3, MR3
makes sure that the correspondent tunnel interface is already
established by both MR3 and HA3. If that tunnel interface marked
with RO-enabled and NPI available in Binding Update List(BUL) entry,
MR3 builds the tunneling packet like below and forwards to next-hop
MR on the nested path. In the outer IPv6 header, Type 6 Routing
Header(RH) needs to be used to indicate next-hop MRs that this
tunneling packet can be delivered to the Home Agent through the
nested tunnels optimization using NPI.
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] ||
MR3: |MR3-CoA| HA3 |:oEXT:|type| 2 |MR1-CoA | MR2-CoA || iPACKET
| | |: :| 6 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
In the example, MR2 does not forward packets to HA2 via default
reverse tunnel(nested tunnel) if they have RH Type 6 optional
header. Instead of reverse tunneling, MR2 refers to the address,
Addr[IDX] indexed by IDX field, and makes sure that it is MR2's
address. If the indexed address matched with any of addresses of
its egress interfaces, MR2 forwards the packet, for which the
Na, et al. Expires - March 2004 [Page 7]
Internet Draft Nested Path Information September 2003
source address and IDX field in outer IPv6 header are only changed
as below, to that interface. Otherwise, the packet will be
discarded. As like MR2's operation, MR1 does the same thing as
below.
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] ||
MR2: |MR2_CoA| HA3 |:oEXT:|type| 1 |MR1-CoA | MR2-CoA || iPACKET
| | |: :| 6 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] ||
MR1: |MR1_CoA| HA3 |:oEXT:|type| 0 |MR1-CoA | MR2-CoA || iPACKET
| | |: :| 6 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
The packet sent from MR1 through the RO-enabled tunnel is delivered
to HA3. HA3 detects the existence of Type 6 RH optional header and
searches a BC entry with NPI that has TLMR on the nested path that
is exactly matched with the source address of the packet. If BU
entry is valid and the correspondent RO-enabled tunnel interface
exists, the packet is forwarded to the interface so that it is
properly decapsulated. As a result of the MR3-HA3 tunneling, the
inner packet properly routed to the original destination by HA3.
3.2 Forward Packet Delivery(HA3 -> MR3)
The packet destined to the LFN in MONET3 is intercepted by HA3 and
delivered by the procedure as follows. HA3 gets know that MR3-HA3
tunnel is RO-enabled. Therefore, the packet is forwarded to MR3
with encapsulated as below via RO-enabled tunnel interface.
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] ||
HA3:| HA3 |MR1-CoA|:oEXT:|type| 2 |MR2-CoA | MR3-CoA || iPACKET
| | |: :| 2 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
MR1 does routing with extended semantics for the packets that have
RH Type 2 optional header as in [4]. The packets with RH Type 2
header sent from HA3 properly delivered to MR3 by MR1 and MR2 on
the nested path as follows:
Na, et al. Expires - March 2004 [Page 8]
Internet Draft Nested Path Information September 2003
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] ||
MR1:|_HA3 |MR2-CoA|:oEXT:|type| 1 |MR2-CoA | MR3-CoA || iPACKET
| | |: :| 2 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
<--------------- outer IPv6 header --------------->
+-------+-------++ -- ++----+---+--------+---------++--------
|oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] ||
MR2:| HA3 |MR3-CoA|:oEXT:|type| 0 |MR2-CoA | MR3-CoA || iPACKET
| | |: :| 2 | | | ||
+-------+-------++ -- ++----+---+--------+---------++--------
The packets with LS=0 are no more routed in MR3, therefore they are
processed by MR3 as if sent from nested forward tunneling between
MR3 and HA3. In the end, the packets decapsulated, and forwarded to
LFN.
Na, et al. Expires - March 2004 [Page 9]
Internet Draft Nested Path Information September 2003
4. Extensions
The proposed solution requires some extensions for existing MIPv6
and IPv6 protocols.
4.1 Neighbor Discovery Extensions
4.1.1 Nested Path Option(NP Option)
Basically, we use the same RA format used in [4] section 6.1. And
also, the format of additional NP Option inherits most of fields in
Tree Information Option used in [4] section 6.2 because of the
similarity of usage. The format of NP Option 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 | Length | Tree_Prefer. | NP_Length=n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|H| Reserved | Bandwidth | DelayTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRPreference | BootTimeRandom |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathCRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Addr[1] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |
| o |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Addr[n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over the originally
specified for Tree Information Option in [4]:
Na, et al. Expires - March 2004 [Page 10]
Internet Draft Nested Path Information September 2003
Type
8-bit unsigned integer set to the assigned value by the IANA.
TBD.
Length
8-bit unsigned integer updated by each MR on the nested path.
The length of the option (including the type and length
fields) in units of 8 octets.
NP_Length
4.1.2 8-bit unsigned integer set to 1 by the TLMR. That indicates
the size of Addr[] array.
Addr[1]
TLMR's IPv6 global address, set by the TLMR. Identifier of
the tree.
Addr[n]
IPv6 global address of n-th MRs on the way, set by n-th MR.
The TLMR MUST include this option in its Router Advertisements.
A MR receiving this option from its Attachment Router MUST update
the Length, TreeDepth, MRPreference, BootTimeRandom and PathCRC
fields,and addtionally MUST append its IPv6 global address as a
Addr[n] slot if it is n-th MR on the path, and MUST propagate it on
its ingress interface(s). The alignment requirement of the NP
Option is 8n.
4.2 MIPv6 Extensions
4.2.1 Nested Routing Path Option(NRP Option)
MR adds new mobility option, NRP Option in BU message to set up the
RO-enabled tunnel with its HA. The format of this option is as
follows:
Na, et al. Expires - March 2004 [Page 11]
Internet Draft Nested Path Information September 2003
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 = TBA | Length=16*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NP_Length=n | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Addr[1](=TLMR address) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |
| o |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Addr[n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8-bit identifier of the Mobility Header option type. The
value that identifies an Access Router Option is yet to be
assigned.
Length
8-bit unsigned integer that specifies the length of the
mobility option in octets, excluding Type and Length fields.
NP_Length
8-bit unsigned integer that indicates the number of Addr[]
slots.
Addr[1..n]
Vector of IPv6 global addresses of MRs on the nested path,
numbered 1 to n.
Na, et al. Expires - March 2004 [Page 12]
Internet Draft Nested Path Information September 2003
NRP Option is only valid in a Binding Update message. The purpose
of this option is to inform HA that it can do optimize the nested
tunnels overhead. Using this information, HA can route packets to
the sender via the MRs on the nested path by extended Type 2 RH
optional header.
4.2.2 Extended Type 2 Routing Header(RH)
The format and semantics of Type 2 Routing Header is perfectly same
with one defined in [4] section 4.1.
4.2.3 Type 6 Routing Header
Type 6 Routing Header is newly defined to enable the NPI-aware
routing by MRs on the nested path. the format of this header 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=6| NextIndex=n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Addr[1] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. . . . .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Addr[n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
Na, et al. Expires - March 2004 [Page 13]
Internet Draft Nested Path Information September 2003
8-bit selector. Identifies the type of header immediately
following the Routing Header. Uses the same value as the
IPv6 Next Header field [10].
Hdr Ext Len
8-bit unsigned integer. Length of the routing header in 8-
octet units, not including the first 8 octets. This value
is always equal to twice the number of addresses in the
Address vector.
Routing Type
8-bit unsigned integer that contains the value 6. This is
type value unconfirmed by IANA. TBD.
NextIndex
8-bit unsigned integer. This value identifies the index of
address vector. The forwarder needs to make sure that
indexed address is same with its address. If yes, it changes
the source address of the packet to its address and forwards
the packet. By hop-by-hop, the mobile router that
understands this type of routing header MUST decrements
NextIndex by 1 at forwarding. If NextIndex is 0, ignore this
option.
Address[1..n]
Vector of 128-bit addresses, numbered 1 to n.
4.3 MR Extension
According to MIPv6 Spec.[1], MR MUST maintain Binding Update
List(BU List). In managing BU List, the following information MUST
be maintained additionally to use RO-enabled MR-HA tunnel defined
in this proposed solution.
Nested Tunnels Optimization(NTO) flag :
When set indicates that the associated BU entry is RO-
enabled for nested tunnels optimization.
Nested Path Information(NPI) Address Vector :
The path vector information transferred in Nested Routing
Path Option at BU.
Na, et al. Expires - March 2004 [Page 14]
Internet Draft Nested Path Information September 2003
The successful BU with NRP Option allows the ready of RO-enabled
tunnel interface that would be associated with the correspondent
entry of BU List. That tunnel interface is set up to add Type 6 RH
optional header at the encapsulation of tunneled packets. After RO-
enabled BU, all packets through RO-enabled reverse tunnel have Type
6 RH optional header in tunnel extension header so that they are
properly delivered to HA through the optimized nested path.
For packets sent from HA through Type 2 RH, MR decapsulates the
outer packet, and forwards the inner packet to the ingress side.
There is no difference with normal packets routed via nested tunnel
because source address is HA and destination address is MR.
4.4 HA Extension
According to MIPv6 Spec.[1], HA MUST maintain Binding Cache(BC).
Like MR extension, HA MUST maintain additionally the following
information in associated BC entry in case of receiving BU with NRP
Option.
Nested Tunnels Optimization(NTO) flag :
When set indicates that the associated BU entry is RO-
enabled for nested tunnels optimization.
Nested Path Information(NPI) Address Vector :
The path vector information carried in Nested Routing Path
Option during BU.
With the success of BU, HA has to add new entry in tunnel interface
table. At that time, the tunnel interface is being marked with RO-
enabled so that Extended Type 2 RH[4] inserted into Tunnel
Extension Header[16] at processing packet tunneling encapsulation.
As a result of applying Type 2 RH based on NPI, all packets
destined to mobile networks are forwarded to TLMR on the nested
path through the RO-enabled forward tunnel.
For the packets forwarded via RO-enabled reverse tunnel by MR, HA
decapsulates them, and checks the validity of Type 6 RH. the
conditions are as follows:
(1) NextIndex MUST be zero.
Na, et al. Expires - March 2004 [Page 15]
Internet Draft Nested Path Information September 2003
(2) There is at least one entry registered by BU with NPI in
which TLMR address matches the source address of incoming
outer packet.
(3) CareOf address of the BC entry MUST match the last one's
address(e.g. MR3) which is the result of subtracting from
NPI address vector(e.g. MR1->MR2->MR3) to the addresses in
Type 6 RH(e.g. MR1->MR2) in order.
If above conditions are all satisfied, inner packets are forwarded
by MIPv6 specification. Otherwise, they are discarded by HA.
Na, et al. Expires - March 2004 [Page 16]
Internet Draft Nested Path Information September 2003
5. Further Route Optimization
5.1 MN-HA Tunnel Optimization in Mobile Networks
In Fig.1, VMN can do RO-enabled binding update with MR4_HA using
nested path MR1_CoA->MR4_CoA. VMN-VMN_HA tunnel can be optimized if
VMN follows faithfully extension of the operation like MR does in
section 4.4.
5.2 MN-CN Route Optimization in Mobile Networks
MIPv6 Route Optimization can be considered in nested mobile
networks. To apply our solution, the following extensions are
required to MN and CN.
(1) MN and CN MUST use the nested routing path option in
doing BU.
(2) RH Type 6 optional header MUST be applied to the packets
sent from MN to CN.
(3) Extended RH Type 2 optional header MUST be applied to
the packets sent from CN to MN.
We see the possibility and detailed protocol design of MN-CN route
optimization using NPI will be next our work item.
Na, et al. Expires - March 2004 [Page 17]
Internet Draft Nested Path Information September 2003
6. Security Considerations
Basically, MR-HA bi-directional tunneling is protected by
IPSEC[7][8][9]. However, we can suspect that the part of NPI maybe
untrustworthy by itself or can be modified by the intermediate AR
that be fake. In case of [4], the vulnerability for spoofing attack
by an attacker on the nested path has been known. Those kinds of
attack can be avoided in the proposed solution as the integrity of
NPI is guaranteed on the fly.
6.1 NPI Authenticity
We need to assure that NPI is an available path and intact. To get
the assurance, there MUST be any security mechanism to authenticate
AR on access link by MR each other. That would be implemented with
some types of Network Access Control(NAC) or domain-specific
authentication method. Due to out of scope of this document, the
details for those mechanisms will not be described in here, but our
solution needs to assume pre-established security association
between visited AR and visiting MR for NPI authenticity.
6.2 How to avoid the spoofing attack
The integrity of information chunks of RH Type 6/2 used in our
solution can be guaranteed by using AH[8]. It means that the
intermediate forwarders on the nested path for RH Type 6/2 cannot
modify any part of NPI. Unlike RRH, NPI is immutable except for
NextIndex so that it can be protected by AH. Any attacker that
doesn't know secret key used in MR-HA tunnel cannot forge NPI
protected by AH for its own benefit.
6.3 The existence of fake MR
There may be a fake MR acting as a forwarder on NPI path.
Inadvertently or not, it's possible because of the lack of network
access security mentioned in section 6.1. Although in this case,
NPI in RH Type 6/2 cannot be modified because of AH protection. And,
Any contents through MR-HA tunnel cannot be disclosed because it
can be protected by ESP[9]. Merely, the possible attack is a
passive denial-of-service that means the denial of routing service.
However, as these types of attacks can be easily detected, it
cannot be an effective attack in itself.
Na, et al. Expires - March 2004 [Page 18]
Internet Draft Nested Path Information September 2003
References
[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July
2002.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-00 (work in progress), May 2003.
[3] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A.
Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix
Scope Binding Updates)", draft-ernst-mobileip-v6-network-03
(work in progress), March 2002.
[4] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header
and Its Application to Mobile Networks", Internet Draft:
draft-thubert-nemo-reverse-routing-header-01
(work in progress), Oct 2002.
[5] Chan-Wah Ng, and Takeshi Tanaka, "Securing Nested Tunnels
Optimization with Access Router Option", Internet Draft:draft
-ng-nemo-access-router-option-00(work in progress), Oct 2002.
[7] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[8] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[10] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December 1998.
[11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[14] Thubert, P., and Molteni, M., "Taxonomy of Route Optimization
Models in the NEMO Context", Internet Draft: draft-thubert-
nemo-ro-taxonomy-00(work in progress), Oct 2002.
Na, et al. Expires - March 2004 [Page 19]
Internet Draft Nested Path Information September 2003
[15] vijay, D., Ryuji, W., Alexandru, P., Pascal, T., "NEMO Basic
Support Protocol", draft-ietf-nemo-basic-support-00(work in
process), June 2003.
[16] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6
Specificiation", RFC2473, December 1998.
Acknowledgments
Authors would like to thank you the authors of [4] and [5] for a
fruitful comments on this problem area.
Authors' Addresses
Jongkeun Na
Information Networking & Computing Lab.
School of Computer Science and Engineering,
Seoul National University, Seoul Korea
EMail: jkna@popeye.snu.ac.kr
Sungho Cho
Information Networking & Computing Lab.
School of Computer Science and Engineering,
Seoul National University, Seoul Korea
EMail: shcho@popeye.snu.ac.kr
Chongkwon Kim
Information Networking & Computing Lab.
School of Computer Science and Engineering,
Seoul National University, Seoul Korea
EMail: ckim@popeye.snu.ac.kr
Sungjin Lee
Telecommunication R&D Center,
Samsung Electronics
Dong Suwon P.O. BOX 105
416, Maetan-3Dong, Paldal-Gu
Suwon-City, Gyunggi-Do, 442-600
KOREA
EMail : steve.lee@samsung.com
Na, et al. Expires - March 2004 [Page 20]
Internet Draft Nested Path Information September 2003
Hyungjeong Kang
Telecommunication R&D Center,
Samsung Electronics
Dong Suwon P.O. BOX 105
416, Maetan-3Dong, Paldal-Gu
Suwon-City, Gyunggi-Do, 442-600
KOREA
EMail : hyunjeong.kang@samsung.com
Changhoi Koo
Telecommunication R&D Center,
Samsung Electronics
Dong Suwon P.O. BOX 105
416, Maetan-3Dong, Paldal-Gu
Suwon-City, Gyunggi-Do, 442-600
KOREA
EMail : chkoo@samsung.com
Na, et al. Expires - March 2004 [Page 21]