Support for trusted ports/DHCP snooping

[henn]

Many switches (including the Nexus & Powerconnect) support having "trusted ports" as part of DHCP snooping, which enhance network security by restricting the ports authorized to act as DHCP servers.

In addition, dynamic ARP inspection forces a particular MAC address to stick with its DHCP-allocated IP address.

These could both be a useful feature for admins wishing to improve the security of HaaS L2 networks (like a shared public net that wants to prevent spoofing attacks) and L3 if we decide to go there.

This fits in quite nicely with the HaaS scheme - there could be an admin-only network_{en/dis}able_trust() that operates on NIC channels which could enable one or both of these features. Complicating matters would be that some switches require a TFTP server on which to store the DHCP table.

@okrieg - thought you might be interested.

[zenhack]

This is getting into substantially broadening the scope of what Haas does. If we're going to start exploring this kind of stuff we should be rethinking our approach for abstracting the switch, rather than blindly trying to bolt it on to the existing design.

One avenue we could go down (which might be the right answer) is to just multiplex the underlying functionality, add much as possible without changing the abstraction. We'd expose information about the full range of features to the user, and just proxy/check permissions.

I'm open to other approaches, but I don't want to start adding support for a bunch of device features without a clear plan for keeping the whole thing manageable and still conceptually simple.

This is probably something to keep bouncing around in our heads while we work on other stuff for the time being.

[henn]

I'm a fan of placing these types of features in the main versioned API, then having switch drivers have some standard way of indicating which features are supported (like proposed in #410). We'd then need a query API to tell the user which features are enabled for which nodes.

As HaaS acquires additional switch support, I would imagine that folks will want to continue being able to use their fancy switch features (like DHCP snooping and ARP inspection).

[zenhack]

I'm actually really against doing this sort of thing as part of a monolithic api. Modern switches have a lot of functionality, and to keep things manageable as we support more of it I think that support needs to be modular; I don't want a centralized api doc that enumerates every switch feature under the sun.

The other concern is that (I think) we need to be able to reason about the implications of each feature on authorization in a systematic way. I'm worried that if we're not careful our reasoning about why the security model works will be quadratic in the number of switch mechanisms like this. If that happens, HaaS will be a failure; it will be unsuitable for use as a trusted core component.

[zenhack]

@gsilvis, any thoughts?

[henn]

What you're saying makes sense if there's a single module that implements a feature, and that module is still experimental.

At the same time, we don't want 4 different implementations of a feature like DHCP snooping, each having a separate API.

[zenhack]

Quoting henn (2015-08-07 17:16:15)

At the same time, we don't want 4 different implementations of a feature like DHCP snooping, each having a separate API.

Sure --- we probably want to do some coordination on what those APIs are going to look like, but I still would like to have them not need to be something that has to be in core.

Maybe the thing to do is start talking about how extensions should be allowed to extend the API? @gsilvis and I are of the opinion that we probably should be adding vlans to the pool via api calls, rather than sticking them in the config, but this needs to be addressed first, since those aren't in core either.

This still doesn't address the "how do we make reasoning about security tractable?" problem.