[dhcwg] draft-ietf-dhc-agentopt-radius-00.txt

I'd like to better understand the need for this document and what
problem it solves.

The model here seems to be:

1) client authenticates itself with access device using 802.1X L2
   signalling.

2) access device happens to also be a DHCP relay agent (required).

3) as part of 802.1x, access device talks to radius server, gets back
   some radius AVPs. It caches those AVPs.

4) when client sends DHCP packets, relay agent appends the radius AVPs
   to the DHCP message via an agent options sub-option.

5) DHC server then uses the radius AVPs to figure out which address to
   give out.

What I'd like to understand better:

1) is this used to (say) assign an address from the correct VLAN? If
   so, can't this be done without using the radius AVPs? I.e., say
   with a generic agent options sub-options that identifies the vlan

2) Seems like it might be dangerous to cache the radius stuff and then
   later (how much later? hours?) include it in messages to the DHC
   server. How does the server know the information is accurate or
   relevant? Moreover, should the DHC server trust those radius AVPs
   without itself checking with the radius server? I would think not,
   in which case what is the benefit of even including that info in
   the DHCP messages, when the DHC server can presumably just get the
   info directly from the radius server itself?

3) Seems like a more general (and less radius specific) approach would
   be for the relay agent to include the information that the client
   provided, and then let the DHC server query the radius server
   itself (just like the access device does). Or, in fact, maybe it
   will query a diameter server. Why wire the RADIUS stuff into the
   DHCP protocol?

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg