Early Review of draft-ietf-roll-rpl-industrial-applicability-02
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
The document is well written and was quite educational for me. However
the Security Considerations section is incomplete and not quite ready.
> This document does not specify operations that could introduce new
> threats. Security considerations for RPL deployments are to be
> developed in accordance with recommendations laid out in, for
> example, [I-D.tsao-roll-security-framework].
This document got obsoleted by a WG document. I am not entirely sure
whether this is intended to be draft-ietf-roll-security-threats or
draft-ietf-roll-security-framework. Please update your draft to point to
the latest document.
> Industrial automation networks are subject to stringent security
> requirements as they are considered a critical infrastructure
> component. At the same time, since they are composed of large
> numbers of resource- constrained devices inter-connected with
> limited-throughput links, many available security mechanisms are
> not practical for use in such networks. As a result, the choice of
> security mechanisms is highly dependent on the device and network
> capabilities characterizing a particular deployment.
While this sounds plausible, this is not very helpful for deployments.
Are there any documents (maybe even research papers) that talk about
different types of deployments and suitable security mechanisms for them?
> In contrast to other types of LLNs, in industrial automation
> networks centralized administrative control and access to
> a permanent secure infrastructure is available.
> As a result link-layer, transport-layer
> and/or application-layer security mechanisms are typically in place
> and may make use of RPL's secure mode unnecessary.
Pointing to RFC 6550 and describing how RPL security services described
there can be replaced by link/transport/application-layer technologies
would be helpful as well.
> 6.1. Security Considerations during initial deployment
> 6.2. Security Considerations during incremental deployment
These sections need completing. Looking at
draft-ietf-roll-applicability-template-03, I can see there a useful
pointer to a document about getting initial keys and trust anchors.