Re: [6lowpan] #142: Stephen Farrel's Discuss comments
Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 29 May 2012 11:09 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA6421F87DE for <6lowpan@ietfa.amsl.com>; Tue, 29 May 2012 04:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.399
X-Spam-Level:
X-Spam-Status: No, score=-100.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MANGLED_NAIL=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuQ3ogeiCzEg for <6lowpan@ietfa.amsl.com>; Tue, 29 May 2012 04:09:31 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id F200721F87D6 for <6lowpan@ietf.org>; Tue, 29 May 2012 04:09:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6B4A3171472; Tue, 29 May 2012 12:09:29 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338289768; bh=tKnpA69OcT2JTk SnDZLSptao7nkODR+7sGEwXjG+DTg=; b=0uZLarGizox6TRIqR+ISlR8Vnlt75W zytwTnQz8Rjm9kxEzWZjsBFsZk/lpLY+YlD7akAFVeKYDC4lACDH5o24coR8Z9AM geQu5FfKx2AHrEq3aztj6jttDlSarZwJgSyqN5QZAX8iz1fvnstyXZz6U4aufoKa ZUIIAmCt/zbRkYwyd5bQSFwo0K7rIBlOBWYtNOwUXc3IQpEDlRivpS9HeWYVV2B9 Uii5PIvzDSoNZUHoZ8zFL3AUwC9Svk/eMM42HC2CMnMIY85XmkWRez1S6UeC2wSD c8m+aXxDGKeT/OuR37XG5UPXaBXSY6v77QDPePV8akS+77KuwctvVLIg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Pc9xZDqLEmUg; Tue, 29 May 2012 12:09:28 +0100 (IST)
Received: from [IPv6:2001:770:10:203:746a:67db:b7ac:1c60] (unknown [IPv6:2001:770:10:203:746a:67db:b7ac:1c60]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 95E2C171479; Tue, 29 May 2012 12:09:25 +0100 (IST)
Message-ID: <4FC4AE65.2010209@cs.tcd.ie>
Date: Tue, 29 May 2012 12:09:25 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: 6lowpan@ietf.org
References: <073.83786121cd4cc06dbcd9434dafab8de5@trac.tools.ietf.org>
In-Reply-To: <073.83786121cd4cc06dbcd9434dafab8de5@trac.tools.ietf.org>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Wed, 30 May 2012 08:06:55 -0700
Cc: 6lowpan issue tracker <trac+6lowpan@trac.tools.ietf.org>, draft-ietf-6lowpan-nd@tools.ietf.org
Subject: Re: [6lowpan] #142: Stephen Farrel's Discuss comments
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2012 11:09:32 -0000
Hi, Those changes look good or at least good enough to shoot out a new rev and I can clear down all or almost all of my discuss points. Thanks, S. On 05/29/2012 03:16 AM, 6lowpan issue tracker wrote: > #142: Stephen Farrel's Discuss comments > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > #1 1.4 - "it is assumed that 6LRs register with all the 6LBRs." is > ambiguous - does it mean each 6LR registers with some 6LBR or s/each/all/ > or s/some/all/ or both? Assuming that all 6LRs are registered with all > 6LBRs would seem to be too difficult and unwise so I think this needs > fixing. > > RESPONSE==> ‘each 6LR to register with all the configured 6LBR in the > 6LowPAN’. This is the intended meaning. We will also flag this with > 6lowpan wg. > > #2 1.4 - Why would probabilistic uniqueness of non-EUI-64-derived > addresses not be sufficient in some networks? If it is, then the "must be > either assigned or checked" seems wrong. > > RESPONSE===> We are consistent with RFC 4862 section 5.4. It is > recommended that non-EUI-64 addresses should be checked for uniqueness if > they are not assigned by a reliable entity. > > #3 3.2 - Does this mean that if I can pretend to be a router I can force > (some) nodes to change their addresses? If so, why is that not mentioned > as an attack in the security considerations? (If IP-address based node > reputation ever evolved for nodes like these then this would be serious > attack - misbehave as addr1, pretend to be a DHCP server and then force > addr1 on some other innocent node.) > > RESPONSE====> Same security consideration as RFC 4862 applies. We will > update the first line of security consideration section to refer to RFC > 4862 to address this comment. Thus it will say: > "The security considerations of IPv6 Neighbor Discovery [RFC4861] and > [RFC4862] apply" > > #4 3.3 - How long is a sleeping node expected to say awake when sending a > registration message? Is that long enough to get an error saying its > chosen address is in use already? If not, then what prevents that node > constantly re-awakening and using the duplicate address (or many identical > such nodes doing that all the time)? > (Saying "A host retransmits...until..." later in that section isn't clear > enough really - there's no 2119 language there at all so I don't know if > that's a MUST or MAY.) > > RESPONSE===> We will make a change in the document to make the optional > behaviors as default (MUST) in order to address Adrian Farrell's comment. > > The draft provides some default recommendations in section 9 and details > behavior are described in section 5.5. Section 3.3 is an overview section > - here we only wanted to give a high-level overview of the protocol. > > > #5 8.1.4 - Is the last sentence here really optional, (everything in > section 8 should be optional, right?) or is that behaviour meant to apply > to all cases? If the latter, it really ought be in 4.2 shouldn't it? Also > there are two 6CO's mentioned there, but its not clear to me at what point > the 2nd is sent (T+5 presumably?) > > RESPONSE===> As per Adrian Farell's comments we are revisitng the optional > behavior sections to make them mandatory by default to reduce confusion > and interoperability issues in the deployment. If 6CO is used, it should > be in the same prefix advertisemnt. ND-19 should address this comment. > > #6 What does "expects" mean in the security considerations? > (Section 11, 2nd para.) That's not 2119 language. Are you saying this > protocol MUST NOT be used if layer 2 security isn't sufficiently strong or > is missing? If not, then what? > > RESPONSE===> > Suggested new text for the 2nd paragraph in security section: > > This specification assumes that the link layer is sufficiently > protected, for instance using MAC sublayer cryptography. Thus, its > threat model is no different from that of IPv6 Neighbor Discovery [RFC > 4861]. The trust model #1, in section 3 of SEND [RFC3756] applies here. > However, any future 6LoWPAN security protocol that applies to Neighbor > Discovery for 6LoWPAN protocol, is out of scope of this document. > > #7 How can "Using link-layer indication for NUD" be a SHOULD deploy but > only a MAY implement? (Table 2, in section 13.) > > RESPONSE====> > Indeed, there is no reference of 'link-layer indication' in the body of > the document, but we listed in the table for a suggestion to the > implementors. We can either take that text out completely from the table > or update the table as : > > | 5.1 | Re-direct Message Acceptance | MUST NOT | MUST NOT | > | | | | | > | |Joining Solicited Node | N/A | N/A | | > Other | Multicast | | | > |Recommend- | Joining all-node Multicast | MUST | MUST | > | ations | Using link-layer indication for | MAY | MAY | > | | NUD | | | > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > General - The logic as to why mesh-under and route-over are the most > important topologies is not explained here and I don't see why its most > valuable to tackle this problem in a topology-specific manner. It's also > a shame that 1.3 needs to have all nodes implementing this to get any > benefit and that each node must be part of only one network. (The latter > is particularly unfortunate given that sleeping node wake times might > cause such a condition over time.) However, this is maybe not actually a > problem since the protocol doesn't seem to be really specific to those > topologies - is that right? If so, then I'd suggest weakening the language > to say that e.g. the authors or WG are more interested in those > topologies, but that the protocol might work in other contexts too. > > RESPONSE====> 6lowpan working group mainly targets IEEE802.15.4 or similar > lowpower networks and topologies. The mesh and route-over topologies came > from that concept. > We agree, that in the introduction section, we can change the text to say > that the protocol might work in other contexts. In fact BTLE and BACNET > are two other networks which are considering this protocol. > The homogeneous nature of nodes are needed in this solution as this > document does not address operations with existing nodes. A generic > solution in ipv6 network is being addressed and developed in: > http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-energy-aware- > nd/ > > > Various places: - What's a non-transitive wireless link? > > RESPONSE=====> non-transitive link is defined in RFC 4861 > Non-transitive reachability means packets from A reach B, and > packets from B reach C, but packets from A don't > reach C.) Many radio links exhibit these. > > Abstract - is a bit awkwardly written, some polish could usefully be > applied. > > RESPONSE====> Will be fixed. Others also commented the same. > > 1.1 - I don't get the relevance of the "primarily two types" of lowpan > topology on p5. Only the last sentence of that paragraph seems relevant or > necessary. Similarly with section 1.2 which, other than introducing > terminology seems unnecessary. > RESPONSE===> 6lowpan wg is interested in these two types of topologies as > these two are defined in IEEE 802.15.4. > > > > 1.3 - A number of the goals say "optimize" - is that meant to mean > "improve" or "make the best"? In the latter, case, that would seem to > require more work, e.g. to be able to compare approaches via metrics or > something. Since I don't think that's really needed, I'd say > s/optimize/improve/g would be more correct. (Similarly for > s/minimize/reduce/) > > RESPONSE===> We will try to make this change in the document when > applicable. The goal of optimization is improvement. >
- [6lowpan] #142: Stephen Farrel's Discuss comments 6lowpan issue tracker
- Re: [6lowpan] #142: Stephen Farrel's Discuss comm… Stephen Farrell
- Re: [6lowpan] #142: Stephen Farrel's Discuss comm… 6lowpan issue tracker
- Re: [6lowpan] #142: Stephen Farrel's Discuss comm… 6lowpan issue tracker