DHC WG meeting - IETF 72 0900-1130 2008-07-29 (Tue) Minutes ---------------------------------- Thanks to Ted Lemon for taking these minutes. RFC 5192, "DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents", was published The following drafts were announced as ready for working group last call: draft-ietf-dhc-subnet-alloc-07 (Informational) draft-ietf-dhc-vpn-option-09 draft-ietf-dhc-dhcpv6-reconfigure-rebind-04 (To be refreshed) draft-ietf-dhc-container-opt-01 (To be refreshed) draft-ietf-dhc-relay-id-suboption-00 draft-ietf-dhc-l2ra-01 (After WG discussion) Layer 2 Relay Agent Information M. Kamath draft-ietf-dhc-l2ra-01 We're going to do some wordsmithing on the mailing list prior to WG last call. No objections were raised to the idea of bringing it to WG last call, which will be initiated after wordsmithing is complete. NTP Server Option for DHCPv6 B. Lourdelet draft-ietf-ntp-dhcpv6-ntp-opt-00 This draft will go to last call in the ntp working group. The DHCP content, including the DHCP option structure, needs a last review from the dhc WG. Ted Lemon raised the issue that DHCP option packing may be problematic for this application. We are going to discuss the issue on the dhc WG mailing list and report back to the ntp WG. DHCP Reconfigure Extension Option V. Vinokour draft-vinokour-dhcp-reconfigure-option-00 Ted Lemon brought up the issue that this option, while focused on networks with a security model like TR-101, would actually apply to all networks, and that operators might mistakenly configure it in environments where it's not appropriate. He proposed using a nonce as in DHCPv6 to idiot-proof the protocol. One person brought up the question of whether or not this would work through a NAS. There was another comment regarding a nonce, that we would have to implement algorithm from RFC 3118 to use that method. The same speaker said that certain parts of the community like service providers would like to use the DHCPFORCERENEW message but have been blocked by the lack of RFC 3118 implementations. This draft represents that part of the community, saying that its members are aware that there are security issues, but want to use it anyway. Benoit Lourdelet said that in a number of networks that want to implement DHCPFORCERENEW with RFC 3118 in mind, they are just including option 18 and 19 and not checking it. You could get the same result by making sure that client and server are not paying attention to content of option 19. The ideas of DHCPFORCERENEW with a nonce and with no DHCP security will be discussed on the dhc WG mailing list. Use of Host Generating Interface ID in DHCPv6 F. Xia draft-xia-dhc-host-gen-id-00 Ralph Droms asked Jari Arkko whether this belongs in the csi working group. Jari responded that we need to take a step back and figure out what are the benefits that we might get out of it, what are the possible design alternatives. Let's try to draw that picture, why we would be doing this. Ralph asked what is "this"? This draft or more generally? Jari responded more generally, if you try to do something with DHCP and CGA addresses. We need to have a discussion in this WG and csi, and csi has a work item to develop this design space and understand what benefits might be. Once further along, we can talk about adopting WG items. We're not there yet. Ralph asked what was result from CSI? Jari responded that there were presentations on two drafts on that space at the csi WG meeting and the drafts also mentioned on the dhc WG mailing list. There wasn't that much time in the csi meeting to talk about that topic. One possibility is that a client could inform the DHCP server that it has this address, and use it to secure some transactions. Ralph asked that when there is more info on how that discussion is going to go forward would you let us know so we can participate? Jari responded that he can, although it would probably be better if people interested would also sign up for csi list and be involved directly rather than through management. There was useful discussion on dhc WG list, and Jari suggests we hold off a little bit about discussion on exactly how options are formatted and focus on high-level issues. Frank Xia said he thought the csi WG current work is defining requirements, not new solutions. Jari said that the csi WG charter is more about requirements and design space but not yet chartered to do a specific protocol. Of course the dhc WG is chartered to make improvements in DHCP security. When we know what we want to do we can decide which WG will take protocol. Not there yet. Ralph encouraged anyone with interest to sign up for csi WG. The dhc WG is going to keep this draft on hold until csi WG discussion progresses. Clarifying Handling of M&O Flags in IPv6 Ras H. Cha draft-cha-ipv6-ra-mo-00 Ted Lemon mentioned that he has an idea for a somewhat more organic solution to the problem. Jari said that the IPv6 and 6man WGs have been talking about this issue for ten years, and we have a draft-00 up for adoption to the WG. Maybe we should be considering the history a bit more. Ralph said we have to start somewhere. Ted mentioned that the dhc has actually been following this, and the draft isn't just coming out of nowhere. The dhc WG chairs will coordinate with the 6man and v6ops WG chairs, as well as the relevant ADs, to decide how to proceed. Secure DHCPv6 using CGA S. Jiang draft-jiang-dhc-Secure-DHCPv6-00 Ralph asks if the discussion in the csi WG is currently putting a hold on this draft. Jari said he's not sure he wants to say hold off, but stop discussing encoding for now. Securing DHCP is part of the dhc WG charter. Discussion in both the dhc WG and the csi WG about what we could do is useful, perhaps going to csi WG mailing list would be more focused place for this discussion. Jari suggested that the authors revise the document or perhaps merge this document with draft-xia-dhc-host-gen-id-00 or having the high-level one document discussion and discussing more in the csi WG. The dhc WG chairs will contact the csi WG chairs about this draft and draft-xia-dhc-host-gen-id-00 to devise a plan about how to proceed. Lightweight DHCPv6 Relay Agents D. Miles This document describes the equivalent of l2ra for DHCPv6. The scenario is similar to the scenario of an relay agent in DHCPv4 on a device that has no IP addresses. The DHCPv6 relay agent wants to insert agent options on non-routing devices, avoid configuration of IP parameters on these devices, have a minimal footprint, doesn't interact on wire with other functions, in particular ND. We don't want changes on client, server or other relays on the path. Ralph asked when David (speaker) says it doesn't support unicast, he doesn't understand why you'd even mention that in the sense that a traditional relay agent is also not involved in unicast. David responded that the document is only clarifying how to intercept; intercepting only on the multicast address. Ralph raised a second, minor semantic detail: This is really clarification for the use of RFC3315 in a device with no L3 address. It does no damage to RFC3315, and just clarifies what wouldn't be obvious to do. Mukund Kamath asked if the LDRA maintains state based on intercepted messages? David responded no, that's why interface ID is required, so that LDRA can validate and forward. The document isn't specific about whether the implementation should use interface ID to determine interface to send message out of. Mukund Kamath asked if there is no concept of maintaining IP address associated with the client. David said that is correct. The dhc WG will hold additional discussion of this draft on the dhc WG mailing list before considering it for adoption as a WG work item. Service Identifiers Option for DHCPv6 H. Deng draft-deng-dhc-service-identifiers-01 Ralph asked first, this document talks about services associated with a connection; however, the operation of DHCP is to provide an address or addresses to a client, not a connection per se, so what is the list of services being mapped to? Suppose the client reads the option, says oh there's the service I want, what information does it have that makes it change. What does it do based on information. Deng said for example, after DHCP has been used for address assignment, sometime go to default route. When terminal side get client identifier option, also another option, DHCP assigns routing options to support an IP connection. When the mobile terminal receives IP identifier information, it may decide not to try any application through this interface. Ralph asked if the device may have multiple interfaces, and service identifiers are for different interfaces? Woj Dec asked if the draft is proposing that services will be advertised on a client-by-client basis? How is this list constructed? Ralph responded that the list can be constructed that way according to policy on the server. David Miles asked why is the client not inserting this option in the solicit message to indicate which services it's interested in? I would think that might simplify server operation. It would seem out of character for a client not to include the option. Deng responded that he hadn't thought about the client soliciting services it is interested in. David said the client obviously needs to be aware of which services it is aware of and should ask for those services. Ralph noted that this option doesn't actually carry address of the services, just names of services that are available, and the idea is that they're cached on the client for subsequent use by applications. The client then has a rendezvous point. All this option is doing is identifying which service is available through which interface. The details of accessing the server, e.g. server address are out of scope for this option. Deng agreed. Ralph asked for confirmation that there's an assumption that a client knows how to access a service, and this option is designed just to help it figure out which interface to use for that service. I'm wondering if there are other alternative architectures. Deng responded that DNS might be used? John Schnizlein said that it seems like we have half of the pieces - you can configure all the services, but how does the client find the thing that has the services? Another WG member asked suppose we have a client that wants these services, and a client doesn't receive any. Does that mean service not accessible? Benoit Lourdelet commented that we are designing the Dynamic /Host/ Configuration protocol and he doesn't see a fit here. Niall wondered about the lifetime of the data that's cached from these options. If new services become available or service is taken down, there's a discrepancy. Deng: thank you. This document requires further revision before consideration as a dhc WG work item. Extensions to Layer 2 Relay Agent M. Kamath draft-ietf-dhc-l2ra-extensions-00 This draft has been accepted as a WG work item. The chairs are going to ask for volunteers to give feedback. Woj Dec asked what are the situations when L3 relay agents broadcast to L2 relay, which was followed by a big long discussion about how IP subnets work. David Miles asked how is the same problem seems true, how is the L3 relay agent going to know which interface to send L2 message down? (sic) DHCPv4 Leasequery by relay agent remote ID M. Kamath draft-kurapati-dhc-leasequery-by-remote-id-01 This document was reviewed for acceptance as a WG work item. The consensus at the meeting was to accept it as a WG work item; acceptance will be confirmed on the WG mailing list. DHCPv4 bulk lease query M. Kamath draft-dtv-dhc-dhcpv4-bulk-leasequery-00 Another document, draft-dtv-dhc-dhcpv4-bulk-leasequery-00, has been published addressing the same problem space. Ralph said that if there are no questions or discussion, we're going to ask that two groups get together and work out a common proposal. IPv6 RADIUS attributes for DHCP based networks B. Lourdelet draft-lourdelet-radext-ipv6-dhcp-00 (Woj - can you confirm you were the speaker in the following exchange?) Woj Dec asked if this option will send a prefix length or only an IP address? Benoit responded that if we go into prefix length, we may go into default router address, and he is concerned we are going to come to heated debate about where prefix lengths and default route should be specified. There wouldn't be a way for offered prefix lengths to be mapped to an existing DHCPv6 address. Woj said that the default route shouldn't be problem because when you set up PPP link-local address of other side is known, so it can be used by default. Benoit asked so you would add prefix length to construct RA out of it? Or to define a companion DHCPv6 options based on it? Woj said my idea would be to somehow separate the stateless autoconf/64 boundary from DHCPv6 because sometimes it is really helpful to have different. Benoit asked would we keep IPv6 prefix and interface id from RFC3162 and add prefix length to be fully independent with IPv6 address and prefix to add to RA? What would you do with prefix length? Woj said to use it with normal communication. Benoit asked so you would use it to generate RA? Woj responded no, it would be a fully DHCPv6 configured environment. Benoit asked if you could configure the interface of the BRAS with that information. Woj said yes. Ralph said that this is a discussion that goes outside of dhc WG. My intuition is that what this is going to pass is an address. If there's a prefix and prefix length, that would be passed separately. Benoit responded that this option is not going to fly very far if you do that. Ralph said, putting on his "know everything hat", that's the right way to do it. Prefix are supplied separately. Ric Pruss asked with separate mechanism, how do you get a per-subscriber prefix and prefix length to a targeted host? You would say the whole subnet gets this treatment with RA. responded that's for a different WG. He noted that there is a framed IPv6 prefix, only slightly related. What is one supposed to do with that? Benoit said the framed IPv6 prefix is used to create an RA on the PPP link. said that it seems like outside of DHCP we need to look at additional RADIUS options to support populating these RAs. Ralph remarked that he thought he understood framed IPv6 prefix. Benoit said he should probably just move on to the section describing the scenarios. Hannes Tschofenig said Benoit should talk to him because RADIUS option could contain DIAMETER attributes as well. The issue came up in the dime WG, that compatibility sections in RADIUS docs are almost always wrong. Benoit: said he will make sure that the DIAMETER compatibility section is reviewed by the appropriate WG. Next PXE (pre-boot execution environment) D. Thaler 10 minutes Dave's presentation was a heads up to the dhc WG that a revision of PXE is under development that includes IPv6 and there will be requirements for new DHCPv6 options. Authentication Extensions for the Dynamic Host Configuration Protocol R. Pruss draft-pruss-dhcp-auth-dsl-03 said he understands the idea is to authenticate the client by username and password. Have you thought about the home gateway being the client? This scenario requires device, not user, authentication. Ric agreed that it's very rare to see PPPoE running from end devices now. asked if the DHCP authentication could be extended to PC clients. Has Ric thought about including a message in a DHCPNAK if authentication fails, so the client knows it's not getting IP address because authentication failed. Ric responded that's actually a policy decision: you may want to give the client an IP address and put him on a remedial segment. So adding a message in the DHCPNAK is a good idea. Alper Yegin said this whole flow seems to be based on DHCP proxy model we are not familiar with in the dhc WG and the IETF. There's a lot happening here, some DHCP messages terminating on NAS, some on server. NAS (relay agent - RD) in between consumes some messages, letting some others pass through, adding bits in both directions. In order to assess this proposal, we need to understand underlying proxy model. Ralph said that while he didn't remember the details from the draft, one thing that would be helpful is as a clarification to avoid the use of the term "DHCP Proxy." DHCP Proxy is not a well-defined architectural element. The draft should indicate that the NAS is acting as a DHCP relay agent. With those clarifications we could take on discussions of fundamental DHCP architecture. So, suppose we continue to call the NAS a DHCP relay agent. What Ric's proposal does is extend the architecture for the relay agent to initiate a message exchange with the client that doesn't involve the server. Ric responded that the draft actually does use the word relay, and avoids use of "proxy". Subhir Das asked is the NAS on relay agent? Ralph responded that the relay agent is colocated with the NAS. Subhir said that currently draft says it's a server. Ric said that he added a relay portion to the draft. Subhir asked if the NAS could be either a relay agent or a server or both? Ric said not both. Ralph confirmed that either NAS acts as server or as a relay agent. Ric said this is why we started calling it proxy; the NAS has to see all the messages. Ralph said we have well-defined mechanisms for having the relay agent see all the messages. Subhir said when you do not have the the DHCP server in the NAS, it's the separate server located elsewhere sending the offer. So the NAS generates a DHCPDISCOVER sent to the server. Ric responded no, the NAS/relay holds the DHCPDISCOVER until after the EAP authentication. Ralph pointed out an important detail: because we don't have something defined as a proxy (but we don't need to in this case), all we're doing is modifying the behavior of a relay agent to not pass the DHCPDISCOVER message on to the server right away. There's nothing that precludes that in relay agents. Alper said that what the NAS or relay agent does is engage in its own DHCP interaction with the client by wedging in DHCPEAPREQUEST/RESPONSE. It breaks the DHCP end-to-end model, because, for example, the NAS is inserting options as messages pass towards DHCP client. The DHCPOFFER is sent from the DHCP server and the NAS inserts the EAPSUCCESS option into that message as it goes towards the DHCP client. Ralph acknowledged that the insertion of options by the relay agent is a problem. Ric said that issues is called out as a change to the DHCP architecture in the draft. Originally, the design sent a separate EAPSUCCESS, then the DHCPOFFER. Ric go suggestions that it could be optimized down to one message, but if this optimization breaks something else, we can revert back to previous version. David Miles asked as an implementor, why do we want to go to a new message type? Ric responded that he looked into putting this mechanism into the existing message types. This DHCP authentication is just clearly a set of different behaviors. The fundamental thing that's been going on in the mailing list is that the resend behavior is the other way around. For those changes, the new message type was recommended. Ralph said "you could do it, but it would be wrong". Ric added that specifically you can't put the IP address in the DHCPOFFER, which breaks a lot of things. Subhir said that Ric wants to send EAPSUCCESS directly to client. He asked if you do that, how do you bind the DHCP layer and the NAS layer? The DHCPOFFER now inserts EAPSUCCESS. Lionel pointed out that in the introduction of the draft that the main purpose is to authenticate the home gateway. Ric clarified that is true the DSL forum use cases. Lionel added that the introduction also describes that the home gateway could be a router or a bridge. So to deploy this you will need to deploy also the specific DHCPEAP for device behind home gateway. Ric said that the architecture in the draft addresses both cases. If a service provider wants to run DHCP authentication from a PC, Ric doesn't see a problem except that there is a requirement to install software on the subscribers host. That scenario didn't fly with PPPoE. Ric doesn't have much expectation that this will ever run on end users laptops. John Brzozowski said that you'd have to make a change on client's laptop. Ric added that a client could certainly be supplied for DHCP authentication, but he doesn't believe we'll see demand. Lionel said that the purpose of this draft is not just to be able to remove PPP, but the main purpose for now is to be able to do DHCP authentication at the home gateway; but if HGW is able to be either a bridge or a router you will need solution for both scenarios. What is described here is only when the HGW is a router. Text should be added to note that if you want to deploy this you will have to update devices connected to HGW. Ric responded no, if we have a bridge here it is transparent to the spec. Lionel said the bridge could be the HGW so if you have IP devices connected to the bridge you'd have to implement this on those devices. David asked if Lionel is saying the HGW can be a bridge, and therefore not have an IP address, but still use DHCP. Ric followed up that in the TR-146 architecture bridges are allowed. The current draft doesn't address the HGW-bridge scenario because the draft just talks about the client, not the home gateway. JohnB said that since it's a valid mode, this draft really should say something about what has to happen if bridging is enabled in TR-101. Ric said that would be pretty easy to do and he'll do that. Alper said that when he looks at this call flow from a distance, what he sees is that there's a regular DHCP interaction, and then at some point EAP-based authentication is wedged in, new DHCP messages are defined, new options are defined. The endpoints for this wedged-in flow is different than endpoints for regular DHCP. So he doesn't understand why that wedged-in part has to be DHCP. Ric thanked Alper for his opinion. Jari finished up by saying just to add to what Ralph said about the process, what Jari is expecting from this WG is not to look at whether this is applicable, but more about what impact of this would be for DHCP Architecture. What happens with MTUs in relays, endpoints of protocol. What happens with possible DHCP security mechanisms? What happens if the stuff you talked about or Peter talked about when you have a client that connects to this. What interoperability implications there might be. Jari would like WG to figure this out, have facts on the table, start high-level discussion in internet area once we have those facts.