Networking Working Group T. Tsao, Ed. Internet-Draft March 1, 2010 Intended status: Informational Expires: September 2, 2010 A Security Design for RPL: IPv6 Routing Protocol for Low Power and Lossy Networks draft-sdt-roll-rpl-security-00 Abstract This document presents a security design for RPL: IPv6 Routing Protocol for Low Power and Lossy networks. The effort builds upon previous work on routing security and adapts the security assessments to the issues specific to RPL. With the threat model, the security objectives and required services are identified. These assessments then provide the basis of the security recommendations for incorporation into RPL. 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 to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Tsao Expires September 2, 2010 [Page 1] Internet-Draft Security Design for RPL March 2010 This Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 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 BSD License. Tsao Expires September 2, 2010 [Page 2] Internet-Draft Security Design for RPL March 2010 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operating Domains and Threats . . . . . . . . . . . . . . . . 4 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 6 5. Security Design . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Options . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. Basic Packet Structure . . . . . . . . . . . . . . . . 8 5.2.2. Security Header . . . . . . . . . . . . . . . . . . . 10 5.2.3. Security Suboption . . . . . . . . . . . . . . . . . . 10 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Tsao Expires September 2, 2010 [Page 3] Internet-Draft Security Design for RPL March 2010 1. Terminology This document adopts the terminology defined in [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. 2. Introduction The IETF ROLL working group is in the process of defining a routing protocol, RPL [I-D.ietf-roll-rpl], for IPv6 routing over LLNs. RPL builds routes in the form of Destination Oriented Directed Acyclic Graphs (DODAGs). RPL may be categorized as a distance-vector protocol, in which routes are exchanged among neighbors, as opposed to a link-state protocol, in which local link states are flooded to all routing participants. This document serves as a repository for the security design for RPL. It will evolve as the ROLL effort progresses, and in conjunction with the work on RPL, it is meant to be eventually merged with the RPL RFC. The following section considers the threats to RPL. The security objectives as well as the required services are given in Section 4. Section 5 describes how to realize the required security services. Section 6 considers issues that have system implications for the implementation of RPL security. 3. Operating Domains and Threats Applying the approach outlined in [I-D.tsao-roll-security-framework], Figure 1 gives a level-1 data flow diagram representation of RPL to show the "assets" and "points of access" that may be vulnerable and need to be protected for the RPL routing protocol. Tsao Expires September 2, 2010 [Page 4] Internet-Draft Security Design for RPL March 2010 ...................................................... : : |Multicast : : Group_i|<----->(DIO)<-------------+ : : | : |Multicast : | : Group_j or : V : Node_j|<------>(DIS)<----->(RPL Control/ : : Trickle Timer/ _____________ : : Loop Avoidance)---->Candidate : : ^ ^ Neighbor List : |Multicast : | | ------------- : Group_k or : | | | : Node_k|<------>(DAO)<----------+ | V : : | (Route Generation) : : | | : : | ______V______ : : | Routing Table : : | ------+------ : : RPL on Node_l | | : ..........................|................|.......... | | |Forwarding V | To/From Node_m|<------------>(IPv6 Flow Label)<-------+ Notation: (Proc) A process Proc ________ DataBase A data storage DataBase -------- |Node_n| An external entity Node_n -------> Data flow Figure 1: Data Flow Diagram of RPL From Figure 1, it is seen that threats to the proper operation of RPL can be realized through attacks on its DIO, DIS, and DAO control message exchanges, as well as on the control information the protocol places into the user data flow in the form of the IPv6 Flow Label. Note that as shown in Figure 1 RPL uses multicast in addition to unicast for control exchanges, thus likely requiring a more complex process for key management. The support for multicast key management is outside the scope of the routing protocol. Tsao Expires September 2, 2010 [Page 5] Internet-Draft Security Design for RPL March 2010 4. Security Requirements The fundamental security objective for RPL is to ensure proper functioning in the presence of adversaries. More specific immediate objectives can be derived through the framework provided in Section 6 of [I-D.tsao-roll-security-framework]; the base requirements stated there concern message integrity, authenticity and liveliness of the principals of a connection, and protection of message replay. The framework also recognized that message encryption may be desirable. Based on the framework analysis, the security objectives for RPL are formulated as below (securing DIS messages and Flow Labels is not yet fully considered in this revision of the document). RPL security features shall ensure that: 1. the received DIO, DIS, and DAO messages are not modified during transportation; 2. participants of the DIO, DIS, and DAO message exchanges are authentic; 3. the received DIO, DIS, and DAO messages are not retransmissions of previous messages; 4. the content of the DIO, DIS, and DAO messages may be made to be legible to only authorized entities. In meeting the above objectives, the following services are initially chosen: 1. integrity protection of the DIO and DAO messages; 2. authentication of the participants of the DIO and DAO message exchanges; 3. anti-replay protection of the received DIO and DAO messages; 4. encryption of the content of the DIO and DAO messages. As pointed out in [I-D.tsao-roll-security-framework] pointed out that it is also necessary to allow adaptation of the security services afforded to the particular constraints of the deployment environment. However the current security design begins with a focus on the requirement to implement RPL security features directly as part of the routing protocol. No consideration in therefore currently given to capabilities that may be supported by other communications layers of the applicable network. Following completion of the RPL-specific security design consideration shall be given to how the required Tsao Expires September 2, 2010 [Page 6] Internet-Draft Security Design for RPL March 2010 security features can be met through security at other communication layers (for example, through IEEE 802.15.4 link layer security), without the redundancy that would be negatively affect LLNs. The following section thus considers the manner in which to afford the required security services are directly implemented as part of RPL. 5. Security Design This section describes the security design for RPL. 5.1. Options The design specifies options to make the afforded services flexible with regard to their incorporation within RPL or other communications layer. The following is an initial outline of the elements to be incorporated. 1. Message Specification a. Use an admin field in the DIO and DAO to indicate the actual protection provided. This will include the ability to indicate that no protection (authenticity, encryption, etc.) is applied b. Use sub-option fields in the DIO and DAO to carry security information c. Securing DIS messages and Flow Labels with forwarded traffic is TBD 2. Security Algorithm a. The basic mechanism for protecting integrity and verifying authenticity of DIO and DAO packets will be AES128/CCM* with four byte MIC and optional payload encryption. 3. Security Mechanisms a. Require two base security options (1) no security (2) shared, instance-wide key generated using PRNG at the time that the sessions are created Tsao Expires September 2, 2010 [Page 7] Internet-Draft Security Design for RPL March 2010 b. Include two additional options (1) pairwise-shared keys generated using PRNG at the time that the sessions are created (2) digital signature based c. Initial authentication to create a session would come from (1) no authentication (2) pre-configured, instance-wide join key with no access control list (3) pre-configured, instance-wide join key with access control list (4) pre-configured join key unique to the MAC ID of the node (5) public key certificate The mechanisms for out-of-band pre-configuration are out of scope for RPL; [I-D.oflynn-6lowapp-bootstrapping] addresses this issue. 5.2. Implementation The options given in Section 5.1 are realized through extending the DIO and DAO bases defined in [I-D.ietf-roll-rpl], adding a security suboption, and applying security operations on all suboption payload of the DIO and DAO messages. 5.2.1. Basic Packet Structure The DIO and DAO messages defined in [I-D.ietf-roll-rpl] consist of a base and suboptions. The base is an always-present container. Figure 2 shows the DIO base. Tsao Expires September 2, 2010 [Page 8] Internet-Draft Security Design for RPL March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|A|T|S|0| Prf | Sequence | Rank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID | DTSN | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | DODAGID | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | sub-option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: DIO Base The DAO base is shown in Figure 3: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DAO Sequence | DAO Rank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID | Route Tag | Prefix Length | RRCount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DAO Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse Route Stack (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-option(s)... +-+-+-+-+-+-+-+-+ Figure 3: DAO Base The DIO and DAO suboptions have the same format as shown in Figure 4: Tsao Expires September 2, 2010 [Page 9] Internet-Draft Security Design for RPL March 2010 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Subopt. Type | Subopt Length | Subopt Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 4: Suboption Generic Format 5.2.2. Security Header It is proposed to extend the DIO and DAO bases to contain a security header field that indicates the applied security suites and carries auxiliary security materials, e.g. nonce and IV. The details of the various suites and corresponding security materials are to be developed in later revisions. 5.2.3. Security Suboption It is proposed to add a security suboption for common use in the DIO and DAO messages to contain the message authentication code when message authentication is applied. When present, the security option will be the last suboption of the message. There may be ways to reduce the overhead of using the suboption as a carrier of the message authentication code; further consideration will be given in later revisions. 6. Discussions For reason of trust binding, it is desirable to be able to assume a globally unique device identifier for RPL nodes, such as EUI-64. For devices that have a clock on board, timeliness may be provided with a single flow mechanism. In contrast, one can realize this by using cryptographic challenge-response protocols, but these involve two or more flows. Support for either approach should be a function of network capability. It is desirable that security I/O parameter passing for RPL is compatible with layer-2, e.g., structure of keying material. In this regard, 802.15.4e would be a good candidate reference model. 7. IANA Considerations This memo includes no request to IANA. Tsao Expires September 2, 2010 [Page 10] Internet-Draft Security Design for RPL March 2010 8. Security Considerations This document describes a security design for RPL: IPv6 Routing Protocol for Low Power Lossy Networks. 9. Contributors This work is the result of both the ROLL security design team and individual contributors. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.ietf-roll-rpl] Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-06 (work in progress), February 2010. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-02 (work in progress), October 2009. [I-D.oflynn-6lowapp-bootstrapping] O'Flynn, C., "Initial Configuration of Resource- Constrained Devices", draft-oflynn-6lowapp-bootstrapping-00 (work in progress), January 2010. [I-D.tsao-roll-security-framework] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", draft-tsao-roll-security-framework-01 (work in progress), September 2009. Tsao Expires September 2, 2010 [Page 11] Internet-Draft Security Design for RPL March 2010 Author's Address Tzeta Tsao (editor) Email: tzeta.tsao@ekasystems.com Tsao Expires September 2, 2010 [Page 12]