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

Hi Dominique,

Quickly chiming in here. Please see below for one comment.

> On 18. Mar 2020, at 00:30, dominique.barthel@orange.com wrote:
> 
> Hello Benjamin,
> 
> See my comment to your point, inlined.
> 
> Dominique 
> 
> Le 17/03/20 22:13, « Benjamin Kaduk » <kaduk@mit.edu> a écrit :
> 
>> On Fri, Mar 13, 2020 at 11:48:18PM +0000, dominique.barthel@orange.com
>> wrote:
>>> 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.
>> 
>> This "if properly implemented" seems pretty critical.  Do we need to leave
>> a reminder that implementations have to know about UDP TLVs in order to
>> properly identify all fields in the headers to be compressed?
> 
> Indeed, the protocol parser and the SCHC rules need to know about the UDP
> TLVs if one wants to compress them.
> But the same is true of all the other fields. I don't think this one
> warrants a special notice.
> What I insist on is that, if an implementation does not know of the UDP
> TLVs, it will not reconstruct an erroneous UDP Length, even for a packet
> that contains these TLVs, assuming that the protocol parser checks the UDP
> and IPv6 lengths for consistency.

I think this last statement (“protocol parser checks the UDP
and IPv6 lengths for consistency”) is the important point that needs to be explicitly mention in the document!

Thanks!
Mirja

> See my example in a separate mail.
> 
>> 
>> -Ben
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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