[Roll] AD review of draft-ietf-roll-security-threats

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 08 August 2014 17:00 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5A3331A045D for <roll@ietfa.amsl.com>; Fri, 8 Aug 2014 10:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BpIj-ayOUxRa for <roll@ietfa.amsl.com>; Fri, 8 Aug 2014 10:00:35 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967471A0407 for <roll@ietf.org>; Fri, 8 Aug 2014 10:00:35 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain []) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78H0Xht019353; Fri, 8 Aug 2014 18:00:33 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com []) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78H0WHH019345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 18:00:32 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-ietf-roll-security-threats@tools.ietf.org
Date: Fri, 08 Aug 2014 18:00:31 +0100
Message-ID: <039901cfb32a$4396fa40$cac4eec0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac+zKjbjWAt8/OXPR76hTX4S1nHWDg==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--10.129-10.0-31-10
X-imss-scan-details: No--10.129-10.0-31-10
X-TMASE-MatchedRID: uM/FAQ+OoQfLLefpbEkxkJmug812qIbzbv16+gil4jc3Z3efQH+wj0j8 AtVpDcmg30nY8d71auJnI/RGosR8EpVSBURTFYjQoMo9pWsaF6VlrsuS5tC+P/W2znIlYDjDRiX 6fzbAQPUvK5dSZworPLHR1wcQzR2o06P6nK44odAItCy6ZX/lLx852jgffnmI+yNYYwngrxbvv/ IA2HPk+OByqm2JX7QD3Fu/vVUHOxojc2rIhESDRt35+5/2Rxqmbb9qvlMXO4Kyd65qZFFPk2mCt i+JzZB1MzGNNFA7dQEbZLZQawUR5v3oDYuWRaGYEhGH3CRdKUUHZg6HZbmAcfgnJH5vm2+g1BoO 0FXL0sgf8ff5tbWyxfcKXYM536/nF0rpaZ47th8SuhBXNJb1dEyQ5fRSh265BMjYv8ffQVVnKwn YEuaPmLjObRk3pjhHg8SU+T+Au5YzjsQsSbMmptcd9O3aJYmbRtu4vtjjtzQJW4Re2U2py2Rkbo 3bzUFsYu0aFyYZk872vyDIp/5VLuVHGbcDbAq6OX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPIfiAqr jYtFiQXY+x/7KhI2QdJb2/QOA/yhaNhoUTlUMsjarW1v8ENY37cGd19dSFd
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Fkopu0WsY70RxuYKB5geKUyeb4g
Cc: roll@ietf.org
Subject: [Roll] AD review of draft-ietf-roll-security-threats
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 17:00:38 -0000

Hi authors,

I have conducted my usual AD review of your document having received a
publication request. The purpose of the review is to make sure that the
document is in the best possible shape to go through IETF last call and
IESG evaluation.

Thank you for taking the time and investing the effort on this
important document.

I find the content readable and easy to understand (thank you). I'm not
a security expert, but what you have written is clear and credible. Good

There is just a small set of editorial issues that I would like you to 
clean up before I run the IETF last call.

I'll put the document into "Revised I-D Needed" state and wait for you
to post a revision.

Thanks for the work,


The references are a mess as indicated by idnits and the Shepherd


The point here is that you can't just include something in the 
references section because you think it is a fine document or you are
friends with the author :-)  If a document is worth reading in the
context of this I-D, then there should be a mention of it somewhere 
(appropriate) in the text. If there is nowhere that you find it 
appropriate to mention the reference, then remove it from the references

[I-D.ietf-roll-terminology] is now RFC 7102.


A few abbreviations are used without expansion.



Your one use of RFC 2119 language outside Section 8 is unnecessary.

   RPL uses multicast as part of it's protocol,
   and therefore mechanisms which RPL uses to secure this traffic MAY be
   applicable to MPL control traffic as well: the important part is that
   the threats are similiar.

s/MAY/might also/

Furthermore, while your use of 2119 in Section 8 is fine with me, it is
not in harmony with the boilerplate you have included after the

I suggest you move it to Section 3, and have it read...

   Although this is not a protocol specification, the key words "MUST", 
   document are to be interpreted as described in RFC 2119 [RFC2119] in 
   order to clarify and emphasize the guidance and directions to 
   implementers and deployers of LLN nodes that utilize RPL.


4.3 is a helpful way to present things. I think that "Limited energy,
memory, and processing node resources" also needs to highlight the
increased susceptibility of LLN nodes to denial of service attacks since
it is not only easier o swamp such nodes, but they can be exhausted to
the extent that they are never able to function again! Such an attack
may be mounted through the routing plane (and impact both routing and
data forwarding) or through the data plane (to impact both forwarding
and routing). Thus, there is also an interdependency between the two
planes that may be tighter in LLNs than in other networks.