On Mar 14, 2023, at 7:10 AM, Bernie Volz <bev...@gmail.com> wrote: > Of course if the data is malformed, then following existing policies > (rfc6929) is prudent. Though even there it isn’t 100% clear what to do if the > attribute is well formatted but the option data is bad - mostly the length of > the last DHCP option exceeds the remaining data in the RADIUS attribute. I > doubt we expect RADIUS or DHCP servers to assure that each individual option > is valid (such as the length is a multiple of 4 or 16 if data is list of > addresses).
If a RADIUS server implements this specification, we pretty much do expect that. RADIUS servers which don't support this specification can have administrators define the options as opaque strings: 0xabcdef... In that case, the RADIUS server has no idea what the data is, and doesn't validate the options. RADIUS servers which do support this specification have some way to expose the DHCP data as something other than opaque strings. In which case the RADIUS server takes those humanly readable values, and packs them into DHCP options, and then into RADIUS attributes. This packing not only must be done correctly, it should automatically create correctly-formed attributes. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
