Re: [6tisch] removing the 'e'

Jonathan Simon <jsimon@linear.com> Tue, 31 March 2015 17:02 UTC

Return-Path: <jsimon@linear.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB2A1A1A48 for <6tisch@ietfa.amsl.com>; Tue, 31 Mar 2015 10:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.534
X-Spam-Level:
X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 ORwCJWzX4RFP for <6tisch@ietfa.amsl.com>; Tue, 31 Mar 2015 10:02:27 -0700 (PDT)
Received: from p02c11o148.mxlogic.net (p02c11o148.mxlogic.net [208.65.144.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BBF1A0140 for <6tisch@ietf.org>; Tue, 31 Mar 2015 10:02:27 -0700 (PDT)
Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o148.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id 323da155.2b722b010940.22270.00-566.61334.p02c11o148.mxlogic.net (envelope-from <jsimon@linear.com>); Tue, 31 Mar 2015 11:02:27 -0600 (MDT)
X-MXL-Hash: 551ad32346b8879a-b6439e187a6285b1f175e9330564c05d2d811117
Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o148.mxlogic.net(mxl_mta-8.2.0-3) with ESMTP id a13da155.0.22153.00-321.60984.p02c11o148.mxlogic.net (envelope-from <jsimon@linear.com>); Tue, 31 Mar 2015 11:02:25 -0600 (MDT)
X-MXL-Hash: 551ad3213a52c9c8-c595d559d27566e425381d07b7eac34c72b1b0a7
Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 3B46F7409D; Tue, 31 Mar 2015 10:02:16 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_E5ACAFFA-53D3-48F4-8B3A-3DDFDA1ADD3D"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jonathan Simon <jsimon@linear.com>
In-Reply-To: <551AAE57.4020104@gmail.com>
Date: Tue, 31 Mar 2015 10:01:36 -0700
Message-Id: <C03D31E5-BE9F-43E6-82C4-3AD7E95EE208@linear.com>
References: <E045AECD98228444A58C61C200AE1BD849D905A6@xmb-rcd-x01.cisco.com> <55199457.3000504@gmail.com> <E045AECD98228444A58C61C200AE1BD849D91419@xmb-rcd-x01.cisco.com> <551AA689.1060100@gmail.com> <861C280A4EB34046A0D9A4324E4E8224014F9EB2@de08ex3001.global.ds.honeywell.com> <551AAE57.4020104@gmail.com>
To: Rene Struik <rstruik.ext@gmail.com>, Kris Pister <ksjp@berkeley.edu>
X-Mailer: Apple Mail (2.1878.6)
X-AnalysisOut: [v=2.1 cv=FeEjxfO6 c=1 sm=1 tr=0 a=glloKNylpeYNumXQcclYyA==]
X-AnalysisOut: [:117 a=glloKNylpeYNumXQcclYyA==:17 a=BLceEmwcHowA:10 a=MqD]
X-AnalysisOut: [INYqSAAAA:8 a=YlVTAMxIAAAA:8 a=emO1SXQWCLwA:10 a=DHaPdAVlA]
X-AnalysisOut: [AAA:8 a=_68yT5t_ctkrgjcNoQgA:9 a=AD9mmo8x8tDFYPH_:21 a=qH_]
X-AnalysisOut: [uDzW1GKG22IoL:21 a=pILNOxqGKmIA:10 a=Irsl7UoqOcEA:10 a=x6y]
X-AnalysisOut: [LWgJ6YqJr2DwU:21 a=oGwULtaURLWgERgI:21 a=sb9g0YzzQgdUpC_x:]
X-AnalysisOut: [21 a=_W_S_7VecoQA:10 a=NPI4PQ6hFa3hbkAUJZsA:9 a=ZVk8-NSrHB]
X-AnalysisOut: [gA:10]
X-Spam: [F=0.5500000000; CM=0.500; MH=0.550(2015033112); S=0.200(2014051901)]
X-MAIL-FROM: <jsimon@linear.com>
X-SOURCE-IP: [12.218.215.72]
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/Ia5ZI0DtjL4pyMDd_T5gmxBK3cg>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] removing the 'e'
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2015 17:02:30 -0000

Chiming in…

I agree with Rene, “802.15.4-2011 as amended by 802.15.4e-2012” is a perfectly valid specification, and one that has formed the basis of a number of products, including my company’s.

I believe that Pat is trying to faithfully represent upcoming changes, and that the primary goal of 802.15.4-2015 effort is to correct mistakes and remove ambiguities that might result in different implementations.  Yet there have been a few incompatible changes introduced, perhaps for valid reasons - I would argue the short address doesn’t leak info if only authenticating, and doesn’t prevent the combination of EUI + ASN + Key from being replayed, so that more moderate informative language could be used to solve this particular problem.  I also think that policing IE’s is naive - the IEEE doesn’t own the band, and a robust design uses security to ensure that frame content is correct. 

So I guess it comes down to two things:

1) are the incompatible changes adding something that is needed for 6TiSCH - if not, we are free in 6TiSCH to override behavior we don’t like, e.g. “x is as described in spec y, except for the limitation of clause z, which is taken from spec p, clause q”
2) do we need to see 802.15.4-2015 before adopting it as a normative reference?  Paranoid me says yes, but if people agree to 1) then its not really a problem.

-- 
Jonathan 

> Thanks Kris;
> 
> Let's review your points:
> 
> - IE IDs:  When 15.4e was introduced, we allowed vendors to freely use 25 non-standardized IDs with the explicit warning that another vendor could be using that ID creating a conflict, destroying coexistence. Since that time we have seen a significant number of requests for IE IDs, so given the limited number of IDs and the fact that there really is no vendor coexistence with the original scheme, we changed to one specific vendor ID where the vendor's OUI is required to make the IE unique.
> 
> - macTsRxOffset: the basic intent of macTsRxOffset is to center the transmission start within the range of 2200 µs (macTSRxWait). So the transmitter's macTsTxOffset (2120µs) should be 1100µs (macTsRxWait/2) greater than macTxRxOffset(1020µs).  However, 15.4e mistakenly used the term "frame" when it actually meant "PPDU". The start of the frame occurs 192 µs after the start of the PPDU or packet. 15.4e's value of 1120µs was an extra 100µs to compensate for the PHY components (which are really 192 µs). In summary, we could either continue to use the term frame with macTxRxOffset=1020µs, or use PPDU and add 192 µs.
> 
> - use of short addresses in nonce generation: 15.4e changed the nonce requirement of 15.4-2011, from requiring the use of the 8-octet extended address to allowing the usage of the short address (btw - all operations modes not just TSCH). It is generally understood that using the short address in the nonce generation is very problematic. Even if the short address is unique inside the PAN, there could be multiple PANs sharing the same keying material and using same short address for multiple devices. Using only the short address and not a combination of PANId and macShortAddress since it also puts another requirement, that short address needs to be unique over all PANs which use same key, not only unique inside the current PAN.
> 
> - TLV vs. LTV: The revision retains the IE formatting from 15.4e, it remains backward compatible.  The statement "the fact that such a change, with little to no practical value, would require continuous debate over many meetings is a sign that backward compatibility is not top of mind for a good part of the WG" is totally incorrect.  All standards organizations require that all individuals and organizations be heard, and they were in a thoughtful manner.
> 
> In summary, the changes done in the revision were to correct issues and problems.  The standardized TSCH IE IDs were not changed, rather a method was added to eliminate vendor conflicts in non-standardized IDs and the extra IDs were put back into reserve.  The macTxRxOffset was changed to be consistent with the correct terminology. While using the short address for nonce generation is not compliant to the revision, the group consensus was that it's not appropriate to knowingly degrade security, hence reverting back to the 802.15.4-2011 method.
> 
> Pat Kinney
> Kinney Consulting LLC
> IEEE 802.15 WG vice chair, TG chair
> ISA100.11a WG chair
> O: +1.847.960.3715
> pat.kinney@kinneyconsultingllc.com