Internet Draft A. Petrescu Document: draft-petrescu-nemo-threats-xx.txt A. Olivereau Expires: July 2004 C. Janneteau H.-Y. Lach Motorola January 2004 Threats for Basic Network Mobility Support (NEMO threats) 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. Abstract This document describes security threats related to the network mobility base protocol (NEMO). Threats of Mobile IPv6 for Mobile Hosts are only briefly touched when in need of support of related NEMO threats. The NEMO signalling 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 MH and HA (IPsec), dynamic routing protocol authentication, NEMO prefix table, ingress filtering checks at HA and tunnel encapsulation limiting are presented as protocol features affording protection against threats. NEMO threats for which there are no protections are briefly mentioned. Petrescu et al. Expires July 2004 [Page i] INTERNET-DRAFT Mobile Networks Threats January 2004 Table of Contents Status of this Memo................................................i Abstract...........................................................i Conventions Used in this Document..................................1 1. Introduction and Overview.......................................1 2. Interactions between MR and HA..................................4 3. Interactions between several MR's of same HA....................7 4. Forwarding Information Updates at HA............................7 5. Nested Mobility.................................................8 6. Other Threats...................................................8 Acknowledgements...................................................8 A. IPsec Architecture for Nested Mobility..........................8 B. IPsec Protection of Binding Updates and Acknowledgements.......10 C. IPsec non-Protection of Home Agent Discovery Messaging.........18 References........................................................19 Changes...........................................................21 Copyright Notice..................................................22 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 [2]. In addition to the NEMO terminology [5], four additional terms were useful for descriptions within this document. Binding Update: an IPv6 datagram that contains a Mobility Header whose MH Type field is 0x5; it is sent by a Mobile Node to its Home Agent. Binding Acknowledgement: an IPv6 datagram that contains a Mobility Header whose MH Type field is 0x6; it is sent by a Home Agent in response to a Binding Update received from a Mobile Node. Mobile Security Gateway: an entity acting simultaneously as a NEMO Mobile Router and as an IPsec Security Gateway. Home Security Gateway: an entity acting simultaneously as a NEMO Home Agent and as an IPsec Security Gateway. 1. Introduction and Overview The Network Mobility base protocol [4] describes means for a Mobile Router using Mobile IPv6 [8] to offer continuous connectivity for a set of hosts and routers within a moving network, to the Internet. A moving network has a relatively stable internal IP structure and will usually not transit traffic. The Mobile Router is part of the moving network and moves together with all nodes of it. Petrescu et al. Expires July 2004 [Page 1] INTERNET-DRAFT Mobile Networks Threats January 2004 Documents desribing protocols should contain a Security Section [18][20]. Section 8 of the NEMO base protocol is such a section; it contains briefly outlined guidelines on the methods to use to offer a relatively high level of security (IPsec, HA ingress filtering and routing protocol verifications indications). This document presents the characteristics of the initial threat model that was used as basis for developping the respective Security Considerations section. A Mobile Router implements most functionalities of a Mobile IPv6 Mobile Host [8]. Notable additions include the R-bit management and NEMO-specific modes (implicit and explicit). A NEMO Home Agent implements most functionalities of a Mobile IPv6 HA with the the additions of R-bit management, the two modes and, additionally, interactions with its forwarding information (routing table) management. There are no new messages introduced by the base NEMO document [4] when compared to Mobile IPv6 [8]. The modified messages are: Binding Update, Binding Acknowledgement, Home Agent Discovery Request and Home Agent Discovery Reply. New R-bit fields have been included in the Binding Update and the Home Agent Discovery Request and Reply; a new MNP field has been introduced in the Binding Update; the Status field of a Binding Acknowledgement contains new values. A new mobility configuration 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) threats relating to forwarding information updates at HA and, finally and (4) threats related to nested mobility. Another document attempting to describe threats in the NEMO context is [9]. This document avoids description of threats relating to Route Optimization for moving networks, to Mobile IPv6 for Mobile Hosts, to multihoming for moving networks; other generic mobility threats exist whose solutions are proposed by PANA, AAA and SEND Working Groups. For threats relating to Mobile IPv6 for Mobile Hosts, reader is referred to section 15.1 of [8], to [1] and [16]. For threats relating to access granting and control, or threats of IPv6 behaviour on same link, please see the above mentioned Working Group documents. For threats on the routing protocol (eventually used between MR and HA) see [3]. Petrescu et al. Expires July 2004 [Page 2] INTERNET-DRAFT Mobile Networks Threats January 2004 The current network mobility base specification [4] requires 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 [1]. Using AH and/or ESP between MR and HA is of paramount importance in order to protect against a wide range of attacks. The Internet IPsec architecture can be particularized for Mobile Routers by distinguishing two cases: (1) IPsec protection in transport mode for NEMO signalling and (2) IPsec protection in tunnel mode for NEMO traffic between LFN and CN. AH/ESP used in transport mode for NEMO signalling protects Binding Updates, Binding Acknowledgements (but does not protect Home Agent Address Discovery Requests and Home Agent Address Discovery Replies). They are exchanged between the Mobile Router (Mobile Security Gateway) and Home Agent (Home Security Gateway): +--------+ +--------+ | Mobile | AH/ESP transport mode | Home | | Sec GW |========================| Sec GW | | (MR) | | (HA) | +--------+ +--------+ AH/ESP used in tunnel mode for NEMO traffic protects all fields of all IP datagrams exchanged between LFN and CN, including application-level data: +--------+ AH/ESP tunnel mode +--------+ +-----+ | Mobile |________________________| Home | +----+ | LFN |.....| Sec GW |........................| Sec GW |.....| CN | +-----+ | (MR) |------------------------| (HA) | +----+ +--------+ +--------+ This IPsec architecture for moving networks can be extended to nested network mobility configurations, by means of encapsulating tunneling. See section A for illustrations of IPsec for nested mobility. Other means of protecting communication between MR and HA are needed in certain cases; they include the use of the NEMO Prefix Table, the prefix-extended ingress filtering technique [6] used by the NEMO Home Agent and the tunnel encapsulation limiting. If further additional tools are needed, a good overview of authentication mechanisms in the Internet can be found in [19]. Last but not least, even if IPsec, ingress filtering, Prefix Table and tunnel encapsulation limiting are used, we acknowledge the existence of other security risks with the NEMO base protocol. They stem mainly from the lack of certain security features of the underlying Mobile IPv6 protoocol. For example: attacks on the R bit within the Home Agent Discovery messaging, and location privacy risks. Petrescu et al. Expires July 2004 [Page 3] INTERNET-DRAFT Mobile Networks Threats January 2004 2. Interactions between MR and HA T.1 Threat on the MNP field (redirection threat): the simplest and most important (but avoidable) threat of the NEMO basic support protocol is the redirection of traffic of all addresses within a Mobile Network Prefix. An attacker sending an un-protected NEMO Binding Update to a Home Agent for a certain MNP is actually instructing that Home Agent to forward all traffic for MNP towards the address of the attacker. The gravity of the risk is more important than in the case of Mobile Hosts; an attacker Mobile Host could re-direct only one legitimate Home Address, while with NEMO an attacker MR could re-direct all the addresses within an MNP. Moreover, the risk is all the more important since attacker MR can be positioned anywhere in the Internet, NEMO is not restrained to a closed system. In order to avoid this risk actually realizing, it is important to protect all signalling messages between MR and HA by IPsec (this is also required by [1] and [8]). In general, if HA uses AH/ESP transport mode for all NEMO signalling with the legitimate MR then attacker MR is not able to realize such a re-direction attack, because AH/ESP in transport mode covers the MNP field of the BU. T.2 Threat on the R bit of BU: An attacker Mobile Host asks its Home Agent to forward all traffic addressed to addresses within MNP to its current Care-of Address. Normally, Mobile Hosts do not send the R-bit in the Binding Update. An attacker Mobile Host can specify the R-bit and thus receiving traffic addressed to other addresses than simply to its Home Address. However, if IPsec is used, the R-bit in the BU is covered both by AH and ESP in transport mode, so if HA and MH have a trust relationship it is assumed that MH will not specify the R bit. T.3 Threat on the Status field of BAck: an attacker entity on the path between legitimate MR and HA modifies the Status field of the Binding Acknowledgement sent by the HA to MR. It is assumed that MR has previously sent a BU to HA with the R-bit set and that HA replied with Status 140 (Mobile Router Operation not Permitted). The attacker entity substitutes 141 (Invalid Prefix) for 140 and thus leads MR into re-sending Binding Updates to Home Agent (instead of stopping sending Binding Updates). However, the AH/ESP headers cover the Status field of the BAck and thus attacker can not tamper with the Status field, invalidating this threat. T.4 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 Address, 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 two-fold: on one hand HA would stop forwarding packets of the legitimate MNP towards the legitimate MR; on the other hand HA would start forwarding packets of a false MNP towards the legitimate MR. Petrescu et al. Expires July 2004 [Page 4] INTERNET-DRAFT Mobile Networks Threats January 2004 IPsec can not help protecting against attacker MR obtaining the Home Address of the legitimate MR (it is not covered by ESP when legitimate MR sends BU or receives BAck). However, IPsec can protect against the attacker MR specifying an illegitimate MNP within a BU; the MNP field in the BU is covered by ESP in transport mode. The description of this threat started with MR using implicit mode and attacker trying explicit mode. The description applies equally well if the initial step was in explicit mode and second step used implicit mode. T.5 Threat on the R bit of Home Agent Discovery Request: an attacker on the path between legitimate MR and HA transforms the R bit from 1 to 0. The Home Agents thus receive a request for non-NEMO Home Agents and will not set the R bit in the Reply message. Thus the MR is led into believing there is no HA on the home link supporting Mobile Routers. IPsec does not protect against this threat since the Home Agent Address Discovery Request is not protected neither by AH nor by ESP headers. T.6 Threat on the R bit of Home Agent Discovery Reply: an attacker entity on the path between legitimate MR and HA transforms the R bit from 1 to 0. It is assumed that, initially, the MR has sent a Home Agent Address Discovery message to the home network with the R-bit set, thus requesting responses from HA's that support Mobile Routers; it is also assumed that the HA replied a legitimate Reply containing the R bit set. The effect of this threat is that MR is falsely led into believing that no HA on the home network can support Mobile Routers. IPsec does not protect against this threat since the Home Agent Address Discovery Reply is not protected neither by AH nor by ESP headers. T.7 Threat of address spoofing: 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 [6]). 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 base specification offers further help by requiring the Home Address to match a Mobile Network Prefix owned by the Mobile Router. If is obvious that this threat applies to Mobile IPv6 for Mobile Hosts and, where Mobile IPv6 for Mobile Hosts offers protection, it automatically offers protection for Mobile Routers as well. Petrescu et al. Expires July 2004 [Page 5] INTERNET-DRAFT Mobile Networks Threats January 2004 T.8 Threat on location privacy: [it is not immediately clear to authors whether location privacy can be qualified as a NEMO security threat per se or as a particular risk of open communications in mobile environments.] In the context of Mobile Hosts (not Mobile Routers), location privacy represents 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 sufficient for an attacker wishing to find the current location of a victim Mobile Host to snoop traffic between the victim and its Home Agent. When the Mobile Host changes its location and updates the Home Agent, a pair of Binding Update/Acknowledgement messages is communicated. An attacker on the path can find the association Home Address - Care-of Address of the Mobile Host, even if AH and/or ESP headers are used to protect the two packets. Both AH and ESP for Binding Updates and Acknowledgements are used in transport mode (not tunnel mode), thus the base header (containing the Care-of Address and the Home Agent address), the Destination Options header and the Routing Header Type 2 (containing the Home Address) are transmitted in clear (but message integrity, and implicitely integrity of the Home Address and the Care-of Address, is afforded by AH), see section B.6. In the context of NEMO, the location privacy can be described as the desire of a Local Fixed Node within a moving network to not reveal, or hide, the location triplet LFN Home Address - MR Care-of Address - MR Home Address. An attacker outside the moving network and on the path between the Mobile Router and its Home Agent could snoop packets. If the bidirectional tunnel between the Mobile Router and its Home Agent is not protected by ESP, then attacker can find the LFN Home Address in the src field of the inner packet sent by MR to HA and the MR Care-of Address in the src field of the outer base header. The MR Home Address could have been obtained from the Binding Update or the Binding Acknowledgement, as described in the previous paragraph. In this way, attacker can gain knowledge of the triplet LFN Home Address - MR Home Address - MR Care-of Address. However, if MR uses ESP tunnel mode protection for the bidirectional tunnel, then attacker has no means to gain visibility of the LFN Home Address. Thus, even if location privacy might be considered as a security threat, it is mostly a risk for Mobile Hosts, and can not be qualified as a NEMO risk; the association Home Address - Care-of Address of a Mobile Host might be revealing location information but the location triplet can not be revealed if ESP is used for non-signaling traffic between MR and HA. T.9 Threat on the Routing Header Type 2: attacker modifies the type of the routing header type 2 of a Binding Acknowledgement sent by HA to MR and substitues 0 for 2. In addition attacker may specify a number of addresses within this fake type 0 routing header. The risk is that attacker provokes bombing attacks and stays hidden Petrescu et al. Expires July 2004 [Page 6] INTERNET-DRAFT Mobile Networks Threats January 2004 (its address does not appear in the packet); it is the Home Agent's and the Mobile Router's addresses that appear in the attack. The risk is typically a Mobile IPv6 for hosts risk, but it is more important in the case of Mobile Routers because Mobile Hosts are not expected to implement routing header software, or are expected to implement type 2 routing headers exclusively (for Mobile Hosts). However, all routers (Mobile Routers included) are expected to implement routing headers type 0, thus they are more at risk with this threat. Protection against this risk is again offered by AH which covers all fields of the Routing Header Type 2. 3. Interactions between several MR's of same HA T.10 DoS threat on peer MR by attacker spoofing a legitimate MR's Care-of Address. A similar threat exists in the case of Mobile IPv6 for Mobile Hosts, but is less important than in the case of NEMO. In the context of Mobile IPv6 for Mobile Hosts, consider two Mobile Hosts belonging to the same Home Agent; each MH is trusted by the Home Agent (with IPsec). The victim MH and the attacker MH are both visiting the same foreign network. The attacker MH reads the Care-of Address of the victim from the Binding Update or Acknowledgement that victim exchanges with HA. The attacker MH sends Binding Update for the victim's CoA and its own Home Address. Thus the HA will forward all traffic intended to attacker's Home Address towards victim's Care-of Address, even though IPsec is correctly being used. This threat applies in the NEMO context as follows: 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. The attacker MR could instruct the HA 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 base protocol 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. 4. 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" [17]). How the prefix table might help with this. How routing protocols authentication could be interpreted to solve the potential "prefix ownership" problem. The use of the prefix table to help authorizing the injection of route updates is different than the use of the same prefix table in explicit mode in order to authorize insertion of bindings (in NEMO explicit mode), as presented in threat T.x. Petrescu et al. Expires July 2004 [Page 7] INTERNET-DRAFT Mobile Networks Threats January 2004 The current base NEMO specification contains: 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. 5. Nested Mobility T.11 DoS threat on TLMR due to too many levels of nested networks: several moving networks may attach one under the other thus forming a nested aggregation of moving networks ("levels" can be pictured as follows: first MR attached under TLMR makes it for a one-level aggregation of moving networks; a second MR attached under TLMR is still a one-level aggregation; were the second MR attached under the first MR, it would have been a two-level aggregation). 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 original expectations of the capabilities of this Mobile Router (overload in the form of more cycles dedicated to IPv6 Fragmentation and Reassembly, as well as Path MTU calculations), thus becoming a DoS attack. It is thus possible for MR to need to limit the number of levels of moving networks nesting under it; it could use the Tunnel Encapsulation option by setting a limit on the number of levels of mobile networks below it. Nested mobility configurations appear also when Mobile Hosts visit mobile networks. However, all Mobile Hosts will always attach to a same level; given a mobile network, it is not possible to build a more than one-level nested aggregation only by adding Mobile Hosts (MH's don't attach one under the other). Thus, the above mentioned threat of nested configurations is pertinent to nested moving networks exclusively. 6. Other Threats Other threats exist. Acknowledgements Threats related to network mobility have been discussed on the IETF NEMO WG list, whose members are acknowledged here. Seongho Cho provided significant feedback about several threats. A. IPsec Architecture for Nested Mobility The IPsec architecture can be particularized for nested mobility cases by using nested encapsulation. In the figure below we picture the protection of NEMO signalling between MR1 and its HA (HA_MR1), when the moving network of MR1 is nesting within the Petrescu et al. Expires July 2004 [Page 8] INTERNET-DRAFT Mobile Networks Threats January 2004 moving network of MR2 (it is assumed that the MR2 has already performed NEMO signalling with its own HA - HA_MR2). The first level of IPsec protection is offered by the AH/ESP transport mode between MR1 and HA_MR1 (1). The second level is offered by AH/ESP tunnel mode between MR2 and HA_MR2 (2). +--------+ +--------+ +--------+ +--------+ | | | | | | | | | Mobile | | Mobile |__2__| Home |___| Home | | Sec GW |=1=| Sec GW |=====| Sec GW |===| Sec GW | | (MR1) | | (MR2) |-----|(HA_MR2)|---|(HA_MR1)| | | | | | | | | +--------+ +--------+ +--------+ +--------+ The IPsec protection of application-level traffic between LFN and CN, when LFN belongs to a nested moving network is pictured below. The first level of protection is offered by the AH/ESP tunnel mode between MR1 and HA_MR1 while the second is offered by the AH/ESP tunnel mode between MR2 and HA_MR2. +--------+ +--------+ +--------+ +--------+ | | | |__2__| | | | +-----+ | Mobile |_1_| Mobile |_____| Home |___| Home | +----+ | LFN |..| Sec GW |...| Sec GW |.....| Sec GW |...| Sec GW |..| CN | +-----+ | (MR1) |---| (MR2) |-----|(HA_MR2)|---|(HA_MR1)| +----+ | | | |-----| | | | +--------+ +--------+ +--------+ +--------+ A parcticular case of nested mobility configuration is the visit of of a MH within a moving network. The signalling protection is offered by AH/ESP in transport mode between MH and HA_MH (1) and by AH/ESP offered by AH/ESP in tunnel mode between MR and HA_MR (2). +--------+ +--------+ +-------+ +--+ | Mobile |___________2____________| Home | | | |MH|===1====| Sec GW |========================| Sec GW |==| HA_MH | +--+ | (MR) |------------------------| (HA_MR)| | | +--------+ +--------+ +-------+ Still in the case of nested mobility of a MH within a moving network, the application-level traffic between MH and CN is offered a first level of protection by the AH/ESP tunnel mode between MH and HA_MN (1) and a second level by the AH/ESP tunnell mode between MR and HA_MR (2). +--------+ +--------+ +-------+ +---+ | |_________2________| | | | | |_1__| Mobile |__________________| Home |___| | +----+ |MH |....| Sec GW |..................| Sec GW |...| HA_MH |....| CN | | |----| (MR) |------------------| (HA_MR)|---| | +----+ +---+ | |------------------| | | | +--------+ +--------+ +-------+ Petrescu et al. Expires July 2004 [Page 9] INTERNET-DRAFT Mobile Networks Threats January 2004 B. IPsec Protection of Binding Updates and Acknowledgements In this section, we used the following NEMO messages for threat analysis: Binding Update, Binding Acknowldegement. The following fields have been considered as relevant for NEMO threat analysis: -src and dst addresses in the base header. -the Home Address in the Destination Options 0 header of the Binding Update. -the R bit in the AHLKR field of the Binding Update. -the Prefix Len and Mobile Network Prefix fields in a Binding Update sent in explicit mode. -the Routing Type, Segments Left and Home Address fields in the Routing Header Type 2 of the Binding Acknowledgement. -the Status field of the Binding Acknowledgement. In building the packet formats below, the following notation was used: *: NEMO field, or bit or value introduced by NEMO base protocol, or containing helpful information for realization of the NEMO-related risks described in this document. x: authenticated field, as covered by AH ICV. y: encrypted field, as part of ESP payload data. z: authenticated field, as part of ESP authentication data. For example, fields that are marked (*xyz) are helping realizing threats, but are protected by AH and ESP non-NULL authentication, thus rendering most NEMO threats impossible; fields that are only marked (*) are not protected, thus might constitute security risks. In the following sections, pairs consisting of a Binding Update and the corresponging Binding Acknowledgement are illustrated. Each section describes two pairs: the pair when MR is in a foreign network followed by the pair when MR is returning to the home network. Section B.1 presents unprotected pairs while section B.6 presents pairs protected both by AH and ESP in transport mode (ESP with non-NULL authentication algorithm). Intermediary sections use transport mode AH exclusively or transport mode ESP exclusively (ESP with or without authentication algorithm). Petrescu et al. Expires July 2004 [Page 10] INTERNET-DRAFT Mobile Networks Threats January 2004 B.1 Unprotected BU and BAck when MR in foreign network Base Header Base Header src: CoA (*) src: Home Agent address (*) dst: Home Agent address (*) dst: CoA (*) Destination Options Routing Header Home Address: Home Address (*) Routing Type: 2 (*) Mobility Header Segments Left: 1 (*) Header Len Home Address: Home Address (*) MH Type: Mobility Header Reserved: Header Len: Checksum: MH Type: Message Data Reserved: Seq # Checksum: AHLKR (*) Message Data Lifetime: Status (*) Mobility Options K: Alternate CoA: CoA Reserved Mobile Net Prefix Option Seq #: Prefix Len: (*) Lifetime: Mobile Net Prefix: (*) Mobility Options Binding Refresh Advice Refresh Interval: Unprotected BU and BAck when MR returns home Base Header Base Header src: Home Address (*) src: Home Agent address (*) dst: Home Agent address (*) dst: Home Address (*) Mobility Header Mobility Header Header Len Header Len: MH Type: MH Type: Reserved: Reserved: Checksum: Checksum: Message Data Message Data Seq # Status (*) AHLKR (*) K: Lifetime: Reserved Mobility Options Seq #: Mobile Net Prefix Option Lifetime: Prefix Len: (*) Mobility Options Mobile Net Prefix: (*) Binding Refresh Advice Refresh Interval: Petrescu et al. Expires July 2004 [Page 11] INTERNET-DRAFT Mobile Networks Threats January 2004 B.2 AH protected BU and BAck when MR in foreign network Base Header Base Header src: CoA (*x) src: Home Agent address (*x) dst: Home Agent address (*x) dst: CoA (*x) Destination Options Routing Header Home Address: Home Address (*x) Routing Type: 2 (*x) Authentication Header Segments Left: 1 (*x) SPI: Home Address: Home Address(*x) Seq No: Authentication Header ICV: SPI: Mobility Header Seq No: Header Len ICV: MH Type: Mobility Header Reserved: Header Len: Checksum: MH Type: Message Data Reserved: Seq # Checksum: AHLKR (*x) Message Data Lifetime: Status (*x) Mobility Options K: Alternate CoA: CoA Reserved Mobile Net Prefix Option Seq #: Prefix Len: (*x) Lifetime: Mobile Net Prefix: (*x) Mobility Options Binding Refresh Advice Refresh Interval: AH protected BU and BAck when MR returns home Base Header Base Header src: Home Address (*x) src: Home Agent address (*x) dst: Home Agent address (*x) dst: Home Address (*x) Authentication Header Authentication Header SPI: SPI: Seq No: Seq No: ICV: ICV: Mobility Header Mobility Header Header Len Header Len: MH Type: MH Type: Reserved: Reserved: Checksum: Checksum: Message Data Message Data Seq # Status (*x) AHLKR (*x) K: Lifetime: Reserved Mobility Options Seq #: Mobile Net Prefix Option Lifetime: Prefix Len: (*x) Mobility Options Mobile Net Prefix: (*x) Binding Refresh Advice Refresh Interval: Petrescu et al. Expires July 2004 [Page 12] INTERNET-DRAFT Mobile Networks Threats January 2004 B.3 ESP NULL auth algo for BU and BAck when MR in foreign network Base Header Base Header src: CoA (*) src: Home Agent address (*) dst: Home Agent address (*) dst: CoA (*) Destination Options Routing Header Home Address: Home Address (*) Routing Type: 2 (*) ESP Header Segments Left: 1 (*) SPI: Home Address: Home Address (*) Seq No: ESP Header Mobility Header SPI: Header Len Seq No: MH Type: Mobility Header Reserved: Header Len: Checksum: MH Type: Message Data Reserved: Seq # Checksum: AHLKR (*y) Message Data Lifetime: Status (*y) Mobility Options K: Alternate CoA: CoA Reserved Mobile Net Prefix Option Seq #: Prefix Len: (*y) Lifetime: Mobile Net Prefix: (*y) Mobility Options ESP Trailer Binding Refresh Advice Refresh Interval: ESP Trailer ESP NULL auth algo for BU and BAck when MR returns home Base Header Base Header src: Home Address (*) src: Home Agent address (*) dst: Home Agent address (*) dst: Home Address (*) ESP Header ESP Header SPI: SPI: Seq No: Seq No: Mobility Header Mobility Header Header Len Header Len: MH Type: MH Type: Reserved: Reserved: Checksum: Checksum: Message Data Message Data Seq # Status (*y) AHLKR (*y) K: Lifetime: Reserved Mobility Options Seq #: Mobile Net Prefix Option Lifetime: Prefix Len: (*y) Mobility Options Mobile Net Prefix: (*y) Binding Refresh Advice ESP Trailer Refresh Interval: ESP Trailer Petrescu et al. Expires July 2004 [Page 13] INTERNET-DRAFT Mobile Networks Threats January 2004 B.4 ESP non-NULL auth algo for BU and BAck when MR in foreign network Base Header Base Header src: CoA (*) src: Home Agent address (*) dst: Home Agent address (*) dst: CoA (*) Destination Options Routing Header Home Address: Home Address (*) Routing Type: 2 (*) ESP Header Segments Left: 1 (*) SPI: Home Address: Home Address (*) Seq No: ESP Header Mobility Header SPI: Header Len Seq No: MH Type: Mobility Header Reserved: Header Len: Checksum: MH Type: Message Data Reserved: Seq # Checksum: AHLKR (*yz) Message Data Lifetime: Status (*yz) Mobility Options K: Alternate CoA: CoA Reserved Mobile Net Prefix Option Seq #: Prefix Len: (*yz) Lifetime: Mobile Net Prefix: (*yz) Mobility Options ESP Trailer Binding Refresh Advice ESP Auth Refresh Interval: ESP Trailer ESP Auth ESP non-NULL auth algo for BU and BAck when MR returns home Base Header Base Header src: Home Address (*) src: Home Agent address (*) dst: Home Agent address (*) dst: Home Address (*) ESP Header ESP Header SPI: SPI: Seq No: Seq No: Mobility Header Mobility Header Header Len Header Len: MH Type: MH Type: Reserved: Reserved: Checksum: Checksum: Message Data Message Data Seq # Status (*yz) AHLKR (*yz) K: Lifetime: Reserved Mobility Options Seq #: Mobile Net Prefix Option Lifetime: Prefix Len: (*yz) Mobility Options Mobile Net Prefix: (*yz) Binding Refresh Advice ESP Trailer Refresh Interval: ESP Auth ESP Trailer ESP Auth Petrescu et al. Expires July 2004 [Page 14] INTERNET-DRAFT Mobile Networks Threats January 2004 B.5 AH and ESP NULL for BU and BAck when MR in foreign network Base Header Base Header src: CoA (*x) src: Home Agent address (*x) dst: Home Agent address (*x) dst: CoA (*x) Destination Options Routing Header Home Address: Home Address (*x) Routing Type: 2 (*x) Authentication Header Segments Left: 1 (*x) SPI: Home Address: Home Address(*x) Seq No: Authentication Header ICV: SPI: ESP Header Seq No: SPI: ICV: Seq No: ESP Header Mobility Header SPI: Header Len Seq No: MH Type: Mobility Header Reserved: Header Len: Checksum: MH Type: Message Data Reserved: Seq # Checksum: AHLKR (*xy) Message Data Lifetime: Status (*xy) Mobility Options K: Alternate CoA: CoA Reserved Mobile Net Prefix Option Seq #: Prefix Len: (*xy) Lifetime: Mobile Net Prefix: (*xy) Mobility Options ESP Trailer Binding Refresh Advice Refresh Interval: ESP Trailer Petrescu et al. Expires July 2004 [Page 15] INTERNET-DRAFT Mobile Networks Threats January 2004 AH and ESP NULL for BU and BAck when MR returns home Base Header Base Header src: Home Address (*x) src: Home Agent address (*x) dst: Home Agent address (*x) dst: Home Address (*x) Authentication Header Authentication Header SPI: SPI: Seq No: Seq No: ICV: ICV: ESP Header ESP Header SPI: SPI: Seq No: Seq No: Mobility Header Mobility Header Header Len Header Len: MH Type: MH Type: Reserved: Reserved: Checksum: Checksum: Message Data Message Data Seq # Status (*xy) AHLKR (*xy) K: Lifetime: Reserved Mobility Options Seq #: Mobile Net Prefix Option Lifetime: Prefix Len: (*xy) Mobility Options Mobile Net Prefix: (*xy) Binding Refresh Advice ESP Trailer Refresh Interval: ESP Trailer Petrescu et al. Expires July 2004 [Page 16] INTERNET-DRAFT Mobile Networks Threats January 2004 B.6 AH and ESP non-NULL for BU and BAck when MR in foreign network Base Header Base Header src: CoA (*x) src: Home Agent address (*x) dst: Home Agent address (*x) dst: CoA (*x) Destination Options Routing Header Home Address: Home Address (*x) Routing Type: 2 (*x) Authentication Header Segments Left: 1 (*x) SPI: Home Address: Home Address(*x) Seq No: Authentication Header ICV: SPI: ESP Header Seq No: SPI: ICV: Seq No: ESP Header Mobility Header SPI: Header Len Seq No: MH Type: Mobility Header Reserved: Header Len: Checksum: MH Type: Message Data Reserved: Seq # Checksum: AHLKR (*xyz) Message Data Lifetime: Status (*xyz) Mobility Options K: Alternate CoA: CoA Reserved Mobile Net Prefix Option Seq #: Prefix Len: (*xyz) Lifetime: Mobile Net Prefix: (*xyz) Mobility Options ESP Trailer Binding Refresh Advice ESP Auth Refresh Interval: ESP Trailer ESP Auth Petrescu et al. Expires July 2004 [Page 17] INTERNET-DRAFT Mobile Networks Threats January 2004 AH and ESP non-NULL for BU and BAck when MR returns home Base Header Base Header src: Home Address (*x) src: Home Agent address (*x) dst: Home Agent address (*x) dst: Home Address (*x) Authentication Header Authentication Header SPI: SPI: Seq No: Seq No: ICV: ICV: ESP Header ESP Header SPI: SPI: Seq No: Seq No: Mobility Header Mobility Header Header Len Header Len: MH Type: MH Type: Reserved: Reserved: Checksum: Checksum: Message Data Message Data Seq # Status (*xyz) AHLKR (*xyz) K: Lifetime: Reserved Mobility Options Seq #: Mobile Net Prefix Option Lifetime: Prefix Len: (*xyz) Mobility Options Mobile Net Prefix: (*xyz) Binding Refresh Advice ESP Trailer Refresh Interval: ESP Auth ESP Trailer ESP Auth C. IPsec non-Protection of Home Agent Discovery Messaging In this section, we used the following NEMO messages for threat analysis: Home Agent Address Discovery and Home Agent Address Reply. The following fields have been considered as relevant for NEMO threat analysis: -src and dst addresses in the base header. -the R bit in the ICMPv6 discovery and reply messages. -the R bit in the Home Agent Information Option of the Reply message. In building the packet formats below, the following notation was used: *: NEMO field, or bit or value introduced by NEMO base protocol, or containing helpful information for realization of the NEMO-related risks described in this document. x: authenticated field, as covered by AH ICV. y: encrypted field, as part of ESP payload data. z: authenticated field, as part of ESP authentication data. For example, fields that are marked (*xyz) are helping realizing threats, but are protected by AH and ESP non-NULL authentication, thus rendering most NEMO threats impossible; fields that are only marked (*) are not protected, thus might constitute security risks. Petrescu et al. Expires July 2004 [Page 18] INTERNET-DRAFT Mobile Networks Threats January 2004 C.1 Unprotected Home Agent Address Discovery and Reply Base Header Base Header src: CoA (*) src: Home Agent address (*) dst: Home Agents anycast (*) dst: CoA (*) ICMPv6 message ICMPv6 message Type Type Code Code Checksum Checksum Identifier Identifier R (*) R (*) Home Agent Information Option Type Length R (*) Remark the the Agent Discovery messages are not protected at all by IPsec and may lead to important security threats. NEMO threat analysis is concerned solely by the use of the R bit of these messages, and by the risks involved on tampering with the integrity or the confidentiality of this bit exclusively. References [1] 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. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Barbir, A., Murphy, S. and Yang, Y., "Generic Threats to Routing Protocols". Internet Draft, IETF. draft-ietf-rpsec-routing-threats-02.txt. August 2003. [4] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P., "Nemo Basic Support Protocol" (work in progress). Internet Draft, IETF. draft-ietf-nemo-basic-support-02.txt. December 2003. [5] Ernst, T. and Lach, H.-Y, "Network Mobility Support Terminology", Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt. May 2003. [6] Ferguson, P. and Senie, D., "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [7] Gupta, M. and Melam, N., "Authentication/Confidentiality for OSPFv3" (work in progress). Internet Draft, IETF. draft-ietf-ospf-ospfv3-auth-04.txt. December 2003. Petrescu et al. Expires July 2004 [Page 19] INTERNET-DRAFT Mobile Networks Threats January 2004 [8] 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. [9] Jung, S., Zhao, F., Wu, F., Kim, H. and Sohn, S., "Threat Analysis for NEMO" (work in progress). Internet Draft, IETF. draft-jung-nemo-threat-analysis-01.txt. October 2003. [10] Kent, S. and Seo, K., "Security Architecture for the Internet Protocol" (work in progress). Internet Draft, IETF. draft-ietf-ipsec-rfc2401bis-02.txt. January 2004. [11] Kent, S., "IP Authentication Header" (work in progress). Internet Draft, IETF. draft-ietf-ipsec-rfc2402bis-05.txt. September 2003. [12] Kent, S. and Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [13] Madson, C., "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. [14] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher Algorithm with Explicit IV", RFC 2405, November 1998. [15] Madson, C. and Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [16] 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. [17] Nikander, P., "An Address Ownership Problem in IPv6" (work in progress). Internet Draft, IETF. draft-nikander-ipng-address-ownership-00.txt. February 2001. [18] Postel, J. and Reynolds, J., "Instructions to RFC Authors", RFC 2223, October 1997. [19] Rescorla, E., "A Survey of Authentication Mechanisms" (work in progress). Internet Draft, IETF. draft-rescorla-auth-mech-02.txt. October 2003. [20] Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [21] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000. Petrescu et al. Expires July 2004 [Page 20] INTERNET-DRAFT Mobile Networks Threats January 2004 Changes November 2003: revision 00 submitted. January 2004: revision 01 submitted. -added appendices with detailed packet formats. -added the threat on Home Agent Discovery messaging. -added detailed explanations on existing threats and how IPsec headers protect. -eliminated the highly generic threats on Confidentiality and Integrity to better focus on NEMO specific threats. Authors' Addresses Alexandru Petrescu Christophe Janneteau Motorola Labs Motorola Labs Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69354827 Phone: +33 1 69352548 Alexandru.Petrescu@motorola.com Christophe.Janneteau@motorola.com Alexis Olivereau Hong-Yon Lach Motorola Labs Motorola Labs Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69352516 Phone: +33 1 69352536 Alexis@motorola.com Hong-Yon.Lach@motorola.com Copyright (C) The Internet Society (2004). 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. Petrescu et al. Expires July 2004 [Page 21]