Minutes for the DHC WG Meeting at IETF 75 2009-07-31 0900-1130 CEST Draft version, 2009-08-01 19:18:26 CEST Thanks to Carsten Strotmann for taking notes. These minutes were prepared by the WG co-chairs: John Brzozowski and Ted Lemon. Administrivia Agenda bashing; blue sheets; scribe; Jabber scribe Draft last call and adoption announcements The session starts with a discussion of current document status WG-ID. The draft dhc-container-opt. has been send to IESG, revision of the document is needed based on feedback. A number of other documents are ready for submission to the IESG. The dhcpv6-reconfigure-rebind draft has expired, John Brzozowski is working on refreshing this, it will be send to the IESG queue. The wg-chairs have asked the authors of draft-ietf-dhc-vpn-option to address some issues and then it will be send to IESG. The draft-ietf-dhc-relay-id-suboption draft has been refreshed and is ready to go to IESG. The draft-ietf-dhc-dhcpv4-vendor-message and draft-ietf-dhc-dhcpv6-vendor-message drafts have expired and need to be refreshed. WG-Chair ask for any objections for draft-ietf-dhc-dhcpv6-agentopt-delegate before going to WG last-call (will be confirmed on the list) - there was not objections from the participants. The draft-ietf-dhc-option-guidelines draft needs new reviewers. The draft-ietf-dhc-dhcpv6-opt-netboot draft is ready to go on the technical level, ready for last call if there are no objections. The draft-ietf-dhc-dhcpv4-bulk-leasequery draft got substantial comments, and is not ready for last call. Needs further discussion. Authentication Extensions for the Dynamic Host Configuration Protocol Alan DeKok First, Alan DeKok gave his presentation, and made the following points: - The requirement for a protocol of this type is for a mechanism that authenticates using EAP on a network where the administrative domain of the broadband provider and the administrative domain of service providers are not the same. - The proposal is to use DHCP as a transport mechanism for EAP - 802.1x isn't the right choice in some cases because it presumes that the RADIUS client is in the switch that is physically connected to the supplicant. This is impractical in networks that are owned by multiple entities. - Authentication must occur prior to DHCP address assignment, because we don't know what address to give to the client until we know who their service provider is. - People are transporting all kinds of weird things over 802.1x because it's the only path you have to the supplicant; this is similar. - Reason for not using PANA is that there aren't a lot of servers and clients deployed, not a lot of operational experience, and the code to implement this protocol is small. 2000 lines of code instead of 100,000. Firmware upgrade still required, but much lower risk. Comments: Iljitsch van Beijnum: Objections: - It's not 802.1x and not PANA. - Cisco has created this problem, and this makes it worse. - It may be difficult to get support from O.S. vendors to run this on home machines rather than on ISP-provided home gateway in cases where that is a requirement. John Brzozowski: WG has talked to Richard Pruss in Dublin (IETF 72) that this must also be able to run on the home computer even if it will be more likely will run on the home gateway Iljitsch: - There may be problems when the answer gotten via DHCPv4 conflicts with the answer gotten via DHCPv6, or when the DHCPv4 and DHCPv6 information is not synchronized. - On the clients this is un-deployable because it takes vendors like Apple, Microsoft long time to implement DHCP changes - This is a layering violation. - Would prefer that this not be published even as an informational RFC because people might treat it as a standard. Leave as a dead draft instead. Mark Townsley: would it help if the document disclosed all the problems Iljitsch has raised? Iljitsch: people don't read warnings, so that wouldn't make any difference. John: how should this be done instead? Iljitsch: the preferred approach is to first setup the low layer, then setup the high layer, like in PPP model, PANA might have some shortcomings but can be more easily implemented like in a Java applet in a browser Mark: this wasn't a workable option. Would Iljitsch prefer PPP? Iljitsch: although PPP model is right, PPP is not the right answer in this case. 802.1x was really the only correct way. PANA is also wrong, just differently wrong. Mark: The broadband forum industry has dug a hole by using PPP, but that is a fact now and cannot changed, the alternative that is shipping now is worse, DHCP already has been hijacked. Client runs DHCP, L2.5 DSLAM peeks inside packets and adds information about user connection, and sends it in the clear without authentication, and this is then used as a credential for getting service. So it is now a 3 box issue. This proposal removed the DSLAM and the system is back to DHCP client to server, used to authenticate before the IP Address is sent, which is the model of PPP. DHCP is already used for authentication, it will not go away. Alan: we haven't seen PANA take off yet, and thinks it's unlikely that it will. It's similar to DIAMETER, which was intended to replace RADIUS, but did not, and is now used in ways that are orthogonal to the way RADIUS is used, even following much effort to kill RADIUS. PANA would be nice if deployed, but the reality is that people have billions of dollars of equipment running protocols like RADIUS and DHCP. Mark Townsley: EAP over DHCP will bring back client server DHCP, predicting the future for this is crystal ball glazing, EAP sets the stage for 802.1x, which is architectural more clean, but 802.1x is not possible now WG Chair: tries cut off this discussion Iljitsch: this is an opportunity for IETF to say this is architecturally wrong. If we say it's wrong, it's not going to get built on. Mark Townsley: we need to communicate, if there are architectural concerns, document them in the RFC Ted Lemon: technical question: the startup handshake is with security, but no security thereafter, there is no continuing authentication process, should be mentioned in security considerations Alan: yes, there is no cryptographic tie between the authentication and the following DHCP traffic, but it can be implemented on base of RFC3118 (Authentication for DHCP Messages) David Allen: this protocol provides a convenient way to tie identifiers for access session, user ID, MAC address, and assigned IP address, which provides a lot of operational value for very little effort. Alan: today you get all of that except that you don't get a cryptographically authticated tie-in to the IP address. Lionel Morand: what state would DHCP have to maintain? Alan Dekok: the DHCP relay need to maintain a little more state because of this longer-lived EAP option. Some of the additional state is already in devices that use 802.1x, state of translation between EAP side and RADIUS side needs to be kept, basically it implements a radius client in the dhcp relay, relay does not need to keep state after initial dhcp offer Antoine: we need to make sure this is well-documented. Alan Dekok: the draft is very clear, no hidden gotchas Six or seven people raised their hands when John asked who had read the draft. WG Chairs wrap up discussion DHCP Option for Local Domain Name Discovery Y. Wang/Q. Wu One person raised their hand when John asked who had read the document. John Brzozowski: asks presenter to explain where this requirement is coming from Wu: its coming from the hotkey WG, hotkey WG is rechartering, potential work item for hotkey WG WG: would be good for hotkey, dhc would review, recommends to start this work in hotkey, then come back to dhc WG for review once it is worked on in hotkey Stuart Chesire: dhcp already has a domain name option, how is this local domain name different? Wu: local domain name is very specific to hotkey, it is the name of a EAP server, not the domain name of the service provider or installation. Suresh Krishnan: Please clarify in the document what the applicability is. Does if the DHCP relay agent need to start snooping on AAA to figure out the local domain name? Would like to see more clarity on this in the document, asked author to update the document to correct this. Ted Lemon: Is this was really a DHC working group item? It should probably be done in the hokey working group Ralph Droms: It would be okay to write two separate documents for this, one in the hokey working group and one in the dhc working group, with the hokey working group document describing the protocol as it is applied, and the dhc document describing just the DHCP option. IPv6 via IPv4 Service Provider Networks ("6rd") O. Troan presented http://www.ietf.org/proceedings/75/slides/dhc-4.pdf Ole gave a quick overview of how the option works and asked for review by the working group. Alain: would it make sense to put a version number in the option? Ted Lemon: we do not have an option code shortage, so maybe we should just fork a new option if the format changes. Jinmei Tatuya: by using a prefix length rather than a subnet mask for the IPv4 prefix, was it intended that non-contiguous subnet masks would not be supported? Ole: yes, this eliminates the possibility of noncontiguous masks, and that one could imagine other encodings. Mark: it's advantageous to be able to mask off top bits in cases where the IP address being represented is an RFC1918 address - there's no reason to waste four bits of address space representing the class A network number. Suresh: calling the mask index a prefix length is confusing, because normally a prefix length indicates how many of the most significant bits of the address are relevant, whereas here it's how many of the least significant bits. Mark Andrews: call it suffix-length instead. Jinmei Tatuya, Alain Durand and Mark Andrews agreed to review the document for the correctness of the DHCP information. The DHC WG doesn't need to review the technical content of the document aside from the parts that define the DHCP option. DHCPv4 Options for Home Information Discovery in Dual Stack MIPv6 B. Sarikaya presented http://www.ietf.org/proceedings/75/slides/dhc-1.pdf This document makes use of the DHCP protocol in a similar way to the equivalent document for IPv6. Ralph Droms: which working group is sponsoring this work? John Brzozowski: it is originating from mext, but that they would have to recharter in order to take it on as a working group item. Behcet: Jari Arkko had asked for this work to be expedited. Ted Lemon: the IPv6 version of this document needs a respin because of a problem that was discovered when it was in the RFC editor queue, and proposed that we call for more review after the respin is done. *** We will call for more review after we receive the respin. Alper Yegin is working on it. Problem Statement for DHCP Relay Agent Hui Deng http://www.ietf.org/proceedings/75/slides/dhc-2.pdf Hui Deng described the problem. Currently only a single DHCPv4 relay agent information option can be added to a DHCP packet as it is relayed between the DHCPv4 client and the DHCPv6 server. However, in current practice layer two relay agents are being deployed which add an option 82 to the DHCP client packet before sending it to a layer three relay agent. This agent cannot add any further information to the packet, because only one option 82 is allowed by RFC3118. This substantially increases the amount of configuration information required by the DHCPv6 server. He gave the example of a building with four floors, where each floor has a layer three relay agent, and many layer two relay agents. If both the layer two and layer three relay agent could add an option 82, an access control policy based on option 82 that controlled access on a per-floor basis would require only four configuration points. The same policy using just layer two relay agents required 31 configuration points in the example he gave. He mentioned that at the previous IETF he had presented an option that allowed the layer three relay agent to stuff additional information into the option 82 added by the layer two relay agent. He asked if this option was preferable, or if it would be better to add a second option. Ted Lemon: If the layer three relay agent modified the layer two relay agent's option 82 in transit, this would invalidate any signature added by the layer two relay agent. Hui Deng: Yes. Which option do you prefer? Ted: I would prefer that the layer three relay agent add a second option, rather than modifying the first option in transit, but that there had been an objection raised to this at the previous meeting that was not captured in the minutes. Suresh Krishnan: it would be possible to go to the audio stream to recover this information. Ted Lemon agreed to do so. Ted Lemon: adding sub-option to option 82 might break existing implementations, adding a new option is the way to go *** Ted Lemon will review the audio from San Francisco to clarify this point and then we will discuss this further on the working group mailing list. DHCPv6 Extension for PNAT H. Deng 5 minutes (there was no draft for this yet) http://www.ietf.org/proceedings/75/slides/dhc-3.pdf Hui Deng presented a description of a requirement for providing IPv4 addresses on an IPv6-only network for the use of IPv4-only software on IPv6-only nodes. Alain Durand: I am chair of the Softwires working group. The use case you describe was almost identical to a use case being worked on in softwires. You should bring this proposal to the softwires working group. Ralph Droms: clarification question: application in an IPv6 only network, need IPv4 provisioned to work? Deng: Almost. If you are thinking that way you are assuming we are solving scenario where IPv4 network goes through IPv6, but I think that scenario is mostly considering from the network layer, so we consider this problem more realisitcally, conventional IPv4 applications, so I think one scenario you haven't difference from softwire is we consider two hosts need to talk to each other. Alain: I believe there is a mobility application. Ralph: The nodes using this may only have an IPv6 stack, but may have IPv4 apps with a non-stack shim that lets them think they are running over IPv4, and this is a way to get them an IPv4 address to use. Tony Hain: this would be a dual-stack host, but only provisioned with an IPv6 address. Alain: This is exactly what Softwires is addressing. Deng: DHCPv6 needs to be able to provision IPv4 address in an IPv6 only network. Ralph: We should suspend disbelief on whether this belongs in Softwires or Behave. It's okay for us to hear about what we would need to know in order to review the document. Alain: there's the larger issue of how generally we should pass IPv4 information when the only IP network is an IPv6 network. For instance it might be useful to get the IPv4 address of a DNS server over DHCPv6. Possibility we could simply import all DHCPv4 options into DHCPv6. Ralph: the WG long since concluded that we should bring options over one at a time as needed, rather than doing a bulk import, because many options simply would not be relevant. He said that there's no prohibition against carrying V4 options in IPv6, and that the WG is happy to do that on a case-by-case basis. John Brzozowski: the Cablelabs client config option includes two suboptions whose values are IPv4 addresses, in the Cablelabs Vendor option space, and these are transmitted using DHCPv6. Ted Lemon: should we do this as an addr option, or as an specific DHCPv4 option, you can do this already with existing ipv6 dhcp server by specifying the address space correctly, but a specific IPv4 option would looking cleaner to the end-user Ralph: Ted, could you clarify how you would propose that clients differentiate between IPv4 and IPv6 addresses in this model. Suresh: just set the first 96 bits to zero. Tony Hain: use v4-mapped addresses. Ted Lemon: needs to flagged to be intended for this specific use, not for use on the wire Suresh: the behavior has to be defined. Alain Durand: if this is solved by a tunnel it would be able to use normal DHCPv4, and these are things discussed in other places Deng: the client should continue to use a normal IPv6 address. Alain: if you use a tunnel you can just do address configuration over the tunnel using DHCPv4. Tony: there's no problem with v4-mapped addresses being accidentally used because routers won't forward them. This is not tunneling. I do not believe this is harmful. *** Mark Townsley will read the draft. Jinmei Tatuya has read the draft. Further discussion on mailing list. DHCPv6 Relay Agent Assignment Notification Option Chairs 10 minutes Ted Lemon: The draft tries to solve the way to setup the routing information in dhcp replay agents. Currently it is done by snooping on the relay agent traffic. This option should enable to dhcp system to send the information for routing information to eliminate the guesswork. Allows the relay agent to add a route in its routing table based on DHCP information. A potential timing problem could affect customer routing. Complicated protocol was suggested to prevent this failure mode, this protocol was not received well, decision to go forward with the original proposal and document the potential failure mode which would be an operational problem. The option is solving the original requirement and needs to advance soon. WG Chairs encourage people to read the draft and supply feedback. Mark Andrews volunteered to review and to provide feedback. Ralph Droms will refresh/resubmit the draft. DHCP EAP Authentication Analysis Current status/discussion John Brzozowski: Update on analysis document, -01 version is being prepared. It's not ready for this meeting, but should be ready by the end of August. Ralph Droms (AD hat on): asks about the relationship between analysis draft and authentication document discussed, asks about the timeline for the authentication document John Brzozowski: analysis document will get update with all the concerns addressed Ralph Droms: is there a dependency between taking on the DHCP authentication document as a WG work item and the completion of the analysis, or can the document become a WG work item and during the iterations take the analysis into consideration John Brzozowski: in order for the authentication document to become a WG work item the analysis have to be completed. Asks if there is any disagreement to this next steps. Mark Townsley: observes that it seems like a workaround to work on a topic without it being a WG work item. Document should be published with all working group analysis. Want this as a WG work item. BBF is going to use this. Products are shipping. Mark wants this to be well-defined in the IETF. Jari Arkko (from Jabber): The analysis document is necessary. If it is going to say that there are remaining problems, we are not taking the dhcp authentication draft. I do not believe the train has left the station. The IETF needs to make a decision whether we do this or not. I oppose taking on the document. The analysis document has to be completed first. Ralph Droms: the analysis doc and DHCP Authentication doc have both been changing. It's taking a while to converge, and it may take a while to converge. Is there a way to come to faster convergence? State that the analysis doc relates to a previous version of the authentication doc, and use that as the basis for deciding whether to take this on as a WG item? John Brzozowski: The latest update to the DHCP Authentication document was an improvement. There is a better chance of accepting the authentication doc now vs. with a previous version. With version 06 of the DHCP authentication document and version 01 of the analysis document the WG will have a better set of information to make a decision on how to go forward with this work. Ralph Droms: before the Hiroshima meeting, all possible speed would be appreciated Ted Lemon: the DHCP authentication document has 26 pages, the new version is very clear and easy to follow, recommends to re-read the document John Brzozowski: summarizes next steps, by end of august publish -01 of the analysis, further discussion in Hiroshima 11:04 DHC WG closed