Subject: [nemo] draft-jung-nemo-threat-analysis-02

From: "S. Felix Wu" <[email-masked]>
Date: Sun, 29 Feb 2004 03:45:21 -0800

Hi,

Souhwan sent me this draft on Feb, 13, and asked me to submit.
I appologize that I forgot to send it, so it didn't appear in
submitted draft.

This draft currently described mainly the attacks we presented
in the previous IETF. (The draft we posted last time, version
01, didn't really reflect our presentation.)

Attached is the draft. Any comments will be highly appreciated.
Appologize again for the delay.

-Felix

-- 
----------------------------------------------------------------------
Dr. S. (Shyhtsun) Felix Wu                           [email-masked]
Associate Professor                      http://www.cs.ucdavis.edu/~wu
Computer Science Department                     office: 1-530-754-7070
University of California at Davis               fax:    1-530-752-4767
----------------------------------------------------------------------
NEMO Working Group                                         Souhwan Jung
Internet-Draft                                      Soongsil University
Expires: August, 2004                                          Fan Zhao
							    S. Felix Wu
							       UC Davis
							    HyunGon Kim
							   SungWon Sohn
								   ETRI
							 February, 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. Threats related to 
   the operations of nested MR, and multi-homing (multiple MRs) are 
   also investigated. Finally,security requirements for NEMO basic 
   protocols and specific implementation notes are described.

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. 

S. Jung et. al.            Expires August, 2004                 [Page 1]

Internet-Draft  Threat Analysis on NEMO basic operations   February 2004

Table of Contents

   1.    Motivations  

   2.    Threats to MR-HA tunneling
         2.1 Threats to the MR-HA IPsec Transport SA
         2.2 Threats to IP-in-IP tunnel between MR and HA
   3.    Threats to error processing operations
         3.1 DoS attack due to error processing of BU
   4.    Threats to interactions between MRs
   
         Changes from previous version
	  
         References

         Authors' Addresses

         Intellectual Property and Copyright Statements

S. Jung et. al.            Expires August, 2004                [Page 2]

Internet-Draft  Threat Analysis on NEMO basic operations  February 2004

1. Motivations

Networks in motion (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 MobileIP/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 must be protected very well. 
Otherwise, many malicious attacks such as traffic hijacking or denial 
of service are possible by intentionally injecting incorrect BU messages. 
Under both MobileIP 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 (NEtworks in Motion), and discussed its potential security problems, 
especially, related to IPsec and other tunneling functions. 
Through our experiments (as well as our discussions with IPsec 
implementers from major router venders), we validated that the problems 
we raised here are practically possible. 

S. Jung et. al.            Expires August, 2004                [Page 3]

Internet-Draft  Threat Analysis on NEMO basic operations  February 2004

2 Potential threats to network in motion

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.

2.1 Threats to the MR-HA IPsec Transport SA

Three different potential attack scenarios are presented in this section.

2.1.1	BU spoofing: no ingress filtering at MR

The first case assumes that there is no ingress filtering activated at MR. 
Figure 1 shows the attack scenario.

    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

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 August, 2004                [Page 4]

Internet-Draft  Threat Analysis on NEMO basic operations  February 2004

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.

2.1.2	BU spoofing: 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.

    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

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 
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.

S. Jung et. al.            Expires August, 2004                [Page 5]

Internet-Draft  Threat Analysis on NEMO basic operations  February 2004

2.2 Threats to IP-in-IP tunnel between MR and HA

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.

2.2.1	Attack from inside

Figure 3 shows an attack scenario from inside nodes. 

 |--------|           |--------|   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

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 
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.

S. Jung et. al.            Expires August, 2004                [Page 6]

Internet-Draft  Threat Analysis on NEMO basic operations  February 2004

2.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.

 |--------|   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

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 
forwarding the packets from MNN or CN.        

S. Jung et. al.            Expires August, 2004                [Page 7]

Internet-Draft  Threat Analysis on NEMO basic operations  February 2004

3. Threats to error processing operations

3.1 DoS attack due to error processing of BU

Section 5.4 of basic support draft[3], Error Processing of Binding Update, 
says that if the status is set to '142', the Mobile Router should send a 
similar Binding Update to another Home Agent on the same home link.  
If no Home Agent replies positively then Mobile Router SHOULD refrain 
from sending this Binding Updates to any Home Agent on the home link.  
Additionally, the Home Agent MUST stop advertising the respective 
prefix(es) in the mobile network with associated Router Advertisements, 
and modify its own forwarding information accordingly.  
Following this, the Mobile Router MAY send Binding Updates in another 
mode (e.g. implicit) to a Home Agent on the same home link.?

If a malicious MR sends a BU on the explicit mode to its HA claiming 
a MNP belonging to another MR, the HA will notice the MNP is not valid, 
and send a BA with 142 code will be generated. According to the 
statement above, HA stops advertising this MNP, which will be a DoS 
attack to the MR that is already using the MNP. If the malicious MR 
keep sending other invalid MNPs to the HA, then those MNPs will be 
blocked for service.

4. Threats to interactions between 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.

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[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.

S. Jung et. al.            Expires August, 2004                [Page 8]

Internet-Draft  Threat Analysis on NEMO basic operations  February 2004           

References

   [1]   Ernst, T., et al, "Network Mobility Support Goals and
         Requirements", 
         Internet Draft: draft-ietf-nemo-requirements-01.txt, 
         Work In Progress, May  2003.

   [2]   Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         Internet Draft: draft-ietf-nemo-terminology-00.txt, Work In
         Progress, May 2003.

   [3]   Devarapalli V., et al, "NEMO Basic Support Protocol", Internet
         Draft: draft-wakikawa-nemo-basic-02.txt, Work In Progress,
         December 2003.

   [4]   Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support 
         in IPv6", 
         Internet Draft: draft-ietf-mobileip-ipv6-24.txt, 
         Work In Progress, June 2003.

   [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.
       
   [6]   Ng, C. W. and Tanaka, T., "Multihoming Issues in Network Mobility 
         Support", Internet Draft:
         draft-ng-nemo-multihoming-issues-02.txt, Work In Progress,
         October 2003.

   [7]   Arkko, J. et. al. ,"Using IPsec to Protect Mobile IPv6 Signaling
         between Mobile Nodes and Home Agents,"
         Internet Draft: draft-ietf-mobileip-mipv6-ha-ipsec-06.txt, 
         Work In Progress, June 2003.
       
   [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.

Changes from the previous version

1. Removed the threat model and generic threat stuff.
2. Described threats specific to basic support protocol.
3. Described details of specific threats to MR-HA tunneling.
4. Added thretas due to error processing. 
5. Added threats to multihoming

S. Jung et. al.            Expires August, 2004               [Page 9]

Internet-Draft  Threat Analysis on NEMO basic operations  February 2004

Authors' Addresses

   Souhwan Jung
   Soongsil University
   1-1, Sangdo-dong, Dongjak-ku
   Seoul 156-743
   KOREA
   
   Phone: +82-2-820-0714
   EMail: [email-masked]

   Fan Zhao
   Department of Computer Science
   University of California, Davis
   One Shield Avenue
   Davis, CA 95616
   USA

   Phone: +1-530-752-3128
   EMail: [email-masked]

   Felix Wu
   Department of Computer Science
   University of California, Davis
   One Shield Avenue
   Davis, CA 95616
   USA

   Phone: +1-530-754-7070
   EMail: [email-masked]

   HyunGon Kim
   Network Security Department
   ETRI
   161 Kajong-Dong, Yusong-Gu
   Taejon 305-600
   KOREA
   
   Phone: +82-42-860-5428
   Email: [email-masked]   

   SungWon Sohn
   Network Security Department
   ETRI
   161 Kajong-Dong, Yusong-Gu
   Taejon 305-600
   KOREA

   Phone: +82-42-860-5072
   Email: [email-masked]

S. Jung et. al.            Expires August, 2004               [Page 10]

Internet-Draft  Threat Analysis on NEMO basic operations  February 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.

S. Jung et. al.            Expires August, 2004               [Page 11]

Internet-Draft  Threat Analysis on NEMO basic operations  February 2004