"manufacturer" selection process refinement

[elear]

Right now "manufacturer" works on the basis of devices that only use same-manufacturer or are otherwise in the manuf_list struct. That's not quite what we want in the longer run. That means that devices not in that struct or in the config are not able to be associated with "manufacturer". To fix this, we would want to know the IP address or some other tag that we can apply an access control to. IP addresses are hard unless they're provided via DHCP_REQUEST, or we otherwise know some other topological information, like which switch the device is connected to, in which case we could poll.

[iggy2028]

I don't think I'm quite groking what you're suggesting, but I've added some thoughts below.

According to section 4.1 of the I-D, "This node consists of a hostname that would be matched against the authority component of another Thing's MUD URL." It follows then that that authority component included in the "manufacturer" directive (e.g., foo.com) must be in the config file, otherwise there's no way to determine any policy. I don't know how you would arbitrarily determine policy to an authority-component that is not configured. You wouldn't even know what IP addresses are associated with that manufacturer if the authority component of that manufacturer isn't in the configuration file.

So then what policy can be used to link together a Device (which has its own manufacturer policy) with a different authority component? I think the original thought was that the Thing would then use a vlan defined from the manufacturer defined by "foo.com", although I'm not sure what happens if its own authority component also had a VLAN. You take about IP addresses, and I don't understand exactly where you're going. If you'll planning to keep track of all of the IP addresses per manufacturer instead of using a VLAN, that's hard. In that case both "manufacturer" and "same-manufacturer" would need to be changed to keep a record of all the current IP addresses that are associated with a manufacturer, and you'll have to be very aware in the code of the limits on the number of ACE statements that switches support in Cisco dACLs, as well as other implementations of the ACLs.

[elear]

Yes, that's hard. That's the challenge. Not only is it a lot of code, but it's a lot of state. But I am also thinking that same-manufacturer can be treated differently from manufacturer, as it is in 1.0. same-manufacturer you can just cram into a VLAN (albeit that means you have to properly provision the size of the VLAN in the case of IPv4). For manufacturer the situation is a bit different. If there is a VLAN assigned for that other manufacturer, we can simply grab the attendant IP addresses and stick them into someone else's allow statement. But if there is no VLAN assignment for the other manufacturer, then at the moment what we have is a MAC address. We could in theory create an L2 ACL, I suppose, but that seems fragile. If we don't have the IP address, we have to go hunting for it. With LLDP and EAP that would almost certainly be the case. Even with DHCP, unless we see the offer or the request, we still go hunting. And "hunting" in this case would mean probing the switch and the port for the device's IP address via the ARP table (hoping that it's there). And that would require shoving all sorts of SNMP state in.