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

[Gorry Fairhurst <[e-mail]>]

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, [e-mail] 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 »<[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.
>>
>> _______________________________________________
>> Tsv-art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tsv-art
>
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art