search

lp-wan / datamodel

use of yang to describe SCHC
1 stars 3 forks source link

Ana's Comments on schc access control #10

Open MarinoMtz opened 1 year ago

MarinoMtz commented 1 year ago

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

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

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

MarinoMtz commented 1 year ago

Hi Ana @minaburo, here you"ll find some answers to the questions you sent us.

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

IM: I tried to use the same terminology as in the architecture draft?

SOR. Set of Rules. C'est le Context?

IM: SoR, is the Set of Rules as in: Figure 5: Summerized SCHC elements

IM: I don't know what is a context, but an instance is a session which is operation between a pair of peers (end-points).

RM. Rule Manager. Peut-on faire le lien avec le draft architecture?

IM: Yes

Core RM. Quelle est sa difference?

IM: Il est au niveau du end point qui a le role du core.

Device RM. Quelle est sa difference?

IM: Il est au niveau du end point qui a le role du device.

Compromised Core. C'est quoi compromised Core or Device?? Compromised Device

IM: Un end-point qui a le role du core ou device qui a été modifié par un attaquant

Destructive Rule. C'est quoi une règle destructive? Qui peut la introduire et comment les avoir?

IM: Une regle menant a une combinaison destructive, qui peut etre plus atractive car elle offre un taux de compression plus élévé

IM: L'idée c'est qu'avec le access control personne peut les introduire

NACM ? Je n'ai pas trouvé

[Figure 5](NETCONF Access Control Model (NACM)): NETCONF Access Control Model (NACM)

DM. Data Model Faire lien avec le RFC9363?

IM: Oui

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

IM: It may be benefical to include it indeed

  • 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.

IM: What is a context?? the Rule DB is the element to the left of the left of Figure 5: Summerized SCHC elements

  • In Threat Model What is peer of peers?

Same as in the archi draft

  • In Scenario 1.

    Why the impact of the attack depends on the original rule?

IM: It depends on the compression rate, if the original rule does not compress, the impact will be more important

What is an original rule?

IM: In the scenario we are trying to describe, the idea is to have some management messages that will use CORECONF to change the Set Of Rules, this can go from the device to the core of vice versa. So the original rule is the one that the end point is trying to update.

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

IM: yes, my bad

  • In Scenario 1. Point 2 What do you mean by messages aiming at changing rules?

IM: Reffer to the answer to --> What is an original rule?

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?

IM: I have also though about that, we might change this and add that notion of changing status, can be discussed

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.

IM: Good idea, if yes, I think we should restric the MA:CDa combination to ports so that they are not compressed (meaning always need to be present in the residue)

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?

IM: By introducing destructive rules: The residue f the original Rule is larger than the residue of the rule once the modification has been done.

  • YANG Access Control NACM meaning?

Refer to rfc6536

Which granularity? Explain I don't understand the case of Uri-path

IM: Where ?

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

IM: From the SoR you mean? IM: There can be a management operation where the rule contains more or less FIDs than the original one

  • 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?

IM: Good question, I tend to believe yes there can be a case like that, but I'll let @ltn22 Laurent to iterate here

I think that not all the Rules may be modified. For example No-Compress Rule is a fixed Rule.

IM: Why?

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?

IM: @ltn22 ?

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

IM: @ltn22 ?

Ana

ltn22 commented 1 year ago

Hi Ana and Ivan;

I agree we have to define things more precisely. RFC 8724 gives some definitions regarding compression and fragmentation and sometime we don't use them correctly and here the AC opens to more architectural perspectives. I think it is good to work on it here and be aligned with the architecture draft.

Hi Ana @minaburo, here you"ll find some answers to the questions you sent us.

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

IM: I tried to use the same terminology as in the architecture draft?

SOR. Set of Rules. C'est le Context?

LT: That's a good point, I will say that SoR is just the rules and context is the SoR + some elements to identify the owner. In some occasions, such as in the core, we can have several Set of Rules to handle several devices. In my view we have several Set of Rules and several contexts. (the context cannot be view globally but is dependant of a device).

IM: SoR, is the Set of Rules as in: Figure 5: Summerized SCHC elements

IM: I don't know what is a context, but an instance is a session which is operation between a pair of peers (end-points).

LT: I'm always confused by this two terms, I've no opinion, except that what is a session with more than 2 participants ?

RM. Rule Manager. Peut-on faire le lien avec le draft architecture?

IM: Yes

Core RM. Quelle est sa difference?

IM: Il est au niveau du end point qui a le role du core.

LT: Core SCHC manipulates rules for several devices, and is not the source or destination of the traffic. Device SCHC manipulates its own rules and is the source or destination of the traffic. We can have:

LT: see above

IM: Il est au niveau du end point qui a le role du device.

Compromised Core. C'est quoi compromised Core or Device?? Compromised Device

IM: Un end-point qui a le role du core ou device qui a été modifié par un attaquant

Destructive Rule. C'est quoi une règle destructive? Qui peut la introduire et comment les avoir?

IM: Une regle menant a une combinaison destructive, qui peut etre plus atractive car elle offre un taux de compression plus élévé

LT: In SCHC equal/not-send, ignore/value-sent, ignore/compute-*, MSB/LSB, Match-mapping/mapping-sent do not destroy the information. the information is ever 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.

but 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.

One point, I didn't find it in RFC8724, is that if several rules apply, the compressor select the one with the smallest SCHC packet.

IM: L'idée c'est qu'avec le access control personne peut les introduire

NACM ? Je n'ai pas trouvé

[Figure 5](NETCONF Access Control Model (NACM)): NETCONF Access Control Model (NACM)

DM. Data Model Faire lien avec le RFC9363?

IM: Oui

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

IM: It may be benefical to include it indeed

  • 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.

IM: What is a context?? the Rule DB is the element to the left of the left of Figure 5: Summerized SCHC elements

  • In Threat Model What is peer of peers?

Same as in the archi draft

  • In Scenario 1.

Why the impact of the attack depends on the original rule?

IM: It depends on the compression rate, if the original rule does not compress, the impact will be more important

What is an original rule?

IM: In the scenario we are trying to describe, the idea is to have some management messages that will use CORECONF to change the Set Of Rules, this can go from the device to the core of vice versa. So the original rule is the one that the end point is trying to update.

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

IM: yes, my bad

  • In Scenario 1. Point 2 What do you mean by messages aiming at changing rules?

IM: Reffer to the answer to --> What is an original rule?

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?

IM: I have also though about that, we might change this and add that notion of changing status, can be discussed

LT: yes, we need to understand better all the possible attacks.

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.

IM: Good idea, if yes, I think we should restric the MA:CDa combination to ports so that they are not compressed (meaning always need to be present in the residue)

LT: Agree, in fact in the original draft we have the possibility just to change the TV, or to change MO-CDA-TV without any restrictions.

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?

IM: By introducing destructive rules: The residue f the original Rule is larger than the residue of the rule once the modification has been done.

  • YANG Access Control NACM meaning?

Refer to rfc6536

Which granularity? Explain I don't understand the case of Uri-path

IM: Where ?

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

IM: From the SoR you mean? IM: There can be a management operation where the rule contains more or less FIDs than the original one

LT: 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.

  • 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?

IM: Good question, I tend to believe yes there can be a case like that, but I'll let @ltn22 Laurent to iterate here

LT: this means, that you can add or remove some rules (may be we can have something more specific we can add frag rule but not compression,...)

I think that not all the Rules may be modified. For example No-Compress Rule is a fixed Rule.

IM: Why?

LT: good point see above.

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?

IM: @ltn22 ?

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.

Which is the difference between modify-compression-rule and modify-field? LT:in the first you can add field descriptor, on the second just to change values.

IM: @ltn22 ?

Ana

minaburo commented 1 year ago

Hello See my comments below

Ana

On Thu, May 4, 2023 at 10:05 AM Laurent Toutain @.***> wrote:

Hi Ana and Ivan;

I agree we have to define things more precisely. RFC 8724 gives some definitions regarding compression and fragmentation and sometime we don't use them correctly and here the AC opens to more architectural perspectives. I think it is good to work on it here and be aligned with the architecture draft.

Ana: I agree

Hi Ana @minaburo https://github.com/minaburo, here you"ll find some answers to the questions you sent us.

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

IM: I tried to use the same terminology as in the architecture draft?

Ana: I prefer to use terminology of 8724, architecture is a draft an is an ongoing work. If things change you will need to change yours too.

SOR. Set of Rules. C'est le Context?

LT: That's a good point, I will say that SoR is just the rules and context is the SoR + some elements to identify the owner. In some occasions, such as in the core, we can have several Set of Rules to handle several devices. In my view we have several Set of Rules and several contexts. (the context cannot be view globally but is dependant of a device).

Ana: Looking at RFC8724 terminology "Context: A set of Rules used to compress/decompress headers, or to fragment/reassemble a packet. "

IM: SoR, is the Set of Rules as in: Figure 5 https://datatracker.ietf.org/doc/draft-ietf-schc-architecture/00/#figure-5: Summerized SCHC elements https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-architecture-01#name-summerized-schc-elements

IM: I don't know what is a context, but an instance is a session which is operation between a pair of peers (end-points).

LT: I'm always confused by this two terms, I've no opinion, except that what is a session with more than 2 participants ?

Ana: Look above, context is a set of Rules, there is nothing else, unless you want to add something more???

RM. Rule Manager. Peut-on faire le lien avec le draft architecture?

IM: Yes

Core RM. Quelle est sa difference?

IM: Il est au niveau du end point qui a le role du core.

LT: Core SCHC manipulates rules for several devices, and is not the source or destination of the traffic. Device core manipulates its own rules and is the source or destination of the traffic. We can have:

  • dev-dev is some very specific cases.
  • dev-core, the LPWAN case
  • core-core, the PPP case

Device RM. Quelle est sa difference?

LT: see above

Ana: We need to add this in the draft, to make clear what we are doing.

IM: Il est au niveau du end point qui a le role du device.

Compromised Core. C'est quoi compromised Core or Device?? Compromised Device

IM: Un end-point qui a le role du core ou device qui a été modifié par un attaquant

Destructive Rule. C'est quoi une règle destructive? Qui peut la introduire et comment les avoir?

IM: Une regle menant a une combinaison destructive, qui peut etre plus atractive car elle offre un taux de compression plus élévé

LT: In SCHC equal/not-send, ignore/value-sent, ignore/compute-*, MSB/LSB, Match-mapping/mapping-sent do not destroy the information. the information is ever 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.

but 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.

One point, I didn't find it in RFC8724, is that if several rules apply, the compressor select the one with the smallest SCHC packet.

Ana: In the RFC8724 we decided to eliminate this option by leaving the implementation the freedom to choose the Rule it prefers, look at section7.2 Packet Processing "This specification does not prevent multiple Rules from matching the above steps and, therefore, being valid for use. Which Rule to use among multiple valid Rules is left to the implementation. As long as the same Rule set is installed at both ends, this degree of freedom does not constitute an interoperability issue."

Following this issue, the implementation is not forced to choose the smallest residue and can do differently because of other constraints, like the Rule defined in a Device. This is an opportunity to avoid your example ;) If the parser choose the optimal residue by size then the parser can be attacked as you mention, otherwise something more can happens.

IM: L'idée c'est qu'avec le access control personne peut les introduire

NACM ? Je n'ai pas trouvé

[Figure 5](NETCONF Access Control Model (NACM)): NETCONF Access Control Model (NACM) https://datatracker.ietf.org/doc/rfc6536/

DM. Data Model Faire lien avec le RFC9363?

IM: Oui

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

IM: It may be benefical to include it indeed

  • 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.

IM: What is a context?? the Rule DB is the element to the left of the left of Figure 5 https://datatracker.ietf.org/doc/html/draft-ietf-schc-architecture/00/#figure-5: Summerized SCHC elements https://datatracker.ietf.org/doc/html/draft-ietf-schc-architecture/00/#name-summerized-schc-elements

Ana: Context is a set of Rules, the information of the compression/fragmentation. But RFC8724 does not use Rule database anywhere, so what is a Rule Database is it the context or a Registry where I can get the context?

  • In Threat Model What is peer of peers?

Same as in the archi draft

Ana: it is not peer of peers but PAIR OF PEERS!!

  • In Scenario 1.

Why the impact of the attack depends on the original rule?

IM: It depends on the compression rate, if the original rule does not compress, the impact will be more important

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?

What is an original rule?

IM: In the scenario we are trying to describe, the idea is to have some management messages that will use CORECONF to change the Set Of Rules, this can go from the device to the core of vice versa. So the original rule is the one that the end point is trying to update.

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

IM: yes, my bad

  • In Scenario 1. Point 2 What do you mean by messages aiming at changing rules?

IM: Reffer to the answer to --> What is an original rule?

Ana: The point is to agree on which Rules can be modified and which ones are not, and when this Rules can be modified which parts can be or not. If an attack arrives in a non modified part you can detect it else you have to create something that detect the attack.

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?

IM: I have also though about that, we might change this and add that notion of changing status, can be discussed

LT: yes, we need to understand better all the possible attacks.

Ana: the question is do we need to add a status to the 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.

IM: Good idea, if yes, I think we should restric the MA:CDa combination to ports so that they are not compressed (meaning always need to be present in the residue)

Ana: you mean MO/CDA Ana: No I think port can be compressed but are not able to be modified.

LT: Agree, in fact in the original draft we have the possibility just to change the TV, or to change MO-CDA-TV without any restrictions.

Ana: I think we need to study or discuss which cells on the Rule can be modified and see then the attacks over that

And also we can put modification degrees, depending on who you are?

Ana: ?

-You talk about a case where the residue can be reduced, how can the reduction takes place?

IM: By introducing destructive rules: The residue f the original Rule is larger than the residue of the rule once the modification has been done.

Ana: Yes only in the parser that choose the optimal residue...

  • YANG Access Control NACM meaning?

Refer to rfc6536

Which granularity? Explain I don't understand the case of Uri-path

IM: Where ?

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

IM: From the SoR you mean? IM: There can be a management operation where the rule contains more or less FIDs than the original one

LT: 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??

  • 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?

IM: Good question, I tend to believe yes there can be a case like that, but I'll let @ltn22 https://github.com/ltn22 Laurent to iterate here

LT: this means, that you can add or remove some rules (may be we can have something more specific we can add frag rule but not compression,...)

I think that not all the Rules may be modified. For example No-Compress Rule is a fixed Rule.

IM: Why?

LT: good point see above.

Ana: Yes, an attack can add a Rule to the context and then push the parser to choose it.

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?

IM: @ltn22 https://github.com/ltn22 ?

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.

Which is the difference between modify-compression-rule and modify-field? LT:in the first you can add field descriptor, on the second just to change values.

Ana: Explain me or give an example where you need to add a FID, a FID different from the one of your non compressed header?

IM: @ltn22 https://github.com/ltn22 ?

Ana

— Reply to this email directly, view it on GitHub https://github.com/lp-wan/datamodel/issues/10#issuecomment-1534261323, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFFDUSVF4FNHVDYVGRTVJLXENPMTANCNFSM6AAAAAAXUU2OOA . You are receiving this because you were mentioned.Message ID: @.***>

MarinoMtz commented 1 year ago

Thanks for the comments, so here I'll try to summarize:

I propose to go forward to add the first three points to the draft now, and to open a issue per discussion issue listed in point 4.

  1. Terminology section -- Define things more precisely:
    • Align with 8724
    • If possible align with architecture draft as it's an ongoing work
  2. Definitions that are already present in archi or 8724:
    • A Context is Set a of Rules [8724]
    • A Context does not contain additional information [8724].
    • A SCHC instance (or session) is a protocol operation between a pair of peers [Archi].
    • There is a context or Set of Rules per session [Archi].
    • There can be multiple sessions or instances on a SCHC Core [defined as Network Gateway in archi].
    • A Device typically has only one instance.
  3. Definitions to be added in the draft:
    • Rule Manipulation: The role of a Rule Manager:
      • 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:
      • dev-dev is some very specific cases.
      • dev-core, the LPWAN case
      • core-core, the PPP case
    • 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 ever 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.
  4. Ongoing Discussion:
    • 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.
    • 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?
    • 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.
    • Rules types or status:
      • Either type: original, changing, destructive
      • Or Rules status.
    • Uri-path discussion
    • AC to Rules or part of Rules