Hi Linda, Thanks for your SECDIR review of the document. And thank you for jumping on the request to provide the review. Much appreciated.
I do have a few comments. Please see inline. > On Jan 29, 2025, at 10:39 AM, Linda Dunbar <[email protected]> wrote: > > Med, > > You are right that the risks associated with ACL manipulation are not unique > to this draft and align with those in RFC 8519. However, the introduction of > new features such as defined-sets, aliasing, and payload-based filtering > expands the attack surface, warranting additional mitigation recommendations. The document does cover defined-sets in the Security Considerations section of the document. Maybe some sentences could be added for aliasing and payload-based filtering. > > While RFC 8341 provides a foundation for user and data access control, it > does not explicitly address ACL-specific threats such as unauthorized > modifications or tampering. Given the critical role ACLs play in security > policy enforcement, it may be beneficial to reinforce best practices tailored > to ACL configurations, such as: > > Requiring digital signatures (e.g., PKI-based certificates, HMAC) for ACL > modifications to ensure authenticity. > Deploying anomaly detection mechanisms to detect and alert on unusual ACL > modifications. > Restricting ACL modifications to predefined maintenance windows to reduce > exposure to accidental or unauthorized changes. All good points. However, I believe they are not specific to ACL configuration. NETCONF/RESTCONF already requires secure authenticated sessions to be established to make any modifications or read the config. Repeating your first bullet item will be redundant in this document. > > It doesn't look like that there is any BCP specifically addressing ACL > integrity protections, perhaps referencing broader security best practices > from RFC 2196 (Site Security Handbook) or RFC 4949 (Internet Security > Glossary) could be helpful. The last two bullet items are items that should be targeted for a BCP like RFC 2196. Cheers. > <> > Linda > > -----Original Message----- > From: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> > Sent: Wednesday, January 29, 2025 12:52 AM > To: Linda Dunbar <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[email protected]> > Cc: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]> > Subject: RE: Secdir last call review of draft-ietf-netmod-acl-extensions-13 > > Hi Linda, > > Thank you for the review. > > You are completely right about the risks, which are not specific to this I-D > but are similar to RFC8519. This is why we do have the following: > > Similar to [RFC8519], unauthorized write access to these list can > allow intruders to modify the entries so as to permit traffic that > should not be permitted, or deny traffic that should be permitted. > The former may result in a DoS attack, or compromise a device. > The latter may result in a DoS attack. > > For sure, unauthorized access to configuration data (not only ACLs) will > cause a lot of damage. Consider access to a routing configuration, address > allocation, etc. So, if there are any robust measures to recommend, these > should be applicable beyond ACL case. This is why we leverage common blocks > such as RFC8341 for control of users/data access, mutual authentication, etc. > > I think that the guards in the spec are good ones. However, if you are aware > of an ** authoritative BCP ** that we can consider, please let us know. > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : Linda Dunbar via Datatracker <[email protected] > > <mailto:[email protected]>> Envoyé : mardi 28 > > janvier 2025 19:23 À : [email protected] <mailto:[email protected]> Cc : > > [email protected] > > <mailto:[email protected]>; last- [email protected] > > <mailto:[email protected]>; > > [email protected] <mailto:[email protected]> Objet : Secdir last call review of > > draft-ietf-netmod-acl- > > extensions-13 > > > > Reviewer: Linda Dunbar > > Review result: Not Ready > > > > I have reviewed this document as part of the SEC area directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > Security area directors. > > Document editors and WG chairs should treat these comments just like > > any other last-call comments. > > > > Summary: The document defines extensions to the ACLs YANG Model > > specified in RFC 8519. While the description is clear, it lacks > > details on the mitigation methods for ACL Manipulation Risks. > > > > New features such as defined-sets, aliasing, and payload-based > > filtering introduce potential security risks if not properly > > authenticated and authorized. An attacker could: a) Modify ACL > > entries to bypass security policies (e.g., allow the malicious > > traffic); b) Introduce denial-of-service > > (DoS) conditions by blocking legitimate traffic. > > > > To mitigate these risks, the document should include recommendations > > for security best practices, such as, requiring the ACL configuration > > changes to be digitally signed using PKI- based certificates or HMAC > > (Hash-based Message Authentication Code); maintaining a detailed log > > of ACL modifications; storing a hash of ACL configurations in a > > tamper-resistant database; implementing anomaly detection mechanisms > > to trigger alerts for unusual ACL modification; restricting ACL > > modifications only during maintenance windows to minimize accidental > > or unauthorized changes, etc. > > > > Adding these security controls would significantly enhance the > > document's robustness against ACL manipulation attacks. > > > > Best Regards, Linda Dunbar > > > > > > ____________________________________________________________________________________________________________ > 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 [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
