[Roll] updates/changes in security-threats

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 17 December 2013 02:39 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359811AE049 for <roll@ietfa.amsl.com>; Mon, 16 Dec 2013 18:39:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.905
X-Spam-Level:
X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_MIME_NO_TEXT=0.01, T_TVD_MIME_NO_HEADERS=0.01, URIBL_RHS_DOB=1.514] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND3wgRXSDQwV for <roll@ietfa.amsl.com>; Mon, 16 Dec 2013 18:39:22 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 97EB71AE036 for <roll@ietf.org>; Mon, 16 Dec 2013 18:39:21 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A18252017E for <roll@ietf.org>; Mon, 16 Dec 2013 22:53:17 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 4B76163B8A; Mon, 16 Dec 2013 21:39:04 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3CC8763848 for <roll@ietf.org>; Mon, 16 Dec 2013 21:39:04 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 16 Dec 2013 21:39:04 -0500
Message-ID: <22189.1387247944@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [Roll] updates/changes in security-threats
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: 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: Tue, 17 Dec 2013 02:39:24 -0000

<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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-