Container Option for Server Configuration
draft-ietf-dhc-container-opt-07

My apologies for getting to this draft so late. I did not realize what it was and did not even realize this work was in progress. It has lots of implication to VoIP and IpTV work in RAI.  These are discus discuss and many of them simply reflect I am just getting up to speed on this now. 

I would like the geopriv and ecrit folks to get a chance to look at this. My understanding of their assumptions about DHCP will work is not at all consistent with this and this could have some fairly significant implications to plans for Emergency 911 type systems. 


Today, RG are almost always NATs and they are deployed in a nested fashion. So the DSL modem may have a RG, but very often another "RG" that is perhaps a wireless AP is plugged into that. This draft needs advice on how it works with multiple layers of RGs. My current read of it, it does not look like it would work in the layered case.  

This draft needs advice on how the RG deals with conflicts. For example, if normally it would take whatever DNS server was found by the RG client and advertise that in the RG server. But imagine the container also has the name of the DNS server. Which one does the RG Server use?

I don't understand why the the SP needs to be able send different information to the equipment behind the RG than it sends to the RG. Can you clarify the reasoning behind this requirement?


In section 3, the third req bullet point. I'm not clear on the requirement. Are you saying there much be a way for a SP to add new potion that gets sent to the user equipment without changing the software/config on the RG? This would make sense to me as a requirement but I'm not sure this draft meets that. When the RG Server gets an option it does not know about in he container, what does it do with it?


How is expiry of the information in the container handled? If the SP wants to change some of the information in it, how is that done? 

These containers are going to get very large - does anything need to be said about size? With this work with a 10k container?

In section 5.5, can you please explicitly list the things the RG Server needs to discard - as an implementer I would not know what to do. 

Can the SP send a container even if the RG client does not request it? This seems inconsistent with other DHCP stuff. Why is it like this?

Can the RG server return a container to someone that requests it and what goes in it?

The idea that DHCP authentication would be configure between two nested RG in grandma's house seems extremely unlikely. I am not aware of any deployments that use authenticated DHCP between SP and RG. The idea that I can get pushed a container with the RG client did not even send a request, seems very disturbing from a security point of view. This is going to contain things like my location for E911 calls. I realize that what is possible for the security is going to be pretty limited but I'd like to see it at least mitigate attackers that were not on the path between RG Client and SP DHCP server. 


The statement that the RG server MAY discard everything make a device that passes nothing useful down fully compliant with the spec. This seems a bit problematic for trying to deploy services that actually use this. I rather see something along lines of SHOULD pass it all unless explicitly configured to block something and default configuration needs to not block.

I share the concerns expressed by othe ADs about the danger of this document being interpreted as defining an extension of DHCP that would allow usage as  a more generic service configuration protocol. I believe that there is need for more strict language that clarifies the scope of the container option and restricts the deployment space to RGs. 

Specifically wherever it makes sense replace 'configuration information' by 'DHCP configuration information'. 

Also in the Intorduction section: 

  The DHCP Container option defined in this document provides a
   mechanism through which the RG DHCP client can pass DHCP options to
   the RG DHCP server without explicit knowledge of the semantics of
   those options.  With this option, the SP DHCP server can pass both
   current and future DHCP options to the RG DHCP server.

   The DHCP Container option does not carry IP addresses, IPv6 prefixes
   or other information about leases.  It carries other configuration
   information.

The last phrase should make clear that the DHCP container option carries configuration information expressed as DHCP options. 

Also, in the OPS-DIR review by Tina Tsou the observation was made that it is not clear from the text that the RG client and RG server are always considered as being physically colocated in the same device. It would be good to make this statement explicit, to avoid any other 'creative' deployments or interpretations in the future.

This document appears to target a very specific type of deployment, but doesn't explicitly restrict the applicability of the option to that deployment scenario. 

Given the very limited semantic definition it's very difficult to anticipate the potential consequences should some other type of deployment attempt to use the option, or if the option leaks into unintended places.

There was some list discussion around multiple interfaces in an RG, but it focused on DHCP-clients on those interfaces. It's not clear what could happen that's sane if the RG element had more than one interface where it was acting as a server.

---- (4/13/2010 Adopting Cullen Jenning's Discuss) ------

I would like the geopriv and ecrit folks to get a chance to look at this. My understanding of their assumptions about DHCP will work is not at all consistent with this and this could have some fairly significant implications to plans for Emergency 911 type systems.


Today, RG are almost always NATs and they are deployed in a nested fashion. So the DSL modem may have a RG, but very often another "RG" that is perhaps a wireless AP is plugged into that. This draft needs advice on how it works with multiple layers of RGs. My current read of it, it does not look like it would work in the layered case.

This draft needs advice on how the RG deals with conflicts. For example, if normally it would take whatever DNS server was found by the RG client and advertise that in the RG server. But imagine the container also has the name of the DNS server. Which one does the RG Server use?

I don't understand why the the SP needs to be able send different information to the equipment behind the RG than it sends to the RG. Can you clarify the reasoning behind this requirement?


In section 3, the third req bullet point. I'm not clear on the requirement. Are you saying there much be a way for a SP to add new potion that gets sent to the user equipment without changing the software/config on the RG? This would make sense to me as a requirement but I'm not sure this draft meets that. When the RG Server gets an option it does not know about in he container, what does it do
with it?


How is expiry of the information in the container handled? If the SP wants to change some of the information in it, how is that done?

These containers are going to get very large - does anything need to be said about size? With this work with a 10k container?

In section 5.5, can you please explicitly list the things the RG Server needs to discard - as an implementer I would not know what to do.

Can the SP send a container even if the RG client does not request it? This seems inconsistent with other DHCP stuff. Why is it like this?

Can the RG server return a container to someone that requests it and what goes in it?

The idea that DHCP authentication would be configure between two nested RG in grandma's house seems extremely unlikely. I am not aware of any deployments that use authenticated DHCP between SP and RG. The idea that I can get pushed a container with the RG client did not even send a request, seems very disturbing from a security point of view. This is going to contain things like my location for E911 calls. I realize that what is possible for the security is going to be pretty limited but I'd like to see it at least mitigate attackers that were not on the path between RG Client and SP DHCP server.


The statement that the RG server MAY discard everything make a device that
passes nothing useful down fully compliant with the spec. This seems a bit
problematic for trying to deploy services that actually use this. I rather see something along lines of SHOULD pass it all unless explicitly configured to block something and default configuration needs to not block.

This document probably deserves some discussion. To be honest, I am torn between voting YES and DISCUSS. Let's see how the discussion on the call goes.

On the one hand, the DHCP container object is a good thing. It permits the host and the SP DHCP Server, even when the intervening RG client has no idea what those two parties are discussing.

On the other hand, this conversation could be dangerous. If one were to think of the customer and SP domains as being separate, the RG client would be a reasonable place to put the security boundary. If the boundary were implemented at the RG client, it would be a bad thing for the client to pass on messages that it doesn't understand.

If this option were to be used, each client host would have to protect itself from bad behavior on the part part of the SP (e.g., installing as route to 0.0.0.0/0 through your other provider, installing a static route to the SP's competitor through /dev/null).

  The Gen-ART Review by Scott Brim posted on 7 April 2009 raises some
  concerns that have not been addressed.  Responses to these concerns
  are needed, even if there are not any document changes.  The review
  can be found at:
     http://www.softarmor.com/rai/temp-gen-art/
     draft-ietf-dhc-container-opt-05-brim.txt

Joe Salowey's secdir review (posted on 14 April 2009) proposed clarifying text for the
security considerations and raised questions regarding the suitability of this protocol
for interactions between the RG server and client hosts.  I have not seen a response
to this message, and am interested in hearing the author's position on the proposed text
and the applicability question.