draft-ietf-roll-applicability-home-building-06.txt   draft-ietf-roll-applicability-home-building-07.txt 
Roll A. Brandt Roll A. Brandt
Internet-Draft Sigma Designs Internet-Draft Sigma Designs
Intended status: Informational E. Baccelli Intended status: Informational E. Baccelli
Expires: June 4, 2015 INRIA Expires: July 23, 2015 INRIA
R. Cragie R. Cragie
ARM ARM
P. van der Stok P. van der Stok
Consultant Consultant
December 01, 2014 January 19, 2015
Applicability Statement: The use of the RPL protocol suite in Home Applicability Statement: The use of the RPL protocol suite in Home
Automation and Building Control Automation and Building Control
draft-ietf-roll-applicability-home-building-06 draft-ietf-roll-applicability-home-building-07
Abstract Abstract
The purpose of this document is to provide guidance in the selection The purpose of this document is to provide guidance in the selection
and use of protocols from the RPL protocol suite to implement the and use of protocols from the RPL protocol suite to implement the
features required for control in building and home environments. features required for control in building and home environments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 4, 2015. This Internet-Draft will expire on July 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 3, line 21 skipping to change at page 3, line 21
7.3. Security Considerations for P2P uses . . . . . . . . . . 21 7.3. Security Considerations for P2P uses . . . . . . . . . . 21
7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 21
7.5. RPL Security features . . . . . . . . . . . . . . . . . . 21 7.5. RPL Security features . . . . . . . . . . . . . . . . . . 21
8. Other related protocols . . . . . . . . . . . . . . . . . . . 22 8. Other related protocols . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. RPL shortcomings in home and building deployments . 27 Appendix A. RPL shortcomings in home and building deployments . 28
A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 27 A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 28
A.1.1. Traffic concentration at the root . . . . . . . . . . 28 A.1.1. Traffic concentration at the root . . . . . . . . . . 28
A.1.2. Excessive battery consumption in source nodes . . . . 28 A.1.2. Excessive battery consumption in source nodes . . . . 28
A.2. Risk of delayed route repair . . . . . . . . . . . . . . 28 A.2. Risk of delayed route repair . . . . . . . . . . . . . . 28
A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 28 A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 29
Appendix B. Communication failures . . . . . . . . . . . . . . . 29 Appendix B. Communication failures . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The primary purpose of this document is to give guidance in the use The primary purpose of this document is to give guidance in the use
of the RPL protocol suite in two application domains: of the RPL protocol suite in two application domains:
o Home automation o Home automation
skipping to change at page 4, line 33 skipping to change at page 4, line 33
text describes a subset of those protocols and the conditions under text describes a subset of those protocols and the conditions under
which the subset is appropriate and provides recommendations and which the subset is appropriate and provides recommendations and
requirements for the accompanying parameter value ranges. requirements for the accompanying parameter value ranges.
In addition, an extension document has been produced specifically to In addition, an extension document has been produced specifically to
provide a solution for reactive discovery of point-to-point routes in provide a solution for reactive discovery of point-to-point routes in
LLNs [RFC6997]. The present applicability document provides LLNs [RFC6997]. The present applicability document provides
recommendations and requirements for the accompanying parameter value recommendations and requirements for the accompanying parameter value
ranges. ranges.
A common set of security threats are described in A common set of security threats are described in [RFC7416]. The
[I-D.ietf-roll-security-threats]. The applicability statements applicability statements complement the security threats document by
complement the security threats document by describing preferred describing preferred security settings and solutions within the
security settings and solutions within the applicability statement applicability statement conditions. This applicability statement
conditions. This applicability statement recommends more light recommends more light weight security solutions and specify the
weight security solutions and specify the conditions under which conditions under which these solutions are appropriate.
these solutions are appropriate.
1.2. Requirements language 1.2. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Terminology 1.3. Terminology
This document uses terminology from [RFC6997], This document uses terminology from [RFC6997],
skipping to change at page 19, line 43 skipping to change at page 19, line 43
In building control, management is mandatory. It is expected that In building control, management is mandatory. It is expected that
installations will be managed using the set of currently available installations will be managed using the set of currently available
tools(including IETF tools like MIBS, NETCONF modules, DHCP and tools(including IETF tools like MIBS, NETCONF modules, DHCP and
others) with large differences between the ways an installation is others) with large differences between the ways an installation is
managed. managed.
7. Security Considerations 7. Security Considerations
This section refers to the security considerations of [RFC6997], This section refers to the security considerations of [RFC6997],
[RFC6550], [I-D.ietf-roll-trickle-mcast], and the counter measures [RFC6550], [I-D.ietf-roll-trickle-mcast], and the counter measures
discussed in sections 6 and 7 of [I-D.ietf-roll-security-threats]. discussed in sections 6 and 7 of [RFC7416].
Communications network security is based on providing integrity Communications network security is based on providing integrity
protection and encryption to messages. This can be applied at protection and encryption to messages. This can be applied at
various layers in the network protocol stack based on using various various layers in the network protocol stack based on using various
credentials and a network identity. credentials and a network identity.
The credentials which are relevant in the case of RPL are: (i) the The credentials which are relevant in the case of RPL are: (i) the
credential used at the link layer in the case where link layer credential used at the link layer in the case where link layer
security is applied (see Section 7.1) or (ii) the credential used for security is applied (see Section 7.1) or (ii) the credential used for
securing RPL messages. In both cases, the assumption is that the securing RPL messages. In both cases, the assumption is that the
skipping to change at page 20, line 38 skipping to change at page 20, line 38
order to prevent unauthorized parties from accessing the information order to prevent unauthorized parties from accessing the information
exchanged over the links. It is good practice to create a network of exchanged over the links. It is good practice to create a network of
nodes which share the same keys for link layer security and exclude nodes which share the same keys for link layer security and exclude
nodes sending unsecured messages. With per-message data origin nodes sending unsecured messages. With per-message data origin
authentication, it is possible to prevent unauthorized nodes joining authentication, it is possible to prevent unauthorized nodes joining
the mesh. the mesh.
At initial deployment the network is secured by consecutively At initial deployment the network is secured by consecutively
securing nodes at the link layer, thus building a network of secured securing nodes at the link layer, thus building a network of secured
nodes. The Protocol for carrying Authentication for Network Access nodes. The Protocol for carrying Authentication for Network Access
(PANA) Relay Element [RFC6345] in conjunction with PANA [RFC5191] (PANA) [RFC5191] with an Extensible Authentication Protocol (EAP)
provides a framework for network access and delivery of common link provides a framework for network access and delivery of common link
keys. keys. Several versions of EAP exist. ZigBee specifies the use of
EAP-TLS [RFC5216]. Wi-SUN HAN (Home Area Network) uses EAP-PSK
[RFC4764], which also looks promising for building control at this
moment.
New approaches to initial security deployment are being developed in New approaches to initial security deployment are being developed in
[I-D.kumar-dice-dtls-relay] and [I-D.kumar-dice-dtls-relay] and
[I-D.richardson-6tisch--security-6top]. Other initiatives are likely [I-D.richardson-6tisch--security-6top]. They assume a partial
to emerge in the context of minimal intervention configuration. At ordering of the nodes, such that unsecured nodes are added
this moment it is not clear what the final most widely deployed sequentially with the restriction that a path between two secured
solution will be. nodes exists which passes through secured nodes only. Other
initiatives are likely to emerge in the context of minimal
intervention configuration.
For building control an installer will probably use an installation For building control an installer will probably use an installation
tool that establishes a secure communication path with the joining tool that establishes a secure communication path with the joining
node. In the home, nodes can be visually inspected by the home owner node. In the home, nodes can be visually inspected by the home owner
and simple measures like pushing buttons simultaneously on joint and and simple measures like pushing buttons simultaneously on joint and
joining devices is probably sufficient. joining devices is probably sufficient.
This recommendation is in line with the countermeasures described in This recommendation is in line with the countermeasures described in
section 6.1.1 of [I-D.ietf-roll-security-threats] section 6.1.1 of [RFC7416]
7.2. Security Considerations during incremental deployment 7.2. Security Considerations during incremental deployment
When nodes are lost, no additional security measures are needed, the When nodes are lost, no additional security measures are needed, the
network remains secure as before by not allowing the addition of new network remains secure as before by not allowing the addition of new
nodes. New nodes can be added by using the same protocols used for nodes. New nodes can be added by using the same protocols used for
initial deployment. Some protocols may need a state change to a initial deployment. Some protocols may need a state change to a
subset of the secured nodes, other protocols only need the presence subset of the secured nodes, other protocols only need the presence
of a "trusted" installation node [RFC6345], [RFC5191], or of a "trusted" installation node [RFC6345], [RFC5191], or
[I-D.kumar-dice-dtls-relay]. [I-D.kumar-dice-dtls-relay].
skipping to change at page 21, line 31 skipping to change at page 21, line 37
Refer to the security considerations of [RFC6997]. Many initiatives Refer to the security considerations of [RFC6997]. Many initiatives
are under way to provide lighter weight security such as: are under way to provide lighter weight security such as:
[I-D.ietf-dice-profile] and [I-D.keoh-dice-multicast-security] [I-D.ietf-dice-profile] and [I-D.keoh-dice-multicast-security]
7.4. MPL routing 7.4. MPL routing
The routing of MPL is determined by the enabling of the interfaces The routing of MPL is determined by the enabling of the interfaces
for specified Multicast addresses. The specification of these for specified Multicast addresses. The specification of these
addresses can be done via a CoAP application as specified in addresses can be done via a CoAP application as specified in
[I-D.ietf-core-groupcomm]. An alternative is the creation of a MPL [RFC7390]. An alternative is the creation of a MPL MIB and use of
MIB and use of SNMPv3 [RFC3411] or equivalent techniques to specify SNMPv3 [RFC3411] or equivalent techniques to specify the Multicast
the Multicast addresses in the MIB. The application of security addresses in the MIB. The application of security measures for the
measures for the specification of the multicast addresses assures specification of the multicast addresses assures that the routing of
that the routing of MPL packets is secured. MPL packets is secured.
7.5. RPL Security features 7.5. RPL Security features
This section follows the structure of section 7, "RPL security This section follows the structure of section 7, "RPL security
features" of [I-D.ietf-roll-security-threats], where a thorough features" of [RFC7416], where a thorough analysis of security threats
analysis of security threats and proposed counter measures relevant and proposed counter measures relevant to RPL and MPL are done.
to RPL and MPL are done.
In accordance with section 7.1 of [I-D.ietf-roll-security-threats], In accordance with section 7.1 of [RFC7416], "Confidentiality
"Confidentiality features", a secured RPL protocol implements payload features", a secured RPL protocol implements payload protection, as
protection, as explained in Section 7 of this document. The explained in Section 7 of this document. The attributes key-length
attributes key-length and life-time of the keys depend on operational and life-time of the keys depend on operational conditions,
conditions, maintenance and installation procedures. maintenance and installation procedures.
Section 7.1 and Section 7.2 of this document recommend link-layer Section 7.1 and Section 7.2 of this document recommend link-layer
measures to assure integrity in accordance with section 7.2 of measures to assure integrity in accordance with section 7.2 of
[I-D.ietf-roll-security-threats], "Integrity features". [RFC7416], "Integrity features".
The provision of multiple paths recommended in section 7.3 The provision of multiple paths recommended in section 7.3
"Availability features" of [I-D.ietf-roll-security-threats] is also "Availability features" of [RFC7416] is also recommended from a
recommended from a reliability point of view. Randomly choosing reliability point of view. Randomly choosing paths is a possibility.
paths is a possibility.
Key management discussed in section 7.4, "Key Management" of Key management discussed in section 7.4, "Key Management" of
[I-D.ietf-roll-security-threats], is not standardized and discussions [RFC7416], is not standardized and discussions continue.
continue.
Section 7.5, "Considerations on Matching Application Domain Needs" of Section 7.5, "Considerations on Matching Application Domain Needs" of
[I-D.ietf-roll-security-threats] applies as such. [RFC7416] applies as such.
8. Other related protocols 8. Other related protocols
Application and transport protocols used in home and building Application and transport protocols used in home and building
automation domains are expected to mostly consist in CoAP over UDP, automation domains are expected to mostly consist in CoAP over UDP,
or equivalents. Typically, UDP is used for IP transport to keep down or equivalents. Typically, UDP is used for IP transport to keep down
the application response time and bandwidth overhead. CoAP is used the application response time and bandwidth overhead. CoAP is used
at the application layer to reduce memory footprint and bandwidth at the application layer to reduce memory footprint and bandwidth
requirements. requirements.
9. IANA Considerations 9. IANA Considerations
No considerations for IANA pertain to this document. No considerations for IANA pertain to this document.
10. Acknowledgements 10. Acknowledgements
This document reflects discussions and remarks from several This document reflects discussions and remarks from several
individuals including (in alphabetical order): Mukul Goyal, Sandeep individuals including (in alphabetical order): Mukul Goyal, Sandeep
Kumar, Jerry Martocci, Charles Perkins, Michael Richardson, and Zach Kumar, Jerry Martocci, Charles Perkins, Yvonne-Anne Pignolet, Yoshira
Shelby Ohba, Michael Richardson, and Zach Shelby
11. Changelog 11. Changelog
Changes from version 0 to version 1. Changes from version 0 to version 1.
o Adapted section structure to template. o Adapted section structure to template.
o Standardized the reference syntax. o Standardized the reference syntax.
o Section 2.2, moved everything concerning algorithms to section o Section 2.2, moved everything concerning algorithms to section
skipping to change at page 24, line 15 skipping to change at page 24, line 18
o Replaced RFC2119 terminology by non-normative terminology o Replaced RFC2119 terminology by non-normative terminology
o Rearranged text of section 7, 7.1, and 7.2 to agree with the o Rearranged text of section 7, 7.1, and 7.2 to agree with the
intention of section 7.2 intention of section 7.2
Changes from version 5 to version 6. Changes from version 5 to version 6.
o Issues #162 - #166 addressed o Issues #162 - #166 addressed
Changes from version 6 to version 6.
o Text of section 7.1 edited for better security coverage.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, January 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008. Access (PANA)", RFC 5191, May 2008.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy "Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009. Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy "Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009. Networks", RFC 5673, October 2009.
skipping to change at page 25, line 34 skipping to change at page 26, line 5
Low-Power and Lossy Networks", RFC 6997, August 2013. Low-Power and Lossy Networks", RFC 6997, August 2013.
[RFC6998] Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A [RFC6998] Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A
Mechanism to Measure the Routing Metrics along a Point-to- Mechanism to Measure the Routing Metrics along a Point-to-
Point Route in a Low-Power and Lossy Network", RFC 6998, Point Route in a Low-Power and Lossy Network", RFC 6998,
August 2013. August 2013.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, January 2014. Lossy Networks", RFC 7102, January 2014.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, "A Security Threat Analysis for the
Routing Protocol for Low-Power and Lossy Networks (RPLs)",
RFC 7416, January 2015.
[I-D.ietf-roll-trickle-mcast] [I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle- and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-11 (work in progress), November 2014. mcast-11 (work in progress), November 2014.
[I-D.ietf-roll-security-threats]
Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, "A Security Threat Analysis for Routing
Protocol for Low-power and lossy networks (RPL)", draft-
ietf-roll-security-threats-11 (work in progress), October
2014.
[IEEE802.15.4] [IEEE802.15.4]
"IEEE 802.15.4 - Standard for Local and metropolitan area "IEEE 802.15.4 - Standard for Local and metropolitan area
networks -- Part 15.4: Low-Rate Wireless Personal Area networks -- Part 15.4: Low-Rate Wireless Personal Area
Networks", <IEEE Standard 802.15.4>. Networks", <IEEE Standard 802.15.4>.
[G.9959] "ITU-T G.9959 Short range narrow-band digital [G.9959] "ITU-T G.9959 Short range narrow-band digital
radiocommunication transceivers - PHY and MAC layer radiocommunication transceivers - PHY and MAC layer
specifications", <ITU-T G.9959>. specifications", <ITU-T G.9959>.
12.2. Informative References 12.2. Informative References
skipping to change at page 26, line 23 skipping to change at page 26, line 38
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA) Relay Element", RFC 6345, August 2011. Access (PANA) Relay Element", RFC 6345, August 2011.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014. Constrained-Node Networks", RFC 7228, May 2014.
[RFC7390] Rahman, A. and E. Dijk, "Group Communication for the
Constrained Application Protocol (CoAP)", RFC 7390,
October 2014.
[I-D.ietf-6lo-lowpanz] [I-D.ietf-6lo-lowpanz]
Brandt, A. and J. Buron, "Transmission of IPv6 packets Brandt, A. and J. Buron, "Transmission of IPv6 packets
over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08 over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08
(work in progress), October 2014. (work in progress), October 2014.
[I-D.ietf-dice-profile] [I-D.ietf-dice-profile]
Tschofenig, H., "A Datagram Transport Layer Security Tschofenig, H. and T. Fossati, "A TLS/DTLS 1.2 Profile for
(DTLS) 1.2 Profile for the Internet of Things", draft- the Internet of Things", draft-ietf-dice-profile-08 (work
ietf-dice-profile-05 (work in progress), October 2014. in progress), December 2014.
[I-D.keoh-dice-multicast-security] [I-D.keoh-dice-multicast-security]
Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A.
Rahman, "DTLS-based Multicast Security in Constrained Rahman, "DTLS-based Multicast Security in Constrained
Environments", draft-keoh-dice-multicast-security-08 (work Environments", draft-keoh-dice-multicast-security-08 (work
in progress), July 2014. in progress), July 2014.
[I-D.kumar-dice-dtls-relay] [I-D.kumar-dice-dtls-relay]
Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay
for Constrained Environments", draft-kumar-dice-dtls- for Constrained Environments", draft-kumar-dice-dtls-
relay-02 (work in progress), October 2014. relay-02 (work in progress), October 2014.
[I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-25 (work in progress), September
2014.
[I-D.richardson-6tisch--security-6top] [I-D.richardson-6tisch--security-6top]
Richardson, M., "6tisch secure join using 6top", draft- Richardson, M., "6tisch secure join using 6top", draft-
richardson-6tisch--security-6top-04 (work in progress), richardson-6tisch--security-6top-04 (work in progress),
November 2014. November 2014.
[SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL [SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL
Routing Protocol for IPv6 Sensor Networks: Testbed Routing Protocol for IPv6 Sensor Networks: Testbed
Experiments", Proceedings of the Conference on Software Experiments", Proceedings of the Conference on Software
Telecommunications and Computer Networks, Split, Croatia,, Telecommunications and Computer Networks, Split, Croatia,,
September 2011. September 2011.
 End of changes. 29 change blocks. 
60 lines changed or deleted 69 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/