draft-ietf-roll-rpl-16.txt   draft-ietf-roll-rpl-17.txt 
ROLL T. Winter, Ed. ROLL T. Winter, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track P. Thubert, Ed. Intended status: Standards Track P. Thubert, Ed.
Expires: June 11, 2011 Cisco Systems Expires: June 18, 2011 Cisco Systems
A. Brandt A. Brandt
Sigma Designs Sigma Designs
T. Clausen T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
J. Hui J. Hui
Arch Rock Corporation Arch Rock Corporation
R. Kelsey R. Kelsey
Ember Corporation Ember Corporation
P. Levis P. Levis
Stanford University Stanford University
K. Pister K. Pister
Dust Networks Dust Networks
R. Struik R. Struik
JP. Vasseur JP. Vasseur
Cisco Systems Cisco Systems
December 8, 2010 December 15, 2010
RPL: IPv6 Routing Protocol for Low power and Lossy Networks RPL: IPv6 Routing Protocol for Low power and Lossy Networks
draft-ietf-roll-rpl-16 draft-ietf-roll-rpl-17
Abstract Abstract
Low power and Lossy Networks (LLNs) are a class of network in which Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained. LLN routers both the routers and their interconnect are constrained. LLN routers
typically operate with constraints on processing power, memory, and typically operate with constraints on processing power, memory, and
energy (battery power). Their interconnects are characterized by energy (battery power). Their interconnects are characterized by
high loss rates, low data rates, and instability. LLNs are comprised high loss rates, low data rates, and instability. LLNs are comprised
of anything from a few dozen and up to thousands of routers. of anything from a few dozen and up to thousands of routers.
Supported traffic flows include point-to-point (between devices Supported traffic flows include point-to-point (between devices
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 June 11, 2011. This Internet-Draft will expire on June 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 5, line 17 skipping to change at page 5, line 17
10.1. Security Overview . . . . . . . . . . . . . . . . . . . 90 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 90
10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 91 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 91
10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 92 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 92
10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 92 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 92
10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 93 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 93
10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 94 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 94
10.7. Reception of Incoming Packets . . . . . . . . . . . . . 95 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 95
10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 96 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 96
10.8. Coverage of Integrity and Confidentiality . . . . . . . 97 10.8. Coverage of Integrity and Confidentiality . . . . . . . 97
10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 97 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 97
10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 97 10.9.1. CCM Nonce . . . . . . . . . . . . . . . . . . . . . . 97
10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 98 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 98
11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 100 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 100
11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 100 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 100
11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 101 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 101
11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 102 11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 102
11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 102 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 102
12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 105 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 105
13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 107 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 107
14. Guidelines for Objective Functions . . . . . . . . . . . . . 108 14. Guidelines for Objective Functions . . . . . . . . . . . . . 108
14.1. Objective Function Behavior . . . . . . . . . . . . . . 108 14.1. Objective Function Behavior . . . . . . . . . . . . . . 108
skipping to change at page 37, line 10 skipping to change at page 37, line 10
Authentication Code of the specified length. The ENC attribute Authentication Code of the specified length. The ENC attribute
indicates that the message is encrypted. The Sign attribute indicates that the message is encrypted. The Sign attribute
indicates that the message has a signature of the specified indicates that the message has a signature of the specified
length. length.
Flags: 8-bit unused field reserved for flags. The field MUST be Flags: 8-bit unused field reserved for flags. The field MUST be
initialized to zero by the sender and MUST be ignored by the initialized to zero by the sender and MUST be ignored by the
receiver. receiver.
Counter: The Counter field indicates the non-repeating 4-octet value Counter: The Counter field indicates the non-repeating 4-octet value
(nonce) used with the cryptographic mechanism that implements used to construct the cryptographic mechanism that implements
packet protection and allows for the provision of semantic packet protection and allows for the provision of semantic
security. security. See Section 10.9.1.
Key Identifier: The Key Identifier field indicates which key was Key Identifier: The Key Identifier field indicates which key was
used to protect the packet. This field provides various levels used to protect the packet. This field provides various levels
of granularity of packet protection, including peer-to-peer of granularity of packet protection, including peer-to-peer
keys, group keys, and signature keys. This field is keys, group keys, and signature keys. This field is
represented as indicated by the Key Identifier Mode field and represented as indicated by the Key Identifier Mode field and
is formatted as follows: is formatted as follows:
0 1 2 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 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
skipping to change at page 45, line 30 skipping to change at page 45, line 30
The CC message is used to check secure message counters and issue The CC message is used to check secure message counters and issue
challenge/responses. A CC message MUST be sent as a secured RPL challenge/responses. A CC message MUST be sent as a secured RPL
message. message.
6.6.1. Format of the CC Base Object 6.6.1. Format of the CC Base Object
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |R| Flags | Nonce | | RPLInstanceID |R| Flags | CC Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID + + DODAGID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Counter | | Destination Counter |
skipping to change at page 46, line 16 skipping to change at page 46, line 16
associated with the DODAG, as learned from the DIO. associated with the DODAG, as learned from the DIO.
R: The 'R' flag indicates whether the CC message is a response. A R: The 'R' flag indicates whether the CC message is a response. A
message with the 'R' flag cleared is a request; a message with message with the 'R' flag cleared is a request; a message with
the 'R' flag set is a response. the 'R' flag set is a response.
Flags: 7-bit unused field reserved for flags. The field MUST be Flags: 7-bit unused field reserved for flags. The field MUST be
initialized to zero by the sender and MUST be ignored by the initialized to zero by the sender and MUST be ignored by the
receiver. receiver.
Nonce: 16-bit unsigned integer set by a CC request. The CC Nonce: 16-bit unsigned integer set by a CC request. The
corresponding CC response includes the same nonce value as the corresponding CC response includes the same CC nonce value as
request. the request.
Destination Counter: 32-bit unsigned integer value indicating the Destination Counter: 32-bit unsigned integer value indicating the
sender's estimate of the destination's current security Counter sender's estimate of the destination's current security Counter
value. If the sender does not have an estimate, it SHOULD set value. If the sender does not have an estimate, it SHOULD set
the Destination Counter field to zero. the Destination Counter field to zero.
Unassigned bits of the CC Base are reserved. They MUST be set to Unassigned bits of the CC Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception. zero on transmission and MUST be ignored on reception.
The Destination Counter value allows new or recovered nodes to The Destination Counter value allows new or recovered nodes to
skipping to change at page 93, line 5 skipping to change at page 93, line 5
10.4. Consistency Checks 10.4. Consistency Checks
RPL nodes send Consistency Check (CC) messages to protect against RPL nodes send Consistency Check (CC) messages to protect against
replay attacks and synchronize counters. replay attacks and synchronize counters.
1. If a node receives a unicast CC message with the R bit cleared, 1. If a node receives a unicast CC message with the R bit cleared,
and it is a member of or is in the process of joining the and it is a member of or is in the process of joining the
associated DODAG, it SHOULD respond with a unicast CC message to associated DODAG, it SHOULD respond with a unicast CC message to
the sender. This response MUST have the R bit set, and MUST have the sender. This response MUST have the R bit set, and MUST have
the same Nonce, RPLInstanceID and DODAGID fields as the message the same CC Nonce, RPLInstanceID and DODAGID fields as the
it received. message it received.
2. If a node receives a multicast CC message, it MUST discard the 2. If a node receives a multicast CC message, it MUST discard the
message with no further processing. message with no further processing.
Consistency Check messages allow nodes to issue a challenge-response Consistency Check messages allow nodes to issue a challenge-response
to validate a node's current Counter value. Because the CC Nonce is to validate a node's current Counter value. Because the CC Nonce is
generated by the challenger, an adversary replaying messages is generated by the challenger, an adversary replaying messages is
unlikely to be able to generate a correct response. The Counter in unlikely to be able to generate a correct response. The Counter in
the Consistency Check response allows the challenger to validate the the Consistency Check response allows the challenger to validate the
Counter values it hears. Counter values it hears.
skipping to change at page 94, line 36 skipping to change at page 94, line 36
the security section (T, Sec, KIM, and LVL) in the outgoing RPL the security section (T, Sec, KIM, and LVL) in the outgoing RPL
packet to describe the protection level and security settings that packet to describe the protection level and security settings that
are applied (see Section 6.1). The Security subfield bit of the RPL are applied (see Section 6.1). The Security subfield bit of the RPL
message Code field MUST be set to indicate the secure RPL message. message Code field MUST be set to indicate the secure RPL message.
The Counter value used in constructing the AES-128 CCM Nonce The Counter value used in constructing the AES-128 CCM Nonce
(Figure 31) to secure the outgoing packet MUST be an increment of the (Figure 31) to secure the outgoing packet MUST be an increment of the
last Counter transmitted to the particular destination address. last Counter transmitted to the particular destination address.
Where security policy specifies the application of delay protection, Where security policy specifies the application of delay protection,
the Timestamp Counter used in constructing the Nonce to secure the the Timestamp Counter used in constructing the CCM Nonce to secure
outgoing packet MUST be incremented according to the rules in the outgoing packet MUST be incremented according to the rules in
Section 10.5. Where a Timestamp Counter is applied (indicated with Section 10.5. Where a Timestamp Counter is applied (indicated with
the 'T' flag set) the locally maintained Time Counter MUST be the 'T' flag set) the locally maintained Time Counter MUST be
included as part of the transmitted secured RPL message. included as part of the transmitted secured RPL message.
The cryptographic algorithm used in securing the outgoing packet The cryptographic algorithm used in securing the outgoing packet
shall be specified by the node's security policy database and MUST be shall be specified by the node's security policy database and MUST be
indicated in the value of the Sec field set within the outgoing indicated in the value of the Sec field set within the outgoing
message. message.
The security policy for the outgoing packet shall determine the The security policy for the outgoing packet shall determine the
applicable Key Identifier Mode (KIM) and Key Identifier specifying applicable Key Identifier Mode (KIM) and Key Identifier specifying
the security key to be used for the cryptographic packet processing, the security key to be used for the cryptographic packet processing,
including the optional use of signature keys (see Section 6.1). The including the optional use of signature keys (see Section 6.1). The
security policy will also specify the algorithm (Algorithm) and level security policy will also specify the algorithm (Algorithm) and level
of protection (Level) in the form of authentication or authentication of protection (Level) in the form of authentication or authentication
and encryption, and potential use of signatures that shall apply to and encryption, and potential use of signatures that shall apply to
the outgoing packet. the outgoing packet.
Where encryption is applied, a node MUST replace the original packet Where encryption is applied, a node MUST replace the original packet
payload with that payload encrypted using the security protection, payload with that payload encrypted using the security protection,
key, and nonce specified in the security section of the packet. key, and CCM nonce specified in the security section of the packet.
All secured RPL messages include integrity protection. In All secured RPL messages include integrity protection. In
conjunction with the security algorithm processing, a node derives conjunction with the security algorithm processing, a node derives
either a Message Authentication Code (MAC) or signature that MUST be either a Message Authentication Code (MAC) or signature that MUST be
included as part of the outgoing secured RPL packet. included as part of the outgoing secured RPL packet.
10.7. Reception of Incoming Packets 10.7. Reception of Incoming Packets
This section describes the reception and processing of a secured RPL This section describes the reception and processing of a secured RPL
packet. Given an incoming secured RPL packet, where the Security packet. Given an incoming secured RPL packet, where the Security
skipping to change at page 95, line 40 skipping to change at page 95, line 40
MUST NOT send any messages in response. These policies can include MUST NOT send any messages in response. These policies can include
security levels, keys used, source identifiers, or the lack of security levels, keys used, source identifiers, or the lack of
timestamp-based counters (as indicated by the 'T' flag). The timestamp-based counters (as indicated by the 'T' flag). The
configuration of the security policy database for incoming packet configuration of the security policy database for incoming packet
processing is out of scope for this specification (it may, for processing is out of scope for this specification (it may, for
example, be defined through DIO Configuration or through out-of-band example, be defined through DIO Configuration or through out-of-band
administrative router configuration). administrative router configuration).
Where the message security level (LVL) indicates an encrypted RPL Where the message security level (LVL) indicates an encrypted RPL
message, the node uses the key information identified through the KIM message, the node uses the key information identified through the KIM
field as well as the Nonce as input to the message payload decryption field as well as the CCM Nonce as input to the message payload
processing. The Nonce shall be derived from the message Counter decryption processing. The CCM Nonce shall be derived from the
field and other received and locally maintained information (see message Counter field and other received and locally maintained
Section 10.9.1). The plaintext message contents shall be obtained by information (see Section 10.9.1). The plaintext message contents
invoking the inverse cryptographic mode of operation specified by the shall be obtained by invoking the inverse cryptographic mode of
Sec field of the received packet. operation specified by the Sec field of the received packet.
The receiver shall use the Nonce and identified key information to The receiver shall use the CCM Nonce and identified key information
check the integrity of the incoming packet. If the integrity check to check the integrity of the incoming packet. If the integrity
fails against the received message authentication code (MAC), a node check fails against the received message authentication code (MAC), a
MUST discard the packet. node MUST discard the packet.
If the received message has an initialized (zero value) Counter value If the received message has an initialized (zero value) Counter value
and the receiver has an incoming Counter currently maintained for the and the receiver has an incoming Counter currently maintained for the
originator of the message, the receiver MUST initiate a Counter originator of the message, the receiver MUST initiate a Counter
resynchronization by sending a Consistency Check response message resynchronization by sending a Consistency Check response message
(see Section 6.6) to the message source. The Consistency Check (see Section 6.6) to the message source. The Consistency Check
response message shall be protected with the current full outgoing response message shall be protected with the current full outgoing
Counter maintained for the particular node address. That outgoing Counter maintained for the particular node address. That outgoing
Counter will be included within the security section of the message Counter will be included within the security section of the message
while the incoming Counter will be included within the Consistency while the incoming Counter will be included within the Consistency
skipping to change at page 97, line 28 skipping to change at page 97, line 28
zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPSec zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPSec
Authenticated Header). MAC and signature calculations are performed Authenticated Header). MAC and signature calculations are performed
before any compression that lower layers may apply. before any compression that lower layers may apply.
When a RPL ICMPv6 message is encrypted, encryption starts at the When a RPL ICMPv6 message is encrypted, encryption starts at the
first byte after the security section and continues to the last byte first byte after the security section and continues to the last byte
of the packet. The IPv6 header, ICMPv6 header, and RPL message up to of the packet. The IPv6 header, ICMPv6 header, and RPL message up to
the end of the security section are not encrypted, as they are needed the end of the security section are not encrypted, as they are needed
to correctly decrypt the packet. to correctly decrypt the packet.
For example, a node sending a message with LVL=5, KIM=0, and For example, a node sending a message with LVL=1, KIM=0, and
Algorithm=0 uses the CCM algorithm[RFC3610] to create a packet with Algorithm=0 uses the CCM algorithm [RFC3610] to create a packet with
attributes ENC-MAC-32: it encrypts the packet and appends a 32-bit attributes ENC-MAC-32: it encrypts the packet and appends a 32-bit
MAC. The block cipher key is determined by the Key Index; the Nonce MAC. The block cipher key is determined by the Key Index; the CCM
is computed as described in Section 10.9.1; the message to Nonce is computed as described in Section 10.9.1; the message to
authenticate and encrypt is the RPL message starting at the first authenticate and encrypt is the RPL message starting at the first
byte after the security section and ends with the last byte of the byte after the security section and ends with the last byte of the
packet; the additional authentication data starts with the beginning packet; the additional authentication data starts with the beginning
of the IPv6 header and ends with the last byte of the RPL security of the IPv6 header and ends with the last byte of the RPL security
section. section.
10.9. Cryptographic Mode of Operation 10.9. Cryptographic Mode of Operation
The cryptographic mode of operation described in this specification The cryptographic mode of operation described in this specification
(Algorithm = 0) is based on CCM and the block-cipher AES- (Algorithm = 0) is based on CCM and the block-cipher AES-
128[RFC3610]. This mode of operation is widely supported by existing 128[RFC3610]. This mode of operation is widely supported by existing
implementations. CCM mode requires a nonce. implementations. CCM mode requires a nonce (CCM nonce).
10.9.1. Nonce 10.9.1. CCM Nonce
A RPL node constructs a CCM nonce as follows: A RPL node constructs a CCM nonce as follows:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Source Identifier + + Source Identifier +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter | | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved | LVL | |KIM|Resvd| LVL |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 31: CCM Nonce Figure 31: CCM Nonce
Source Identifier: 8 bytes. Source Identifier is set to the logical Source Identifier: 8 bytes. Source Identifier is set to the logical
identifier of the originator of the protected packet. identifier of the originator of the protected packet.
Counter: 4 bytes. Counter is set to the (uncompressed) value of the Counter: 4 bytes. Counter is set to the (uncompressed) value of the
corresponding field in the Security option of the RPL control corresponding field in the Security option of the RPL control
message. message.
Key Identifier Mode (KIM): 2 bits. KIM is set to the value of the
corresponding field in the Security option of the RPL control
message.
Security Level (LVL): 3 bits. Security Level is set to the value of Security Level (LVL): 3 bits. Security Level is set to the value of
the corresponding field in the Security option of the RPL the corresponding field in the Security option of the RPL
control message. control message.
Unassigned bits of the nonce are reserved. They MUST be set to zero Unassigned bits of the CCM nonce are reserved. They MUST be set to
when constructing the nonce. zero when constructing the CCM nonce.
All fields of the nonce are represented in most-significant-octet and All fields of the CCM nonce are represented in most-significant-octet
most-significant-bit first order. and most-significant-bit first order.
10.9.2. Signatures 10.9.2. Signatures
If the Key Identification Mode (KIM) mode indicates the use of If the Key Identification Mode (KIM) mode indicates the use of
signatures (a value of 3), then a node appends a signature to the signatures (a value of 3), then a node appends a signature to the
data payload of the packet. The Security Level (LVL) field describes data payload of the packet. The Security Level (LVL) field describes
the length of this signature. the length of this signature.
The signature scheme in RPL for Security Mode 3 is an instantiation The signature scheme in RPL for Security Mode 3 is an instantiation
of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of
[RFC3447]. It uses as public key the pair (n,e), where n is a 2048- [RFC3447]. It uses as public key the pair (n,e), where n is a 2048-
bit or 3072-bit RSA modulus and where e=2^{16}+1. It uses CCM mode bit or 3072-bit RSA modulus and where e=2^{16}+1. It uses CCM mode
[RFC3610] as the encryption scheme with M=0 (as a stream-cipher). [RFC3610] as the encryption scheme with M=0 (as a stream-cipher).
Note that although [RFC3610] disallows CCM mode with M=0, this
specification explicitly allows CCM mode with M=0 when used in Note that although [RFC3610] disallows the CCM mode with M=0, RPL
conjunction with a signature as in this case, because the signature explicitly allows the CCM mode with M=0 when used in conjunction with
provides sufficient protection. It uses the SHA-256 hash function a signature, because the signature provides sufficient data
specified in Section 6.2 of [FIPS180]. It uses the message encoding authentication. Here, the CCM mode with M=0 is specified as in
rules of Section 8.1 of [RFC3447]. [RFC3610], but where the M' field in Section 2.2 MUST be set to 0.
It uses the SHA-256 hash function specified in Section 6.2 of
[FIPS180]. It uses the message encoding rules of Section 8.1 of
[RFC3447].
Let 'a' be a concatenation of a six-byte representation of Counter Let 'a' be a concatenation of a six-byte representation of Counter
and the message header. The packet payload is the right- and the message header. The packet payload is the right-
concatenation of packet data 'm' and the signature 's'. This concatenation of packet data 'm' and the signature 's'. This
signature scheme is invoked with the right-concatenation of the signature scheme is invoked with the right-concatenation of the
message parts a and m, whereas the signature verification is invoked message parts a and m, whereas the signature verification is invoked
with the right-concatenation of the message parts a and m, and with with the right-concatenation of the message parts a and m, and with
signature s. signature s.
RSA signatures of this form provide sufficient protection for RPL RSA signatures of this form provide sufficient protection for RPL
skipping to change at page 127, line 18 skipping to change at page 127, line 18
Timeliness (delay protection): Assurance that transmitted Timeliness (delay protection): Assurance that transmitted
information was received in a timely manner. information was received in a timely manner.
The actual protection provided can be adapted on a per-packet basis The actual protection provided can be adapted on a per-packet basis
and allows for varying levels of data authenticity (to minimize and allows for varying levels of data authenticity (to minimize
security overhead in transmitted packets where required) and for security overhead in transmitted packets where required) and for
optional data confidentiality. When nontrivial protection is optional data confidentiality. When nontrivial protection is
required, replay protection is always provided. required, replay protection is always provided.
Replay protection is provided via the use of a non-repeating value Replay protection is provided via the use of a non-repeating value
(nonce) in the packet protection process and storage of some status (CCM nonce) in the packet protection process and storage of some
information for each originating device on the receiving device, status information (originating device and the CCM nonce counter last
which allows detection of whether this particular nonce value was received from that device), which allows detection of whether this
used previously by the originating device. In addition, so-called particular CCM nonce value was used previously by the originating
delay protection is provided amongst those devices that have a device. In addition, so-called delay protection is provided amongst
loosely synchronized clock on board. The acceptable time delay can those devices that have a loosely synchronized clock on board. The
be adapted on a per-packet basis and allows for varying latencies (to acceptable time delay can be adapted on a per-packet basis and allows
facilitate longer latencies in packets transmitted over a multi-hop for varying latencies (to facilitate longer latencies in packets
communication path). transmitted over a multi-hop communication path).
Cryptographic protection may use a key shared between two peer Cryptographic protection may use a key shared between two peer
devices (link key) or a key shared among a group of devices (group devices (link key) or a key shared among a group of devices (group
key), thus allowing some flexibility and application-specific key), thus allowing some flexibility and application-specific
tradeoffs between key storage and key maintenance costs versus the tradeoffs between key storage and key maintenance costs versus the
cryptographic protection provided. If a group key is used for peer- cryptographic protection provided. If a group key is used for peer-
to-peer communication, protection is provided only against outsider to-peer communication, protection is provided only against outsider
devices and not against potential malicious devices in the key- devices and not against potential malicious devices in the key-
sharing group. sharing group.
skipping to change at page 141, line 25 skipping to change at page 141, line 25
[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-01 (work in progress), draft-ietf-6man-rpl-routing-header-01 (work in progress),
October 2010. October 2010.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-13 (work in progress), draft-ietf-roll-routing-metrics-14 (work in progress),
December 2010. December 2010.
[I-D.ietf-roll-trickle] [I-D.ietf-roll-trickle]
Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", draft-ietf-roll-trickle-06 (work "The Trickle Algorithm", draft-ietf-roll-trickle-06 (work
in progress), December 2010. in progress), December 2010.
[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.
 End of changes. 25 change blocks. 
53 lines changed or deleted 60 lines changed or added

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