[netmod] Re: rfc8407bis: rpc mention in the security template

Wed, 30 Oct 2024 03:26:41 -0700

FWIW, my client-server drafts do consider the security of nodes defined only in groupings. 

Then, in other drafts using those groupings, the Security Considerations would say to also look at the Security Considerations from RFCs containing the imported modules. 

This way:

  - the considerations aren’t context specific 
  - the drafts didn’t have to repeat the same thing where used (only once where defined)

Kent // contributor


On Oct 30, 2024, at 2:42 AM, [email protected] wrote:



Hi Mahesh,

 

The text quoted from the udp-client-server is actually following the template, especially this check:

 

     -- if your YANG module does not define any data nodes, then

     -- add the following text

 

   The YANG module defines a set of identities, types, and

   groupings. These nodes are intended to be reused by other YANG

   modules. The module by itself does not expose any data nodes that

   are writable, data nodes that contain read-only state, or RPCs.

   As such, there are no additional security issues related to

   the YANG module that need to be considered.

 

   …

 

For the generic question you asked below, the practice I have seen in the past is to be silent about this. See for example RFC8575, RFC8341, RFC8346, etc.

 

Having done that in the past is not a reason to prevent us to make a change if we do see a value.

 

Cheers,

Med

 

De : Mahesh Jethanandani <[email protected]>
Envoyé : mercredi 30 octobre 2024 00:58
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>
Cc : [email protected]
Objet : Re: rfc8407bis: rpc mention in the security template

 


And as additional context to what Med is asking, here is some text from draft-ietf-netconf-udp-client-server:

 

The module by itself does not expose any data nodes that are writable, data nodes that contain read-only state, or RPCs. As such, there are no additional security issues related to the YANG module that need to be considered.

 

Granted, in this case the draft is defining only groupings. Regardless, the question is if the draft is not defining e.g., any writable nodes, should the draft be silent about it, or call out explicitly?

 

Cheers.



On Oct 29, 2024, at 1:33 AM, [email protected] wrote:

 

Hi all,

Mahesh raised a comment for a document I'm editing:

====


Do the authors want to add a statement that says no rpcs are defined,
and therefore no security considerations need to be documented for
them.


[Med] Not sure that is needed. Please note that the template only requests to add RPC cons where these are defined:

   -- if your YANG module has defined any RPC operations
   -- describe their specific sensitivity or vulnerability.

Do you see a value in saying it explicitly? If so, we need to have this included in the template.
====

Any preference about updating the template?

Cheers,
Med
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

 

Mahesh Jethanandani

 

 

 

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to