[secdir] Re: Secdir last call review of draft-ietf-netmod-acl-extensions-13

[Mahesh Jethanandani <[e-mail]>]

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 <[e-mail]> 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: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> 
> Sent: Wednesday, January 29, 2025 12:52 AM
> To: Linda Dunbar <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 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 <[e-mail] <mailto:[e-mail]>> Envoyé : mardi 28 
> > janvier 2025 19:23 À : [e-mail] <mailto:[e-mail]> Cc : 
> > [e-mail] <mailto:[e-mail]>; last- [e-mail] <mailto:[e-mail]>; 
> > [e-mail] <mailto:[e-mail]> 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
[e-mail]