Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 18 March 2020 12:50 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5985C3A1546; Wed, 18 Mar 2020 05:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 TZCsxuc-gw-c; Wed, 18 Mar 2020 05:50:09 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 85BD83A1536; Wed, 18 Mar 2020 05:50:08 -0700 (PDT)
Received: from p200300dee7239a00e8505cca0b302030.dip0.t-ipconnect.de ([2003:de:e723:9a00:e850:5cca:b30:2030]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jEY95-0008Ur-CN; Wed, 18 Mar 2020 13:50:03 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: =?utf-8?q?=3C30843=5F1584487855=5F5E715DAF=5F30843=5F429=5F4=5F?= =?utf-8?q?DA971B0C=2E72109=25dominique=2Ebarthel=40orange=2Ecom=3E?=
Date: Wed, 18 Mar 2020 13:50:02 +0100
Cc: Benjamin Kaduk <kaduk@mit.edu>, Joseph Touch <touch@strayalpha.com>, "draft-ietf-lpwan-coap-static-context-hc.all@ietf.org" <draft-ietf-lpwan-coap-static-context-hc.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, The IESG <iesg@ietf.org>, "lp-wan@ietf.org" <lp-wan@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-lpwan-ipv6-static-context-hc@ietf.org" <draft-ietf-lpwan-ipv6-static-context-hc@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <27E35DC7-C83E-4C6C-984A-3AC1C183BC28@kuehlewind.net>
References: <158152010913.17982.18347318138768196852@ietfa.amsl.com> =?utf-8?q?=3C340=5F1584143298=5F5E6C1BC2=5F340=5F169=5F1=5FDA91D669=2E71EAC?= =?utf-8?q?=25dominique=2Ebarthel=40orange=2Ecom=3E?= =?utf-8?q?=3C20200317211335=2EGR50174=40kduck=2Emit=2Eedu=3E_=3C30843=5F158?= =?utf-8?q?4487855=5F5E715DAF=5F30843=5F429=5F4=5FDA971B0C=2E72109=25dominiq?= =?utf-8?q?ue=2Ebarthel=40orange=2Ecom=3E?=
To: dominique.barthel@orange.com
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1584535809;5e8577c1;
X-HE-SMSGID: 1jEY95-0008Ur-CN
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/3e895av7qJCIvbo5u8IZVcEer5w>
Subject: Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2020 12:50:29 -0000

Hi Dominique,

Quickly chiming in here. Please see below for one comment.

> On 18. Mar 2020, at 00:30, dominique.barthel@orange.com wrote:
> 
> Hello Benjamin,
> 
> See my comment to your point, inlined.
> 
> Dominique 
> 
> Le 17/03/20 22:13, « Benjamin Kaduk » <kaduk@mit.edu> a écrit :
> 
>> On Fri, Mar 13, 2020 at 11:48:18PM +0000, dominique.barthel@orange.com
>> wrote:
>>> Hello all,
>>> 
>>> This is the response by the ietf-lpwan-ipv6-static-context-hc co-authors
>>> to the observation below by Joseph Touch.
>>> You are right that Section 10 of ietf-lpwan-ipv6-static-context-hc only
>>> shows how to compress IPv6/UDP packets that have no extensions.
>>> 
>>> However, the SCHC specification in Section 7.1 states
>>> "It is assumed that
>>>   there is a protocol parser alongside SCHC that is able to identify
>>>   all the fields encountered in the headers to be compressed, and to
>>>   label them with a Field ID."
>>> 
>>> Furthermore, Section 7.3 states
>>> "If any
>>>         header field of the packet being examined cannot be matched
>>>         with a Field Description with the correct FID, the Rule MUST be
>>>         disregarded.  If any Field Description in the Rule has a FID
>>>         that cannot be matched to one of the header fields of the
>>>         packet being examined, the Rule MUST be disregarded."
>>> 
>>> It follows that, if an IPv6 packet does contain the new UDP TLVs
>>> introduced by draft-tsvwg-udp-options, it will not match a Rule destined
>>> to compress the IPv6/UDP headers and that does not have these TLVs as
>>> part
>>> of the Field Descriptors.
>>> Therefore, it will no be compressed by that Rule and will not be
>>> decompressed with a wrong UDP Length at the receive end.
>>> 
>>> By contrast, if a Rule destined to compress the IPv6/UDP headers does
>>> have
>>> these UDP TLVs as part of the Field Descriptors, it is responsible for
>>> reconstructing the UDP Length properly. This can be achieved by means
>>> already provided by SCHC, such as sending the value over the wire or
>>> matching it to an expected constant, etc.
>>> 
>>> In conclusion, the SCHC compression mechanism, if properly implemented,
>>> is
>>> fully compatible with draft-tsvwg-udp-options.
>> 
>> This "if properly implemented" seems pretty critical.  Do we need to leave
>> a reminder that implementations have to know about UDP TLVs in order to
>> properly identify all fields in the headers to be compressed?
> 
> Indeed, the protocol parser and the SCHC rules need to know about the UDP
> TLVs if one wants to compress them.
> But the same is true of all the other fields. I don't think this one
> warrants a special notice.
> What I insist on is that, if an implementation does not know of the UDP
> TLVs, it will not reconstruct an erroneous UDP Length, even for a packet
> that contains these TLVs, assuming that the protocol parser checks the UDP
> and IPv6 lengths for consistency.

I think this last statement (“protocol parser checks the UDP
and IPv6 lengths for consistency”) is the important point that needs to be explicitly mention in the document!

Thanks!
Mirja
 



> See my example in a separate mail.
> 
>> 
>> -Ben
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art