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

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

OK ...

I would like to see (though it is your call as to whether I will as they
wording may be tricky):

1. Improved description of the usage model for options that could be
considered RSOO options. The abstract, introduction and protocol summary
could be clearer that RSOO options should only be used for cases where
the relay has acquired information that needs to be delivered to the
client that the server would otherwise not be able to know. It is not a
mechanism for the relay to provide configuration that the server would
normally be configured with.

2. Please work in some text to be very clear that existing options are
all RSOO-disabled. It wasn't that clear to me that this was the case
(though I do fully agree that as the document says "Unless specifically
called out as an RSOO-enabled option, no DHCP option should appear in an
RSOO."

I think requesting an IANA registry for these is also a good idea as it
assures that there is one place we can go to see what the list of
RSOO-enabled options are, rather than having to look through various
RFCs? If IANA is unwilling to do this, then we can take it out.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[e-mail]] 
Sent: Monday, October 04, 2010 2:20 PM
To: Bernie Volz (volz)
Cc: Andre Kostur; Qin Wu; [e-mail]
Subject: Re: [dhcwg]
I-DAction:draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt

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!