[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
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]