Hi Jensen, Please see inline.
Cheers, Med De : Jensen Zhang <jingxuan.n.zh...@gmail.com> Envoyé : jeudi 11 mai 2023 04:15 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : ietf-wg-alto/draft-ietf-alto-oam-yang <reply+abcca5ijepgbnlogwrs6aswcewnptevbnhhgcsj...@reply.github.com>; IETF ALTO <alto@ietf.org> Objet : Re: [alto] [ietf-wg-alto/draft-ietf-alto-oam-yang] Security Considerations (Issue #33) Hi Med, Sorry for the late reply. On Tue, May 9, 2023 at 9:39 PM <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> wrote: Hi Jensen, Thanks for drafting that text. I do still that some sensitive data nodes have to be listed. For example, * Access to all authentication-related data nodes should be protected; those that are inherited from other models have already “nacm:default-deny-write” statement, while there is no such protected from the data node that are added in the draft. Thanks for the suggestion. I agree. But I think the only authentication-related data nodes explicitly added in the current document are "http-auth-client/user-id" and "https-auth-client/user-id" under "auth-client". The leaf nodes referenced by them have already been protected. Shall the leafrefs themselves be also protected? [Med] I think that is safe that the leafrefs themselves be protected. In addition, we need at least two other actions: (1) remind that imported authentication-related data are adequately protected as per my previous reply. (2) add a warning that given that no “nacm:*” statement is added in the top-level auth container, future augmentations should include those. * Consider the example of “poll-interval”: a misbehaving node can set a very large value that would lead to maintaining stale data. Setting very low values can also be considered as a misbehavior. It is a very interesting point. I agree that the range of "poll-interval" should be limited. But the accepted range may depend on the data sources and implementations. It is hard to define a fixed range in the module. Do you have any suggestions about it? Or we just explain this consideration without any concrete solution? [Med] We don’t need to define random ranges for this or touch the YANG model. We only need to list the data node in the security considerations with the associated vulnerability. Thanks. Thanks, Jensen _________________________________________________________________________________________________________________________ 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.
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
