NEMO Working Group Souhwan Jung
Internet-Draft Soongsil University
Expires: January 19, 2005 Fan Zhao
S. Felix Wu
UC Davis
HyunGon Kim
SungWon Sohn
ETRI
July 19, 2004
Threat Analysis on NEMO Basic Operations
draft-jung-nemo-threat-analysis-02
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 August, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes potential security threats to NEMO basic
operations. The threats are mostly related to the integral use of
IPsec and IP-in-IP tunnel between MR and HA. Other threats related
to the operations of multiple MRs, and potential DoS attacks on MR
and HA are also investigated.
S. Jung et. al. Expires January, 2005 [Page 1]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction
2. Assumptions
3. Threats to interactions between MR and HA
3.1 Attacks to the MR-HA IPsec Transport SA
3.1.1 BU spoofing attack without ingress filtering at MR
3.1.2 BU spoofing attack with ingress filtering at MR
3.2 Attacks to MR-HA tunnel
3.2.1 Attack from inside
3.2.2 Attack from outside
3.3 Attacks to the signaling messages
4. Threats to interaction among MRs
4.1 Attacks to multihomed MRs
5. DoS attacks to MR or HA
Changes from previous version
References
Authors' Addresses
Intellectual Property and Copyright Statements
1. Introduction
NEwork MObility (NEMO) introduces a network entity called Mobile
Router(MR)[2]. MR has different features from mobile host that operates
based on Mobile IP technologies[4]. Since MR functions both as a mobile
node and a gateway to provide mobile network with Internet access to
outside world, it needs specific treatment for managing operations and
securities.
The MIP/NEMO community has spent quite a lot of efforts in designing
security mechanisms to protect critical control messages exchanged among
protocol entities such as HA (Home Agent), MN (Mobile Node), or MR
(Mobile Router in NEMO). In particular, the authenticity and integrity
of the Binding Update (BU) messages SHOULD be protected very well.
S. Jung et. al. Expires January, 2005 [Page 2]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
Otherwise, many malicious attacks such as traffic hijacking or denial
of service are possible by intentionally injecting incorrect BU messages.
Under both MIP6 and NEMO, IPsec Transport ESP (Encapsulating Security
Payload) [8] is used to protect the binding update messages between HA
and MN/MR.
IPsec itself provides a network layer security service between two
network entities, and it nicely integrates a number of strong
cryptographic components under its architecture. Due to this strong fact
of IPsec security, many Internet protocols, especially in the
network layer, have been built on top of the security strength of IPsec.
The list is currently growing, but at least, we can include OSPFv6,
TRIP (Telephony Routing over IP, under the IP Telephony working group),
RSVP/NSIS (Next Step in Signaling), L3VPN, PANA (Protocol for Authentication
and Network Access), MobileIP and NEMO.
While IPsec itself is indeed quite secure, the security of the protocols
using IPsec might still be very questionable. In fact, through our security
analysis toward NEMO, we realize that the IPsec architecture itself does
NOT specify/mandate its relationship with other functional components
(such as packet forwarding, ingress filtering, IP-in-IP tunnel, or
application interface) in the same router.
Therefore, as will be shown later, most of the IPsec implementers have not
considered how to properly glue the IPsec engine with the rest of the
system such that the whole system (such as the MR in NEMO) can be easily
broken in. In short, IPsec by itself is indeed doing its job securely,
but the component putting packets into the IPsec module might not.
This draft describes vulnerabilities to the basic operations of
NEMO, and discussed its potential security problems, especially, related
to IPsec and other tunneling functions.
2. Assumptions
Many different types of threats to NEMO were described by [11] and [12].
But most of the threats can be easily protected by using existing IPsec
AH/ESP through the bi-directional tunnel between MR and HA. Some of
threats are not specific to NEMO basic operations, but generic to
Mobile IP or host security.
The generic threats to NEMO basic operations can be classified into
three different categories: threats on the tunnel between MR and HA,
threats on the path among multiple MRs, and threats to the MR and HA
themselves.
S. Jung et. al. Expires January, 2005 [Page 3]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
Since many serious attacks are possible with a compromised MR/HA, we
get rid of the threats derived from a compromised MR/HA. Therefore, we
assume the following conditions for further discussion of generic threats
to basic NEMO operations.
2.1 The IPsec AH/ESP security mechanisms are activated on MR-HA tunnels.
2.2 No compromise of the prefix and binding cache tables in HA.
2.3 No compromise of critical information like MNP and HoA on MR.
2.4 Multiple HAs have their own trust relationships provided by ISP.
2.5 No current security mechanisms are applied among multiple MRs.
3. Threats to interactions between MR and HA
The major threats to the basic operations of mobile network are from
the tunneling operations. Tunneled packet can disguise itself using
fake source and destination addresses. The MR or HA should be responsible
to verify the validity of those packets. Since the basic operation of
mobile network is based on the IPsec tunnel and IP-in-IP tunnel between
MR and HA, the threats to those tunneling operations will be investigated
in this section.
3.1 Attacks to the MR-HA IPsec Transport SA
Two different potential attack scenarios are presented in this section.
3.1.1 BU spoofing attack: no ingress filtering at MR
The first case assumes that there is no ingress filtering activated at MR.
Figure 1 shows the attack scenario.
In the Figure 1, a malicious MNN generates a spoofed packet by setting
source address to the HoA of the MR and destination address to the address
of HA, and also includes the BU of MR as a payload. The format and contents
of the BU message look exactly like a BU from the MR. When the MR received
the packet from the attacker, it first saves the packet to the buffer,
and checks the security policy database (SPD) of the packet. Since the MR
cannot tell the fake packet from the packet from itself at this point, it
finds that the packet requires the IPsec processing, and forwards it to
the security interface for IPsec processing. Then the IPsec module
encapsulates the packet using the ESP transport mode and the associated SA.
When the HA received the packet, it verifies the packet by checking the
IPsec ESP SA that will be valid because it is encapsulated by a valid MR.
Finally, the HA is fooled to believe that the BU is from the MR, and
updates the binding cache of itself.
S. Jung et. al. Expires January, 2005 [Page 4]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
MNN MR HA
|--------| |----------------| |-----------|
| | | |-------|| ESP | |-------| |
|Attacker|---------->|-------| IPSec ||====================| | IPSec | |
| | | | ^ |-------|| Transport | |-------| |
|--------| | |-|--------------| | |-----------|
| At this point, MR | checks the packet
| cannot tell the fake | using ESP and
|-----------| BU from a BU from |-----------| updates Binding
|Src=HoA | itself, and applies |Src=CoA | Cache (corrupts
|Dst=HA | IPSec ESP. |Dst=HA | binding cache)
|... | |ESP |
|BU(MNP,CoA)| |... |
|-----------| |BU(MNP,CoA)|
Attacker |-----------|
generates Packet is
a fake BU encapsulated
with ESP
Figure 1. MNN spoofs the BU of the MR without ingress filtering
This attack is possible due to two reasons. The first one is that the
MR is not using ingress filtering to check the topological correctness
of the source address. If the MR checks the source address of the packet,
and finds that the source address is set to itself, then it will drop
the packet. Another reason is that the MR forgets where the packet came
from, once it gets the packets and saves to a buffer. If the MR can
distinct the packet stream generated by other nodes (Layer2) from those
by itself (Layer4), then the fake packet will not be processed by IPsec,
and will be forwarded to HA encapsulated in an IP-in-IP tunnel.
Then the attack will fail to modify the binding cache of the HA.
3.1.2 BU spoofing attack: with ingress filtering at MR
This attack scenario is similar to the first scenario, but assumes the
ingress filtering at the MR. Figure 2 shows the attack scenario.
In this scenario, the attacker generates a spoofed BU message using
IP-in-IP encapsulation as shown in the figure. Now, the outer source
address is set to the address MNN and the destination address is set
to the address of the MR. The inner source address is set to the HoA
of MR and the inner destination address is set to the address of HA.
This attack is possible due to the order of packet processing at the
MR as shown in the figure. If the MR performs the ingress filtering
at first, and then do the tunnel decapsulation, then the fake packet
can get through the ingress filtering of the MR. The rest of the story
S. Jung et. al. Expires January, 2005 [Page 5]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
is the same as the first scenario. If the MR do perform the ingress
filtering after the tunnel decapsulation, the fake packet can be dropped
at the MR in this scenario. Therefore, it is very important to implement
multiple functions of the MR in the right order. In real world,
the ingress filtering function of the routers are not activated in many
cases, and then those routers are exposed to this type of attacks.
MNN IP_in_IP MR HA
|--------| packet is |----------------------------| |-----------|
| | generated ||-------| |------| |-----|| ESP | |-------| |
|Attacker|---------->||Ingress|-|tunnel|---|IPSec||===============| | IPSec | |
| | | ||filter | |decap | ^ | || Transport | | | |
| | | ||-------| |------| | |-----|| | | |-------| |
|--------| | |-------------------|--------| | |-----------|
| | | checks the
|-------------| |-----------| |-----------| packet
|Outer Src=MNN| |Src=HoA | |Src=CoA | using ESP
|Outer Dst=MR | |Dst=HA | |Dst=HA | and updates
|Src=HoA | |... | |ESP | binding
|Dst=HA | |BU(MNP,CoA)| |... | cache
|... | |-----------| |BU(MNP,CoA)|
|BU(MNP,CoA) | At this point, MR cannot |-----------|
|-------------| tell the fake BU from a BU Packet is
Attacker generates from itself, and applies encapsulated
a fake BU using IPSec ESP. with ESP
IP-in-IP tunnel
Figure 2. MNN spoofs a BU of MR with ingress filtering
3.2 Attacks to MR-HA tunnel
Processing IP-in-IP packets in a mobile router requires encapsulation
and decapsulation module with a dedicated protocol number.
Securing IP-in-IP tunneled packets requires a specific security mechanism
like IPsec tunnel mode encapsulation. The attacks to the IP-in-IP tunnel
can initiate from inside of the mobile network to MR or from outside
directly to HA. We will investigate two attack scenarios using MR and HA
as stepping stones.
3.2.1 Attack from inside
Figure 3 shows an attack scenario from inside nodes.
In the scenario, an attacker generates a fake IP-in-IP packet setting the
external source address to the address of another MNN inside the mobile
network and the external destination address to the address of MR.
Inside the encapsulation, the internal source address is set to a spoofed
IP address and the internal destination address is set to the address of
S. Jung et. al. Expires January, 2005 [Page 6]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
victim machine. Once the MR receives the packets, the MR decapsulates
the packets, and recognizes to process the packets using IP-in-IP
encapsulation and forward to the HA.
Therefore, the MR encapsulates the inside payload in IP-in-IP format
(external source address = CoA of MR, external destination address =
address of HA), and sends it to HA. HA forwards the packet to the victim
machine. The possible attacks from this scenario are IP spoofing or DoS
attack to the victim machine. Similar attacks have been known to mobile
network communities for a while, but the main point here is that MR can
prevent this attack by checking ingress filtering after the GRE decapsulation.
|--------| |--------| IP-in-IP |--------| |--------|
| | | | tunnel | | | |
| MNN |---------->| MR |==============| HA |-------->| Victim |
| | | | | | | | | | |
|--------| | |--------| | |--------| | |--------|
inside | | |
attacker | | |--------------|
|--------------| |--------------| |Src=spoofed IP|
|Ext. Src=MNN | |Ext. Src=CoA | |Dst=victim |
|Ext. Dst=MR | |Ext. Dst=HA | |payload |
|Src=spoofed IP| |Src=spoofed IP| |--------------|
|Dst=victim | |Dst=victim |
|payload | |payload |
|--------------| |--------------|
generates a spoofed
IP packet
Figure 3. Inside attack using MR and HA as stepping stone
3.2.2 Attack from outside
In this scenario, similar attacks can be initiated from outside of a mobile
network. Figure 4 shows the attack scenario.
In the Figure 4, an attacker from outside can generate a spoofed IP-in-IP
packet with setting the external source address to the CoA of MR and the
external destination address to the address of HA, which includes a spoofed
IP address as the internal source address, and the address of the victim
machine as the internal destination address. If the access router of the
outside attacker activates ingress filtering, this packet can be dropped at
the access router. But many routers without ingress filtering will pass
through this packet, and then HA may forward the packet to the victim machine.
Due to this security problem, most routers do not process the IP-in-IP packets,
but MR and HA in mobile networks should process IP-in-IP packets for
S. Jung et. al. Expires January, 2005 [Page 7]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
forwarding the packets from MNN or CN.
|--------| IP-in-IP |--------| |--------|
| | tunnel | | | |
| MR |==============| HA |--------------->| Victim |
| | | | | | |
|--------| |--------| | |--------|
^ |
| |---------------|
| |Src=spoofed IP |
|---------------| | |Dst=victim |
|Ext. Src=CoA | | |payload |
|Ext. Dst=HA | | |---------------|
|Src=spoofed IP |-------|
|Dst=victim | |
|payload | |---|outside
|---------------| | |attacker
generates a spoofed |---|
IP-in-IP packet
Figure 4. Outside attack using HA as a stepping stone
3.3 Modifications of the signaling messages
Some part of the signaling messages between MR and HA are delivered in
clear text. Therefore, this type of attacks are mostly related to the
modification of the signaling messages between MR and HA. For example,
the attacker on the path between MR and HA can modify the destination
of BU/BA messages to a wrong destination. The mis-destined messages shall
be dropped at the destination.
Another type of attacks are possible by modifying the flag option bit
(e.g. R bit) of the signaling messages. The modified signaling message
can be ignored or processed incorrectly at the destination.
4. Threats to interactions among multiple MRs
4.1 Attacks to multi-homed MRs
In case that two or more MR exists on a mobile subnet for multihoming,
there may be multiple bi-directional paths to forward packet to a HA or
multiple HAs respectively.
S. Jung et. al. Expires January, 2005 [Page 8]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
If one of the tunnel paths is broken for any reason, the MR(MR1) associated
with the faulty path loses Internet connection, and should find an
alternative bi-directional tunnel path through another MR2. In this case,
MR1 becomes a nested MR of MR2. NEMO basic draft[3] describes that MR SHOULD
not respond to the unsolicited RA messages to its egress interface,
but according to the MR operations by multihoming draft B.2.2 [6], the MR1 SHOULD
listen the RA from alternative MR2 on its ingress interface.
At this point, a malicious MR may advertise a RA with a fake CoA to MR1.
Then the MR1 will get a wrong CoA information.
This threat is not directly related to the NEMO basic operation, but to
the inter-MR operations. There is no explicit security mechanism for inter-MR
operations for multihoming cases, threats related to inter-MR operations
SHOULD be considered.
5. DoS attack to MR or HA
Attackers can initiate packet flooding attack to MR or HA using the
MR-HA tunnel. For example, outside attackers can generate a flood of
IP-in-IP packets using topologically correct external source address to
avoid ingress filtering at their access routers, and make them delivered
to the MR via the MR-HA tunnel. HA (or MR) have no way of filtering this
type of packet flooding.
This type of attack is also possible from inside of mobile networks, but
It is not supposed to be common to initiate flooding attack from inside
of the mobile network.
References
[1] Ernst, T., et al, "Network Mobility Support Goals and
Requirements",
Internet Draft: draft-ietf-nemo-requirements-02.txt (work in
progress), February 2004.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
Internet Draft: draft-ietf-nemo-terminology-01.txt (work in
Progress), February 2004.
[3] Devarapalli V., et al, "NEMO Basic Support Protocol", Internet
Draft: draft-ietf-nemo-basic-support-03.txt (work in progress),
June 2004.
[4] Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support
in IPv6", RFC 3775, June 2004.
[5] Petrescu, A., et al, "Issues in Designing Mobile IPv6 Network
Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet
Draft: draft-petrescu-nemo-mrha-03.txt (work in progress),
October 2003.
S. Jung et. al. Expires January, 2005 [Page 9]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
[6] Ng, C. W. and Tanaka, T., "Analysis of Multihoming in Network Mobility
Support", Internet Draft:
draft-ietf-nemo-multihoming-issues-00.txt (work in progress),
July 2004.
[7] Arkko, J. et. al. ,"Using IPsec to Protect Mobile IPv6 Signaling
between Mobile Nodes and Home Agents," RFC 3776, June 2004.
[8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[9] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[10] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[11] A. Petrescu, et. al.,ôThreats for Basic Network Mobility Support.ö
Internet Draft: draft-petrescu-nemo-thretas-01.txt (work in progress),
January 2004.
[12] S. Cho et. al, ôThreat for Multi-homed Mobile Networks,ö
Internet-Draft: draft-cho-nemo-threat-multihoming-00.txt
(work in progress), February 2004.
Changes from the previous version
1. Added assumptions
2. Deleted threats from binding errors
3. Added DoS attacks
Authors' Addresses
Souhwan Jung
Soongsil University
1-1, Sangdo-dong, Dongjak-ku
Seoul 156-743
KOREA
Phone: +82-2-820-0714
EMail: souhwanj@ssu.ac.kr
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
S. Jung et. al. Expires January, 2005 [Page 10]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
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
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
SungWon Sohn
Network Security Department
ETRI
161 Kajong-Dong, Yusong-Gu
Taejon 305-600
KOREA
Phone: +82-42-860-5072
Email: swsohn@etri.re.kr
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
S. Jung et. al. Expires January, 2005 [Page 11]
Internet-Draft Threat Analysis on NEMO basic operations July 2004
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. Jung et. al. Expires January, 2005 [Page 12]