Benjamin Kaduk has entered the following ballot position for draft-ietf-bfd-yang-16: 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-bfd-yang/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2.1 describes a scheme wherein an IGP may generate events that cause BFD sessions to be created/destroyed; this effectively is proxying commands from IGP over the local BFD API, which brings the authentication and authorization of the IGP into scope, even if the local BFD configuration access is authenticated. (That is, the proxying component is always authenticated, but now bears responsibility for performing authentication/authorization/sanity checks on commands before proxying them.) Since IGP security is a topic for elsewhere, the changes to this document seem scoped to documenting the requirements on the IGP/local proxy for these checks, and arguably for only allowing authenticated IGP events to create authenticated BFD sessions (though arguably not as well, for the latter, since this is a YANG model document and not an architecture document). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not very familiar with YANG notifications; is there a risk that they can be abused as a DoS attack vector on the notification recipient by an attacker (e.g., by causing a flapping series of state transition events or by creating/destroying many sessions)? Regarding the Security Considerations: It's unclear whether local-multiplier, the various intervals, and authentication are the only nodes that merit mention for every per-forwarding-path-type module. For example, source/destination addresses could be modified to direct traffic at unwitting recipients, and the key-chain and meticulous settings also seem security-related. Similarly, read-only access to the discriminators (and key-chain/authentication information) could make it easier for an attacker to spoof traffic.
