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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 18 March 2020 11:33 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 4A57F3A1412; Wed, 18 Mar 2020 04:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 JTCjW7P0_wjO; Wed, 18 Mar 2020 04:33:04 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id CC1E73A1411; Wed, 18 Mar 2020 04:33:03 -0700 (PDT)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id C86B61B00191; Wed, 18 Mar 2020 11:32:56 +0000 (GMT)
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: dominique.barthel@orange.com, Joseph Touch <touch@strayalpha.com>
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>
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?= <13a7c9d6-4deb-46f2-c203-095510b9a79c@erg.abdn.ac.uk>
Message-ID: <086b8002-dd2a-4383-809d-8b05cc6c9deb@erg.abdn.ac.uk>
Date: Wed, 18 Mar 2020 11:32:55 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <13a7c9d6-4deb-46f2-c203-095510b9a79c@erg.abdn.ac.uk>
Content-Type: multipart/alternative; boundary="------------6884845EFE5F4234A685D61F"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/Ta6tdnlvMziK-uJLQaJm-RW-rx8>
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 11:33:08 -0000

Magnus commented in more detail while I was composing my reply by 
re-reading ROHC specs.

Gorry

On 18/03/2020 11:29, Gorry Fairhurst wrote:
>
> It's Joe's discussion, but from my viewpoint I would have thought that 
> it was at least VERY useful to clearly indicate what to do when the 
> UDP indicated length differs from the IP indicated length.
>
> - This is important, since TSVG is developing a PS that specifically 
> will do this.
>
> RFC3095 contains:
>        The Length field of the UDP header MUST match the Length field(s)
>        of the preceding subheaders, i.e., there must not be any padding
>        after the UDP payload that is covered by the IP Length.
>
> The word padding should really be bytes, but seems like it is heading in the correct direction to define the issue.
>   
> Why does this ID not require sending uncompressed?
> .... If it is not this spec which spec needs to say something?
>
> Gorry
> On 18/03/2020 00:20, 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.
>>
>> _______________________________________________
>> Tsv-art mailing list
>> Tsv-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/tsv-art
>
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art