One document matched: draft-zhao-nemo-rrh-security-00.txt
NEMO Working Group Fan Zhao
Internet Draft S. Felix Wu
Expires: January 12, 2005 UC Davis
Souhwan Jung
Soongsil Univ.
HyunGon Kim
ETRI
July 12, 2004
Secure Reverse Routing Header Solution in NEMO
draft-zhao-nemo-rrh-security-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 January 12, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract: In this draft, we begin with an extensive security analysis
on a NEMO RO proposal, RRH, and then propose an effective security
mechanism to resist those new threats introduced by the RRH header in
the nested mobile network.
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.
Zhao et. al. Expires January 2005 [page 1]
Internet Draft Secure Reverse Routing Header July 2004
1. Introduction
This document assumes the reader is familiar with the Reverse Routing
Header protocol defined in [9] and other NEMO related documents [1-6].
Route optimization problem in NEMO has attached a lot of interests from
the researchers. Please refer to a few of related Route Optimization
drafts and taxonomy of Route Optimization models described in [8]. The
RRH proposal tries to solve this problem by embedding the routing
information in the data plane rather than building the routing state in
the control plane. By doing so, mobile nodes can manage to response
more quickly to the topology changes than other proposals. However, the
carrier of such important routing information, RRH header, is not
protected by the end-to-end security, which is also stated in the
original draft [9]. This document analyzes in depth the security of RRH
proposal. The results show that with unprotected RRH header the
adversary can more easily launch the attack than in the NEMO basic
support protocol. And we also propose the security solutions to resist
such attacks.
2. Assumptions
2.1 MN/MR has pre-established security association with the HA if they
belong to the same domain.
2.2 LFN/MN could have the pre-established security association with its
CN.
2.3 Generally no pre-established security association exists between
MN/MR and HA belonging to the different domains.
2.4 No assumption is made about the pattern of topology changes in NEMO
nested mobile network, in other words, the user or device mobility
model.
2.5 There exist only a relatively small number of malicious MRs in the
NEMO mobile network, if any.
3. An Example Scenario and Terminology
3.1 An example scenario
We make several minor changes on the following figure borrowed from the
RRH draft [9] as an example topology.
+---------------------+
| Internet |---CN
+---------------|-----+
/ Access Router
MR3_HA |
======?======
MR1
|
====?=============?===========
MR5 MR2
| |
=========== ===?==================?======
MR3 MR7
| |
Mobile Network3 --> ==|========?===== =====|=====
LFN1 MR4 LFN2
|
=========
An example nested Mobile Network
Zhao et. al. Expires January 2005 [page 2]
Internet Draft Secure Reverse Routing Header July 2004
This example also focuses on a Mobile Network node at depth 3 (Mobile
Network3) inside the tree, represented by its mobile router MR3.
3.2 Terminology
- Inbound packet
The packets coming into the nested mobile network.
- Outbound packet
The packets going out of the nested mobile network.
4. Security Analysis
Based on the location of adversaries, the scope of security analysis is
divided into two: in the Internet and inside the NEMO nested mobile
network.
4.1 Security Analysis on the Routing Path in the Internet
Generally there are more security risks in the Internet than inside the
NEMO nested mobile network because the packets between MN and CN will
traverse multiple domains (AS) belonging to the different ISPs, and
even different countries.
The adversary on the path can eavesdrop, drop, modify, delay and replay
any packet passing by. However due to the limitation of space, these
generic threats will not be elaborated.
The integrity and confidentiality of (at least) part of the RRH header
is not protected, so the adversary has no difficulty gathering and
analyzing the topology information of nested mobile network to make
preparation for the next stage attack.
4.1.1 Leakage of topology information
We use MR3 as an example in the following description.
Any adversary on the path between root-MR and HA3 can learn the binding
of HoA and CoA of MR3 because both BU packet of MR3 and data packets
(MR3 is the first MR to forward those data packets.) contain both HoA
and CoA of MR3 in the RRH header in the clear text.
Compared with NEMO basic support, if IPSec ESP is used between MR and
HA, the adversary needs to be on the path between HA2 and HA3 in order
to know the binding between HoA and CoA of MR3.
In order to know the bindings of all the MRs, the adversary just needs
to be around the root-HA while in NEMO basic support with ESP, the
adversary has to be able to eavesdrop around all the HAs.
Any adversary on the path between root-MR and HA3 can also easily know
the path from root-MR to MR3 while in NEMO basic support with ESP, the
adversary has to be able to eavesdrop around both HA1 and HA2.
Zhao et. al. Expires January 2005 [page 3]
Internet Draft Secure Reverse Routing Header July 2004
So RRH is more easily to leak the topology information than NEMO basic
support. And in RRH the outside attacker can cooperate with the inside
attacker to know the topology information more easily.
4.1.2 DoS attack
Since the content of RRH header is not covered by any end-to-end
security protection, the adversary could modify the RRH in order to
consume the bandwidth inside the NEMO nested mobile network or
resources of MRs. (The length of RRH header could be protected
indirectly if the packet length field in IP header is protected by AH.
However, it requires that the MR knows the exact number of slots before
sending, which may not be easily achieved when the topology is changed
quickly. Even worse the adversary can still modify the RRH content.)
This DoS attack can achieve the same damage as the flooding attack by a
lower sending rate and a lower possibility to be detected.
4.1.2.1 extend the RRH header
By inserting more IP addresses into the RRH header, the attacker forces
the packets to take a much longer path inside the nested mobile network.
Thus the mobile routers, which are usually resource-limited, are forced
to spend more resource to forward those packets and the bandwidth of
link, which is usually wireless link, is easily exhausted.
4.1.2.2 form a loop in the RRH header
The adversary can form a loop in the RRH header. Since the ingress
filtering only checks whether the source IP address is topology correct,
it does not detect or prevent the formation of loop. Since Multi-homing
will be adopted widely, the loop will be more easily formed because of
the rich connectivity. Given that the maximum number of slots is ten,
the number of loops can be up to nine.
4.1.2.3 Comparison with the NEMO basic support
It is not easy to forge the IP header with the ESP tunnel mode. Thus
the DoS threat is more serious in RRH.
4.2 Security Analysis on the routing path inside the NEMO nested mobile
network
This looks like an insider attack. Any MR including the root MR can
eavesdrop, drop, modify, delay and replay any packet in the path. In
the following analysis, we assume that MR3 is a malicious MR.
4.2.1 Leakage of topology information
MR3 can learn the topology information about the subtree rooted at
itself, the path from the root MR to itself directly from the RRH
header and the topology information from MR7 by eavesdropping since MR3
and MR7 share the LAN. Compared with in NEMO basic support, ESP can
prevent the topology information of such subtree, the path to root-MR
and the topology information from MR7 from being revealed.
The inside malicious MR can cooperate with the outside adversary. By
modifying the RRH header, the insider malicious MR forces the
interesting packet to pass by the outside adversary in order to
facilitate the cryptanalysis or make the topology information revealed
easily.
Zhao et. al. Expires January 2005 [page 4]
Internet Draft Secure Reverse Routing Header July 2004
4.2.2 DoS attack
Based on the topology information it knows, the malicious MR can
consume the bandwidth and resource of other MR (upstream, downstream
and neighbor MR) by extending or forming a loop in the RRH header.
However in the NEMO basic support, the adversary can only attack the
MRs in the subtree if ESP or IP-in-IP is used.
The malicious MR3 can eavesdrop the RRH header in the outbound packet
from MR7 and modify the RRH in order for the reply packet to attack
either the upstream router or the downstream router. As it spoofs the
topology-correct IP address of MR7, the ingress filtering of MR2 does
not detect it. Also there is security check on the destination IP
address in the reply (inbound) packet.
If there are two malicious MR, MRi and MRj, they can collaborate to
attack the MRs between MRi and MRj.
4.3 Other threats
MR3 can intentionally fill up all the slots in the RRH header from MR4.
Since the number of slots is limited, MR3 forces the upstream MR to
forward the packet by the reverse tunnel between MR and HA. This attack
belongs to the denial-of-service attack and greatly increases the round
trip delay and other QoS performance.
MR3 may also launch the redirection attack which is similar with in the
NEMO basic support.
4.4 Summary
Lack of similar ESP protection over IP addresses in the RRH header
makes RRH more vulnerable than NEMO basic support. Some threats
described above are inherently similar with those in the source routing.
5. Security Mechanism
5.1 Hop-by-hop authentication and encryption
Each MRi except the first MR generates and uses a secret key, Ki, to
authenticate and encrypt the RRH header it receives. In the following
context, E(Ki, *) represents the encryption operation, A(Ki, *)
represents the authentication operation, the content of slot i is
denoted by si and "||" represents the concatenation. Note that as the
first MR in the path, MR3 does not need to do the following encryption
and authentication because HA3 needs MR3_HoA in the clear text and
MR3_HoA can be already included in the end-to-end authentication. The
order of operation is authentication after encryption.
The packet is sent from the first MR, MR3 as follows.
Zhao et. al. Expires January 2005 [page 5]
Internet Draft Secure Reverse Routing Header July 2004
<-------------- outer IPv6 header -------------------->
+-------+-------++ -- ++----+-------+-------+---------+ +-------
|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |
|MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HoA | |iPACKET
| | |: :| 4 | | | | |
+-------+-------++ -- ++----+-------+-------+---------+ +-------
MR2 sent the packet as follows.
<-------------- outer IPv6 header --------------------->
+-------+-------++ -- ++----+-------+--------+---------+ +-------
|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |
|MR2_CoA|MR3_HA |:oEXT:|type| |MR3_CoA |MR3_HoA | |iPACKET
| | |: :| 4 | | | | |
+-------+-------++ -- ++----+-------+--------+---------+ +-------
| E(K2,s1) |
|<- A(K2, s1||s0)->|
MR1 sent the packet as follows.
<-------------- outer IPv6 header ---------------------->
+-------+-------++ -- ++----+--------+--------+---------+ +-------
|oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | |
|MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA |MR3_CoA |MR3_HoA | |iPACKET
| | |: :| 4 |E(K1,s2)|E(K2,s1)| | |
+-------+-------++ -- ++----+--------+--------+---------+ +-------
|E(K1,s2)|E(K2,s1)|
|<- A(K2, s1||s0)->|
|<- A(K1, s2||s1||s0) ->|
Since HA3 only copies and pastes the RRH header without any processing,
HA3 does not need to understand the content of RRH header by sharing
this secret key with any MR.
The reply packet should equip with the same RRH header. MR1 will verify
the MAC value of RRH header. If successful, MR1 decrypts the RRH header
and forward to the next MR; otherwise it drops the packet silently.
Other MRs will verify and decrypt the RRH header recursively until it
reaches the final destination.
We can use any encryption algorithm and the cipher text can be just put
in the slot to replace the IP address. A specific field is needed to
store the MAC value. Nowadays for a keyed hash function to be secure,
the output should be at least 80 bits. The detailed format will be
designed later.
Compared with IPSec ESP tunnel mode in NEMO basic support, it greatly
reduces the computation overhead since the time to generate the cipher
text and MAC is proportional to the length of input, just a few bytes
in the RRH header here rather than the whole packet in ESP tunnel mode.
Zhao et. al. Expires January 2005 [page 6]
Internet Draft Secure Reverse Routing Header July 2004
We may also want to prevent the replay attack by using the timestamp or
sequence number. The detailed format will be designed later.
MR3 achieves more anonymity than in RRH since the adversary does not
know the path to MR3. It also prevents the adversary forging any slot
in the RRH header. Since the adversary does not know the private key,
the forged slot will be detected and the compromised packet will be
dropped.
This scheme still needs a lot of cryptography operations and a lot of
space to store the MAC. (In the RRH draft, the maximum number of slots
allowed is 10.) In the following we propose a lightweight solution in
an end-to-end fashion.
5.2 Security mechanism to address the threats in the Internet
To address the threats in the Internet, we aggregate the authentication
and encryption done by the intermediate MRs. So only the root MR needs
to do these operations. This assumes the root-MR is trustable because
we focus on the threats in the Internet which happen more likely than
inside the nested mobile network. Compared with the cost and protection,
we believe that this is a feasible solution.
5.2.1 RRH Authentication to provide the integrity protection
The root MR will generate a secret key, K and use the keyed hash
function, for example, HMacMD5 or HmacSha1, to generate the MAC code of
the RRH header in the outbound packet and verify the MAC code in the
inbound packet. Note that the root MR does not share this key with any
other entity. Besides the IP addresses inside the RRH header, the root
MR may also use the timestamp or sequence number to prevent the replay
attack.
5.2.2 RRH Encryption to provide the confidentiality
The root MR uses a secret key, K, to encrypt the RRH except the bottom
slot in the outbound packet and decrypt the RRH in the inbound packet.
Note that encryption alone is not secure, so the authentication is
usually needed to protect the integrity.
5.3 Security enhancement to address the inside threats
The ingress filtering is not enough to prevent the inside attack. We
propose to check not only the source IP address but also the
destination IP address. This check is done by each MR based on the
local topology information, such as IP addresses of the adjacent
upstream MR and adjacent downstream MR. Some kind of loop can be
detected.
5.4 Routability probe to address both inside and outside threats
Since MR does not have the path information before sending the packets,
MR cannot include the RRH in the end-to-end security. We assume that
there is no topology change within one round trip delay and introduce
the "Routability probe" to collect the RRH before sending the packet.
Zhao et. al. Expires January 2005 [page 7]
Internet Draft Secure Reverse Routing Header July 2004
5.4.1 Routability probe
In this test, MR probes the path between itself and root-MR.
MR sends a specific probe packet to collect the IP address of MRs in
the path to TLMR. The intermediate MR fills the RRH header in this
probe packet just as in the RRH draft and will also check the RRH
header based on its local topology information (It is reasonable to
assume that MR knows the adjacent upstream and downstream MR
information. If MR does not know at all, it may just let it pass. ) as
in 5.3. If the RRH header fails in this check, it will be dropped.
When root-MR receives the probed packet, it will generate the MAC on
the RRH header using its public key, and return the probe packet and
MAC to the MR. The intermediate MR will verify the MAC. If the
verification is successful, the intermediate MR will do the local check.
Note that the malicious router cannot modify the RRH header after root-
HA signs it. Thus the RRH header becomes evidence if the malicious MR
forges the RRH header. If it is detected, although the intermediate MR
cannot tell exactly who is the malicious MR, it can launch an alert or
invoke a stronger security protection to resist the attack or drop it
to avoid the damage.
5.4.2 The rest of procedure
If no attack is detected, the probe packet will arrive at the sending
MR. After successfully verifying the MAC generated by the root-MR, MR
includes the RRH header into the end-to-end SA with its HA.
The CN verifies the received packet based on the end-to-end SA. If
successful, it will generate the reply packet based using the same SA
with MR. The RRH header and the MAC generated by root-MR are also
included.
Root-MR verifies the received RRH header before forwarding to the
destination. The intermediate MR will verify the MAC. If the
verification is successful, the intermediate MR will do the local check.
5.4.3 Summary
This proposal only uses one cryptography operations by root-MR. We use
the public key of root-HA just because there is no pre-shared key
between root-HA and other MRs. Routability probe before sending the
packet makes the intermediate MRs have opportunities to detect the
attack as early as possible. If the first MR can receive the probe
packet within one round trip delay, it means that there is no loop or
this routing path taken by the probe packet really works. Note that the
first MR does not have to probe every time before sending the packet.
It may just do it when some problem happens. It is efficient but at the
cost of one round trip delay.
Zhao et. al. Expires January 2005 [page 8]
Internet Draft Secure Reverse Routing Header July 2004
6. Security considerations
This document comes with up some new threats that are more dangerous
than in the NEMO basic support protocol. We contemplate the cause of
such risks and propose the countermeasure to effectively resist the
attacks. We hope this document will help understand the problem and
result in a secure and efficient route optimization solution.
References:
[1] T. Ernst, "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-02, Work in Progress, February
2004.
[2] T. Ernst, and H-Y. Lach, "Network Mobility Support
Terminology", draft-ietf-nemo-terminology-01, Work in
Progress, February 2004.
[3] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubertet,
"Network Mobility (NEMO) Basic Support Protocol", IETF
proposed standard, draft-ietf-nemo-basic-support-03, June
2004.
[4] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2003.
[5] C. Ng, J. Charbon, E. Paik, and T. Ernst, "Analysis of
Multihoming in Network Mobility Support", draft-ng-nemo-
multihoming-issues-03.txt, Work In Progress, February 2004.
[6] J. Arkko, V. Devarapalli, and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents," RFC 3776, June 2004.
[7] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[8] P. Thubert, M. Molteni, C. Ng, H. Ohnishi, and E. Paik,
"Taxonomy of Route Optimization models in the Nemo Context",
draft-thubert-nemo-ro-taxonomy-02, Work in Progress, February
2004.
[9] P. Thubert, and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks", draft-thubert-nemo-
reverse-routing-header-05, Work in Progress, June 2004.
[10] T. Tanaka, and C. Ng, "Securing Nested Tunnels Optimization
with Access Router Option", draft-ng-nemo-access-router-
option-00, Work in Progress, November 2002.
Zhao et. al. Expires January 2005 [page 9]
Internet Draft Secure Reverse Routing Header July 2004
Authors' Addresses
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
Zhao et. al. Expires January 2005 [page 10]
Internet Draft Secure Reverse Routing Header 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.
Zhao et. al. Expires January 2005 [page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 04:24:27 |