--- 1/draft-ietf-roll-security-threats-03.txt 2013-09-05 06:14:24.666458379 -0700 +++ 2/draft-ietf-roll-security-threats-04.txt 2013-09-05 06:14:24.754460583 -0700 @@ -1,134 +1,138 @@ -Networking Working Group T. Tsao +Routing Over Low-Power and Lossy Networks T. Tsao Internet-Draft R. Alexander Intended status: Informational Cooper Power Systems -Expires: December 27, 2013 M. Dohler +Expires: March 08, 2014 M. Dohler CTTC V. Daza A. Lozano Universitat Pompeu Fabra - June 25, 2013 + M. Richardson + Sandelman Software Works + September 04, 2013 A Security Threat Analysis for Routing over Low-Power and Lossy Networks - draft-ietf-roll-security-threats-03 + draft-ietf-roll-security-threats-04 Abstract This document presents a security threat analysis for routing over low-power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. These assessments provide the basis of the security recommendations for incorporation into low-power, lossy network routing protocols. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on December 27, 2013. + + This Internet-Draft will expire on March 08, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 6 - 3.1. Routing Assets and Points of Access . . . . . . . . . . . 7 - 3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 9 - 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 11 - 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 12 - 4. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . . 14 - 5. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 14 - 5.1. Threats due to failures to Authenticate . . . . . . . . . 14 - 5.2. Threats due to failures to Authenticate . . . . . . . . . 14 - 5.3. Threats and Attacks on Confidentiality . . . . . . . . . . 14 - 5.3.1. Routing Exchange Exposure . . . . . . . . . . . . . . 15 - 5.3.2. Routing Information (Routes and Network Topology) - Exposure . . . . . . . . . . . . . . . . . . . . . . . 15 - 6. Threats and Attacks on Integrity . . . . . . . . . . . . . . . 16 - 6.1. Routing Information Manipulation . . . . . . . . . . . . . 16 - 6.2. Node Identity Misappropriation . . . . . . . . . . . . . . 17 - 7. Threats and Attacks on Availability . . . . . . . . . . . . . 17 - 7.1. Routing Exchange Interference or Disruption . . . . . . . 17 - 7.2. Network Traffic Forwarding Disruption . . . . . . . . . . 18 - 7.3. Communications Resource Disruption . . . . . . . . . . . . 19 - 7.4. Node Resource Exhaustion . . . . . . . . . . . . . . . . . 20 - 8. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 20 - 8.1. Confidentiality Attack Countermeasures . . . . . . . . . . 21 - 8.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 21 - 8.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 21 - 8.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 22 - 8.1.4. Countering Physical Device Compromise . . . . . . . . 23 - 8.1.5. Countering Remote Device Access Attacks . . . . . . . 25 - 8.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 26 - 8.2.1. Countering Unauthorized Modification Attacks . . . . . 26 - 8.2.2. Countering Overclaiming and Misclaiming Attacks . . . 26 - 8.2.3. Countering Identity (including Sybil) Attacks . . . . 27 - 8.2.4. Countering Routing Information Replay Attacks . . . . 27 - 8.2.5. Countering Byzantine Routing Information Attacks . . . 27 - 8.3. Availability Attack Countermeasures . . . . . . . . . . . 28 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 4 + 3.1. Routing Assets and Points of Access . . . . . . . . . . . 5 + 3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 7 + 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 8 + 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . 10 + 4. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 12 + 5. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. Threats due to failures to Authenticate . . . . . . . . . 12 + 5.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 12 + 5.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 13 + 5.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 13 + 5.2. Threats and Attacks on Confidentiality . . . . . . . . . 13 + 5.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 13 + 5.2.2. Routing Information (Routes and Network Topology) + Exposure . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Threats and Attacks on Integrity . . . . . . . . . . . . . . 14 + 6.1. Routing Information Manipulation . . . . . . . . . . . . 14 + 6.2. Node Identity Misappropriation . . . . . . . . . . . . . 15 + 7. Threats and Attacks on Availability . . . . . . . . . . . . . 15 + 7.1. Routing Exchange Interference or Disruption . . . . . . . 16 + 7.2. Network Traffic Forwarding Disruption . . . . . . . . . . 16 + 7.3. Communications Resource Disruption . . . . . . . . . . . 17 + 7.4. Node Resource Exhaustion . . . . . . . . . . . . . . . . 17 + 8. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 18 + 8.1. Confidentiality Attack Countermeasures . . . . . . . . . 18 + 8.1.1. Countering Deliberate Exposure Attacks . . . . . . . 19 + 8.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 19 + 8.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 20 + 8.1.4. Countering Remote Device Access Attacks . . . . . . . 21 + 8.2. Integrity Attack Countermeasures . . . . . . . . . . . . 21 + 8.2.1. Countering Unauthorized Modification Attacks . . . . 22 + 8.2.2. Countering Overclaiming and Misclaiming Attacks . . . 22 + 8.2.3. Countering Identity (including Sybil) Attacks . . . . 22 + 8.2.4. Countering Routing Information Replay Attacks . . . . 23 + 8.2.5. Countering Byzantine Routing Information Attacks . . 23 + 8.3. Availability Attack Countermeasures . . . . . . . . . . . 24 8.3.1. Countering HELLO Flood Attacks and ACK Spoofing - Attacks . . . . . . . . . . . . . . . . . . . . . . . 29 - 8.3.2. Countering Overload Attacks . . . . . . . . . . . . . 30 - 8.3.3. Countering Selective Forwarding Attacks . . . . . . . 31 - 8.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 32 - 8.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 33 - 9. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 33 - 9.1. Confidentiality Features . . . . . . . . . . . . . . . . . 34 - 9.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 35 - 9.3. Availability Features . . . . . . . . . . . . . . . . . . 36 - 9.4. Key Management . . . . . . . . . . . . . . . . . . . . . . 37 - 9.5. Consideration on Matching Application Domain Needs . . . . 38 - 9.5.1. Security Architecture . . . . . . . . . . . . . . . . 38 - 9.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 41 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 + Attacks . . . . . . . . . . . . . . . . . . . . . . . 24 + 8.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 + 8.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 + 8.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 28 + 8.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 29 + 9. ROLL Security Features . . . . . . . . . . . . . . . . . . . 29 + 9.1. Confidentiality Features . . . . . . . . . . . . . . . . 30 + 9.2. Integrity Features . . . . . . . . . . . . . . . . . . . 31 + 9.3. Availability Features . . . . . . . . . . . . . . . . . . 32 + 9.4. Key Management . . . . . . . . . . . . . . . . . . . . . 33 + 9.5. Consideration on Matching Application Domain Needs . . . 34 + 9.5.1. Security Architecture . . . . . . . . . . . . . . . . 34 + 9.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 37 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 40 + 13.2. Informative References . . . . . . . . . . . . . . . . . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction In recent times, networked electronic devices have found an increasing number of applications in various fields. Yet, for reasons ranging from operational application to economics, these wired and wireless devices are often supplied with minimum physical resources; the constraints include those on computational resources (RAM, clock speed, storage), communication resources (duty cycle, packet size, etc.), but also form factors that may rule out user @@ -136,91 +140,69 @@ simply safety considerations (e.g., with gas meters). As a consequence, the resulting networks are more prone to loss of traffic and other vulnerabilities. The proliferation of these low-power and lossy networks (LLNs), however, are drawing efforts to examine and address their potential networking challenges. Securing the establishment and maintenance of network connectivity among these deployed devices becomes one of these key challenges. This document presents a threat analysis for securing Routing Over LLNs (ROLL) through an analysis that starts from the routing basics. - The objective is two-fold. First, the analysis will be used to - identify pertinent security issues. Second, it will facilitate both - the assessment of a protocol's security threats and the - identification of necessary countermeasures to secure the ROLL - protocols. The approach adopted is a five step process, 1) examine - security issues in ROLL, 2) describe the threat sources, 3) analyze - threats and attacks, 4) consider countermeasures, and 5) provide - recommendations for securing ROLL. + The process requires two steps. First, the analysis will be used to + identify pertinent security issues. The second step is to identify + necessary countermeasures to secure the ROLL protocols. As there are + multiple ways to solve the problem and the specific tradeoffs are + deployment specific, the specific countermeasure to be used is + detailed in applicatbility statements. This document uses [IS07498-2] model, which includes Authentication, Access Control, Data Confidentiality, Data Integrity, and Non- Repudiation but to which Availability is added. - spt: If this is just about control plane security then we should say - so right up front. + All of this document concerns itself with control plane traffic only. 2. Terminology - This document adopts the terminology defined in [RFC6550] and in - [RFC4949], with the following addition: - - Control Sequence Control plane: Supports routing and management - functions. - - Data Plane Data plane: See Forwarding plane. - - Data Plane Forwarding plane: Responsible for receiving a packet on - an incoming interface, performing a lookup to identify the - packet's next hop and determine the best outgoing interface - towards the destination, and forwarding the packet out through - the appropriate outgoing interface. - - Node An element of a low-power, lossy network that may be a router - or a host. - - Sleepy Node A sleepy node is a Node that may sometimes go into a - sleep mode (i.e. go into a low power state to conserve power) - and temporarily suspends communication but that is immediately - available. + This document adopts the terminology defined in [RFC6550], in + [RFC4949], and in [I-D.ietf-roll-terminology]. 3. Considerations on ROLL Security Routing security, in essence, ensures that the routing protocol operates correctly. It entails implementing measures to ensure controlled state changes on devices and network elements, both based on external inputs (received via communications) or internal inputs (physical security of device itself and parameters maintained by the device, including, e.g., clock). State changes would thereby involve not only authorization of injector's actions, authentication of - injectors, authentication, integrity, and potentially confidentiality - of routing data, but also proper order of state changes through - timeliness, since seriously delayed state changes, such as commands - or updates of routing tables, may negatively impact system operation. - A security assesment can therefore begin with a focus on the - assetsRFC4949 [RFC4949]that may be the target of the state changes - and the access points in terms of interfaces and protocol exchanges - through which such changes may occur. In the case of routing - security the focus is directed towards the elements associated with - the establishment and maintenance of network connectivity. + injectors, and potentially confidentiality of routing data, but also + proper order of state changes through timeliness, since seriously + delayed state changes, such as commands or updates of routing tables, + may negatively impact system operation. A security assesment can + therefore begin with a focus on the assets [RFC4949] that may be the + target of the state changes and the access points in terms of + interfaces and protocol exchanges through which such changes may + occur. In the case of routing security the focus is directed towards + the elements associated with the establishment and maintenance of + network connectivity. This section sets the stage for the development of the analysis by applying the systematic approach proposed in [Myagmar2005] to the routing security, while also drawing references from other reviews and assessments found in the literature, particularly, [RFC4593] and [Karlof2003]. The subsequent subsections begin with a focus on the elements of a generic routing process that is used to establish routing assets and points of access to the routing functionality. - Next, the ISO 7498-2 security model is briefly described. Then, - consideration is given to issues specific to or amplified in LLNs. - This section concludes with the formulation of a set of security - objectives for ROLL. + Next, the [ISO.7498-2.1988] security model is briefly described. + Then, consideration is given to issues specific to or amplified in + LLNs. This section concludes with the formulation of a set of + security objectives for ROLL. 3.1. Routing Assets and Points of Access An asset is an important system resource (including information, process, or physical resource), the access to, corruption or loss of which adversely affects the system. In the control plane context, an asset is information about the network, processes used to manage and manipulate this data, and the physical devices on which this data is stored and manipulated. The corruption or loss of these assets may adversely impact the control plane of the network. Within the same @@ -317,35 +299,34 @@ general and applied to ROLL in particular is concerned with the primary issues of authentication, access control, data confidentiality, data integrity, and non-repudiation. In the context of ROLL Authentication Authentication involves the mutual authentication of the routing peers prior to exchanging route information (i.e., peer authentication) as well as ensuring that the source of the route data is from the peer (i.e., data origin authentication). - From 5478 LLNs can be drained by unauthenticated peers before - confirguratin From 5673 This requires availability of open and - untrusted side channels for new joiners, and it requires strong - and automated authentication so that networks can automatically - accept or reject new joiners. spt: Do we need more here? + [RFC5548] points out that LLNs can be drained by + unauthenticated peers before configuration. [RFC5673] requires + availability of open and untrusted side channels for new + joiners, and it requires strong and automated authentication so + that networks can automatically accept or reject new joiners. Access Control Access Control provides protection against unauthorized use of the asset, and deals with the authorization of a node. Confidentiality Confidentiality involves the protection of routing information as well as routing neighbor maintenance exchanges so that only authorized and intended network entities may view or access it. - Because LLNs are most commonly found on a publicly accessible shared medium, e.g., air or wiring in a building, and sometimes formed ad hoc, confidentiality also extends to the neighbor state and database information within the routing device since the deployment of the network creates the potential for unauthorized access to the physical devices themselves. Integrity Integrity entails the protection of routing information and routing neighbor maintenance exchanges, as well as derived @@ -354,21 +335,21 @@ beyond the routing protocol. Non-repudiation Non-repudiation is the assurance that the transmission and/or reception of a message cannot later be denied. The service of non-repudiation applies after-the-fact and thus relies on the logging or other capture of on-going message exchanges and signatures. Applied to routing, non-repudiation is not an issue because it does not apply to routing protocols, which are machine-to-machine protocols. Further, with the LLN - application domains as described in RFC5548 [RFC5867], + application domains as described in [RFC5867] and [RFC5548], proactive measures are much more critical than retrospective protections. Finally, given the significant practical limits to on-going routing transaction logging and storage and individual device digital signature verification for each exchange, non-repudiation in the context of routing is an unsupportable burden that bears no further considered as a ROLL security issue. It is recognized that, besides those security issues captured in the ISO 7498-2 model, availability, is a security requirement: @@ -399,27 +379,28 @@ Limited energy, memory, and processing node resources As a consequence of these constraints, there is an even more critical need than usual for a careful study of trade-offs on which and what level of security services are to be afforded during the system design process. The chosen security mechanisms also needs to work within these constraints. Synchronization of security states with sleepy nodes is yet another issue. Large scale of rolled out network - The possibly numerous nodes to be deployed, e.g., an urban - deployment can see several hundreds of thousands of nodes, as - well as the generally low level of expertise expected of the - installers, make manual on-site configuration unlikely. - Prolonged rollout and delayed addition of nodes, which may be - from old inventory, over the lifetime of the network, also - complicate the operations of key management. + The possibly numerous nodes to be deployed make manual on-site + configuration unlikely. For example, an urban deployment can + see several hundreds of thousands of nodes being installed by + many installers with a low level of expertise. Nodes may be + installed and not activated for many years, and additional + nodes may be added later on, which may be from old inventory. + The lifetime of the network is measured in decades, and this + complicates the operation of key management. Autonomous operations Self-forming and self-organizing are commonly prescribed requirements of LLNs. In other words, a routing protocol designed for LLNs needs to contain elements of ad hoc networking and in most cases cannot rely on manual configuration for initialization or local filtering rules. Network topology/ownership changes, partitioning or merging, as well as node replacement, can all contribute to complicating the operations of key management. @@ -436,27 +417,32 @@ can cause serious damage. Unattended locations and limited physical security Many applications have the nodes deployed in unattended or remote locations; furthermore, the nodes themselves are often built with minimal physical protection. These constraints lower the barrier of accessing the data or security material stored on the nodes through physical means. Support for mobility - On the one hand, only a number of applications require the - support of mobile nodes, e.g., a home LLN that includes nodes - on wearable health care devices or an industry LLN that + On the one hand, only a limited number of applications require + the support of mobile nodes, e.g., a home LLN that includes + nodes on wearable health care devices or an industry LLN that includes nodes on cranes and vehicles. On the other hand, if a routing protocol is indeed used in such applications, it will clearly need to have corresponding security mechanisms. + Additionally nodes may appear to move from one side of a wall + to another without any actual motion involved, the result of + changes to electromagnetic properties, such as opening and + closing of a metal door. + Support for multicast and anycast Support for multicast and anycast is called out chiefly for large-scale networks. Since application of these routing mechanisms in autonomous operations of many nodes is new, the consequence on security requires careful consideration. The above list considers how an LLN's physical constraints, size, operations, and variety of application areas may impact security. However, it is the combinations of these factors that particularly stress the security concerns. For instance, securing routing for a @@ -525,22 +511,22 @@ Each individual system's use and environment will dictate how the above objectives are applied, including the choices of security services as well as the strengths of the mechanisms that must be implemented. The next two sections take a closer look at how the ROLL security objectives may be compromised and how those potential compromises can be countered. 4. Threat Sources - provides a detailed review of the threat sources: outsiders and - byzantine. ROLL has the same threat sources. [RFC4593] + [RFC4593] provides a detailed review of the threat sources: outsiders + and byzantine. ROLL has the same threat sources. 5. Threats and Attacks This section outlines general categories of threats under the ISO 7498-2 model and highlights the specific attacks in each of these categories for ROLL. As defined in [RFC4949], a threat is "a potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm." @@ -550,54 +536,82 @@ security services and violate the security policy of a system." The subsequent subsections consider the threats and the attacks that can cause security breaches under the ISO 7498-2 model to the routing assets and via the routing points of access identified in Section 3.1. The assessment steps through the security concerns of each routing asset and looks at the attacks that can exploit routing points of access. The threats and attacks identified are based on the routing model analysis and associated review of the existing literature. The source of the attacks is assumed to be from either - inside or outside attackers Section 4, whose capabilities may be - limited to node-equivalent or more sophisticated computing platforms. + inside or outside attackers. The capability these attackes may be + limited to node-equivalent, but also to more sophisticated computing + platforms. 5.1. Threats due to failures to Authenticate -5.2. Threats due to failures to Authenticate +5.1.1. Node Impersonation -5.3. Threats and Attacks on Confidentiality + If an attacker can join a network with any identify, then it may be + able to assume the role of a legitimate (and existing node). It may + be able to report false readings (in metering applications), or + provide inappropriate control messages (in control systems involving + actuators) if the security of the application is leveraged from the + security of the routing system. + + In other systems where there is separate application layer security, + the ability to impersonate a node would permit an attacker to direct + traffic to itself, which facilitates on-path attacks including + replaying, delaying, or duplicating control messages. + +5.1.2. Dummy Node + + If an attacker can join a network with any identify, then it can + pretend to be a legitimate node, receiving any service legitimate + nodes receive. It may also be able to report false readings (in + metering applications), or provide inappropriate authorizations (in + control systems involving actuators), or perform any other attacks + that are facilitated by being able to direct traffic towards itself. + +5.1.3. Node Resource Spam + + If an attacker can join a network with any identify, then it can + continously do so, draining down the resources of the network to + store identity and routing information, potentionally forcing + legitimate nodes of the network. + +5.2. Threats and Attacks on Confidentiality The assessment in Section 3.2 indicates that there are threat actions against the confidentiality of routing information at all points of access. The confidentiality threat consequences is disclosure, see Section 3.1.2 of [RFC4593]. For ROLL this is the disclosure of routing information either by evesdropping on the communication exchanges between routing nodes or by direct access of node's information. -5.3.1. Routing Exchange Exposure +5.2.1. Routing Exchange Exposure Routing exchanges include both routing information as well as information associated with the establishment and maintenance of neighbor state information. As indicated in Section 3.1, the associated routing information assets may also include device specific resource information, such as memory, remaining power, etc., that may be metrics of the routing protocol. The routing exchanges will contain reachability information, which would identify the relative importance of different nodes in the network. Nodes higher up in the DODAG, to which more streams of information flow, would be more interesting targets for other attacks, and routing exchange exposures can identify them. -5.3.2. Routing Information (Routes and Network Topology) Exposure - +5.2.2. Routing Information (Routes and Network Topology) Exposure Routes (which may be maintained in the form of the protocol forwarding table) and neighbor topology information are the products of the routing process that are stored within the node device databases. The exposure of this information will allow attachers to gain direct access to the configuration and connectivity of the network thereby exposing routing to targeted attacks on key nodes or links. Since routes and neighbor topology information is stored within the node device, threats or attacks on the confidentiality of the information @@ -715,57 +729,58 @@ undermine the central function of network routers and the ability to handle user traffic. This affects the availability of the network because of the potential to impair the primary capability of the network. In addition to physical layer obstructions, the forms of attack that allows disruption of network traffic forwarding include [Karlof2003] o Selective forwarding attacks; - o Wormhole attacks; - - o Sinkhole attacks. - - For reference, Figure 2 depicts the above listed three types of - attacks. - |Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2| (a) Selective Forwarding + Figure 2: Selective Forwarding + + o Wormhole attacks; + |Node_1|-------------Unreachable---------x|Node_2| | ^ | Private Link | '-->|Attacker_1|===========>|Attacker_2|--' (b) Wormhole + Figure 3: Wormhole Attacks + + o Sinkhole attacks. + |Node_1| |Node_4| | | `--------. | Falsify as \ | Good Link \ | | To Node_5 \ | | \ V V |Node_2|-->|Attacker|--Not Forwarded---x|Node_5| ^ ^ \ | | \ Falsify as | | \Good Link / | To Node_5 ,-------' | | | |Node_3| |Node_i| (c) Sinkhole - Figure 2: Selective Forwarding, Wormhole, and Sinkhole Attacks + Figure 4: Selective Forwarding, Wormhole, and Sinkhole Attacks 7.3. Communications Resource Disruption Attacks mounted against the communication channel resource assets needed by the routing protocol can be used as a means of disrupting its operation. However, while various forms of Denial of Service (DoS) attacks on the underlying transport subsystem will affect routing protocol exchanges and operation (for example physical layer RF jamming in a wireless network or link layer attacks), these attacks cannot be countered by the routing protocol. As such, the @@ -853,26 +867,21 @@ Note that the same measures which apply to securing routing/topology exchanges between operational nodes must also extend to field tools and other devices used in a deployed network where such devices can be configured to participate in routing exchanges. 8.1.2. Countering Sniffing Attacks A sniffing attack seeks to breach routing confidentiality through passive, direct analysis and processing of the information exchanges - between nodes. A sniffing attack in an LLN that is not based on a - physical device compromise will rely on the attacker attempting to - directly derive information from the over-the-shared-medium routing/ - topology communication exchange (neighbor discovery exchanges may of - necessity be conducted in the clear thus limiting the extent to which - the information can be kept confidential). + between nodes. Sniffing attacks can be directly countered through the use of data encryption for all routing exchanges. Only when a validated and authenticated node association is completed will routing exchange be allowed to proceed using established session keys and an agreed encryption algorithm. The strength of the encryption algorithm and session key sizes will determine the minimum requirement for an attacker mounting this passive security attack. The possibility of incorporating options for security level and algorithms is further considered in Section 9.5. Because of the resource constraints of @@ -894,162 +903,69 @@ routing protection. This session key shall be applied in conjunction with an encryption algorithm that has been publicly vetted and where applicable approved for the level of security desired. Algorithms such as the Advanced Encryption Standard (AES) [FIPS197], adopted by the U.S. government, or Kasumi-Misty [Kasumi3gpp], adopted by the 3GPP 3rd generation wireless mobile consortium, are examples of symmetric-key algorithms capable of ensuring robust confidentiality for routing exchanges. The key length, algorithm and mode of operation will be selected as part of the overall security trade-off that also achieves a balance with the level of confidentiality - afforded by the physical device in protecting the routing assets (see - Section 8.1.4 below). + afforded by the physical device in protecting the routing assets. As with any encryption algorithm, the use of ciphering synchronization parameters and limitations to the usage duration of established keys should be part of the security specification to reduce the potential for brute force analysis. 8.1.3. Countering Traffic Analysis Traffic analysis provides an indirect means of subverting confidentiality and gaining access to routing information by allowing an attacker to indirectly map the connectivity or flow patterns (including link-load) of the network from which other attacks can be mounted. The traffic analysis attack on an LLN, especially one founded on shared medium, is passive and relies on the ability to - read the immutable source/destination routing information that must - remain unencrypted to permit network routing. Alternatively, attacks - can be mounted through the injection of unauthorized discovery - traffic into the network. By implementing authentication measures - between communicating nodes, active traffic analysis attacks can be - prevented within the LLN thereby reducing confidentiality - vulnerabilities to those associated with passive analysis. + read the immutable source/destination layer-3 routing information + that must remain unencrypted to permit network routing. + + Alternatively, attacks can be mounted through the injection of + unauthorized discovery traffic into the network. By implementing + authentication measures between communicating nodes, active traffic + analysis attacks can be prevented within the LLN thereby reducing + confidentiality vulnerabilities to those associated with passive + analysis. One way in which passive traffic analysis attacks can be muted is through the support of load balancing that allows traffic to a given destination to be sent along diverse routing paths. Where the routing protocol supports load balancing along multiple links at each node, the number of routing permutations in a wide area network - surges thus increasing the cost of traffic analysis. Network - analysis through this passive attack will require a wider array of - analysis points and additional processing on the part of the - attacker. Note however that where network traffic is dispersed as a - countermeasure there may be implications beyond routing with regard - to general traffic confidentiality. Another approach to countering - passive traffic analysis could be for nodes to maintain constant - amount of traffic to different destinations through the generation of - arbitrary traffic flows; the drawback of course would be the - consequent overhead. In LLNs, the diverse radio connectivity and - dynamic links (including potential frequency hopping), or a complex - wiring system hidden from sight, will help to further mitigate - traffic analysis attacks when load balancing is also implemented. + surges thus increasing the cost of traffic analysis. ROLL does not + generally support multi-path routing within a single DODAG. Multiple + DODAGs are supported in the protocol, but few deployments will have + space for more than half a dozen, and there are at present no clear + ways to multiplex traffic for a single application across multiple + DODAGs. + + Another approach to countering passive traffic analysis could be for + nodes to maintain constant amount of traffic to different + destinations through the generation of arbitrary traffic flows; the + drawback of course would be the consequent overhead. The only means of fully countering a traffic analysis attack is through the use of tunneling (encapsulation) where encryption is applied across the entirety of the original packet source/destination - addresses. With tunneling there is a further requirement that the - encapsulating intermediate nodes apply an additional layer of routing - so that traffic arrives at the destination through dynamic routes. - For some LLNs, memory and processing constraints as well as the - limitations of the communication channel will preclude both the - additional routing traffic overhead and the node implementation - required for tunneling countermeasures to traffic analysis. - -8.1.4. Countering Physical Device Compromise - - Section 5 identified that many threats to the routing functionality - may involve compromised devices. For the sake of completeness, this - subsection examines how to counter physical device compromise, - without restricting the consideration to only those methods and - apparatuses available to an LLN routing protocol. - - Given the distributed nature of LLNs and the varying environment of - deployed devices, confidentiality of routing assets and points of - access may rely heavily on the security of the routing devices. One - means of precluding attacks on the physical device is to prevent - physical access to the node through other external security means. - However, given the environment in which many LLNs operate, preventing - unauthorized access to the physical device cannot be assured. - Countermeasures must therefore be employed at the device and - component level so that routing/topology or neighbor information and - stored route information cannot be accessed even if physical access - to the node is obtained. - - With the physical device in the possession of an attacker, - unauthorized information access can be attempted by probing internal - interfaces or device components. Device security must therefore move - to preventing the reading of device processor code or memory - locations without the appropriate security keys and in preventing the - access to any information exchanges occurring between individual - components. Information access will then be restricted to external - interfaces in which confidentiality, integrity, and authentication - measures can be applied. - - To prevent component information access, deployed routing devices - must ensure that their implementation avoids address or data buses - being connected to external general purpose input/output (GPIO) pins. - Beyond this measure, an important component interface to be protected - against attack is the Joint Test Action Group (JTAG) [IEEE1149.1] - interface used for component and populated circuit board testing - after manufacture. To provide security on the routing devices, - components should be employed that allow fuses on the JTAG interfaces - to be blown to disable access. This will raise the bar on - unauthorized component information access within a captured device. - - At the device level a key component information exchange is between - the microprocessor and its associated external memory. While - encryption can be implemented to secure data bus exchanges, the use - of integrated physical packaging which avoids inter-component - exchanges (other than secure external device exchanges) will increase - routing security against a physical device interface attack. With an - integrated package and disabled internal component interfaces, the - level of physical device security can be controlled by managing the - degree to which the device packaging is protected against expert - physical decomposition and analysis. - - The device package should be hardened such that attempts to remove - the integrated components will result in damage to access interfaces, - ports or pins that prevent retrieval of code or stored information. - The degree of Very Large Scale Integration (VLSI) or Printed Circuit - Board (PCB) package security through manufacture can be selected as a - trade-off or desired security consistent with the level of security - achieved by measures applied for other routing assets and points of - access. With package hardening and restricted component access - countermeasures, the security level will be raised to that provided - by measures employed at the external communications interfaces. - - Another area of node interface vulnerability is that associated with - interfaces provided for remote software or firmware upgrades. This - may impact both routing information and routing/topology exchange - security where it leads to unauthorized upgrade or change to the - routing protocol running on a given node as this type of attack can - allow for the execution of compromised or intentionally malicious - routing code on multiple nodes. Countermeasures to this device - interface confidentiality attack needs to be addressed in the larger - context of node remote access security. This will ensure not only - the authenticity of the provided code (including routing protocol) - but that the process is initiated by an authorized (authenticated) - entity. For example, digital signing of firmware by an authorized - entity will provide an appropriate countermeasure. - - The above identified countermeasures against attacks on routing - information confidentiality through internal device interface - compromise must be part of the larger LLN system security as they - cannot be addressed within the routing protocol itself. Similarly, - the use of field tools or other devices that allow explicit access to - node information must implement security mechanisms to ensure that - routing information can be protected against unauthorized access. - These protections will also be external to the routing protocol and - hence not part of ROLL. + addresses. Deployments which use layer-2 security that includes + encryption already do this for all traffic. -8.1.5. Countering Remote Device Access Attacks +8.1.4. Countering Remote Device Access Attacks Where LLN nodes are deployed in the field, measures are introduced to allow for remote retrieval of routing data and for software or field upgrades. These paths create the potential for a device to be remotely accessed across the network or through a provided field tool. In the case of network management a node can be directly requested to provide routing tables and neighbor information. To ensure confidentiality of the node routing information against attacks through remote access, any local or remote device requesting @@ -1181,23 +1097,21 @@ implementation of this type of dedicated routing protocol security where the correctness of aggregate distance vector information can only be validated by initiating confirmation exchanges directly between nodes that are not routing neighbors. Alternatively, an entity external to the routing protocol would be required to collect and audit routing information exchanges to detect the Byzantine attack. In the context of the current security analysis, any protection against Byzantine routing information attacks will need to be directly included within the mechanisms of - the ROLL routing protocol. This can be implemented where such an - attack is considered relevant even within the physical device - protections discussed in Section 8.1.4. + the ROLL routing protocol. 8.3. Availability Attack Countermeasures As alluded to before, availability requires that routing information exchanges and forwarding mechanisms be available when needed so as to guarantee proper functioning of the network. This may, e.g., include the correct operation of routing information and neighbor state information exchanges, among others. We will highlight the key features of the security threats along with typical countermeasures to prevent or at least mitigate them. We will also note that an @@ -1322,22 +1235,28 @@ feasible, certificates should be validated prior to use of the associated keys to counter potential resource overloading attacks. The associated design decision needs to also consider that the validation process requires resources and thus itself could be exploited for attacks. Alternatively, resource management limits can be placed on routing security processing events (see the comment in Section 6, paragraph 4, of [RFC5751]). 8.3.3. Countering Selective Forwarding Attacks - Selective forwarding attacks are another form of DoS attack which - impacts the routing path availability. + Selective forwarding attacks are a form of DoS attack which impacts + the availability of the generated routing paths. + + A selective forwarding attack may be done by a node involved with the + routing process, or it may be done by what otherwise appears to be a + passive antenna or other RF feature or device, but is in fact an + active (and selective) device. An RF antenna/repeater which is not + selective, is not a threat. An insider malicious node basically blends neatly in with the network but then may decide to forward and/or manipulate certain packets. If all packets are dropped, then this attacker is also often referred to as a "black hole". Such a form of attack is particularly dangerous if coupled with sinkhole attacks since inherently a large amount of traffic is attracted to the malicious node and thereby causing significant damage. In a shared medium, an outside malicious node would selectively jam overheard data flows, where the thus caused collisions incur selective forwarding. @@ -1468,21 +1387,21 @@ resistance commensurate with the particular application domain environment to ensure the confidentiality, integrity, and availability of stored routing information. 9.1. Confidentiality Features With regard to confidentiality, protecting the routing/topology information from unauthorized disclosure is not directly essential to maintaining the routing function. Breaches of confidentiality may lead to other attacks or the focusing of an attacker's resources (see - Section 5.3) but does not of itself directly undermine the operation + Section 5.2) but does not of itself directly undermine the operation of the routing function. However, to protect against, and reduce consequences from other more direct attacks, routing information should be protected. Thus, a secured ROLL protocol: o MUST implement payload encryption; o MUST provide privacy when geographic information is used (see, e.g., [RFC3693]); o MAY provide tunneling; @@ -1533,25 +1453,24 @@ checks, change increments, and message event frequency checks, etc. as a means of countering intentional or unintentional Byzantine threats; o MAY incorporate external consistency checking and auditing of routing information to protect against intentional or unintentional Byzantine-induced network anomalies. In conjunction with the integrity protection requirements, a secured ROLL protocol SHOULD log, against the offending node, any security - failure that occurs after a valid integrity check. The record of - such failures (as may result, for example, from incorrect security - policy configuration) can provide the basis for nodes to avoid - initiating routing access to the offender or be used for further - system countermeasures in the case of potential insider attacks. All + failure that occurs after a valid integrity check. The record policy + configuration) can provide the basis for nodes to avoid initiating + routing access to the offender or be used for further system + countermeasures in the case of potential insider attacks. All integrity security failures SHOULD be logged, where feasible, but cannot be reliably considered as countering against the offending source(s). Depending on the nature of the routing protocol, e.g., distance vector or link state, additional measures may be necessary when the validity of the routing information is of concern. In the most basic form, verification of routing peer authenticity and liveliness can be used to build a "chain of trust" along the path the routing information flows, such that network-wide information is validated @@ -1574,22 +1493,22 @@ 9.3. Availability Features Availability of routing information is linked to system and network availability which in the case of LLNs require a broader security view beyond the requirements of the routing entities (see Section 9.5). Where availability of the network is compromised, routing information availability will be accordingly affected. However, to specifically assist in protecting routing availability: o MAY restrict neighborhood cardinality; - o MAY use multiple paths; + o MAY use multiple paths; o MAY use multiple destinations; o MAY choose randomly if multiple paths are available; o MAY set quotas to limit transmit or receive volume; o MAY use geographic information for flow control. 9.4. Key Management @@ -1626,40 +1545,40 @@ The use of a public key infrastructure (PKI), where feasible, can be used to support authenticated short-term key management as well as the distribution of long-term routing security keying material. Note that where the option for a PKI is supported for security of the routing protocol itself, the routing protocol MUST include provisions for public key certificates to be included or referenced within routing messages to allow a node's public key to be shared with communicating peers. Even if the certificate itself is not distributed by the node, there needs to be a mechanism to inform the receiving node where to find the certificate and obtain associated - validation information; see [RFC3029] for an example of the kind of + validation information; see [RFC5055] for an example of the kind of localized PKI support that may be applied in a given LLN environment. Where PKI systems are not feasible, the key management system MUST support means for secure configuration, device authentication, and adherence to secure key wrapping principles for the secure distribution and update of device keys. LLN routing protocols SHOULD be designed to allow the use of existing and validated key management schemes. As part of the LLN optimization, these schemes may be independent of the routing protocol and part of the broader LLN system security specifications. Where the long-term key management is defined separately from the routing protocol security, LLN application domains can appropriately employ IETF-standard key management specifications. Established key management solutions such as IKEv2 [RFC5996] or MIKEY [RFC3830], - which supports several alternative private, public, or Diffie-Hellman - key distribution methods (see [RFC5197]), can thus be adapted for use - in LLNs. For example, see [I-D.alexander-roll-mikey-lln-key-mgmt]. - Group key management and distribution methods may also be developed - based on the architecture principles defined in MSEC [RFC4046]. + which supports several alternative private, public key distributions + methods (see [RFC5197]), can thus be adapted for use in LLNs. For + example, see [I-D.alexander-roll-mikey-lln-key-mgmt]. Group key + management and distribution methods may also be developed based on + the architecture principles defined in MSEC [RFC4046]. 9.5. Consideration on Matching Application Domain Needs Providing security within an LLN requires considerations that extend beyond routing security to the broader LLN application domain security implementation. In other words, as routing is one component of an LLN system, the actual strength of the implemented security algorithms for the routing protocol MUST be made to conform to the system's target level of security. The development so far takes into account collectively the impacts of the issues gathered from @@ -1822,21 +1740,21 @@ There are other factors which are not part of a ROLL routing protocol but which can still affect its operation. These include elements such as weaker barrier to accessing the data or security material stored on the nodes through physical means; therefore, the internal and external interfaces of a node need to be adequate for guarding the integrity, and possibly the confidentiality, of stored information, as well as the integrity of routing and route generation processes. - Figure 3 provides an overview of the larger context of system + Figure 5 provides an overview of the larger context of system security and the relationship between ROLL requirements and measures and those that relate to the LLN system. Security Services for ROLL-Addressable Security Requirements | | +---+ +---+ Node_i | | Node_j _____v___ ___v_____ @@ -1860,21 +1779,21 @@ | |Entity | : +-----+----+ +----+-----+ : |Entity | | | | |-:-+ | | +-:-| | | | \________/ : | +-----+----+ +----+-----+ | : \________/ | | : +>| Physical | | Physical |<+ : | Application : +-----+----+ +----+-----+ : Application Domain User : | | : Domain User Configuration : |__Comm. Channel_| : Configuration : : ...Protocol Stack..................... - Figure 3: LLN Device Security Model + Figure 5: LLN Device Security Model 10. IANA Considerations This memo includes no request to IANA. 11. Security Considerations The analysis presented in this document provides security analysis and design guidelines with a scope limited to ROLL. Security services are identified as requirements for securing ROLL. The @@ -1888,160 +1807,180 @@ acknowledge the guidance and input provided by the ROLL Chairs, David Culler, and JP Vasseur, and the Area Director Adrian Farrel. This document started out as a combined threat and solutions document. As a result of security review, the document was split up by ROLL co-Chair Michael Richardson and security Area Director Sean Turner as it went through the IETF publication process. The solutions to the threads are application and layer-2 specific, and have therefore been moved to the relevant applicability statements. + Ines Robles kept track of the many issues that were raised during the + development of this document + 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. 13.2. Informative References - [FIPS197] "Federal Information Processing Standards Publication 197: - Advanced Encryption Standard (AES)", US National Institute - of Standards and Technology, Nov. 26 2001. + [FIPS197] , "Federal Information Processing Standards Publication + 197: Advanced Encryption Standard (AES)", US National + Institute of Standards and Technology, Nov. 26 2001. [Huang2003] Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Zhang, "Fast Authenticated Key Establishment Protocols for Self-Organizing Sensor Networks", in Proceedings of the 2nd ACM International Conference on Wireless Sensor - Networks and Applications, San Diego, CA, USA, pp. 141- - 150, Sept. 19 2003. + Networks and Applications, San Diego, CA, USA, pp. + 141-150, Sept. 19 2003. [I-D.alexander-roll-mikey-lln-key-mgmt] Alexander, R. and T. Tsao, "Adapted Multimedia Internet KEYing (AMIKEY): An extension of Multimedia Internet KEYing (MIKEY) Methods for Generic LLN Environments", draft-alexander-roll-mikey-lln-key-mgmt-04 (work in progress), September 2012. + [I-D.ietf-roll-terminology] + Vasseur, J., "Terminology in Low power And Lossy + Networks", draft-ietf-roll-terminology-04 (work in + progress), September 2010. + [I-D.suhopark-hello-wsn] Park, S., "Routing Security in Sensor Network: HELLO Flood Attack and Defense", draft-suhopark-hello-wsn-00 (work in progress), December 2005. [IEEE1149.1] - "IEEE Standard Test Access Port and Boundary Scan + , "IEEE Standard Test Access Port and Boundary Scan Architecture", IEEE-SA Standards Board, Jun. 14 2001. + [ISO.7498-2.1988] + International Organization for Standardization, + "Information Processing Systems - Open Systems + Interconnection Reference Model - Security Architecture", + ISO Standard 7498-2, 1988. + [Karlof2003] Karlof, C. and D. Wagner, "Secure routing in wireless sensor networks: attacks and countermeasures", Elsevier AdHoc Networks Journal, Special Issue on Sensor Network Applications and Protocols, 1(2):293-315, September 2003. [Kasumi3gpp] - "3GPP TS 35.202 Specification of the 3GPP confidentiality - and integrity algorithms; Document 2: Kasumi - specification", 3GPP TSG SA3, 2009. + , "3GPP TS 35.202 Specification of the 3GPP + confidentiality and integrity algorithms; Document 2: + Kasumi specification", 3GPP TSG SA3, 2009. [Messerges2003] Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, R., and E. Callaway, "Low-Power Security for Wireless Sensor Networks", in Proceedings of the 1st ACM Workshop on Security of Ad Hoc and Sensor Networks, Fairfax, VA, USA, pp. 1-11, Oct. 31 2003. [Myagmar2005] Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as a Basis for Security Requirements", in Proceedings of the Symposium on Requirements Engineering for Information - Security (SREIS'05), Paris, France, pp. 94-102, Aug - 29, 2005. + Security (SREIS'05), Paris, France, pp. 94-102, Aug 29, + 2005. [Perlman1988] Perlman, N., "Network Layer Protocols with Byzantine Robustness", MIT LCS Tech Report, 429, 1988. - [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", - RFC 1142, February 1990. + [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC + 1142, February 1990. [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. - [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, - November 1998. - - [RFC3029] Adams, C., Sylvester, P., Zolotarev, M., and R. - Zuccherato, "Internet X.509 Public Key Infrastructure Data - Validation and Certification Server Protocols", RFC 3029, - February 2001. + [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November + 1998. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005. [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. - [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- + [RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006. - [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", - RFC 4949, August 2007. + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC + 4949, August 2007. + + [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. + Polk, "Server-Based Certificate Validation Protocol + (SCVP)", RFC 5055, December 2007. [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation - Routing Requirements in Low-Power and Lossy Networks", - RFC 5826, April 2010. + Routing Requirements in Low-Power and Lossy Networks", RFC + 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, - "Internet Key Exchange Protocol Version 2 (IKEv2)", - RFC 5996, September 2010. + "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC + 5996, September 2010. + + [Szcze2008] + Szczechowiak1, P., Oliveira, L., Scott, M., Collier, M., + and R. Dahab, "NanoECC: testing the limits of elliptic + curve cryptography in sensor networks", pp. 324-328, 2008, + . [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A Secure Distance Vector Routing Protocol", in Proceedings of the 2nd International Conference on Applied Cryptography and Network Security, Yellow Mountain, China, pp. 103-119, Jun. 8-11 2004. [Wander2005] Wander, A., Gura, N., Eberle, H., Gupta, V., and S. Shantz, "Energy analysis of public-key cryptography for @@ -2086,10 +2025,17 @@ Email: vanesa.daza@upf.edu Angel Lozano Universitat Pompeu Fabra P/ Circumval.lacio 8, Oficina 309 Barcelona 08003 Spain Email: angel.lozano@upf.edu + Michael Richardson (ed) + Sandelman Software Works + 470 Dawson Avenue + Ottawa, ON K1Z5V7 + Canada + + Email: mcr+ietf@sandelman.ca