Hello, On Wed, 9 Jul 2025, at 13:01, Eliot Lear wrote: > > Alan and I thrown together a bit of a draft that would carry DHCP > option information in a TEAP TLV. The purpose of this is that there > are a number of configuration elements in DHCP that really are not at > all linked to topology or address assignment. Like finding a printer, > a proxy, or things like that. TEAP already builds a security context, > so why not make more use of it? > > Have a look at draft-lear-teap-config-options
Another 'bigger question' to add to the slides... For where topological information (eg. IP address assignment) is deemed to be within scope. Any ideas how the switch port could enforce something like DHCP snooping if there is now nothing on the wire it can read? Joking, not joking, outer-TLVs could help here but this brings back the needs for a crypto-binding which the thoughts around for TEAPv2 are leaning to not do for non-authenticating methods (obviously this could change). Only spit balling but maybe there is something we can instead do to extend the TLS binding to carry over to the DHCP. This would then no longer be limited to TEAP, you could maybe even retrofit it to EAP-(T)TLS. My thinking is the DHCP client would then include an attribute to the server saying "I expect something binding here tied back to the TLS session of my EAP dance" and the DHCP server would include it as an option in the response. The client decide what to do in the presence (or non-presence) of it based on a local policy. With this, you could now do topological (eg. IP) assignment and support DHCP snooping. With the proposal TEAP options approach, there would need to be some additionally special OOB protocol between the switchport and your policy server to communicate these DHCP assignments and make DHCP snooping work in practice. Of course the other option is to leave this at "use this only for assigning the WPAD server" :) Cheers Alex _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
