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

[[e-mail]]

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.