One document matched: draft-struik-roll-rpl-security-design-00.txt
Networking Working Group R.Struik
Internet Draft Certicom Corp.
Intended status: Informational March 1, 2010
Expires: September 1, 2010
Security Design for the IPv6 Routing Protocol for Low Power and
Lossy Networks (RPL)
draft-struik-roll-rpl-security-design-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
This Internet-Draft will expire on September 1, 2010.
Struik Expires September 1, 2010 [Page 1]
Internet-Draft Security Design for RPL March 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 Simplified BSD License.
Abstract
We discuss a security design for the IPv6 Routing Protocol for Low
Power and Lossy Networks (RPL). While the design focuses on
communication security, we also discuss cross-layering aspects and
security policy considerations.
Table of Contents
1. Introduction...................................................2
2. Functional description of packet protection....................5
2.1. Transmission of outgoing packets..........................5
2.1.1. Outgoing packet security procedure...................5
2.2. Reception of incoming packets.............................6
2.2.1. Incoming packet security procedure...................6
3. Packet Formatting..............................................8
4. Information elements...........................................8
5. Security Considerations........................................9
6. IANA Considerations............................................9
7. Conclusions....................................................9
8. Future Work....................................................9
9. References....................................................10
9.1. Normative references.....................................10
9.2. Informative references...................................12
10. Acknowledgments..............................................13
1. Introduction
From a security perspective, wireless adhoc networks are no different
from any other wireless network. They are vulnerable to passive
Struik Expires September 1, 2010 [Page 2]
Internet-Draft Security Design for RPL March 2010
eavesdropping attacks and potentially even active tampering because
physical access to the wire is not required to participate in
communications. The very nature of ad hoc networks and their cost
objectives impose additional security constraints, which perhaps make
these networks the most difficult environments to secure. Devices are
low-cost and have limited capabilities in terms of computing power,
available storage, and power drain; and it cannot always be assumed
they have neither a trusted computing base nor a high-quality random
number generator aboard. Communications cannot rely on the online
availability of a fixed infrastructure and might involve short-term
relationships between devices that may never have communicated before.
These constraints might severely limit the choice of cryptographic
algorithms and protocols and would influence the design of the security
architecture because the establishment and maintenance of trust
relationships between devices need to be addressed with care. In
addition, battery lifetime and cost constraints put severe limits on
the security overhead these networks can tolerate, something that is of
far less concern with higher bandwidth networks. Most of these security
architectural elements can be implemented at higher layers and may,
therefore, be considered to be outside the scope of this standard.
Special care, however, needs to be exercised with respect to interfaces
to these higher layers.
The security mechanisms in this standard are based on symmetric-key and
public-key cryptography and use keys that are provided by higher layer
processes. The establishment and maintenance of these keys are outside
the scope of this standard. The mechanisms assume a secure
implementation of cryptographic operations and secure and authentic
storage of keying material.
The security mechanisms specified provide particular combinations of
the following security services:
o Data confidentiality: Assurance that transmitted information is
only disclosed to parties for which it is intended.
o Data authenticity: Assurance of the source of transmitted
information (and, hereby, that information was not modified in
transit).
o Replay protection: Assurance that a duplicate of transmitted
information is detected.
Struik Expires September 1, 2010 [Page 3]
Internet-Draft Security Design for RPL March 2010
o Timeliness (delay protection): Assurance that transmitted
information was received in a timely manner.
The actual protection provided can be adapted on a per-packet basis and
allows for varying levels of data authenticity (to minimize security
overhead in transmitted packets where required) and for optional data
confidentiality. When nontrivial protection is required, replay
protection is always provided.
Replay protection is provided via the use of a non-repeating value
(nonce) in the packet protection process and storage of some status
information for each originating device on the receiving device, which
allows detection of whether this particular nonce value was used
previously by the originating device. In addition, so-called delay
protection is provided amongst those devices that have a loosely
synchronized clock on board. The acceptable time delay can be adapted
on a per-packet basis and allows for varying latencies (to facilitate
longer latencies in packets transmitted over a multi-hop communication
path).
Cryptographic protection may use a key shared between two peer devices
(link key) or a key shared among a group of devices (group key), thus
allowing some flexibility and application-specific tradeoffs between
key storage and key maintenance costs versus the cryptographic
protection provided. If a group key is used for peer-to-peer
communication, protection is provided only against outsider devices and
not against potential malicious devices in the key-sharing group.
Data authenticity may be provided using symmetric-key based or public-
key based techniques. With public-key based techniques (via
signatures), one corroborates evidence as to the unique originator of
transmitted information, whereas with symmetric-key based techniques
data authenticity is only provided relative to devices in a key-sharing
group. Thus, public-key based authentication may be useful in scenarios
that require a more fine-grained authentication than can be provided
with symmetric-key based authentication techniques alone, such as with
group communications (broadcast, multicast), or in scenarios that
require non-repudiation.
Struik Expires September 1, 2010 [Page 4]
Internet-Draft Security Design for RPL March 2010
2. Functional description of packet protection
2.1. Transmission of outgoing packets
For each transmitted packet, the current time, if any, shall be recorded
and used in the outgoing packet security procedure described in Section
2.1.1. If that procedure is not successful, the packet shall not be
processed further and a status code indicating the purported source of
the error shall be generated with sufficient granularity so as to allow
a subsequent process to act upon this error and perform a failure
recovery and/or error logging and reporting operation; otherwise, the
packet may be communicated.
2.1.1. Outgoing packet security procedure
Input: outgoing packet, required security protection; time of handling.
Output: secured packet, status information.
The outgoing packet security procedure shall include the following
steps:
1. If no cryptographic security protection is required, the procedure
shall return with the secured packet set to the packet to be
secured.
2. The procedure shall derive the nonce to be used to protect the
outgoing packet from locally maintained counter information and
the time of handling and shall report an error code if this
derivation process fails.
3. The procedure shall construct the security-related header fields
of the protected packet and insert these into the packet according
to the procedure described in Section 3. The security-related
header fields shall encode information regarding the security
protection to be applied to the packet and the key and nonce to be
used to protect the packet with sufficient granularity so as to
allow a recipient to recover that information uniquely.
4. The procedure shall execute the cryptographic mode of operation
with as inputs the packet header and packet payload resulting from
the previous step, the security protection to be applied to the
packet, the indicated key to be used, and the nonce value obtained
before.
Struik Expires September 1, 2010 [Page 5]
Internet-Draft Security Design for RPL March 2010
5. The procedure shall suitably combine the payload field with the
output of the cryptographic transformation and substitute the
payload field by the thus obtained field, thus yielding the
secured packet.
6. The procedure shall check whether the thus obtained secured packet
satisfies syntax checks (e.g., on resulting packet length) and
shall perform security policy checks (e.g., as to whether the
security protection applied and the key and nonce value used
satisfy locally maintained security policies for that packet in
question) and shall report an error code if any of these checks
fail.
7. The procedure shall update the locally maintained nonce
information, so as to preclude reconstruction of the same nonce
value twice.
8. The procedure shall return with the thus secured packet.
2.2. Reception of incoming packets
For each received packet, the time of receipt, if any, shall be recorded
and used in the incoming packet security procedure specified in 2.2.1.
If that procedure is not successful, the packet shall not be processed
further and a status code indicating the purported source of the error
shall be generated with sufficient granularity so as to allow a
subsequent process to act upon this error and perform a failure recovery
and/or error logging and reporting operation; otherwise, the packet may
be processed further.
2.2.1. Incoming packet security procedure
Input: received packet; time of receipt.
Output: unsecured packet, status information
The incoming packet security procedure shall include the following
steps:
1. The procedure shall derive the purported security protection
applied to the packet from the packet's security-related header
fields according to the procedure described in Section 3.
2. The procedure shall perform security policy checks (e.g., whether
the security protection applied satisfies locally maintained
security policies for that packet in question) and shall report an
error code if this check fails.
Struik Expires September 1, 2010 [Page 6]
Internet-Draft Security Design for RPL March 2010
3. If those security policy checks succeeded and the purported
security protection indicates that no cryptographic security
protection has been applied, the procedure shall return with the
unsecured packet set to the packet to be unsecured.
4. The procedure shall derive the purported originator of the packet
from the packet header according and convert this to the logical
identifier for that device according the device table described in
Section 3.
5. The procedure shall perform security policy checks (e.g., whether
the security protection applied satisfies locally maintained
security policies for that packet and that originating device in
question) and shall report an error code if this check fails.
6. The procedure shall derive the purported nonce used to protect the
packet from the packet's security-related header fields and the
time of receipt.
7. The procedure shall perform security policy checks on the nonce
value derived in the previous step and locally maintained status
information, including that for the device logically identified in
Step 4 above. This shall include checking whether the nonce value
obtained in the previous step cannot possibly have been used by
the originating device before (thus, providing replay detection)
and, checking whether that counter value corresponds to a recently
communicated packet (thus, providing timeliness). The procedure
shall report an error code if any of these checks fail.
8. The procedure shall derive the purported key used to protect the
packet from information contained in the packet's security-related
header fields and obtain the actual key thus identified from
locally maintained status information according to the key table
described in Section 4. The procedure shall report an error code
if this procedure fails.
9. The procedure shall perform key-related security policy checks
(e.g., whether the key applied satisfies locally maintained
security policies for that packet and for that originating device
in question) and shall report an error code if this check fails.
10.The procedure shall execute the inverse cryptographic mode of
operation with as inputs the packet header and packet payload, the
security protection purportedly applied to the packet and the key
and the nonce value purportedly used to secure the packet.
Struik Expires September 1, 2010 [Page 7]
Internet-Draft Security Design for RPL March 2010
11.If this procedure fails, the procedure shall report an error code;
otherwise, it shall suitably combine the payload field with the
output of the cryptographic transformation and substitute the
payload field by the thus obtained field, thus yielding the
unsecured packet.
12.The procedure shall update the locally maintained nonce
information for the originating device, so as to preclude
successful reception of packets from the same originating device
with the same nonce value twice.
13.The procedure shall return with the thus unsecured packet.
3. Packet Formatting
The security design described here can be implemented with the
general packet format defined in [11], as follows:
o Security subfield.
Specify bit b4 of the so-called DIO base ([11], Fig. 4) as
Security subfield. This field shall indicate whether security is
applied to the packet.
o Security-related header.
Specify the security-related header field as the leftmost DIO sub-
option field ([11], Fig. 5). This sub-option field shall be
present only if the security subfield is set to one.
o Packet payload (from security processing perspective).
All sub-option fields except the leftmost DIO sub option field
shall be considered as packet payload from a security processing
perspective.
4. Information elements
These should be further detailed with a next version of this
document.
Struik Expires September 1, 2010 [Page 8]
Internet-Draft Security Design for RPL March 2010
5. Security Considerations
This document describes a security design for the IPv6 Routing
Protocol for Low Power and Lossy Networks (RPL).
6. IANA Considerations
This document contains no request to IANA.
7. Conclusions
We presented a security design for communication security for the IPv6
Routing Protocol for Low Power and Lossy Networks (RPL) and discussed
cross-layer aspects and security policy considerations.
The design is tailored towards low overall implementation cost, by
providing an orthogonal design that separates general security
constructs and specific security policy settings and that takes cross-
layer aspects and trust lifecycle management consideration of security
design into account.
An application-specific instantiation of this security design (e.g., to
serve specific needs identified in [4], [5], [6], [7]) can be realized
via proper security policy settings.
The design allows for different levels of granularity of security
services, via the use of group keys, ranging from coarse-grained
protection against outsider devices only (via a network-wide key) to
more fine-grained protection relative to a particular multicast group
(via a group key) or relative to an peer-to-peer connection (via a link
key). The use of group keys also supports semi-automatic lifecycle
management, by facilitating key management due to, e.g., network
topology changes and due to changes in trust models underlying network
operations. For more details, we refer to, e.g., [8].
8. Future Work
As for now, the security design focuses on communication security
aspects and does not pay great attention to communication stack layering
and trust lifecycle management aspects. Moreover, scant attention is
being paid to the impact of insider attacks and of compromised devices
on network operations. This should be addressed in a future version of
this document.
Struik Expires September 1, 2010 [Page 9]
Internet-Draft Security Design for RPL March 2010
With the current RPL design [11], there seems to be room for
significantly reducing the over-the-air per-packet communication
overhead. While not strictly a security concern, the use of proper
cryptographic techniques can assist in enhancing robustness of overhead
reduction techniques at relatively low cost (cf., e.g., [9]). Similarly,
there seems to be room for significantly reducing the amount of security
state maintained on communicating devices. This should also be addressed
in a future version of this document.
This being said, some of this work is being undertaken with other IETF
groups, such as, e.g., 6lowapp ([8], [10]). Assumptions and design
considerations need to be validated with 6lowapp charter and may result
in emanating work that may find a home in different IETF groups.
9. References
9.1. Normative references
[1] J.P. Vasseur, ''Terminology in Low power And Lossy Networks,''
draft-ietf-roll-terminology-02, October 8, 2009.
[2] P. Thubert, Ed., ''RPL Objective Function 0,'' draft-ietf-roll-of0-
01, February 18, 2010.
[3] J.P. Vasseur, M. Kim, Eds., K. Pister, H. Chong, ''Routing Metrics
used for Path Calculation in Low Power and Lossy Networks,'' draft-
ietf-roll-routing-metrics-04, December 3, 2009.
[4] A. Brandt, J. Buron, G. Porcu, ''Home Automation Routing
Requirements in Low Power and Lossy Networks,'' draft-ietf-roll-home-
routing-reqs-11, January 3, 2010.
[5] J. Martocci, P. de Mil, W. Vermeylen, N. Riou, ''Building Automation
Routing Requirements in Low Power and Lossy Networks,'' draft-ietf-
roll-building-routing-reqs-09, January 28, 2010.
[6] RFC 5548, Routing Requirements for Urban Low-Power and Lossy
Networks, M. Dohler, T. Watteyne, T. Winger, D. Barthel, May 2009.
[7] RFC 5673, Industrial Routing Requirements in Low-Power and Lossy
Networks, Internet Request for Comments, K. Pister, P. Thubert, S.
Dwars, T. Phinney, October 2009.
Struik Expires September 1, 2010 [Page 10]
Internet-Draft Security Design for RPL March 2010
[8] R. Struik, ''Security Architectural Design Considerations for Low-
Power Wireless Sensor Networks,'' draft-struik-6lowapp-security-
considerations-00, Oct 19, 2009.
[9] R. Struik, ''Security and Efficiency Enhancements,'' IEEE
802.15/08/828r9, June 17, 2009. Available from
https://mentor.ieee.org/802.15/.
[10] C. O'Flynn, ''Initial Configuration of Resource-Constrained
Devices,'' draft-oflynn-6lowapp-bootstrapping-00, January 27, 2010.
[11] T. Winter, T. Winter, P. Thubert, Eds., ''RPL: IPv6 Routing Protocol
for Low power and Lossy Networks,'' draft-ietf-roll-rpl-06, February
3, 2010.
[12] T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, Eds., ''A
Security Framework for Routing over Low Power and Lossy Networks,''
draft-tsao-roll-security-framework-01, September 20, 2009.
[13] ANSI X9.92, Public Key Cryptography for the Financial Services
Industry - Digital Signature Algorithms Giving Partial Message
Recovery - Part 1: Elliptic Curve Pintsov-Vanstone Signatures
(ECPVS), American Bankers Association, 2009. Available from
http://www.ansi.org.
[14] ANSI X9.63-2001, Public Key Cryptography for the Financial Services
Industry - Key Agreement and Key Transport Using Elliptic Curve
Cryptography, American Bankers Association, November 20, 2001.
Available from http://www.ansi.org.
[15] FIPS Pub 186-2, Digital Signature Standard (DSS), Federal
Information Processing Standards Publication 186-2, US Department of
Commerce/National Institute of Standards and Technology,
Gaithersburg, Maryland, USA, January 27, 2000. (Includes change
notice, October 5, 2001.)
[16] FIPS Pub 197, Advanced Encryption Standard (AES), Federal
Information Processing Standards Publication 197, US Department of
Commerce/N.I.S.T., Springfield, Virginia, November 26, 2001.
Available from: http://csrc.nist.gov/.
[17] Institute of Electrical and Electronics Engineers, Inc., IEEE Std.
802.15.4-2006, IEEE Standard for 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)
Struik Expires September 1, 2010 [Page 11]
Internet-Draft Security Design for RPL March 2010
Specifications for Low Rate Wireless Personal Area Networks (WPANs),
New York: IEEE Press, 2006. (Revision of IEEE Std 802.15.4-2006.)
[18] NIST Pub 800-38C, Recommendation for Block Cipher Modes of
Operation - The CCM Mode for Authentication and Confidentiality,
NIST Special Publication 800-38C, US Department of
Commerce/N.I.S.T., Springfield, Virginia, May 2004. Available from
http://csrc.nist.gov/.
9.2. Informative references
[19] E. Callaway, T.S. Messerges, J. Cukier, T.A.M. Kevenaar, L. Puhl,
R. Struik, ''A Security Design for a General Purpose, Self-
Organizing, Multihop Ad Hoc Wireless Network, in Proceedings of the
2003 ACM Workshop on Security of Adhoc and Sensor Networks (SASN),
George Mason University, Fairfax, VA, October 31, 2003.
[20] L.F. Cranor, S. Garfinkel, Eds., Security and Usability: Designing
Secure Systems That People Can Use, Cambridge: O'Reilly, 2005.
[21] C. Karlof, D. Wagner, ''Secure Routing in Wireless Sensor Networks:
Attacks and Countermeasures,'' in Proceedings of the First IEEE
International Workshop on Sensor Network Protocols and Applications
(SNPA), May 11, 2003.
[22] C. Karlof, N. Sastry, D. Wagner, ''TinySec: A Link Layer Security
Architecture for Wireless Sensor Networks,'' in Proceedings of the
Second ACM Conference on Embedded Networked Sensor Systems - SenSys
2004, November 2004.
[23] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied
Cryptography, Boca Raton: CRC Press, 1997.
[24] U.S. Department of Energy, Industrial Wireless Technology for the
21st Century, December 2002. Available from
http://www.oit.doe.gov/sens_cont/pdfs/wireless_technology.pdf
[25] D. Wagner, ''Security for Sensor Networks: Cryptography and Beyond,''
in Proceedings of the 2003 ACM Workshop on Security of Adhoc and
Sensor Networks (SASN), George Mason University, Fairfax, VA,
October 31, 2003.
[26] A.S. Wander, N. Gura, H. Eberle, V. Gupta, S.C. Shantz, ''Energy
Analysis of Public-Key Cryptography for Wireless Sensor Networks,''
Struik Expires September 1, 2010 [Page 12]
Internet-Draft Security Design for RPL March 2010
in Proceedings of the Third IEEE International Conference on
Pervasive Computing - PerCom 2005, 2005.
[27] ZigBee Alliance, 'ZigBee General MRD,' ZigBee document 03/143r0ZB,
June 24, 2003.
10. Acknowledgments
This submission is influenced by discussions with IETF members and
members of the IEEE 802 and ZigBee communities. (Individual members
to be acknowledged in person in later version of this document.)
Struik Expires September 1, 2010 [Page 13]
Internet-Draft Security Design for RPL March 2010
Authors' address:
R. Struik
Certicom Corp.
5520 Explorer Drive, 4th Floor
Mississauga, ON
Canada L4W 5L1
Phone: +1 (905) 501-6083
Email: rstruik@certicom.com
Struik Expires September 1, 2010 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-22 13:22:44 |