Re: [dhcwg] I-DAction:draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt

[Ted Lemon <[e-mail]>]

On Oct 1, 2010, at 4:39 PM, Bernie Volz (volz) wrote:
> I could easily see some of the options where a relay might be configured
> with local policy that it wants to override ... for example, if I want
> to use a specific domain search list or a set of (internal) DNS servers,
> these seem like valid uses of this capability?

Essentially what you are saying is that it might be worthwhile in some cases to configure the DHCP server by storing configuration on individual routers toward the edge of the network.   By comparison, the application we have in mind is for a situation where the router has acquired information about the client during the layer two authentication/authorization process that it wants to share with the client.   This mechanism provides a communications path to the client that solves the problem nicely.   So it's really quite a different situation.

Does what you are talking about make sense?   I guess so--I can see how you might run a network that way.   But it's a very different application.   And nobody does it that way now, nor does anybody expect to.   Furthermore, we haven't thought through the security implications, and I think they are significant.   It's because of the security implications that I want to keep this draft as small and targeted as possible.   The mere *possibility* that this might be useful in the case you describe is not (IMHO) a good enough reason to open such a large attack surface.   If you have a real use case, that's a different thing, but you haven't given us any indication that you do.

> So you'd have to get the DHCP administrator to unconfigure these items
> for the networks serviced by the relay.

Camel.   Tent.   Nose.   The extra opening up of attack surface that you're suggesting is precisely why I don't want us to do this.   In order for this to be useful in the way you are proposing, I think it necessarily has to have relay agent authentication.

> If this is just about the EAP stuff, why not have an EAP specific Relay
> Option that communicates this rather than a very general purpose
> mechanism?? Avoids a lot of these issues and questions?

The reason for having a generic mechanism is that there's another draft that's actually in the IETF publication queue that also depends on this sort of functionality, and that indeed defined a one-off solution.   Each such one-off solution requires special-case code in the DHCP server.   Hence, it makes sense to define a general mechanism for solving problems of this kind.

> BTW: The above text from the draft brings up an old issue ... if relay
> chaining is in use, and multiple relays in the chain include RSOO, what
> is the default order for processing these multiple RSOOs (a DHCP server
> could always allow for policy to override). This was never clarified
> with respect to the link-address field in the Relay-Forw's in 3315
> (though there likely closest relay to the client out makes sense because
> the link-address closest to the client is likely the correct one).

Yeah, I added a bunch of text for this to the relay encapsulation for DHCPv4 draft.   I haven't reread RFC3315 to see how it compares.

> As a nit, if you stick with the general purpose option, the use of
> "suboptions" is a bit confusing in 3. Encoding. I'd recommend you follow
> the convention in RFC 3315 (such as 22.4 and 22.5) and use
> "RSOO-options" instead of "suboptions".

Good point, thanks!