Linda
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-----
> 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.
