draft-ietf-roll-security-framework-06.txt   draft-ietf-roll-security-framework-07.txt 
Networking Working Group T. Tsao Networking Working Group T. Tsao
Internet-Draft R. Alexander Internet-Draft R. Alexander
Intended status: Informational Cooper Power Systems Intended status: Informational Cooper Power Systems
Expires: December 17, 2011 M. Dohler Expires: July 15, 2012 M. Dohler
CTTC CTTC
V. Daza V. Daza
A. Lozano A. Lozano
Universitat Pompeu Fabra Universitat Pompeu Fabra
June 15, 2011 January 12, 2012
A Security Framework for Routing over Low Power and Lossy Networks A Security Framework for Routing over Low Power and Lossy Networks
draft-ietf-roll-security-framework-06 draft-ietf-roll-security-framework-07
Abstract Abstract
This document presents a security framework for routing over low This document presents a security framework for routing over low
power and lossy networks (LLN). The development builds upon previous power and lossy networks (LLN). The development builds upon previous
work on routing security and adapts the assessments to the issues and work on routing security and adapts the assessments to the issues and
constraints specific to low power and lossy networks. A systematic constraints specific to low power and lossy networks. A systematic
approach is used in defining and evaluating the security threats and approach is used in defining and evaluating the security threats and
identifying applicable countermeasures. These assessments provide identifying applicable countermeasures. These assessments provide
the basis of the security recommendations for incorporation into low the basis of the security recommendations for incorporation into low
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 17, 2011. This Internet-Draft will expire on July 15, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 4 skipping to change at page 4, line 4
5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 29 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 29
5.3.3. Countering Selective Forwarding Attacks . . . . . . . 30 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 30
5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 31 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 31
5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 32 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 32
6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 32 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 32
6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 33 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 33
6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 34 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 34
6.3. Availability Features . . . . . . . . . . . . . . . . . . 35 6.3. Availability Features . . . . . . . . . . . . . . . . . . 35
6.4. Security Key Management . . . . . . . . . . . . . . . . . 36 6.4. Security Key Management . . . . . . . . . . . . . . . . . 36
6.5. Consideration on Matching Application Domain Needs . . . . 37 6.5. Consideration on Matching Application Domain Needs . . . . 37
6.5.1. Security Architecture . . . . . . . . . . . . . . . . 37 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 38
6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 40 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 40
7. Application of ROLL Security Framework to RPL . . . . . . . . 41 7. Application of ROLL Security Framework to RPL . . . . . . . . 42
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
11.1. Normative References . . . . . . . . . . . . . . . . . . . 44 11.1. Normative References . . . . . . . . . . . . . . . . . . . 45
11.2. Informative References . . . . . . . . . . . . . . . . . . 45 11.2. Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
In recent times, networked electronic devices have found an In recent times, networked electronic devices have found an
increasing number of applications in various fields. Yet, for increasing number of applications in various fields. Yet, for
reasons ranging from operational application to economics, these reasons ranging from operational application to economics, these
wired and wireless devices are often supplied with minimum physical wired and wireless devices are often supplied with minimum physical
resources; the constraints include those on computational resources resources; the constraints include those on computational resources
(RAM, clock speed, storage), communication resources (duty cycle, (RAM, clock speed, storage), communication resources (duty cycle,
packet size, etc.), but also form factors that may rule out user packet size, etc.), but also form factors that may rule out user
skipping to change at page 36, line 16 skipping to change at page 36, line 16
o MAY use multiple destinations; o MAY use multiple destinations;
o MAY choose randomly if multiple paths are available; o MAY choose randomly if multiple paths are available;
o MAY set quotas to limit transmit or receive volume; o MAY set quotas to limit transmit or receive volume;
o MAY use geographic information for flow control. o MAY use geographic information for flow control.
6.4. Security Key Management 6.4. Security Key Management
The functioning of the security services requires keys and The functioning of the routing security services requires keys and
credentials. Therefore, even though not directly a ROLL security credentials. Therefore, even though not directly a ROLL security
requirement, a LLN MUST have a process for key and credential requirement, a LLN MUST have a process for initial key and credential
distribution, as well as secure storage within the associated devices configuration, as well as secure storage within the associated
(including use of trusted platform modules where feasible and devices (including use of trusted platform modules where feasible and
appropriate to the operating environment). A LLN is encouraged to appropriate to the operating environment). Beyond initial credential
have automatic procedures for the revocation and replacement of configuration, a LLN is also encouraged to have automatic procedures
maintained security credentials. for the long-term revocation and replacement of the maintained
security credentials.
Individual routing peer associations and signaling exchanges will Individual routing peer associations and signaling exchanges will
require the generation and use of keys that may be derived from require the generation and use of keys that may be derived from
public key exchanges or obtained through other device configuration secret or public key exchanges or directly obtained through device
means. Correspondingly, the routing protocol(s) specified by the configuration means. The routing protocol specification MUST include
ROLL Working Group SHOULD employ the provision of key management mechanisms for identifying and synchronizing the keys used for
mechanisms consistent with the guidelines given in [RFC4107]. Based securing exchanges between the routing entities. The keys used to
on that RFC's recommendations, many LLNs, particularly given the protect the communications between the routing entities MAY be
intended scale and ad hoc device associations, will satisfy the implicit, configured keys or may be explicitly generated as part of
requirement for supporting automated key management in conjunction the routing signaling exchange.
with the routing protocol operation. These automated routing session
keys may be derived from pre-stored security credentials or other For the keys used to protect routing associations, the routing
authenticated key management mechanisms. protocol(s) specified by the ROLL Working Group SHOULD employ key
management mechanisms consistent with the guidelines given in
[RFC4107]. Based on that RFC's recommendations, many LLNs,
particularly given the intended scale and ad hoc device associations,
will meet the requirement for supporting automated key management in
conjunction with the routing protocol operation. These short-term,
automated routing session keys may be derived from pre-stored
security credentials or can be generated through key management
mechanisms that are defined as part of the routing protocol exchange.
Beyond the automated short-term keys, a long-term key management
mechanism SHOULD also be defined for changing or updating the
credentials from which short-term routing association key material is
derived.
The use of a public key infrastructure (PKI), where feasible, can be The use of a public key infrastructure (PKI), where feasible, can be
used to support authenticated key management and the distribution of used to support authenticated short-term key management as well as
routing security keying material. Note that where the option for a the distribution of long-term routing security keying material. Note
PKI is supported for security of the routing protocol itself, the that where the option for a PKI is supported for security of the
routing protocol MUST include provisions for public key certificates routing protocol itself, the routing protocol MUST include provisions
to be included or referenced within routing messages to allow a for public key certificates to be included or referenced within
node's public key to be shared with communicating peers. Even if the routing messages to allow a node's public key to be shared with
certificate itself is not distributed by the node, there needs to be communicating peers. Even if the certificate itself is not
a mechanism to inform the receiving node where to find the distributed by the node, there needs to be a mechanism to inform the
certificate and obtain associated validation information; see receiving node where to find the certificate and obtain associated
[RFC3029] for an example of the kind of localized PKI support that validation information; see [RFC3029] for an example of the kind of
may be applied in a given LLN environment. Where PKI systems are not localized PKI support that may be applied in a given LLN environment.
feasible, the key management system MUST support means for secure Where PKI systems are not feasible, the key management system MUST
configuration, device authentication, and adherence to secure key support means for secure configuration, device authentication, and
wrapping principles for the secure distribution and update of device adherence to secure key wrapping principles for the secure
keys. distribution and update of device keys.
LLN routing protocols SHOULD be designed to allow the use of existing LLN routing protocols SHOULD be designed to allow the use of existing
and validated key management schemes. As part of the LLN and validated key management schemes. As part of the LLN
optimization, these schemes may be independent of the routing optimization, these schemes may be independent of the routing
protocol and part of the broader LLN system security specifications. protocol and part of the broader LLN system security specifications.
Where key management is defined separate from the routing protocol Where the long-term key management is defined separate from the
security, LLN application domains can appropriately employ IETF- routing protocol security, LLN application domains can appropriately
standard key management specifications. Established key management employ IETF- standard key management specifications. Established key
solutions such as IKE [RFC5996] or MIKEY [RFC3830], which supports management solutions such as IKE [RFC5996] or MIKEY [RFC3830], which
several alternative private, public, or Diffie-Hellman key supports several alternative private, public, or Diffie-Hellman key
distribution methods (see [RFC5197]), can thus be adapted for use in distribution methods (see [RFC5197]), can thus be adapted for use in
LLNs. Group key management and distribution methods may also be LLNs. For example, see [I-D.alexander-roll-mikey-lln-key-mgmt].
developed based on the architecture principles defined in MSEC Group key management and distribution methods may also be developed
[RFC4046]. based on the architecture principles defined in MSEC [RFC4046].
6.5. Consideration on Matching Application Domain Needs 6.5. Consideration on Matching Application Domain Needs
Providing security within an LLN requires considerations that extend Providing security within an LLN requires considerations that extend
beyond routing security to the broader LLN application domain beyond routing security to the broader LLN application domain
security implementation. In other words, as routing is one component security implementation. In other words, as routing is one component
of a LLN system, the actual strength of the implemented security of a LLN system, the actual strength of the implemented security
algorithms for the routing protocol MUST be made to conform to the algorithms for the routing protocol MUST be made to conform to the
system's target level of security. The development so far takes into system's target level of security. The development so far takes into
account collectively the impacts of the issues gathered from account collectively the impacts of the issues gathered from
skipping to change at page 44, line 30 skipping to change at page 45, line 22
acknowledge the guidance and input provided by the ROLL Chairs, David acknowledge the guidance and input provided by the ROLL Chairs, David
Culler and JP Vasseur, and the Area Director Adrian Farrel. Culler and JP Vasseur, and the Area Director Adrian Farrel.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-6man-rpl-option] [I-D.ietf-6man-rpl-option]
Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
Information in Data-Plane Datagrams", Information in Data-Plane Datagrams",
draft-ietf-6man-rpl-option-03 (work in progress), draft-ietf-6man-rpl-option-06 (work in progress),
March 2011. December 2011.
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with RPL", Routing Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-03 (work in progress), draft-ietf-6man-rpl-routing-header-07 (work in progress),
March 2011. December 2011.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011. progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 45, line 23 skipping to change at page 46, line 19
of Standards and Technology, Nov. 26 2001. of Standards and Technology, Nov. 26 2001.
[Huang2003] [Huang2003]
Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J.
Zhang, "Fast Authenticated Key Establishment Protocols for Zhang, "Fast Authenticated Key Establishment Protocols for
Self-Organizing Sensor Networks", in Proceedings of the Self-Organizing Sensor Networks", in Proceedings of the
2nd ACM International Conference on Wireless Sensor 2nd ACM International Conference on Wireless Sensor
Networks and Applications, San Diego, CA, USA, pp. 141- Networks and Applications, San Diego, CA, USA, pp. 141-
150, Sept. 19 2003. 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-02 (work in
progress), July 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in Networks", draft-ietf-roll-terminology-06 (work in
progress), March 2011. progress), September 2011.
[I-D.suhopark-hello-wsn] [I-D.suhopark-hello-wsn]
Park, S., "Routing Security in Sensor Network: HELLO Flood Park, S., "Routing Security in Sensor Network: HELLO Flood
Attack and Defense", draft-suhopark-hello-wsn-00 (work in Attack and Defense", draft-suhopark-hello-wsn-00 (work in
progress), December 2005. progress), December 2005.
[IEEE1149.1] [IEEE1149.1]
"IEEE Standard Test Access Port and Boundary Scan "IEEE Standard Test Access Port and Boundary Scan
Architecture", IEEE-SA Standards Board, Jun. 14 2001. Architecture", IEEE-SA Standards Board, Jun. 14 2001.
 End of changes. 18 change blocks. 
58 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/