Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt
Alexandru Petrescu <alexandru.petrescu@motorola.com> Tue, 11 November 2003 20:53 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21380 for <nemo-archive@lists.ietf.org>; Tue, 11 Nov 2003 15:53:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfVV-0003ph-9k; Tue, 11 Nov 2003 15:53:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfUa-0003pD-Lk for nemo@optimus.ietf.org; Tue, 11 Nov 2003 15:52:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21227 for <nemo@ietf.org>; Tue, 11 Nov 2003 15:51:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfUZ-0001se-00 for nemo@ietf.org; Tue, 11 Nov 2003 15:52:03 -0500
Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1AJfUY-0001sa-00 for nemo@ietf.org; Tue, 11 Nov 2003 15:52:02 -0500
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hABKosfZ027236; Tue, 11 Nov 2003 13:50:55 -0700 (MST)
Received: from motorola.com ([163.14.20.4]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id hABKotkl030313; Tue, 11 Nov 2003 14:51:00 -0600
Message-ID: <3FB14BAC.5070005@motorola.com>
Date: Tue, 11 Nov 2003 21:50:52 +0100
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thierry Ernst <ernst@sfc.wide.ad.jp>
CC: vijayd@iprg.nokia.com, souhwanj@ssu.ac.kr, nemo@ietf.org
Subject: Re: [nemo] commens on draft-jung-nemo-threat-analysis-01.txt
References: <3FADC478.6080200@iprg.nokia.com> <12D4CC22.3000809@motorola.com> <20031111044052.5e3ab93a.ernst@sfc.wide.ad.jp>
In-Reply-To: <20031111044052.5e3ab93a.ernst@sfc.wide.ad.jp>
X-Enigmail-Version: 0.72.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: nemo-admin@ietf.org
Errors-To: nemo-admin@ietf.org
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Id: NEMO Working Group <nemo.ietf.org>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Thierry Ernst wrote: > However, while Vijay mentioned that some threats in > dtraft-jung-nemo-threat-analysis-01.txt are not specific to NEMO, I > still think it's useful to keep those in mind and the best way is a > written document. Right. > Alex, what you wrote below is very interesting. Why don't you write a > short I-D and get help from other people ? It's good to have a > starting document on the table. Here's a document you ask. I'm going to submit it formatted after the IETF meeting. So, I would like to ask help from other people to help with threat analysis. This document is really in its inceptive phase, I just tried to make it very specific to NEMO. Please remark on the presented threats, or suggest new ones. Or maybe you find the structure is not right, maybe one can change that too. Disclaimer to Souhwan: this is in no way competition, just my way of seeing the threats, thanks for understanding. Alex GBU Internet Draft A. Petrescu Document: draft-petrescu-nemo-threats-00.txt Motorola Expires: May 2004 November 2003 Threats for Basic Network Mobility Support (NEMO threats) <draft-petrescu-nemo-threats-00.txt> Status of this Nemo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes security threats related to the network mobility base protocol (NEMO). It does not present threats of Mobile IPv6. The communication between MR and HA, as well as the forwarding information at HA and nested mobility configurations are considered to be the main sensitive points of the protocol. Existing tools of Mobile IPv6 protection between MN and HA (IPsec), dynamic routing protocol authentication, NEMO prefix table and ingress filtering checks at HA are presented as potential help defending against threats. Table of Contents Status of this Memo................................................i Abstract...........................................................i Conventions Used in this Document..................................1 1. Introduction and Overview.......................................1 X. Interactions between MR and HA.................................. X. Interactions between several MR's of same HA.................... X. MR and HA in different administrative domains................... X. Forwarding Information Updates at HA............................ X. Nested Mobility................................................. X. Other Threats................................................... Acknowledgements................................................... References......................................................... Changes............................................................ Intellectual Property Rights Considerations........................ Authors' Addresses................................................. Copyright Notice................................................... 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 []. X. Introduction and Overview The Network Mobility base protocol [] describes means for a Mobile Router using Mobile IPv6 [] to offer continuous connectivity for a set of hosts and routers inside a moving network, to the Internet. A moving network has a relatively stable internal IP structure and will usually not transit traffic. A Mobile Router implements most functionalities of a Mobile IPv6 Mobile Host with the notable additions of the BU R-bit management and NEMO-specific modes (implicit, explicit network , explicit prefix len). A NEMO Home Agent implements most functionalities of a Mobile IPv6 HA with the notable additions of BU R-bit management, the three previously mentioned modes and, additionally, interactions with its forwarding information (routing table) management. A new mobility behaviour introduced by NEMO with respect to Mobile IPv6 mobility is the "nested" configuration, in which two moving networks served by different Mobile Routers (each with its own Home Agent) attach one under the other. A simpler case of nested mobility appears when one Mobile Host visits a moving network (MH and MR having different Home Agents). While Route Optimization is currently an integral part of the Mobile IPv6 specification for Mobile Hosts, it is not a part of the behaviour of a Mobile Router or of that of a NEMO Home Agent. Thus, this document describes security threats that pertain to: (1) interactions between MR and its HA, (2) interactions between several MR's served by same HA, (3) interactions between MR and HA when they belong to different administrative domain, (4) threats relating to forwarding information updates at HA and, finally, (5) threats related to nested mobility. For the described threats, suggestions are given for possible tools. This document does not describe threats relating to Route Optimization for moving networks, nor threats relating to Mobile IPv6 for hosts, nor other mobility-related threats whose solutions are described by PANA, EAP, AAA and SEND Working Groups. For threats relating to Mobile IPv6 for Mobile Hosts, reader is kindly referred to [], []. For threats relating to access granting and control, or threats of IPv6 behaviour on same-link, please see the above mentioned Working Groups documents. A similar document attempting to describe threats in the NEMO context is []. The current network mobility base specification specifies that all signaling messages between the Mobile Router and the Home Agent MUST be authenticated by IPsec. The use of IPsec to protect Mobile IPv6 signaling messages is described in detail in the HA-MN IPsec specification. Using AH and/or ESP between MR and HA is of paramount importance in order to protect against a wide range of threats. However, other means of protecting communication between MR and HA might be useful in certain cases. A good overview of authentication mechanisms in the Internet can be found in []. X. Interactions between MR and HA Threat on switching between modes: MR sends BU in implicit mode to HA, HA replies back positively, using MNP from external means (not from BU). During this time, the attacker gained knowledge of the MR's Home Addres, sends BU to HA in explicit mode for the same Home Address but a MNP specified in the BU, different than what HA already has. HA replies back positively to MR and switches to explicit mode and a different MNP. Threat is DoS: tunneling data between MR and HA stops, MR is in implicit mode while HA in explicit mode. IPsec protects against this behaviour in that HA will drop the attacker's BU because can't decrypt the received ESP (attacker does not have the keys shared between MR and HA). Threat on location privacy: Location privacy is the desire of a Mobile Host to not reveal, or hide, its current association Care-of Address (its location) - Home Address (its permanent identifier) from an attacker listening on the path between MH and HA. It is not a desire to hide only one address, but the association. It is a problem in that attacker A may have visibility over the Home Address and the Care-of Address of a Binding Update or Binding Acknowledgement between MR and HA even if ESP is used (ESP does not cover the base IPv6 header of the BU whose src field contains the CoA, neither the DO1 header containing the Home Address). It is also a temporality problem for MH in that an attacker on the same visited link as MH may intercept the Binding Request Refresh messages from HA towards MH after the MH has left that visited link, thus deducing that that MH was "located" on that link at a certain point in time. This is not a location privacy problem for LFN behind MR, because all traffic from LFN is encapsulated inside the ESP tunnel between MR and HA; moreover, since LFN only has a Home Address (no CoA) there is actually no association to hide from wily attackers. Masquerading for Denial-of-Service: when attacker needs to send an unreasonably large amount of IP packets to a target without risk of his current address being identified, it could do so by two means. First, it would set the src address of the packets to another address, at random (thus "spoofing" a legitimate address, or "masquerading" as that address). However, the first-hop router might forbid forwarding packets whose source address are not topologically correct at that particular router (ingress filtering). Second, if ingress filtering at the access router is in place, the MH might first encapsulate towards HA, thus tricking the access router; HA decapsulates and "bombs" the actual target by using MH's Home Address as source address. However, the ingress filtering technique is used at the HA as well; Mobile IPv6 requires HA of MH to only forward those packets from MH if the src address of the outer header to match a Care-of Address entry in the BC and the src address in the inner header to match the home address field of the same entry. The NEMO spec goes further in the ingress filtering detail by requiring the Home Address to match a Mobile Network Prefix owned by the Mobile Router. Confidentiality threat: the payload of all IPv6 packets between LFN and CN is encapsulated inside the bidirectional tunnel between MR and HA. An attacker placed in the path between LFN and CN might have visibility over all this traffic. But, if the encapsulating tunnel uses ESP tunnel mode, payload is encrypted, thus hidden. In this respect, MR acts exactly as MH. Authentication threat: the same attacker might modify the payload of data between LFN and CN. But if AH is used, payload is authenticated, thus impossible to modify without LFN and CN noticing it. In this respect too, MR acts as MH. Using AH and/or ESP between MR and HA is of paramount importance in order to protect against a wide range of threats. X. Interactions between several MR's of same HA DoS threat on peer MR: consider a legitimate MR with prefix MNP and an attacker MR with a different prefix, both served by the same HA. Each MR shares a set of keys with HA, and SA's linking the respective Home Addresses and the HA address. The attacker MR could instruct the HA to to add MNP in the binding cache, relating it to its own Home Address (instead of to the legitimate MR's Home Address), thus effectively denying service to the legitimate MR and redirecting the entire traffic to MNP towards the attacker MR. Even if HA uses IPsec, it could not protect against attacker MR's claiming the legitimate MR's MNP. However, the prefix table specified by NEMO associates a MR's Home Address to the MNP that it owns, thus constituting a means for MR to check against attacker MR claiming a prefix it does not actually own. This particular threat applies equally well to Mobile IPv6 for hosts: an attacker MH may demand the HA (with which it holds an SA) to insert a BC entry of its CoA towards the Home Address of a legitimate MH, even if both MH's have respective SA's with that HA. If the threat is solved by Mobile IPv6 for hosts, the method specified by Mobile IPv6 should naturally be reused by NEMO base support too. X. MR and HA in different administrative domains [This is rather tough for me to understand.] It is possible that HA and MR belong to a same administrative domain. It is also possible that HA and MR belong to different administrative domains. In the latter case, there might be important security risks, and routing instability risks. For one, if MR advertises a prefix towards HA, HA accepts it and propagates it upper stream then an important instability in the Internet at large might appear (because MR's prefix is administratively assigned somewhere else, in MR's administrative domain). Second, if HA advertises prefixes towards the mobile network, then routing instability in the mobile network might appear. Because of those two reasons, it might be recommended for MR and HA to forbid the exchange of any routing information (other than Mobile IPv6) when MR and HA belong to different administrative domains. X. Forwarding Information Updates at HA How current routing protocols routers authentify each other, how they lack a concept of "prefix ownership" (see the "address ownership problem" []). How the prefix table might help with this. How routing protocols authentication could be interpreted to solve the potential "prefix ownership" problem. The current base NEMO specification reads: When the Mobile Router is running a dynamic routing protocol as described in section 7, it injects routing update messages into the Home Link. The Home Agent MUST verify that the Mobile Router is allowed to send routing updates before processing the messages and propagating the routing information. X. Nested Mobility DoS threat on TLMR due to too many nested networks: several moving networks may attach one under the other forming a nested aggregation of moving networks. Naturally, the top-level MR will forward traffic of all moving networks attached under it. When the number of levels is large, this may become an overload on the initial expectations of the capabilities of this Mobile Router, thus becoming a DoS attack. It is possible that a MR has a desire to limit the number of moving networks that nest under it; it could use the Tunnel Encapsulation option by setting a limit on the number of levels of mobile networks below it. X. Other Threats Other threats might exist. X. Acknowledgements Threats related to network mobility have been discussed on the NEMO list, whose members are acknowledged here. Particularly relevant threats woven in the threading of this document have been described by (in random order): V. Devarapalli, E. Nordmark, T. Ernst, S. Jung. Authentication mechanisms of routing protocols mentioned by S. M. Corson. More, etc. X. References [] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P., "Nemo Basic Support Protocol" (work in progress). Internet Draft, IETF. draft-ietf-nemo-basic-support-01.txt. September 2003. [] Johnson, D., Perkins, C. and Arkko, J., "Mobility Support in IPv6" (work in progress). Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt. June 2003. [] Arkko, J., Devarapalli, V. and Dupont, F., "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents" (work in progress). Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. June 2003. [] Nikander, P., Harkins, D., Patil, B., Roberts, P., Nordmark, E. and Makin, A., "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6" (work in progress). Internet Draft, IETF. draft-team-mobileip-mipv6-sec-reqts-00.txt. December 2001. [] Jung, S., Zhao, F., Wu, F., Kim, H., Sohn, S., "Threat Analysis for NEMO" (work in progress). Internet Draft, IETF. draft-jung-nemo-threat-analysis-01.txt. October 2003. [] Rescorla, E., "A Survey of Authentication Mechanisms" (work in progress). Internet Draft, IETF. draft-rescorla-auth-mech-01.txt. March 2003. [] Nikander, P., "An Address Ownership Problem in IPv6" (work in progress). Internet Draft, IETF. draft-nikander-ipng-address-ownership-00.txt. February 2001. Changes November 2002: revision 00 submitted. Author's Addresses Alexandru Petrescu Motorola Labs Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 France Phone: +33 1 69354827 Alexandru.Petrescu@motorola.com 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 assigns. 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. Funding for the RFC editor function is currently provided by the Internet Society.
- [nemo] commens on draft-jung-nemo-threat-analysis… Vijay Devarapalli
- Re: [nemo] commens on draft-jung-nemo-threat-anal… Alexandru Petrescu
- Re: [nemo] commens on draft-jung-nemo-threat-anal… Thierry Ernst
- [nemo] Re: commens on draft-jung-nemo-threat-anal… Souhwan Jung
- Re: [nemo] Re: commens on draft-jung-nemo-threat-… Vijay Devarapalli
- Re: [nemo] commens on draft-jung-nemo-threat-anal… T.J. Kniveton
- Re: [nemo] commens on draft-jung-nemo-threat-anal… William D Ivancic
- Re: [nemo] commens on draft-jung-nemo-threat-anal… Alexandru Petrescu
- Re: [nemo] commens on draft-jung-nemo-threat-anal… Alexandru Petrescu