Hi Sean,
Thank you for the review.
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : Sean Turner via Datatracker <noreply@xxxxxxxx>
> Envoyé : dimanche 23 février 2025 03:47
> À : secdir@xxxxxxxx
> Cc : draft-ietf-netmod-acl-extensions.all@xxxxxxxx; last-
> call@xxxxxxxx; netmod@xxxxxxxx
> Objet : Secdir last call review of draft-ietf-netmod-acl-extensions-14
>
>
> Reviewer: Sean Turner
> Review result: Ready
>
> Hi! I (finally) reviewed this I-D. First a couple of caveats before I
> get to the review: - I read the entire I-D; I mean it is an 80 page
> document with 60 pages of YANG ;) - I did not validate the YANG
> modules; assumed the authors + DRs did. - I did not confirm that the
> module conforms to the NMDA.
>
> I picked ready to go because I think my comments and question below
> are going to be easy to resolved.
>
> With that out of the way, on to the review!
>
> Section 1.1: Do you want to ask the RFC editor to update the 4
> Copyright years in the Appendices to match the Copyright year that
> will be in the Copyright Notice? Right now they are 2024, 2020, 2023,
> and 2023; just asking because I also note that the filename includes
> the same years.
[Med] The one about 2024 needs to be updated to 2025. The others are OK given that these are mirroring the dates in the IANA registry, but more importantly these won't be published in the RFC per this note in Section 1.1:
(2) The modules are provided in Appendix A.2, Appendix B.2, and
Appendix C.2 for the users convenience before publication as RFC.
Please remove these appendices from the final RFC.
>
> Section 3.2 defines protocol sets as follows:
>
> Protocol sets: A protocol set contains a list of protocol values.
> Each protocol can be identified either by a number (e.g., 17) or a
> name (e.g., UDP).
>
> The "or" there makes me wonder whether there is ever going to be a
> chance when somebody use a number and somebody else uses a name. How
> does the matching work? Is that where the alias comes to play?
>
[Med] The "or" is used to echo the union YANG construct used in the spec:
==
leaf-list protocol {
type union {
type uint8;
type string;
}
==
There are implementations that allow to match based on the name while others are based on the numerical values.
The alias covers another aspect.
> The Security Considerations mirror other YANG module security
> considerations, i.e., the first three paragraph follow the same
> format. The bullets in the 3rd paragraph as where it gets interesting.
> Any chance we could add what might happen if an attacker got a view of
> defined-sets:
>
> 'defined-sets': Unauthorized read access of these lists will allow
> an attacker to identify the actual resources that are bound to
> ACLs.
>
> Maybe something along the lines of "disclosure of this information
> could potentially aid an attacker during a network exploit"?
>
[Med] Sure. Updated to:
NEW:
'defined-sets': Unauthorized read access of these lists will allow
an attacker to identify the actual resources that are bound to
ACLs. Likewise, access to this information will help an attacker
to better scope its attacks to target resources that are specific
to a given network instead of performing a random scan. Likewise,
disclosing some of this information (e.g., IP addresses of core
routers) may nullify the effect of topology hiding strategies.
> Mia culpa: I don’t know enough to validate the final paragraph of the
> Security Considerations.
>
____________________________________________________________________________________________________________
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.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
