On Oct 17, 2022, at 7:41 AM, Bernie Volz <[email protected]> wrote: > I was thinking more to put this restriction on the dhcp server, when it makes > use of the Radius attribute to respond to a client. I have no issue with it > being limited at configuration too, but the dhcp server should also make sure > only a limited set of options are sent to client. > > Leaving this wide open causes issues as it may be miss used to inject things > that really shouldn’t be.
I agree. There should be a limited set of options which are allowed, perhaps via a registry. > Looking at it again, it is also unclear how a dhcp server is to use > information. For example, does the server use options from this information > before its own configuration or only if it has no configuration (I suspect > the former, as this is more client/request specific). That should be made explicit in the draft. I don't have opinions either way, but your point makes sense. > And from RFC7037, there is > > 169 DNS-Server-IPv6-Address [RFC6911] > > Does this mean someone could now place the DNS server option into your new > Radius attribute instead of using this attribute to have the server map it to > the DHCP option? If it's allowed by the registry, presumably, yes. RFFC 6911 says that those RADIUS attributes can appear multiple times. So presumably it doesn't matter much if the DNS server information appears once in a RADIUS attribute, and separately in a DHCPv6-Options attribute. They can all be added to the packets. i.e. if the administrator of the system configures something weird, the systems should just do what's asked. Anything past basic filtering is complex to define, and complex to implement. And arguably doesn't have a lot of extra value. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
