Re: [lp-wan] Comments on draft-barthel-schc-oam-schc-03

[Laurent Toutain <[e-mail]>]

On Tue, Feb 13, 2024 at 11:41 AM Ana Minaburo <[e-mail]> wrote:

> Dear Laurent and Dominique,
> I've read your draft. Here, you will find some comments and open questions
> to discuss.
>
> Thank you Ana for the careful reading, our comments are in-line.


> 1. This draft gives new features that augment SCHC.
> - It creates two new MO/CDA
> - Creates a new item in the Rule to achieve an operation, called ACTION
>
> 2. It also gives some feathery strategies for compressing the Type and
> Code of the ICMPv6 header fields.
> - In section 4.2.1, when introducing the example, you want to define
> something different using only the RuleID. Please let me know if I need to
> correct something.
> But here we can discuss some points:
> What is the idea of creating a Rule per Type or doing a general Rule for
> all Types?
>


That's depend of level of precision you want to inform the device. A very
constrain device, may be satisfied by the information, an error occurs when
I'm sending my measurement, so I will increase my sending period to same
energy. Some other devices may be interested by the nature of the error. If
the prefix is unknown, it may mean a routing error, that will be corrected
quickly and a port unavailable, will inform that the server is not running
and may take longuer time to repair. Then the device can update its sending
perdio differently.


> Do you mean a RuleID format that implicitly adds the type/code?
> This is very interesting, but I think we need to open a new discussion
> about it.
>

No, if a device receives a SCHC packet containing only the ruleID this
means that the incoming packet matched the rule, so the TV were in the
Fields.
But I agree to discuss if needed :-)


> 4. Also, when you describe Ping, you only describe the use for LPWAN, and
> I think you need to open the use of Ping to all networks—perhaps giving one
> special section to LPWAN.
>

In my opinion, but maybe it should be more carefully written in the draft,
the ping with just compression is covered by the generic ICMPv6 compression
in § 4.1
Ping-proxy action SHOULD be used only in LPWAN networks.


> 5. Using the proxy.
> How is the security assured here? How does the proxy know the device is
> alive?
>

That's a good question, ping is not really protected and to the best of my
knowledge there is no encryption for ICMPv6, so using a proxy also to
anticipate the Device answer. An attacker will have to take control of the
core SCHC and that's no more a problem of ICMP.

In openSCHC, the SoR is timestamped when one of its rule is used for
decompression. In the proxy-ping action in the rule, there is a parameter
telling the keep-a-live duration. When a ping request arrives to the core
SCHC, the proxy check the different between the current time and the SoR
timestamp. if less than the duration parameter it generates an answer, if
higher, the request is discarded. Note that we can trigger the compression
if the delay is over and a compress ping request will arrive to the device.


> You need to keep the trust between the proxy and the device by doing some
> control instances and keeping this in the Rule.
>

If you use encryption, then the proxying is not possible in the core, as
compression or decompression. If you don't have encryption, the information
is available.
More generally for action, an action may not change the SCHC packet but
trigger some mechanisms managing the rule, so it is more a meta mechanisms.

I don't understand the point. There is a kind of trust in SCHC since both
ends share the same rules. This trust may be reinforced by signing an
canonical representation of the rule (for instance using CORECORE
representation). Before  starting the exchange, both entities ensure the
rules are correct, but this part is not covered by ICMPv6 compression.

>

>  I think that as you have defined it, you identify which Rule may accept
> the ACTION. That identifies the Rule and allows the proxy to answer a
> request, avoiding a waste of resources for an LPWAN device. The
> device executes a control update and releases the constraint network for
> ICMP traffic.
>

That's the rule designer who decide to add an action to protect his link if
he wants to ping the device.


>
> 6. To be explicit, you must
> => separate ICMPv6 compression from Ping usage. Make two separate parts of
> your draft.
>

This is done, but not is a very clean way. Section 4.1 is for generic
compression and 4.2 for and example. But 4.3 targets constrained network. I
propose to have 4.3 in a new section dedicated to constrained devices.


> => Change the title to only ICMPv6, which could represent your work. OAM
> also implies traceroute, mtrace, BFD, IPPM, MPLS-TP, and SNMP.
>

I agree, we look with Dominique about traceroute, but it is difficult to
write a generic document, since the implementation of traceroute differs. I
suppose that the strategy for the others also differs when you are in an
LPWAN.


> => Add a new section to update RFC8724 with the two MO/CDA dedicated to
> ICMP and Actions
>

I think it is better tp augment RFC9363 with a YANG DM for ICMPv6 fields
and new MO/CDA and he introduction of the Action leaf.. and of course  the
architecture document for proxies.


> => Change the Introduction. By omitting OAM.
>
> Ok.


Laurent

> Ana
>
>
>
>
>