--- 1/draft-ietf-roll-security-threats-08.txt 2014-08-13 19:14:33.907106642 -0700 +++ 2/draft-ietf-roll-security-threats-09.txt 2014-08-13 19:14:33.983108487 -0700 @@ -1,64 +1,56 @@ Routing Over Low-Power and Lossy Networks T. Tsao Internet-Draft R. Alexander Intended status: Informational Cooper Power Systems -Expires: January 20, 2015 M. Dohler +Expires: February 14, 2015 M. Dohler CTTC V. Daza A. Lozano Universitat Pompeu Fabra M. Richardson, Ed. Sandelman Software Works - July 19, 2014 + August 13, 2014 A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL) - draft-ietf-roll-security-threats-08 + draft-ietf-roll-security-threats-09 Abstract This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL). 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. -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 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 January 20, 2015. + This Internet-Draft will expire on February 14, 2015. Copyright Notice - Copyright (c) 2014 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 @@ -64,71 +56,71 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Relationship to other documents . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Considerations on RPL Security . . . . . . . . . . . . . . . 5 - 4.1. Routing Assets and Points of Access . . . . . . . . . . . 5 - 4.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 7 + 4.1. Routing Assets and Points of Access . . . . . . . . . . . 6 + 4.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 8 4.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 9 - 4.4. RPL Security Objectives . . . . . . . . . . . . . . . . . 11 - 5. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.4. RPL Security Objectives . . . . . . . . . . . . . . . . . 12 + 5. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 13 6. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Threats due to failures to Authenticate . . . . . . . . . 13 - 6.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 13 + 6.1. Threats due to failures to Authenticate . . . . . . . . . 14 + 6.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 14 6.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 14 6.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 14 - 6.2. Threats and Attacks on Confidentiality . . . . . . . . . 14 - 6.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 + 6.2. Threats and Attacks on Confidentiality . . . . . . . . . 15 + 6.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 15 6.2.2. Routing Information (Routes and Network Topology) - Exposure . . . . . . . . . . . . . . . . . . . . . . 14 - 6.3. Threats and Attacks on Integrity . . . . . . . . . . . . 15 - 6.3.1. Routing Information Manipulation . . . . . . . . . . 15 - 6.3.2. Node Identity Misappropriation . . . . . . . . . . . 16 - 6.4. Threats and Attacks on Availability . . . . . . . . . . . 16 - 6.4.1. Routing Exchange Interference or Disruption . . . . . 16 + Exposure . . . . . . . . . . . . . . . . . . . . . . 15 + 6.3. Threats and Attacks on Integrity . . . . . . . . . . . . 16 + 6.3.1. Routing Information Manipulation . . . . . . . . . . 16 + 6.3.2. Node Identity Misappropriation . . . . . . . . . . . 17 + 6.4. Threats and Attacks on Availability . . . . . . . . . . . 17 + 6.4.1. Routing Exchange Interference or Disruption . . . . . 17 6.4.2. Network Traffic Forwarding Disruption . . . . . . . . 17 - 6.4.3. Communications Resource Disruption . . . . . . . . . 18 - 6.4.4. Node Resource Exhaustion . . . . . . . . . . . . . . 18 - 7. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19 - 7.1. Confidentiality Attack Countermeasures . . . . . . . . . 19 - 7.1.1. Countering Deliberate Exposure Attacks . . . . . . . 19 - 7.1.2. Countering Passive Wiretapping Attacks . . . . . . . 20 - 7.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 - 7.1.4. Countering Remote Device Access Attacks . . . . . . . 21 - 7.2. Integrity Attack Countermeasures . . . . . . . . . . . . 22 - 7.2.1. Countering Unauthorized Modification Attacks . . . . 22 - 7.2.2. Countering Overclaiming and Misclaiming Attacks . . . 23 - 7.2.3. Countering Identity (including Sybil) Attacks . . . . 23 - 7.2.4. Countering Routing Information Replay Attacks . . . . 23 - 7.2.5. Countering Byzantine Routing Information Attacks . . 24 - 7.3. Availability Attack Countermeasures . . . . . . . . . . . 25 + 6.4.3. Communications Resource Disruption . . . . . . . . . 19 + 6.4.4. Node Resource Exhaustion . . . . . . . . . . . . . . 19 + 7. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. Confidentiality Attack Countermeasures . . . . . . . . . 20 + 7.1.1. Countering Deliberate Exposure Attacks . . . . . . . 20 + 7.1.2. Countering Passive Wiretapping Attacks . . . . . . . 21 + 7.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 22 + 7.1.4. Countering Remote Device Access Attacks . . . . . . . 22 + 7.2. Integrity Attack Countermeasures . . . . . . . . . . . . 23 + 7.2.1. Countering Unauthorized Modification Attacks . . . . 23 + 7.2.2. Countering Overclaiming and Misclaiming Attacks . . . 24 + 7.2.3. Countering Identity (including Sybil) Attacks . . . . 24 + 7.2.4. Countering Routing Information Replay Attacks . . . . 24 + 7.2.5. Countering Byzantine Routing Information Attacks . . 25 + 7.3. Availability Attack Countermeasures . . . . . . . . . . . 26 7.3.1. Countering HELLO Flood Attacks and ACK Spoofing - Attacks . . . . . . . . . . . . . . . . . . . . . . . 25 - 7.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 - 7.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 - 7.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 28 - 7.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 29 - 8. RPL Security Features . . . . . . . . . . . . . . . . . . . . 29 - 8.1. Confidentiality Features . . . . . . . . . . . . . . . . 30 - 8.2. Integrity Features . . . . . . . . . . . . . . . . . . . 31 - 8.3. Availability Features . . . . . . . . . . . . . . . . . . 31 - 8.4. Key Management . . . . . . . . . . . . . . . . . . . . . 32 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 33 + Attacks . . . . . . . . . . . . . . . . . . . . . . . 26 + 7.3.2. Countering Overload Attacks . . . . . . . . . . . . . 27 + 7.3.3. Countering Selective Forwarding Attacks . . . . . . . 28 + 7.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 29 + 7.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 30 + 8. RPL Security Features . . . . . . . . . . . . . . . . . . . . 30 + 8.1. Confidentiality Features . . . . . . . . . . . . . . . . 31 + 8.2. Integrity Features . . . . . . . . . . . . . . . . . . . 32 + 8.3. Availability Features . . . . . . . . . . . . . . . . . . 32 + 8.4. Key Management . . . . . . . . . . . . . . . . . . . . . 33 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 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 @@ -144,30 +136,35 @@ deployed devices becomes one of these key challenges. This document presents a threat analysis for securing the Routing Protocol for LLNs (RPL). 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 RPL. 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 applicability statements. - This document uses [IS07498-2] model, which describes Authentication, - Access Control, Data Confidentiality, Data Integrity, and Non- - Repudiation security services and to which Availability is added. + This document uses [ISO.7498-2.1988]] model, which describes + Authentication, Access Control, Data Confidentiality, Data Integrity, + and Non-Repudiation security services and to which Availability is + added. + + Many of the issues in this document were also covered in The IAB + Smart Object Workshop [RFC6574], and The IAB Smart Object Security + Workshop [I-D.gilger-smart-object-security-workshop]. All of this document concerns itself with securing the control plane traffic. As such it does not address authorization or authentication - of application traffic. RPL uses multicast as part of it's protocol, - and therefore mechanisms which RPL uses to secure this traffic MAY be - applicable to MPL control traffic as well: the important part is that - the threats are similiar. + of application traffic. RPL uses multicast as part of its protocol, + and therefore mechanisms which RPL uses to secure this traffic might + also be applicable to MPL control traffic as well: the important part + is that the threats are similar. 2. Relationship to other documents ROLL has specified a set of routing protocols for Lossy and Low- resource Networks (LLN) [RFC6550]. A number of applicability texts describes a subset of these protocols and the conditions which make the subset the correct choice. The text recommends and motivates the accompanying parameter value ranges. Multiple applicability domains are recognized including: Building and Home, and Advanced Metering Infrastructure. The applicability domains distinguish themselves in @@ -179,25 +176,43 @@ The common set of security threats herein are referred to by the applicability statements, and that series of documents describes the preferred security settings and solutions within the applicability statement conditions. This applicability statements may recommend more light weight security solutions and specify the conditions under which these solutions are appropriate. 3. Terminology This document adopts the terminology defined in [RFC6550], in - [RFC4949], and in [I-D.ietf-roll-terminology]. + [RFC4949], and in [RFC7102]. The terms control plane and forwarding plane are used consistently with section 1 of [RFC6192]. + The term DODAG is from [RFC6550]. + + EAP-TLS is defined in [RFC5216]. + + PANA is defined in [RFC5191]. + + CCM mode is defined in [RFC3610]. + + The terms SSID, ESSID and PAN refer to network identifiers, defined + in [IEEE.802.11] and [IEEE.802.15.4]. + + Although this is not a protocol specification, 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 [RFC2119] in order to + clarify and emphasize the guidance and directions to implementers and + deployers of LLN nodes that utilize RPL. + 4. Considerations on RPL 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, and potentially confidentiality of routing data, but also @@ -405,21 +421,23 @@ observations from those requirements and evaluation of their impact on routing security considerations. 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. + another issue. A non-rechargeable battery powered node may + well be limited in energy for it's lifetime: once exchausted, + it may well never function again. Large scale of rolled out network 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. @@ -900,26 +919,27 @@ from a secured ESSID/PAN to an unsecured interface. A prerequisite to countering this attack is to ensure that the communicating nodes are authenticated prior to data encryption applied in the routing exchange. Authentication ensures that the nodes are who they claim to be even though it does not provide an indication of whether the node has been compromised. To mitigate the risk of deliberate exposure, the process that communicating nodes use to establish session keys must be peer-to- - peer (i.e., between the routing initiating and responding nodes). - This helps ensure that neither node is exchanging routing information - with another peer without the knowledge of both communicating peers. - For a deliberate exposure attack to succeed, the comprised node will - need to be more overt and take independent actions in order to - disclose the routing information to 3rd party. + peer (i.e., between the routing initiating and responding nodes). As + is pointed out in [RFC4107], automatic key management is critical for + good security. This helps ensure that neither node is exchanging + routing information with another peer without the knowledge of both + communicating peers. For a deliberate exposure attack to succeed, + the comprised node will need to be more overt and take independent + actions in order to disclose the routing information to 3rd party. 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. 7.1.2. Countering Passive Wiretapping Attacks A passive wiretap attack seeks to breach routing confidentiality through passive, direct analysis and processing of the information @@ -1111,21 +1131,21 @@ Consistent with the end-to-end principle of communications, such an attack can only be fully addressed through measures operating directly between the routing entities themselves or by means of external entities able to access and independently analyze the routing information. Verification of the authenticity and liveliness of the routing entities can therefore only provide a limited counter against internal (Byzantine) node attacks. For link state routing protocols where information is flooded with, - for example, areas (OSPF [RFC2328]) or levels (ISIS [RFC1142]), + for example, areas (OSPF [RFC2328]) or levels (ISIS [RFC7142]), countermeasures can be directly applied by the routing entities through the processing and comparison of link state information received from different peers. By comparing the link information from multiple sources decisions can be made by a routing node or external entity with regard to routing information validity; see Chapter 2 of [Perlman1988] for a discussion on flooding attacks. For distance vector protocols, such as RPL, where information is aggregated at each routing node it is not possible for nodes to directly detect Byzantine information manipulation attacks from the @@ -1527,162 +1547,127 @@ solutions to the threats are application and layer-2 specific, and have therefore been moved to the relevant applicability statements. Ines Robles and Robert Cragie kept track of the many issues that were raised during the development of this document 12. References 12.1. Normative References - [I-D.ietf-roll-terminology] - Vasseur, J., "Terminology in Low power And Lossy - Networks", draft-ietf-roll-terminology-04 (work in - progress), September 2010. - [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. [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with Hysteresis Objective Function", RFC 6719, September 2012. + [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and + Lossy Networks", RFC 7102, January 2014. + [ZigBeeIP] ZigBee Public Document 15-002r00, "ZigBee IP Specification", 2013. 12.2. Informative References [AceCharterProposal] Li, Kepeng., Ed., "Authentication and Authorization for Constrained Environment Charter (work-in-progress)", December 2013, . - [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. - - [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.gilger-smart-object-security-workshop] + Gilger, J. and H. Tschofenig, "Report from the 'Smart + Object Security Workshop', March 23, 2012, Paris, France", + draft-gilger-smart-object-security-workshop-02 (work in + progress), October 2013. [I-D.kelsey-intarea-mesh-link-establishment] Kelsey, R., "Mesh Link Establishment", draft-kelsey- intarea-mesh-link-establishment-05 (work in progress), February 2013. [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 - Architecture", IEEE-SA Standards Board, Jun. 14 2001. + [IEEE.802.11] + , "Draft Standard for Information Technology - + Telecommunications and information exchange between + systems - Local and metropolitan area networks Specific + requirements - Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications ", IEEE + 802.11-REVma, 2006. + + [IEEE.802.15.4] + , "Information technology - Telecommunications and + information exchange between systems - Local and + metropolitan area networks - Specific requirements - Part + 15.4: Wireless Medium Access Control (MAC) and Physical + Layer (PHY) Specifications for Low Rate Wireless Personal + Area Networks (LR-WPANs) ", IEEE Std 802.15.4-2006, June + 2006, . [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. - - [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. [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. - - [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. - [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003. - [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., IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006. [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. + [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. + Yegin, "Protocol for Carrying Authentication for Network + Access (PANA)", RFC 5191, May 2008. - [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of - Various Multimedia Internet KEYing (MIKEY) Modes and - Extensions", RFC 5197, June 2008. + [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS + Authentication Protocol", RFC 5216, March 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 @@ -1690,68 +1675,53 @@ 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. [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. - [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011. [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, April 2012. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. + [RFC7142] Shand, M. and L. Ginsberg, "Reclassification of RFC 1142 + to Historic", RFC 7142, February 2014. + [SmartObjectSecurityWorkshop] Klausen, T., Ed., "Workshop on Smart Object Security", March 2012, . [SolaceProposal] Bormann, C., Ed., "Notes from the SOLACE ad-hoc at IETF85 (work-in-progress)", November 2012, . [Sybil2002] Douceur, J., "The Sybil Attack", First International Workshop on Peer-to-Peer Systems , March 2002. - [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 - wireless sensor networ", in the Proceedings of the Third - IEEE International Conference on Pervasive Computing and - Communications pp. 324-328, March 8-12 2005. - [Yourdon1979] Yourdon, E. and L. Constantine, "Structured Design", Yourdon Press, New York, Chapter 10, pp. 187-222, 1979. Authors' Addresses Tzeta Tsao Cooper Power Systems 910 Clopper Rd. Suite 201S Gaithersburg, Maryland 20878 USA