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

Joseph Touch <touch@strayalpha.com> Wed, 18 March 2020 03:47 UTC

Return-Path: <touch@strayalpha.com>
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 A161A3A0FE5; Tue, 17 Mar 2020 20:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 lXPviV7wC54j; Tue, 17 Mar 2020 20:47:46 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8C53A0FE4; Tue, 17 Mar 2020 20:47:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Iu+eXhBp7dAXMs8X3sc4CjvgyxYSoP1GhLDLAsgJF5A=; b=J7e+ZCa2hGa4upgKME3gqFQML OvwvAuo9+mvRkZh3nYRucJSVFxZ3KGnejCc2PyedTEP6A/+KyAOzUWe8nQ+hsNp8elVAEfjhQPKtr VAvnOqmu6vMDYzm8KRIj+g3Ya8gL91lgRiZZALDjwv1zlN2gMbh90j31333UAGkdrR2a2ozbT74E+ KNrn3diUteUtm82xL26u0caWJEfQ8lqZuQlaZU1PJmGyCDx2UCi9aVDNipRRQ48O1Mo4akZHUk4LR eMQFf+Ik5xqBEZ366SQVf+NWQo+whyYKNIPrTyNIstCQ/W3k6XEDrGG4D9lVfX2GuHLbt2j0hKFgN Lb4ZE+p7w==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60920 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1jEPgD-000usM-Db; Tue, 17 Mar 2020 23:47:46 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_6D53164A-E305-44A2-8B90-023001526CF6"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <18523_1584490925_5E7169AD_18523_418_6_DA9727F0.72166%dominique.barthel@orange.com>
Date: Tue, 17 Mar 2020 20:47:38 -0700
Cc: "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>, Benjamin Kaduk <kaduk@mit.edu>
Message-Id: <F36BDD31-B032-48E9-A168-84944D2B0767@strayalpha.com>
References: <158152010913.17982.18347318138768196852@ietfa.amsl.com> <340_1584143298_5E6C1BC2_340_169_1_DA91D669.71EAC%dominique.barthel@orange.com><20200317211335.GR50174@kduck.mit.edu> <30843_1584487855_5E715DAF_30843_429_4_DA971B0C.72109%dominique.barthel@orange.com><2280383A-EB5A-43AD-98A5-F2A61BB40524@strayalpha.com> <18523_1584490925_5E7169AD_18523_418_6_DA9727F0.72166%dominique.barthel@orange.com>
To: dominique.barthel@orange.com
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/IsFPujzHJjrshJCboZWfoLj6oz4>
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 03:47:49 -0000

Technically, it applies only to UDP headers when the UDP length points to the same location as the IP length when viewed at the compressor.

It doesn’t matter why the UDP length differs or how; UDP options are only a very specific subset of that case.

Joe

> On Mar 17, 2020, at 5:22 PM, <dominique.barthel@orange.com> <dominique.barthel@orange.com> wrote:
> 
> You are totally right.
> I suggest to add that Section 10 only applies to UDP headers without options.
> Does that work?
> 
> Dominique
> 
> De : Joseph Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>>
> Date : Wednesday 18 March 2020 01:12
> À : Dominique Barthel <dominique.barthel@orange.com <mailto:dominique.barthel@orange.com>>
> Cc : Benjamin Kaduk <kaduk@mit.edu <mailto:kaduk@mit.edu>>, "draft-ietf-lpwan-coap-static-context-hc.all@ietf.org <mailto:draft-ietf-lpwan-coap-static-context-hc.all@ietf.org>" <draft-ietf-lpwan-coap-static-context-hc.all@ietf.org <mailto:draft-ietf-lpwan-coap-static-context-hc.all@ietf.org>>, "last-call@ietf.org <mailto:last-call@ietf.org>" <last-call@ietf.org <mailto:last-call@ietf.org>>, The IESG <iesg@ietf.org <mailto:iesg@ietf.org>>, "lp-wan@ietf.org <mailto:lp-wan@ietf.org>" <lp-wan@ietf.org <mailto:lp-wan@ietf.org>>, "tsv-art@ietf.org <mailto:tsv-art@ietf.org>" <tsv-art@ietf.org <mailto:tsv-art@ietf.org>>, "draft-ietf-lpwan-ipv6-static-context-hc@ietf.org <mailto:draft-ietf-lpwan-ipv6-static-context-hc@ietf.org>" <draft-ietf-lpwan-ipv6-static-context-hc@ietf.org <mailto:draft-ietf-lpwan-ipv6-static-context-hc@ietf.org>>
> Objet : Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
> 
> 
> 
>> On Mar 17, 2020, at 4:30 PM, dominique.barthel@orange.com <mailto:dominique.barthel@orange.com> wrote:
>> 
>>> 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. See my example in a separate mail.
> 
> Agreed. The issue is that UDP length can’t be reconstructed UNLESS it matches the end of packet indicated by the IP length.
> 
> In any other case, claiming it can be reconstructed is an error and should not be allowed.
> 
> That appears to be a flaw in the claim that UDP length can be computed. It’s just not true in all cases.
> 
> Joe
> 
>  _________________________________________________________________________________________________________________________
> 
> 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