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

[[e-mail]]

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 » <[e-mail]> 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, [e-mail] 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, « [e-mail] »
>> <[e-mail]> 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 »
>>> <[e-mail] on behalf of [e-mail]> 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
>>>> [e-mail] 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
>>>> [e-mail]
>>>> 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
>> [e-mail]
>> 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.