Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT)

Robert Cragie <robert.cragie@gridmerge.com> Tue, 14 July 2015 22:17 UTC

Return-Path: <robert.cragie@gmail.com>
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 3D1011B2E76; Tue, 14 Jul 2015 15:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 sws9meJpzcox; Tue, 14 Jul 2015 15:17:37 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADCC1B2E77; Tue, 14 Jul 2015 15:17:37 -0700 (PDT)
Received: by qkcl188 with SMTP id l188so16459180qkc.1; Tue, 14 Jul 2015 15:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ng82KcwdLzOgCHDLX9G4K2YwiexL4OFNyc8SzxIeuaM=; b=hUhG/QUyh3dnklxKmhIwI6UDgRD4BadsL8EyNBYoHNa/nzRTGZe3rZQvROMYPeBAqh k+dWPOVT4QOH6Y+7FfHlyssRZ6Rs9SO+FL5xhT1R8cIlw8egCsy0zK70GX/V6xIlWM02 1KcxtJA4VW4RSoT/7u0L1IGiCXgKU3Ybh8FHlZ5rGD7Qel4al4tsXUHp8q9DtlEpxzE3 zdWvRz07mlgjfqPdl71O+pDcoz3BG7pFyxEIP50Vg2iryxJ3RociRgsYQa/4C6sQVWyM KLksnMtPGSa0LfsYpoTBeyoG69MLU8ODRsWs793lg9JpOSNSLD2MulxP1GGhniFtHYyv 5VSg==
MIME-Version: 1.0
X-Received: by 10.55.15.129 with SMTP id 1mr1854256qkp.29.1436912256805; Tue, 14 Jul 2015 15:17:36 -0700 (PDT)
Sender: robert.cragie@gmail.com
Received: by 10.140.108.182 with HTTP; Tue, 14 Jul 2015 15:17:36 -0700 (PDT)
In-Reply-To: <20150713215425.24718.94967.idtracker@ietfa.amsl.com>
References: <20150713215425.24718.94967.idtracker@ietfa.amsl.com>
Date: Tue, 14 Jul 2015 23:17:36 +0100
X-Google-Sender-Auth: 0r1YOgVsYpA6vIio-nsWLDS7Seg
Message-ID: <CADrU+dK0tx-QGersyDUBTuOxOWF1kZgfTxx8AqMC_AY_c4r4bQ@mail.gmail.com>
From: Robert Cragie <robert.cragie@gridmerge.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary=001a1146f100a3f296051add34bf
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/rV7LdmZ8qADbdrPvzXB1ENYgpaU>
Cc: roll-chairs@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-roll-applicability-home-building@ietf.org, Yvonne-Anne Pignolet <yvonneanne.pignolet@gmail.com>, draft-ietf-roll-applicability-home-building.shepherd@ietf.org
Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-11: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com, 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: <https://mailarchive.ietf.org/arch/browse/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, 14 Jul 2015 22:17:40 -0000

Hi Stephen,

Thanks for your further review. Answers and comments inline, bracketed by
<RCC></RCC>

Robert

1) This could be my ignorance of zigbee, but how can we
> use layer 2 security for only some network nodes?  (In
> other words, I don't see how 4.1.8.2 works.)
>

<RCC>All network nodes use L2 security once they have joined the network.
Prior to that, they communicate using an authentication protocol which is
unsecured at L2. Enforcement points police unsecured traffic to ensure it
is only related to authentication, thus preventing data or other control
plane traffic unsecured at L2 from being allowed into the network. So, to
your point, the only traffic allowed unsecured at L2 is authentication
traffic and those nodes are not yet participating in the network.</RCC>

>
> 2) Just checking - this depends on the zigbeeip
> authentication mechanism, with which I'm also not
> familiar, sorry. Does using that mean that this entire
> applicability statement only covers use of RPL where
> zigbee radios are in use? Or can that authentication
> scheme be used independently of the radio technology
> used? (I mean used in practice there, not in theory.)
>

<RCC>The authentication scheme is independent of the radio technology as it
is based on UDP/IP and therefore could be use with a number of different
radio technologies or indeed other MAC/PHY technologies</RCC>

- 4.1.8: "MUST be present" is ambiguous - do you mean
> it must be used? I think you do.
>

<RCC>Yes</RCC>

- 4.1.8: "MUST be distributed or established in a
> secure fashion" isn't really a protocol requirement.
> Do you really just mean "see 4.1.8.1" ?
>

<RCC>Yes. It was meant more as an introductory statement but is redundant
really</RCC>

OLD COMMENTS FOR -10 below, I didn't check if you'd made
> any related changes.
>

<RCC>These seem to apply more to -09. Some of these were fixed in -10, some
in -11 </RCC>


> - I don't get how there's an IPR disclosure for this, but
> whatever.
>

<RCC>Not from me, so I can't comment on that</RCC>

- The non-security parts of this were quite a good read.
>
> - 4.1.8: 1st sentence makes no sense. It says RPL does X or
> not-X in order to Y. There is no choice but for RPL to do X or
> not-X.
>
> - 4.1.8 seems to me to imply that link layer security is
> always needed since there can always be some node that will
> send an unsecured RPL messsage. If you agree, then I think
> that should be made more clear. If you disagree, I'd like to
> understand how.
>
> - 4.1.8, I am surprised not to see a recommendation that
> separate group keys SHOULD be used for different applications
> in the same bulding network. But that may be too fine grained
> a recommendation for this document perhaps.
>

<RCC>No longer applicable as 4.1.8 has been completely rewritten.</RCC>


>
> - 5.1.2.1, I think it'd be clearer to say Imin should be
> between 10 and 50 ms. The "10 - 50 ms" notation can be
> confusing. (Same elsewhere.)
>

<RCC>Used "to" instead of "-"</RCC>

>
> - section 7, 3rd para, "can rely on" is sales language, please
> strike that or s/rely on/depend upon/
>
> - section 7, 3rd para, last sentence: this is sales language
> and should be deleted. Or perhaps s/is/SHOULD be/ would turn
> it back into a piece of specification language.
>

<RCC>Paragraph has been rewritten</RCC>

>
> - 7.1 - this is odd text to see in a proposed standard, but I
> think it's accurately describing the level of interop to
> expect in RPL security, so is probably the right thing to say.
> I'd argue that it'd be even better to bluntly admit/say that
> there is currently no interoperable automated key management
> for RPL. (Same for 7.3) Or, and better, to fix that lack. (See
> my discuss point.)
>

<RCC>Section has been rewritten</RCC>

>
> - 7.2, 1st sentence: this is meaningless as I read it - what
> are you trying to say?
>

<RCC>Section has been rewritten</RCC>

>
> - 7.2, when a node is stolen, the chances are that any keys
> contained in the node are at significant risk of being leaked.
>

<RCC>The text has been changed but probably doesn't meet your requirements
regarding this point. I would say nodes have to be re-keyed at L2 and MAY
need to have additional measures taken depending on the other credentials
they have and how the confidential information is stored. e.g. certificate
revocation..</RCC>

>
> - 7.3, I do not believe that [I-D.keoh-dice-multicast-security]
> is necessarily going to proceed via the DICE WG. Depending
> on it would be fairly high-risk in any case.
>

<RCC>Has been removed</RCC>

>
> - 7.4, last sentence: more sales talk
>

<RCC>I'm not sure we even need a section on MPL; MPL has nothing to do with
RPL. Assuming we do, this is still outstanding, so I suggest replacing "The
application of security measures for the specification of the multicast
addresses assures that the routing of MPL packets is secured." with
something like "For secure dissemination of MPL packets, layer 2 security
SHOULD be used and the configuration of multicast addresses MUST be secure."

>
> - 7.5, what is this specifying? I don't get it. Does 7416 set
> out what to implement to get interop? (I didn't think so, but
> nor does this seem to.)
>

<RCC>This is still outstanding. I think it is OK to briefly highlight the
steps being taken to mitigate against the threats outlined in RFC 7416. The
statement "Key management discussed in section 7.4, "Key Management" of
[RFC7416], is not standardized and discussions continue." is now not
relevant as there is now a proposal in this document. I will work with
Peter to produce some new text on this.</RCC>