lp-wan / datamodel Goto Github PK

Goal: Align with 8724 and if possible align with architecture draft as it's an ongoing work.

1. A Context is Set a of Rules [8724]
2. A Context does not contain additional information [8724].
3. There is a context or Set of Rules per session [Archi].
   3.1 There can be multiple sessions or instances on a SCHC Core [defined as Network Gateway in archi].
   3.2 A Device typically has only one instance.
4. A SCHC instance (or session) is a protocol operation between a pair of peers [Archi].

Ana: Here you will find the list of comments, inputs and questions

• Introduce a Terminology section and explain the following terms, at a first glance I was wondering if I was reading something I can understand
  SOR. Set of Rules. C'est le Context?
  RM. Rule Manager. Peut-on faire le lien avec le draft architecture?
  Core RM. Quelle est sa difference?
  Device RM. Quelle est sa difference?
  Compromised Core. C'est quoi compromised Core or Device??
  Compromised Device
  Destructive Rule. C'est quoi une règle destructive? Qui peut la introduire et comment les avoir?
  NACM ? Je n'ai pas trouvé
  DM. Data Model Faire lien avec le RFC9363?

• Figure 1. If Terminology section is not in the document we need to explain SoR and RM?

• I've noticed that you talk about rule database, but in HC terminology this is the Context or you are referring to something else? I will put the same question to Pascal for the draft architecture that mixes Context and Rule database in the draft.

• In Threat Model
  What is peer of peers?

• In Scenario 1.
  Why the impact of the attack depends on the original rule?
  What is an original rule?

• In Scenario 1. Point 1
  What is the meaning of MA? Do you mean MO? (Matching Operator)

• In Scenario 1. Point 2
  What do you mean by messages aiming at changing rules?
  How many kind of rules you have?

  • For the moment in the document, there are: original, changing, destructive
  • We need to define them to be clear, those rules are the same rule or different rules? is there a changing status for a rule?
    One solution here could be to limit the fields of the Rule that can be modified. I think that Port number is something fixed that cannot be changed, so if there is an attack in a fixed field, it could be detected.
    And also we can put modification degrees, depending on who you are?
    -You talk about a case where the residue can be reduced, how can the reduction takes place?

• YANG Access Control
  NACM meaning?
  Which granularity? Explain
  I don't understand the case of Uri-path

In the Access Control levels,
I don't agree to add or remove FID's, in which case you need to add/remove a FID?
I think you need to add/remove Rules from the Context

• YANG Data Model
  The leaf-ac-modify-set-of-rules is equivalent to say that in your context you will have fixed Rules and modifiable Rules?
  I think that not all the Rules may be modified. For example No-Compress Rule is a fixed Rule.

In the leaf-ac-modify-compression-rule
In no-change (0) Is it correct?: The rule cannot be modified or is it an element of the rule?
In modify-existing-element (1) and add-remove-element: only the FID can be changed or also MO, TV, CDA, any part of the Rule?

Which is the difference between modify-compression-rule and modify-field?

Ana

Goal: Try to find a way of clasifying rules:

1. By type: original, changing, destructive
2. Rules status.

1. Attack Impact :
   Ana: I don't see what you mean? The attack depends on the optimisation of compression? or only on the modification of the Rule information?
   IM: No, the attack does not depends on that, I'm talking about the impact of the attack. Hence, it depends on both. Let me explain: (a) The attack consist on trying to change a Rule that offers certain level of compression. (b) the possible rule that the compromised device is trying to push offers a grater level of compression, (c) if the new rule is effectively pushed and selected by the core, the impact of the attack is more important since there is a lost of information.
   IM You can classify the impact of an attack based on the CIA (Confidentiality, Integrity, and Availability) triad, an attack that only impacts the Availability is less serious than an attack that impacts the integrity.

Destructive Rules: In SCHC equal/not-send, ignore/value-sent, ignore/compute-*, MSB/LSB, Match-mapping/mapping-sent do not destroy the information. The information is either in the TV or in the residue. So the equilibrium is that a specific
rule (more info in the TV) send less residue but as a smaller probability to be selected. Destructive compression ignore/not-sent forces the decompression to take the TV regardless of the initial value. It is possible to create some very attractive rules (very small residue) and with a high probability. Therefore no valuable info is sent on the link.

Ana: In the leaf-ac-modify-compression-rule In no-change (0) Is it correct?:
The rule cannot be modified or is it an element of the rule? In modify-existing-element (1) and add-remove-element: only the FID can be changed or also MO, TV, CDA, any part of the Rule?

LT: what may be not clear in the document, is that without any AC element, a rule cannot be read or write, with 0 it can be read but not modified. You have the possibility to add rules, then to add field descriptor and then modify elements.
Ana: Yes, I think this is not clear, and we need to define which Rules or parts of the Rule are Readable, Writable, etc, This means the permission of each cell in your table and the permission of each Rule in your Context.

Goal: achieve a consensus in how rules are used:

1. Rule Manipulation: The role of a Rule Manager:
2. A SCHC Core manipulates rules for several devices, and is not the source or destination of the traffic. Q SCHC Device manipulates its own rules and is the source or destination of the traffic. We can have:
   2.1 dev-dev is some very specific cases.
   2.1 dev-core, the LPWAN case
   2.3 core-core, the PPP case

1. Rule Selection:
   Laurent: We shall say that the Rule offering the best compression shall be selected.
   Ana: RFC8724 leaves to the implementation the freedom to choose the Rule it prefers. Your example should be avoided.
   IM: Yes, but there is still a probability based on the implementation choice that the modified rule is chosen. Therefore, the attack vector still exists, so the example shall not be avoided.
2. Rule Database:
   Ana: The concept is present in the archi draft but it is not cited anywhere in the RFC. Shall we say this is rather a Registry?
   Ivan: Shall we ask in the ML to reach a consensus on this terminology?

Problem: We don't know the structure of the Uri-Path, so we may need to add or remove FID

Ana: I don't agree to add or remove FID's, in which case you need to add/remove a FID?
Ana: I think you need to add/remove Rules from the Context
Laurent: What if we add you d'ont know the structure of your URI path so you want to add an element
don't know, may be we can avoid it, one scenario is that you d'ont know the structure of your URI path so you want to add an element, but does it worth the cost of introducing it in the current standard.
Ana: This means that you disagree with the definition of the original
header, and so you do not follow RFC8724. Section 7
Compression/Decompression."... the Rule matches the original packet... In a
Rule, the Field Descriptors are listed in the order in which the fields
appear in the packet header...."
So since the beginning the Rule describe the non-compressed header, a new
Uri-Path is un update and perhaps belongs to another packet??