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 03:46 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 96B863A0FE2; Tue, 17 Mar 2020 20:46:47 -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 RhlAonEqZEiv; Tue, 17 Mar 2020 20:46:45 -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 3FDC23A0FDD; Tue, 17 Mar 2020 20:46:45 -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=qdGJwltEQrB8uAsmpFZ/O81i+Adq0o6RPuaHM7UA1yA=; b=oFXkwk/dpUG5XNov4ym4QV7vB AUiU6T2haqNjMMISpFAlcepd7szHbw2/pUngkL4YJLNUyDz0pz1dh1wl8Owhg2rpRdATnzSvwNa72 LUYIw1aBr7jfVaATYGmNM/2emDvFrp8c0Nw/Hl7ugqGIXrJ/xCRc2jbeeRwH47keydiShp4cgINFh RerqBiH/DhPEoEetDAzH6hPNuxX5tF5FE8qgIG3tBkApKoBNTdMCv2aDuJ8bVPsRK6oDqG+Mz5Nj+ p7LJ9QUt+yY/9yl2/7Oy6TM7+y40LlzHmBPirpliy+6qc40g+qw/5OQIiQnft4X0DUO2yOwf+mNKO vweDiAHtQ==;
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 1jEPfD-000usM-IA; Tue, 17 Mar 2020 23:46:44 -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?=3C14147=5F1584490832=5F5E716950=5F14147=5F78=5F1=5FD?= =?utf-8?q?A97272C=2E7215F=25dominique=2Ebarthel=40orange=2Ecom=3E?=
Date: Tue, 17 Mar 2020 20:46:36 -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: <5DB3C96D-6FAF-4D65-8D83-83F39B311DB8@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?= =?utf-8?q?=3CB0375E01-4715-4116-B1DA-16FCFCCBD3B9=40strayalpha=2Ecom=3E_=3C?= =?utf-8?q?14147=5F1584490832=5F5E716950=5F14147=5F78=5F1=5FDA97272C=2E7215F?= =?utf-8?q?=25dominique=2Ebarthel=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/vpE7wPnYZKk9fzVlyLFTg8L1Rsc>
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 03:46:48 -0000

Yes, actually - the key problem is the description of UDP length as “computable” in the section below and in section 10. It is computable *only* when verified so at the source.

Joe

> On Mar 17, 2020, at 5:20 PM, <dominique.barthel@orange.com> <dominique.barthel@orange.com> wrote:
> 
> The default rule is to send the packet uncompressed.
> There is no default rule that says that the UDP length can be recomputed.
> There are specific rules that say that the length can be recomputed, and
> each one knows how the length can be computed.
> And you are right, the UDP length has to be checked before the
> corresponding rule can be applied.
> This is outside the scope of this draft.
> I'm happy to add a warning "This system should not allow a rule that
> indicates that UDP length can be ‘recomputed’ if it isn’t also checked as
> such beforehand." to this draft
> Would that work?
> 
> Dominique
> 
> Le 18/03/20 01:10, « Joseph Touch » <touch@strayalpha.com> a écrit :
> 
>> 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
>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>