Benjamin Kaduk has entered the following ballot position for draft-ietf-netmod-acl-model-19: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think this is good work to have, overall, and the document pretty easy to read. That said, I think the Security Considerations need to be expanded a bit more before this document get published: Write operations (e.g., <edit-config>) to these data nodes without proper protection can have a negative effect on network operations. I think the effects can be on more than just *network* operations, there can be negative effects for end systems that (e.g.) experience DoS attacks that would otherwise have been blocked, receive maliciously crafted packets that trigger application bugs, are used as part of (e.g.) UDP amplification attacks, etc. /acls/acl/aces: This list specifies all the configured access control entries on the device. Unauthorized write access to this list can allow intruders to access and control the system. Unauthorized read access to this list can allow intruders to spoof packets with authorized addresses thereby compromising the system. I agree with the secdir reviewer that "the system" needs to be clarified, and that the consequences of unauthorized write and read access need to be more clearly described. His proposed text is much better than the present text, though there are other ways to convey the needed information. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I tried to call out the editorial nits as such; there are a couple non-editorial comments embedded within. Section 1 The match criteria allows for definition of packet headers and metadata, all of which must be true for the match to occur. nit: Is this missing a word like "contents"? The matching of filters and actions in an ACE/ACL are triggered only after application/attachment of the ACL to an interface, VRF, vty/tty session, QoS policy, routing protocols amongst various other config attachment points. nit: I think the end of this list needs some clarification/termination, like "and routing protocols, amongst" Section 3 The match criteria allows for definition of packet headers or metadata, if supported by the vendor. [...] (same nit as above re "contents") Metadata matching applies to fields associated with the packet, but not in the packet header such as input interface, packet length, or source or destination prefix length. The actions can be any sort of nit: comma after "not in the packet header" Section 4.1 nit: The feature match-on-udp and -icmp descriptions should probably use the plural "headers" to match the other features' descriptions. The mixed-<blah> features seem to implicitly assume that if features X and Y are individually supported, then the combination is also supported. I could imagine that there might exist hardware for which that assumption is not true, but don't know if there actually is any such hardware or it's common enough to be worth caring about here. grouping acl-counters { leaf matched-packets { [...] An implementation should provide this counter on a per-interface per-ACL-entry if possible. nit: missing "basis"? (Also in subsequent instances.) Section A.1 It's unclear that using [email protected] (in particular, the @newco.com part) in an example is reasonable; @newco.example would be better. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
