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]