On Tue, Jul 03, 2018 at 10:56:49PM -0500, Benjamin Kaduk wrote: > On Wed, Jul 04, 2018 at 03:20:42AM +0000, Reshad Rahman (rrahman) wrote: > > <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).
I must admit to being somewhat perplexed by the request here. In the cases where BFD as a top level module is not the creator of a BFD session, you seem to be concerned that BFD can be used to attack a resource by spoofing that non-BFD client. While this is perhaps logically true, it also means that you have a far greater problem of being able to spoof the underlying BFD clients. To give some real-world examples: - BGP typically requires explicit configuration for its endpoints. - Both OSPF and ISIS will require a matched speaker with acceptable configuration parameters for a session to come up. - Static routes with BFD sessions will require explicit configuration. In each of these cases, a client protocol that also wants to use BFD, the simple spoofing of the protocol endpoints is already a massive disaster since it will allow injection of control plane or forwarding state into the device. This is so much worse than convincing a BFD session to try to come up with its default one packet per mode that ... well, I'm boggled we're even talking about this. :-) My request would be that we not complicate the security considerations of this module for such cases. -- Jeff
