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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 14 July 2015 22:36 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 1D2A41B2EBC; Tue, 14 Jul 2015 15:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rWhI1G1es4oa; Tue, 14 Jul 2015 15:36:41 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC1C1B2EB2; Tue, 14 Jul 2015 15:36:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D3C43BE53; Tue, 14 Jul 2015 23:36:39 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pno0oe0sjhVA; Tue, 14 Jul 2015 23:36:37 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.19.158]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8C632BE4D; Tue, 14 Jul 2015 23:36:37 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1436913397; bh=Y6jl837AuspAyBZwQJ87UrS8ftKD+g9FcysapjMvitY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=NPWhCemwLP8ALdbF6dvBclxXfbUFk+eKxJUjnwaNZRb0proE5C0SRGMNAxz6bftR+ TRfaxQmRgvpB5nt1yePw9X1ntujAl0hya4fG6BTMfX++FCd8a2iTQ/0PEz7+StU9DL K0vAqwkMzaLbTuZBakGffhF0n0geBCPNU/TyvvUU=
Message-ID: <55A58EF4.9020700@cs.tcd.ie>
Date: Tue, 14 Jul 2015 23:36:36 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks <roll@ietf.org>
References: <20150713215425.24718.94967.idtracker@ietfa.amsl.com> <CADrU+dK0tx-QGersyDUBTuOxOWF1kZgfTxx8AqMC_AY_c4r4bQ@mail.gmail.com>
In-Reply-To: <CADrU+dK0tx-QGersyDUBTuOxOWF1kZgfTxx8AqMC_AY_c4r4bQ@mail.gmail.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/2zDBIS3s1Oz9ohL3kbY5V-IjoVs>
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: 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:36:45 -0000

Hiya,

On 14/07/15 23:17, Robert Cragie wrote:
> 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>

Right, that's what I thought. So I can't see how the text that
implies that only a subset of nodes on the network are using l2
security works which seems to be implied by the bullet just
before the start of 4.1.8.2.

All the stuff below is fine, so we're just down to the above in
terms of clearing the discuss.

Cheers,
S.

> 
>>
>> 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>
> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>