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

Joseph Touch <touch@strayalpha.com> Wed, 18 March 2020 00:10 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 04B993A0C31; Tue, 17 Mar 2020 17:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
X-Spam-Status: No, score=-1.319 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, 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 9pF4SKoeChuZ; Tue, 17 Mar 2020 17:10:43 -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 79EE83A0C32; Tue, 17 Mar 2020 17:10:43 -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: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=D+meRxM+gPiMP/2a1Uu7h3LK9POS0xBhJKeBDXPVFNs=; b=jAUxO457LIE4dU+SVkEUCZZDU h5Ssh0xSv14mqs2oy0KYC8mlzhcOZArvnyDsqUEKQIKdS3V8ftYB9FiPbCtjho4udK2AJ2ce8uEC2 CiakUuop5GN+6urrL86ZjBe0+YUuGw3OKrSzlKdFy2CdBvKJswHf5sQP3KpCV6ZbRVmrZwwHbILCE zQS4lbxflokOyVHv6bJ6wgqcHL/lcKNKy1aKaKl7itNP1f2HxvtlM/2Nd1hDDMIAox4z5llxNyvN9 6ohwpwnW1r4x4Y9dRLZkkNlmCVuuh7tVLDyEUCOEMwzZl5iBWF2AWqVDgdQl9oGwG/rXpreY6YQJu D/irg5kZQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60886 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 1jEMI9-0019eQ-Na; Tue, 17 Mar 2020 20:10:42 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: =?utf-8?q?=3C32170=5F1584485182=5F5E71533E=5F32170=5F159=5F1=5F?= =?utf-8?q?DA9701E5=2E7204F=25dominique=2Ebarthel=40orange=2Ecom=3E?=
Date: Tue, 17 Mar 2020 17:10:37 -0700
Cc: "tsv-art@ietf.org" <tsv-art@ietf.org>, Suresh Krishnan <Suresh@kaloom.com>, "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: <B0375E01-4715-4116-B1DA-16FCFCCBD3B9@strayalpha.com>
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_=3C32170=5F1584485182=5F?= =?utf-8?q?5E71533E=5F32170=5F159=5F1=5FDA9701E5=2E7204F=25dominique=2Ebarth?= =?utf-8?q?el=40orange=2Ecom=3E?=
To: dominique.barthel@orange.com
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=0.3
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/Hk86WCR6lQQL7EP7bAZEhMD-8yw>
Subject: Re: [Tsv-art] [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 00:10:47 -0000

The problem is with the any default rule that indicates that UDP length can be computed. That is the flaw. It can only be computed if the UDP length matches the end of packet indicated by the IP header.

This system should not allow a rule that indicates that UDP length can be ‘recomputed’ if it isn’t also checked as such beforehand.

That is the flaw. It is with the system not checking, not merely the rule.

Joe

> On Mar 17, 2020, at 3:46 PM, dominique.barthel@orange.com wrote:
> 
> Hello all,
> 
> Here are some examples to illustrate my answer in the mail below.
> 
> We have the following processing chain:
> - protocol parser: breaks the headers of incoming packet into itemised
> fields, each with an identifier that tells what they are. Hands this set
> of fields to the SCHC compressor.
> - SCHC compressor: browses the Rule set to find a Rule that matches the
> set of fields. Compresses each field per the Rule, sends RuleID +
> compression residues + payload.
> - SCHC decompressor: based on the received RuleID and residues, rebuilds
> the itemised fields, hands the set of fields to the protocol reconstructor.
> - protocol reconstructor: concatenates the itemised fields into protocol
> headers, concatenates the payload. Hands to the upper layer.
> 
> Here, let's assume we intend to compress the UDP/IPv6 headers. The upper
> layers headers are considered "payload" in our discussion.
> For this discussion, I will only consider the Length field of IPv6,
> ignoring all other IPv6 fields.
> Therefore, I will say an old-style UDP/IPv6 packet only has 5 fields:
> - IPv6.Length
> - UDP.Length
> - UDP.Checksum
> - UDP.SourcePort
> - UDP.DestPort
> While a post draft-tsvwg-udp-options UDP/IPv6 packet may have more fields
> - UDP.Option1
> - UDP.Option2
> - etc.
> 
> Let's assume ProtocolParserA does not understand draft-tsvwg-udp-options.
> Let's assume ProtocolParserB does understand draft-tsvwg-udp-options.
> Let's assume PacketU is a well formed old-style UPD/IPv6 packet.
> Let's assume PacketV is a post draft-tsvwg-udp-options UPD/IPv6 packet,
> that includes UDP.Option1 and UDP.Option2.
> Let's assume Rule1 only has the old-style 5 field descriptors. In its
> CDAs, the UDP length is elided at the compressor and reconstructed out of
> IPv6.Length at the decompressor.
> Let's assume Rule2 has the 5 old-style field descriptors plus UDP.Option1
> and UDP.Option2. In its CDAs, the UDP length is sent in extenso as a
> compression residue.
> 
> When PacketU or PacketV is submitted to SystemA, which includes
> ProtocolParserA, or to SystemB, which includes ProtocolParserB, the
> outcome is described in the following table.
> 
>                      PacketU                      PacketV
> ---------------------------------------------------------------------------
> --------------------
>     | PPA parser   | 5 itemised fields          | incorrect UDP length,
> nothing handed to SCHC
>     | SCHC comp    | Matches Rule1              |
> SystA|              | UDP.Length elided          |
>     | SCHC decomp  | UDP.Length recomputed      |
>     | PPA reconstr | correct UDP header         |
> ---------------------------------------------------------------------------
> --------------------
>     | PPB parser   | 5 itemised fields          | 7 itemised fields
>     | SCHC comp    | Matches Rule1              | Matches Rule2
> SystB|              | UDP.Length elided          | UDP.Length sent as a
> compression residue
>     | SCHC decomp  | UDP.Length recomputed      | UDP.Length retrieved
> from residue
>     | PPB reconstr | correct UDP header         | correct UDP header
> 
> ---------------------------------------------------------------------------
> --------------------
> 
> Further variations:
> 
> If a PacketW has 3 options, yielding 8 fields, it does not match Rule2.
> With SystB, it will be sent uncompressed.
> If case SystB does not have a Rule1 in the Rule set, PacketU will be sent
> uncompressed.
> If case SystB does not have a Rule2 in the Rule set, PacketV will be sent
> uncompressed.
> There is no way PacketV will be matched by Rule1, which is the case that
> was envisaged as problematic by TSV-ART, if I understood correctly.
> Now, if ProtocolParserA does not check for consistency between UDP.Length
> and IPv6.Length, then we have a problem.
> But the problem is with the protocol parser, not with SCHC.
> 
> Best regards
> 
> Dominique
> 
> 
> 
> 
> 
> 
> Le 14/03/20 00:48, « dominique.barthel@orange.com »
> <dominique.barthel@orange.com> a écrit :
> 
>> 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.
>> 
>> Best regards,
>> 
>> Dominique
>> 
>> 
>> Le 12/02/20 16:08, « lp-wan on behalf of Joseph Touch via Datatracker »
>> <lp-wan-bounces@ietf.org on behalf of noreply@ietf.org> a écrit :
>> 
>>> Reviewer: Joseph Touch
>>> Review result: Almost Ready
>>> 
>>> This document has been reviewed as part of the transport area review
>>> team's
>>> ongoing effort to review key IETF documents. These comments were written
>>> primarily for the transport area directors, but are copied to the
>>> document's
>>> authors and WG to allow them to address any issues raised and also to the
>>> IETF
>>> discussion list for information.
>>> 
>>> When done at the time of IETF Last Call, the authors should consider this
>>> review as part of the last-call comments they receive. Please always CC
>>> tsv-art@ietf.org if you reply to or forward this review.
>>> 
>>> I found no transport issues with this document.
>>> 
>>> However, this document normatively cites
>>> ietf-lpwan-ipv6-static-context-hc,
>>> which does have some transport issues of concern. I am listing them here
>>> because of the dependency between the two documents.
>>> 
>>> In particular, ietf-lpwan-ipv6-static-context-hc overlooks the case where
>>> the
>>> IP header indicates a packet longer than the UDP header, a case that is
>>> currently being developed for UDP header options in TSVWG. This other
>>> document
>>> claims that both UDP and IPv6 length fields can be computed from the
>>> received
>>> data, but this is not the case when the IP header indicates a packet end
>>> after
>>> that of the UDP header. See draft-tsvwg-udp-options for more information.
>>> 
>>> There are no changes needed to this document to address this length
>>> issue, but
>>> the normative dependency in this doc is the reason for indicatin this
>>> document
>>> as "Almost Ready".
>>> 
>>> _______________________________________________
>>> lp-wan mailing list
>>> lp-wan@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lp-wan
>> 
>> 
>> __________________________________________________________________________
>> _______________________________________________
>> 
>> 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.
>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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