--- 1/draft-ietf-roll-security-threats-00.txt 2013-02-25 21:35:08.036041167 +0100 +++ 2/draft-ietf-roll-security-threats-01.txt 2013-02-25 21:35:08.112041716 +0100 @@ -1,35 +1,35 @@ Networking Working Group T. Tsao Internet-Draft R. Alexander Intended status: Informational Cooper Power Systems -Expires: April 8, 2013 M. Dohler +Expires: August 29, 2013 M. Dohler CTTC V. Daza A. Lozano Universitat Pompeu Fabra - October 5, 2012 + February 25, 2013 -A Security Threat Analysis for Routing over Low Power and Lossy Networks - draft-ietf-roll-security-threats-00 +A Security Threat Analysis for Routing over Low-Power and Lossy Networks + draft-ietf-roll-security-threats-01 Abstract This document presents a security threat analysis for routing over - low power and lossy networks (LLN). The development builds upon + 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 + 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. + 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 @@ -38,25 +38,25 @@ 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 April 8, 2013. + This Internet-Draft will expire on August 29, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + 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 @@ -122,119 +122,114 @@ 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 - access interface (e.g., the housing of a small stick-on switch), or + access interfaces (e.g., the housing of a small stick-on switch), or 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 + 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 framework for securing Routing Over LLNs - (ROLL) through an analysis that starts from the routing basics. The - objective is two-fold. First, the framework 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 - the necessary features for development of secure protocols for the - ROLL Working Group. + 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 the necessary features for development of secure + protocols for the ROLL Working Group. The approach adopted in this effort proceeds in four steps, to examine security issues in ROLL, to analyze threats and attacks, to consider the countermeasures, and then to make recommendations for securing ROLL. The basis is found on identifying the assets and points of access of routing and evaluating their security needs based on the Confidentiality, Integrity, and Availability (CIA) model in the context of LLN. 2. Terminology This document adopts the terminology defined in [RFC6550] and in [RFC4949], with the following addition: - Node An element of a low power lossy network that may be a router or - a host. + Node An element of a low-power, lossy network that may be a router + or a host. 3. Considerations on ROLL Security Security, in essence, 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 - proper authorization for actions, authentication, and potentially - confidentiality, 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 assessment can therefore begin with a focus - on the assets or elements of information 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. + not only proper authorization for actions, authentication, and + potentially integrity and confidentiality, 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 assessment can + therefore begin with a focus on the assets or elements of information + 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 framework by + This section sets the stage for the development of the analysis by applying the systematic approach proposed in [Myagmar2005] to the routing security problem, while also drawing references from other reviews and assessments found in the literature, particularly, [RFC4593] and [Karlof2003]; thus, the work presented herein may find use beyond routing for LLNs. 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 CIA 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 implies an important system component (including information, process, or physical resource), the access to, - corruption or loss of which adversely affects the system. In network - routing, assets lie in the routing information, routing process, and - node's physical resources. That is, the access to, corruption, or - loss of these elements adversely affects system routing. In network - routing, a point of access refers to the point of entry facilitating - communication with or other interaction with a system component in - order to use system resources to either manipulate information or - gain knowledge of the information contained within the system. - Security of the routing protocol must be focused on the assets of the - routing nodes and the points of access of the information exchanges - and information storage that may permit routing compromise. The - identification of routing assets and points of access hence provides - a basis for the identification of associated threats and attacks. + 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 context, a point of access is an interface + or protocol that facilitates interaction between control plane + components. Identifying these assets and points of access will + provide a basis for enumerating the attack surface of the control + plane. - This subsection identifies assets and points of access of a generic - routing process with a level-0 data flow diagram [Yourdon1979] - revealing how the routing protocol interacts with its environment. - In particular, the use of the data flow diagram allows for a clear, - concise model of the routing functionality; it also has the benefit - of showing the manner in which nodes participate in the routing - process, thus providing context when later threats and attacks are - considered. The goal of the model is to be as detailed as possible - so that corresponding components and mechanisms in an individual - routing protocol can be readily identified, but also to be as general - as possible to maximize the relevancy of this effort for the various - existing and future protocols. Nevertheless, there may be - discrepancies, likely in the form of additional elements, when the - model is applied to some protocols. For such cases, the analysis - approach laid out in this document should still provide a valid and - illustrative path for their security assessment. + A level-0 data flow diagram [Yourdon1979] is used here to identify + the assets and points of access within a generic routing process. + The use of a data flow diagram allows for a clear and concise model + of the way in which routing nodes interact and process information, + and hence provides a context for threats and attacks. The goal of + the model is to be as detailed as possible so that corresponding + components and mechanisms in an individual routing protocol can be + readily identified, but also to be as general as possible to maximize + the relevancy of this effort for the various existing and future + protocols. Nevertheless, there may be discrepancies, likely in the + form of additional elements, when the model is applied to some + protocols. For such cases, the analysis approach laid out in this + document should still provide a valid and illustrative path for their + security assessment. Figure 1 shows that nodes participating in the routing process transmit messages to discover neighbors and to exchange routing information; routes are then generated and stored, which may be maintained in the form of the protocol forwarding table. The nodes use the derived routes for making forwarding decisions. ................................................... : : : : @@ -287,22 +282,22 @@ * neighbor discovery; * route/topology exchange; * node physical interfaces (including access to data storage). A focus on the above list of assets and points of access enables a more directed assessment of routing security; for example, it is readily understood that some routing attacks are in the form of attempts to misrepresent routing topology. Indeed, the intention of - the security framework is to be comprehensive. Hence, some of the - discussion which follows is associated with assets and points of + the security threat analysis is to be comprehensive. Hence, some of + the discussion which follows is associated with assets and points of access that are not directly related to routing protocol design but nonetheless provided for reference since they do have direct consequences on the security of routing. 3.2. The CIA Security Reference Model At the conceptual level, security within an information system in general and applied to ROLL in particular is concerned with the primary issues of confidentiality, integrity, and availability. In the context of ROLL: @@ -407,21 +402,21 @@ Highly directional traffic Some types of LLNs see a high percentage of their total traffic traverse between the nodes and the LLN Border Routers (LBRs) where the LLNs connect to non-LLNs. The special routing status of and the greater volume of traffic near the LBRs have routing security consequences. In fact, when Point-to-MultiPoint (P2MP) and MultiPoint-to-Point (MP2P) traffic represents a majority of the traffic, routing attacks consisting of advertising untruthfully preferred routes may cause serious - damages. + 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 @@ -430,21 +425,21 @@ 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. 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 a LLN's physical constraints, size, + The above list considers how an LLN's physical constraints, size, operations, and varieties 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 large number of autonomous devices that are left in unattended locations with limited physical security presents challenges that are not found in the common circumstance of administered networked routers. The following subsection sets up the security objectives for the routing protocol designed by the ROLL WG. 3.4. ROLL Security Objectives @@ -543,21 +538,21 @@ access to routing information achievable through the communication exchanges between routing nodes together with the direct access to information maintained within the nodes. 4.1.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, + specific resource information, such as memory, remaining power, etc., that may be metrics of the routing protocol. The exposure of routing information exchanged will allow unauthorized sources to gain access to the content of the exchanges between communicating nodes. The exposure of neighbor state information will allow unauthorized sources to gain knowledge of communication links between routing nodes that are necessary to maintain routing information exchanges. The forms of attack that allow unauthorized access or exposure of @@ -745,21 +740,21 @@ threats to the underlying transport network that supports routing is considered beyond the scope of the current document. Nonetheless, attacks on the subsystem will affect routing operation and so must be directly addressed within the underlying subsystem and its implemented protocol layers. 4.3.4. Node Resource Exhaustion A potential security threat to routing can arise from attempts to exhaust the node resource asset by initiating exchanges that can lead - to the undue utilization or exhaustion of processing, memory or + to the undue utilization or exhaustion of processing, memory, or energy resources. The establishment and maintenance of routing neighbors opens the routing process to engagement and potential acceptance of multiple neighboring peers. Association information must be stored for each peer entity and for the wireless network operation provisions made to periodically update and reassess the associations. An introduced proliferation of apparent routing peers can therefore have a negative impact on node resources. Node resources may also be unduly consumed by the attackers attempting uncontrolled topology peering or routing exchanges, @@ -775,23 +770,23 @@ o Routing information replay attacks; o HELLO flood attacks and ACK spoofing; o Overload attacks. 5. Countermeasures By recognizing the characteristics of LLNs that may impact routing - and identifying potential countermeasures, this framework provides - the basis for developing capabilities within ROLL protocols to deter - the identified attacks and mitigate the threats. The following + and identifying potential countermeasures, this analysis provides the + basis for developing capabilities within ROLL protocols to deter the + identified attacks and mitigate the threats. The following subsections consider such countermeasures by grouping the attacks according to the classification of the CIA model so that associations with the necessary security services are more readily visible. However, the considerations here are more systematic than confined to means available only within routing; the next section will then distill and make recommendations appropriate for a secured ROLL protocol. 5.1. Confidentiality Attack Countermeasures @@ -883,21 +878,21 @@ 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. 5.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 a LLN, especially one + mounted. The traffic analysis attack on an LLN, especially one founded on shared medium, may be passive and relying on the ability to read the immutable source/destination routing information that must remain unencrypted to permit network routing. Alternatively, attacks can be active 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 @@ -929,42 +924,42 @@ limitations of the communication channel will preclude both the additional routing traffic overhead and the node implementation required for tunneling countermeasures to traffic analysis. 5.1.4. Countering Physical Device Compromise Section 4 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 a LLN routing protocol. + 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 + 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 @@ -1087,43 +1082,43 @@ Identity attacks, sometimes simply called spoofing, seek to gain or damage assets whose access is controlled through identity. In routing, an identity attacker can illegitimately participate in routing exchanges, distribute false routing information, or cause an invalid outcome of a routing process. A perpetrator of Sybil attacks assumes multiple identities. The result is not only an amplification of the damage to routing, but extension to new areas, e.g., where geographic distribution is - explicit or implicit an asset to an application running on the LLN, - for example, the LBR in a P2MP or MP2P LLN. + explicitly or implicitly an asset to an application running on the + LLN, for example, the LBR in a P2MP or MP2P LLN. The countering of identity attacks need to ensure the authenticity and liveliness of the parties of a message exchange. The means may - be through the use of shared key or public key based authentication + be through the use of shared key- or public key-based authentication scheme. On the one hand, the large-scale nature of the LLNs makes the network-wide shared key scheme undesirable from a security perspective; on the other hand, public-key based approaches generally require more computational resources. Each system will need to make trade-off decisions based on its security requirements. As an example, [Wander2005] compared the energy consumption between two public-key algorithms on a low-power microcontroller, with reference to a symmetric-key algorithm and a hash algorithm. 5.2.4. Countering Routing Information Replay Attacks In routing, message replay can result in false topology and/or - routes. The counter of replay attacks need to ensure the freshness + routes. The counter of replay attacks needs to ensure the freshness of the message. On the one hand, there are a number of mechanisms commonly used for countering replay, e.g., with a counter. On the other hand, the choice should take into account how a particular - mechanism is made available in a LLN. For example, many LLNs have a + mechanism is made available in an LLN. For example, many LLNs have a central source of time and have it distributed by relaying, such that secured time distribution becomes a prerequisite of using timestamping to counter replay. 5.2.5. Countering Byzantine Routing Information Attacks Where a node is captured or compromised but continues to operate for a period with valid network security credentials, the potential exists for routing information to be manipulated. This compromise of the routing information could thus exist in spite of security @@ -1154,43 +1149,43 @@ adjacent routing peers to provide a secondary channel for performing routing information validation. S-RIP [Wan2004] is an example of the 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 - framework, any protection against Byzantine routing information + 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 5.1.4 + protections discussed in Section 5.1.4. 5.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 a 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 + 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 availability attack may be facilitated by an identity attack as well as a replay attack, as was addressed in Section 5.2.3 and Section 5.2.4, respectively. 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing - attacks are different but highly related forms of attacking a LLN. + attacks are different but highly related forms of attacking an LLN. They essentially lead nodes to believe that suitable routes are available even though they are not and hence constitute a serious availability attack. The origin of facilitating a HELLO flood attack lies in the fact that many routing protocols require nodes to send HELLO packets either upon joining or in regular intervals so as to announce or confirm their existence to the network. Those nodes that receive the HELLO packet assume that they are indeed neighbors. @@ -1237,33 +1232,34 @@ succeeding. As for the latter, the adversary may spoof the ACK messages to convince the affected node that the link is truly bidirectional and thereupon drop, tunnel or selectively forward messages. Such ACK spoofing attack is possible if the malicious node has a receiver which is significantly more sensitive than that of a normal node, thereby effectively extending its range. Since an ACK spoofing attack facilitates a HELLO flood attack, similar countermeasure are applicable here. Viable counter and security measures for both - attacks have been exposed in [I-D.suhopark-hello-wsn]. + attacks have been exposed in [I-D.suhopark-hello-wsn] 5.3.2. Countering Overload Attacks Overload attacks are a form of DoS attack in that a malicious node overloads the network with irrelevant traffic, thereby draining the - nodes' energy store quicker, when the nodes rely on battery or energy - scavenging. It thus significantly shortens the lifetime of networks - of battery nodes and constitutes another serious availability attack. + nodes' energy store quicker, when the nodes rely on batteries or + energy scavenging. It thus significantly shortens the lifetime of + networks of energy-constrained nodes and constitutes another serious + availability attack. With energy being one of the most precious assets of LLNs, targeting its availability is a fairly obvious attack. Another way of - depleting the energy of a LLN node is to have the malicious node + depleting the energy of an LLN node is to have the malicious node overload the network with irrelevant traffic. This impacts availability since certain routes get congested which o renders them useless for affected nodes and data can hence not be delivered; o makes routes longer as shortest path algorithms work with the congested network; o depletes battery and energy scavenging nodes quicker and thus @@ -1314,27 +1310,28 @@ 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. Selective Forwarding attacks can be countered by deploying a series of mutually non-exclusive security measures: o multipath routing of the same message over disjoint paths; - o dynamically select the next hop from a set of candidates. + o dynamically selecting the next hop from a set of candidates. The first measure basically guarantees that if a message gets lost on a particular routing path due to a malicious selective forwarding attack, there will be another route which successfully delivers the - data. Such method is inherently suboptimal from an energy - consumption point of view. The second method basically involves a + data. Such a method is inherently suboptimal from an energy + consumption point of view; it is also suboptimal from a network + utilization perspective. The second method basically involves a constantly changing routing topology in that next-hop routers are chosen from a dynamic set in the hope that the number of malicious nodes in this set is negligible. A routing protocol that allows for disjoint routing paths may also be useful. 5.3.4. Countering Sinkhole Attacks In sinkhole attacks, the malicious node manages to attract a lot of traffic mainly by advertising the availability of high-quality links even though there are none [Karlof2003]. It hence constitutes a @@ -1406,49 +1403,48 @@ convey the relative level of importance or urgency of the features specified. In this view, 'MUST' is used to define the requirements that are specific to the routing protocol and that are essential for an LLN routing protocol to ensure that routing operation can be maintained. Adherence to MUST requirements is needed to directly counter attacks that can affect the routing operation (such as those that can impact maintained or derived routing/forwarding tables). 'SHOULD' is used to define requirements that counter indirect routing attacks where - such attacks that do not of themselves affect routing but can assist - an attacker in focusing its attack resources to impact network - operation (such as DoS targeting of key forwarding nodes). 'MAY' - covers optional requirements that can further enhance security by - increasing the space over which an attacker must operate or the - resources that must be applied. While in support of routing - security, where appropriate, these requirements may also be addressed - beyond the network routing protocol at other system communications - layers. + such attacks do not of themselves affect routing but can assist an + attacker in focusing its attack resources to impact network operation + (such as DoS targeting of key forwarding nodes). 'MAY' covers + optional requirements that can further enhance security by increasing + the space over which an attacker must operate or the resources that + must be applied. While in support of routing security, where + appropriate, these requirements may also be addressed beyond the + network routing protocol at other system communications layers. The first part of this section, Section 6.1 to Section 6.3, is a prescription of ROLL security features of measures that can be addressed as part of the routing protocol itself. As routing is one - component of a LLN system, the actual strength of the security + component of an LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy; how a design may address the needs of the urban, industrial, home automation, and building automation application domains also needs to be considered. The second part of this section, Section 6.4 and Section 6.5, discusses system security aspects that may impact routing but that also require considerations beyond the routing protocol, as well as potential approaches. - If a LLN employs multicast and/or anycast, these alternative + If an LLN employs multicast and/or anycast, these alternative communications modes MUST be secured with the same routing security services specified in this section. Furthermore, irrespective of the modes of communication, nodes MUST provide adequate physical tamper resistance commensurate with the particular application domain - environment to ensure the confidentiality, integrity and availability - of stored routing information. + environment to ensure the confidentiality, integrity, and + availability of stored routing information. 6.1. Confidentiality Features With regard to confidentiality, protecting the routing/topology information from eavesdropping or unauthorized exposure 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 4.1) but does not of itself directly undermine the operation of the routing function. However, to protect against, and improve vulnerability against other more @@ -1458,21 +1454,21 @@ o MUST implement payload encryption; o MUST provide privacy when geographic information is used (see, e.g., [RFC3693]); o MAY provide tunneling; o MAY provide load balancing. Where confidentiality is incorporated into the routing exchanges, encryption algorithms and key lengths need to be specified in - accordance of the level of protection dictated by the routing + accordance with the level of protection dictated by the routing protocol and the associated application domain transport network. In terms of the life time of the keys, the opportunity to periodically change the encryption key increases the offered level of security for any given implementation. However, where strong cryptography is employed, physical, procedural, and logical data access protection considerations may have more significant impact on cryptoperiod selection than algorithm and key size factors. Nevertheless, in general, shorter cryptoperiods, during which a single key is applied, will enhance security. @@ -1498,37 +1494,38 @@ o MUST provide and verify message integrity (including integrity of the encrypted message when confidentiality is applied); o MUST verify the authenticity and liveness of both principals of a connection (independent of the device interface over which the information is received or accessed); o MUST verify message sequence; o SHOULD incorporate protocol-specific parameter validity range - checks, change increments and message event frequency checks, etc. - as a means of countering intentional or unintentional Byzantine - threats; + 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 used for further system - countermeasures in the case of potential insider attacks. All + 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 against the offending source(s). + 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 through the concatenation of trust established at each individual routing peer exchange. This is particularly important in the case of distance vector-based routing protocols, where information is updated @@ -1562,27 +1559,27 @@ 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. 6.4. Security Key Management The functioning of the routing security services requires keys and credentials. Therefore, even though not directly a ROLL security - requirement, a LLN MUST have a process for initial key and credential - configuration, as well as secure storage within the associated - devices (including use of trusted platform modules where feasible and - appropriate to the operating environment). Beyond initial credential - configuration, a LLN is also encouraged to have automatic procedures - for the long-term revocation and replacement of the maintained - security credentials. + requirement, an LLN MUST have a process for initial key and + credential configuration, as well as secure storage within the + associated devices (including use of trusted platform modules where + feasible and appropriate to the operating environment). Beyond + initial credential configuration, an LLN is also encouraged to have + automatic procedures for the long-term revocation and replacement of + the maintained security credentials. Individual routing peer associations and signaling exchanges will require the generation and use of keys that may be derived from secret or public key exchanges or directly obtained through device configuration means. The routing protocol specification MUST include mechanisms for identifying and synchronizing the keys used for securing exchanges between the routing entities. The keys used to protect the communications between the routing entities MAY be implicit, configured keys or may be explicitly generated as part of the routing signaling exchange. @@ -1616,36 +1613,36 @@ 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 separate from the + 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 IKE [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]. + 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]. 6.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 a LLN system, the actual strength of the implemented security + 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 [RFC5548], [RFC5673], [RFC5826], and [RFC5867]. The following two subsections first consider from an architectural perspective how the security design of a ROLL protocol may be made to adapt to the four application domains, and then examine mechanisms and protocol operations issues. 6.5.1. Security Architecture @@ -1660,22 +1657,22 @@ For a ROLL protocol, the security requirements defined in Section 6.1 to Section 6.4 can be addressed at two levels: 1) through measures implemented directly within the routing protocol itself and initiated and controlled by the routing protocol entities; or 2) through measures invoked on behalf of the routing protocol entities but implemented within the part of the network over which the protocol exchanges occur. Where security is directly implemented as part of the routing protocol the security requirements configured by the user (system - administrator) will operate independent of the lower layers. OSPFv2 - [RFC2328] is an example of such an approach in which security + administrator) will operate independently of the lower layers. + OSPFv2 [RFC2328] is an example of such an approach in which security parameters are exchanged and assessed within the routing protocol messages. In this case, the mechanism may be, e.g., a header containing security material of configurable security primitives in the fashion of OSPFv2 or RIPv2 [RFC2453]. Where IPsec [RFC4301] is employed to secure the network, the included protocol-specific (OSPF or RIP) security elements are in addition to and independent of those at the network layer. In the case of LLNs or other networks where system security mandates protective mechanisms at other lower layers of the network, security measures implemented as part of the routing protocol will be redundant to security measures implemented elsewhere @@ -1685,27 +1682,27 @@ all desired countermeasures can be directly addressed by the protocol all the way to the endpoint of the routing exchange. In particular, routing protocol Byzantine attacks by a compromised node that retains valid network security credentials can only be detected at the level of the information exchanged within the routing protocol. Such attacks aimed at the manipulation of the routing information can only be fully addressed through measures operating directly between the routing entities themselves or external entities able to access and analyze the routing information (see discussion in Section 5.2.5). - On the other hand, it is more desirable from a LLN device perspective - that the ROLL protocol is integrated into the framework of an overall - system architecture where the security facility may be shared by - different applications and/or across layers for efficiency, and where - security policy and configurations can be consistently specified. - See, for example, considerations made in RIPng [RFC2080] or the - approach presented in [Messerges2003]. + On the other hand, it is more desirable from an LLN device + perspective that the ROLL protocol is integrated into the framework + of an overall system architecture where the security facility may be + shared by different applications and/or across layers for efficiency, + and where security policy and configurations can be consistently + specified. See, for example, considerations made in RIPng [RFC2080] + or the approach presented in [Messerges2003]. Where the routing protocol is able to rely on security measures configured within other layers of the protocol stack, greater system efficiency can be realized by avoiding potentially redundant security. Relying on an open trust model [Messerges2003], the security requirements of the routing protocol can be more flexibly met at different layers of the transport network; measures that must be applied to protect the communications network are concurrently able to provide the needed routing protocol protection. @@ -1717,30 +1714,30 @@ required for authenticating network traffic, that security provision can then meet the requirement needed for authentication of routing exchanges. In addition, in the context of the different LLN application domains, the level of security specified for routing can and should be consistent with that considered appropriate for protecting the network within the given environment. A ROLL protocol MUST be made flexible by a design that offers the configuration facility so that the user (network administrator) can choose the security settings that match the application's needs. - Furthermore, in the case of LLNs that flexibility SHOULD extend to + Furthermore, in the case of LLNs, that flexibility SHOULD extend to allowing the routing protocol security requirements to be met by measures applied at different protocol layers, provided the identified requirements are collectively met. Since Byzantine attacks that can affect the validity of the information content exchanged between routing entities can only be directly countered at the routing protocol level, the ROLL protocol MAY support mechanisms for verifying routing data validity that - extends beyond the chain of trust created through device + extend beyond the chain of trust created through device authentication. This protocol-specific security mechanism SHOULD be made optional within the protocol allowing it to be invoked according to the given routing protocol and application domain and as selected by the system user. All other ROLL security mechanisms needed to meet the above identified routing security requirements can be flexibly implemented within the transport network (at the IP network layer or higher or lower protocol layers(s)) according to the particular application domain and user network configuration. Based on device capabilities and the spectrum of operating @@ -1775,31 +1772,30 @@ measures implemented within the transport network that are consistent with available system resources and commensurate and consistent with the security level and strength applied in the particular application domain networks. 6.5.2. Mechanisms and Operations With an architecture allowing different configurations to meet the application domain needs, the task is then to find suitable mechanisms. For example, one of the main problems of synchronizing - security states of sleepy nodes, as listed in the last subsection, - lies in difficulties in authentication; these nodes may not have - received in time the most recent update of security material. - Similarly, the issues of minimal manual configuration, prolonged - rollout and delayed addition of nodes, and network topology changes - also complicate security management. In many cases the ROLL protocol - may need to bootstrap the authentication process and allow for a - flexible expiration scheme of authentication credentials. This - exemplifies the need for the coordination and interoperation between - the requirements of the ROLL routing protocol and that of the system - security elements. + security states of sleepy nodes lies in difficulties in + authentication; these nodes may not have received in time the most + recent update of security material. Similarly, the issues of minimal + manual configuration, prolonged rollout and delayed addition of + nodes, and network topology changes also complicate security + management. In many cases the ROLL protocol may need to bootstrap + the authentication process and allow for a flexible expiration scheme + of authentication credentials. This exemplifies the need for the + coordination and interoperation between the requirements of the ROLL + routing protocol and that of the system security elements. Similarly, the vulnerability brought forth by some special-function nodes, e.g., LBRs requires the assurance, particularly, of the availability of communication channels and node resources, or that the neighbor discovery process operates without undermining routing availability. 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 @@ -1848,21 +1844,21 @@ ...Protocol Stack..................... Figure 3: LLN Device Security Model 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations - The framework presented in this document provides security analysis + 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 specific mechanisms to be used to deal with each threat is specified in link-layer and deployment specific applicability statements. 9. Acknowledgments The authors would like to acknowledge the review and comments from Rene Struik and JP Vasseur. The authors would also like to acknowledge the guidance and input provided by the ROLL Chairs, David