Ana's Comments on schc access control #10
Comments
|
Hi Ana @minaburo, here you"ll find some answers to the questions you sent us.
IM: I tried to use the same terminology as in the architecture draft?
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).
IM: Yes
IM: Il est au niveau du end point qui a le role du core.
IM: Il est au niveau du end point qui a le role du device.
IM: Un end-point qui a le role du core ou device qui a été modifié par un attaquant
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
[Figure 5](NETCONF Access Control Model (NACM)): NETCONF Access Control Model (NACM)
IM: Oui
IM: It may be benefical to include it indeed
IM: What is a context?? the Rule DB is the element to the left of the left of Figure 5: Summerized SCHC elements
Same as in the archi draft
IM: It depends on the compression rate, if the original rule does not compress, the impact will be more important
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.
IM: yes, my bad
IM: Reffer to the answer to --> What is an original rule?
IM: I have also though about that, we might change this and add that notion of changing status, can be discussed
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)
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.
Refer to rfc6536
IM: Where ?
IM: From the SoR you mean?
IM: Good question, I tend to believe yes there can be a case like that, but I'll let @ltn22 Laurent to iterate here
IM: Why?
IM: @ltn22 ?
IM: @ltn22 ?
|
|
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.
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).
LT: I'm always confused by this two terms, I've no opinion, except that what is a session with more than 2 participants ?
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
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.
LT: yes, we need to understand better all the possible attacks.
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.
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.
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,...)
LT: good point see above.
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.
|
|
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
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEFFDUSVF4FNHVDYVGRTVJLXENPMTANCNFSM6AAAAAAXUU2OOA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
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.
|
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?
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
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
The text was updated successfully, but these errors were encountered: