Re: [dhcwg] passing relay info back to client

["Bernie Volz (volz)" <[e-mail]>]

Kent:

I’m not sure I understand. Usually the correct location on the network is determined by the server by using the giaddr or Relay-Forw link-address to determine on which network segment a client is on. The remote-id and interface-id options are related to the Relay agent used, so how would the client know what to send (and sending values from where it might have been previously aren’t useful if it has been moved).

Also, letting clients provide this kind of data seems to be a potential security issue?

Also, clients are not often identified by their serial number – but by the link-layer address (see RFC 3315 section on DUIDs). Yes, there is a DUID-EN format which could include a serial number.


-          Bernie

From: dhcwg [mailto:[e-mail]] On Behalf Of Kent Watsen
Sent: Thursday, January 04, 2018 4:41 PM
To: Ted Lemon <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [dhcwg] passing relay info back to client

Hi Ted,

Thanks for the speedy reply and the pointer to RFC 6422.   Yes, that seems to do it, but looking at the IANA registry, I see that OPTION_ERP_LOCAL_DOMAIN_NAME is the only option that is supported thus far, so we'd have to add the Remote-ID and Interface-ID options if needed…

The problem I'm trying to solve is one whereby an operator has a number of devices in storage, any one of which may be retrieved and placed somewhere in their network.   The goal is for the device to bootstrap itself with the correct configuration for its given location in the network.  Normally, a device would "call home", identifying itself via its serial number (i.e., IDevID certificate), for which the NMS is preconfigured to know the device's location, and hence sends the correct configuration (for that location in the network) to the device.   However, some operators don't want to implement the backend tracking logic to know which serial number goes where; instead, they want to rely on values such as remote-id and circuit-id to identify the device's location.  In this case, the device's call home message is something like "this is my serial number, and this is where I'm located".  The NMS receiving the call home message can still verify that the device is a valid device (i.e., its serial number is allowed on the network), but rather than rely on preconfiguration to know where the device is located, it instead uses the location information passed by the device.   Both scenarios lead to the same initial configuration being passed back to the device, they only differ in the steps take to determine where the device is located.  Makes sense?

BTW, in case it's unclear, this zerotouch bootstrapping (call home) step is envisioned to be something that happens just the very first time the device boots.  The NMS would record/bind the device (serial number) to the given location, and hence does not need to be informed of its location ever again.

Thanks again,
Kent


On 1/4/18, 2:57 PM, "Ted Lemon" <[e-mail]<mailto:[e-mail]>> wrote:

RFC 6422 addresses this issue for DHCPv6.   There's no solution for DHCPv4.   In general, we don't want the relay to be adding options to the packet on the way to the client, so it would have to be special-case behavior.   There's no reason why something like RFC 6422 couldn't be done for DHCPv4—it's just that it's a legacy protocol, so we aren't doing work on it.

That said, can you talk about the actual problem you're trying to solve here?   What you said you want to do doesn't actually make sense to me, so either I'm missing something, or you're thinking of doing something with DHCP that doesn't actually make sense in the greater context of DHCP.