Subject: [Roll] updates/changes in security-threats

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Dec 2013 21:39:04 -0500

<HAT OFF>

Last night I posted draft-ietf-roll-security-threats-06.
The diff from -04 to -06 is likely more useful.

http://www.ietf.org/rfcdiff?url1=draft-ietf-roll-security-threats-04&difftype=--html&submit=Go%21&url2=draft-ietf-roll-security-threats-06

1) I believe that I have closed all of the comments that came up during
   the security directorate review of the document.
   Please see: http://goo.gl/A5uYb0 for the list of closed tickets.

2) I have been through the text, and changed "ROLL" to "RPL".
   This is a document about security threats relevant to the protocol
   in RFC6550, not some hypothetical future protocol.

3) A few revisions ago, I moved a </section>, and caused many sections
   to get moved up a level and renumbered.  That was an error, and I
   changed that back.  Teach me to read only the XML version.

4) where it makes sense I have referred to specific features or attributes
   of RFC6550 which mitigate certain attacks.  For instance, in section
   6.2.4 explains how, I think that trickle mitigates many replay attacks,
   as trickle's reaction to idempotent information is to do nothing.
   Further, section 6.3.1.  Countering HELLO Flood Attacks and ACK Spoofing
   Attacks, I explained how the DAO-ACK confirms bidirectionality.

5) I wrote:
   -> For distance vector protocols, such as RPL, where information is <-
   and well, maybe I'm wrong. I just thought I'd check :-)

6) I have touched little of section 7, except for removing a chunk,
   and then stopping...  Does this section still serve any purpose
   now that I've incorporated the RPL specific defense mechanisms into
   section 6? ("Countermeasures")

7) There is new normative reference to ZigBeeIP,
   ROLL-terminology,
   [RFC6719]  MRHOF.

   non-normative to: [AceCharterProposal], MLE, RFC3610,
   RFC6192 "Protecting the Router Control Plane"
   RFC6574 "Report from the Smart Object Workshop"
   RFC6824  MPTCP
   SmartObjectSecurityWorkshop -- was there ever a report on this?
   The Solace IRTF "proposal".

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-