Re: [lp-wan] [Schc] Fwd: draft-architecture-02-inputs "better match"

Hi Ivan,

It can be, Quentin showed it, if we have a metric to select rules that is
only based on the length. Destructive compression concerns a lot of packet
to compress since we ignore the value of fields to select a rule, and very
efficient since we don't sent the fields. May be we can introduce a kind of
hamming distance in a metric to select the rule. A packet which differs too
much from the original are penalized.

In my view, destructive compression is good for HL if we are sure of no
risk of loops after the decompressor. Can be applied also to the FL, but
writing the value with management could be better.

Laurent

On Wed, Jun 7, 2023 at 2:56 PM Ivan Martinez Bolivar (Nokia) <
ivan.martinez_bolivar@nokia-bell-labs.com> wrote:

> Hello SCHCers,
>
> This is a crucial aspect for the Access Control draft that Ana, Laurent
> and I are working on.
>
> I suggest keeping it as it is in RFC8724, allowing implementers to choose
> the Rule as they want, and addressing the scenarios that require careful
> consideration in our draft.
>
> Hence, we shall introduce the notion of "destructive compression", for
> those cases where there are rules including "ignore - not_sent" and tell
> the implementers in which cases this combination is suitable or not.
> Looking at the examples of RFC8724. We got IPv6 Hop Limit, this may not
> be important in a star topology but can be problematic in other cases.
>
> If you think of other cases where this "destructive compression" can be an
> attack vector please let us know, we'll be happy to discuss about it.
>
> Ivan
>
>
> ---------- Forwarded message ---------
> De: *Ana Minaburo* <ana@ackl.io>
> Date: mar, 23 may 2023 a las 20:20
> Subject: [lp-wan] Fwd: draft-architecture-02-inputs "better match"
> To: lp-wan <lp-wan@ietf.org>
>
>
> This too.
>
> ---------- Forwarded message ---------
> From: *Ana Minaburo* <ana@ackl.io>
> Date: Tue, May 23, 2023 at 4:39 PM
> Subject: draft-architecture-02-inputs "better match"
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: <lpwan@ietf.org>, <schc@ietf.org>
>
>
> Hello Pascal,
> This is the second thread.
>
>
>    - 2. Section 3. In the Static Context Header Compression, in the first
>    paragraph, it is mentioned: "The rule that matches best is used to
>    compress."
>
>  *[Ana] *It is very ambiguous because it can be misinterpreted. Does it
> refer to the Rule that matches the complete header, i.e., the Rule with the
> same FIDs as the header format? Or do you mean the best compression
> residue? RFC8724 leaves to the implementation the choice of the Rule to be
> used when multiple valid Rules match.
>
>
>
> Agreed. This should be discussed on the list since it is an attack vector.
> Someone inserting a "better match" can turn a decompressor into a bomber.
> Let us start a thread on this.
>
>
> [Ana] If the best compression residue is what you mean, I agree that it
> introduces an attack vector that needs to be solved by a deeper discussion
> together with the modification of the Rules during the session.
>
> But In a context, several Rules may match the header and may be used to
> compress it. For instance, deciding which one is used is an implementation
> problem.
>
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>
> --
> Gracias
> Ivan Marino
> --
> Schc mailing list
> Schc@ietf.org
> https://www.ietf.org/mailman/listinfo/schc
>

-- 
Laurent Toutain
+------ VoIP (recommended) ---+--- Télécom Bretagne --- +
| Tel: +33 2 22 06 8156             | Tel: + 33 2 99 12 7026    | Visit :
| Fax: +33 2 22 06 8445            | Fax: +33 2 99 12 7030   |
http://class.touta.in
| Laurent@Touta.in                   | Laurent.Toutain@Telecom-Bretagne.eu
+----------------------------------------+--------------------------------+