On Wed, Jul 04, 2018 at 03:20:42AM +0000, Reshad Rahman (rrahman) wrote: > Hi, > > Thanks for the review. Please see inline <RR>. > > > On 2018-07-03, 4:21 PM, "Benjamin Kaduk" <ka...@mit.edu> wrote: > > 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). > <RR> I am not 100% sure I understand the point being made. Is it a question > of underlying the importance of having the IGPs authenticated since the IGPs > can create/destroy BFD sessions via the local API?
That's the crux of the matter, yes. Since (in this case) the IGP state changes are being translated directly into BFD configuration changes, the NETCONF/RESTCONF authentication is not really used. So, any authentication/authorization decisions that are made must be on the basis of authentication at the IGP level. This does not necessarily mean a hard requirement for IGP authentication, though using unauthenticated IGP would then be equivalent (for the purposes of this document) to allowing anonymous NETCONF/RESTCONF access. I'd be happy to just have a note in the security considerations that "when BFD clients such as IGPs are used to modify BFD configuration, any authentication and authorization for the configuration changes take place in the BFD client, such as by using authenticated IGPs". But feel free to reword in a better fashion; this is really just about acknowledging the new access mechanism (since the boilerplate covers SSH/TLS for NETCONF/RESTCONF). > > ---------------------------------------------------------------------- > 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)? > <RR> To do that an attacker would need to e.g. access the local device or the > directly connected devices to cause those BFD state transitions. Probably not the most effective vector available, then. > > 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. > <RR> Good point. I will add those nodes. Thanks! -Benjamin
