DHC Working group Thursday, November 20, 2008 Thanks to Ted Lemon for taking notes at the meeting, on which these minutes are based. [Agenda] Alper asked about the DHC Auth analysis. John will give status update. [DHC WG I-D status] draft-ietf-dhc-subnet-alloc --------------------------- Richard Johnson is confused because there were comments on subnet alloc draft which he hasn't addressed yet, he thinks he needs to do a revision before it goes to IESG. They were mostly nitpicks, he says. Ralph: let's take a note of that and deal with that offline. draft-ietf-dhc-vpn-option ------------------------- Kim Kinnear: I revised the draft based on the comments in the previous previous last call, there were only one set of minor comments from Bernie that said we didn't have to do anything about them, I figured I'd fold them in if there were any other comments from last call, they were mostly textual. I think it's ready for review now. Ralph: didn't get enough review last time. Bernie Volz agreed to review the draft. Ted agreed to do it; you'd better hassle him about it later. David Hankins also agreed to review the draft, in absentia. Kim: what we have now is ready for review, there are three textual comments, one minor possible misunderstanding, I'm sure there will be other similar comments, so not planning to review the draft again until this review is complete. draft-ietf-dhc-dhcpv6-reconfigure-rebind ---------------------------------------- Bernie, Richard and Ted Lemon agreed to review during a new WG last call. draft-ietf-dhc-relay-id-suboption --------------------------------- Bernie, Kim and Ted agreed to review during a new WG last call. draft-ietf-dhc-l2ra, draft-miles-dhc-dhcpv6-ldra ------------------------------------------------ These two drafts need to be correlated so that boilerplate describing problem space is the same or similar, even though mechanisms are different. Ralph is asking everyone to read the docs together so that we can discuss on mailing list. Ralph will kick off discussion. DHCP Auth analysis ------------------ John reports that we're slightly behind schedule. The review team has completed its preliminary review/analysis, and is currently planning on giving a draft version of that analysis to Jari Arkko (dhc WG Internet AD) in January. At that point the review team is going to determine the next step based on whether we get a revised version of the draft. We want to make sure the analysis we do is accurate with respect to the new revision. [Reviews of dhc WG I-Ds] DHCPv6 Remote Boot Options --------------------------------------------------------------------------- Vincent Zimmer from Intel. He's working on EFI in the UEFI forum. PXE is evolving within UEFI, and the latest UEFI spec has IPv6. Problem: what will the boot paradigm scenarios look like on IPv6? We can define APIs but on the wire we felt it was best to come to the IETF and work those. Question: Who will manage the "processor architecture type"? Make it an expert-reviewed IANA managed list. DHCPv6 option for network boot --------------------------------------------------------------------- (no presentation) Discussion of previous two drafts: Question for the group: how should the authors of the two drafts work together? Bernie: Is the next-server option was a good idea given that the URI option already contains that info? Ted: Is the PXE stuff was driving idiosyncracies in the protocol. Ralph wants them to try to reconcile the two drafts offline. DHCPv4 Vendor-specific Message , DHCP Vendor-specific Message ------------------------------------------------------------------------ Both drafts were dsicussed together. Kim: Leasequery had a message ID, but it got stepped on. If we're going to let people try things and see if they work, and standardize real work, could be really valuable. The consensus at the meeting was to accept these drafts as WG work items; acceptance will be confirmed on the WG mailing list. Bulk DHCPv4 Lease Query --------------------------------------------------------------------- The consensus at the meeting was to accept this draft as a WG work item; acceptance will be confirmed on the WG mailing list. DHCP options for Access Point Name and attach type indication ------------------------------------------------------------- Jari: Where does this work belong? Authors and WG chairs will work together to find a home for the work. Bernie: better in mip6? John: have you presented elsewhere? There may be a parent wg that is aligned with your tech, and you would consult us for details around the actual protocol, so we're going to talk to Jari and see if there's a WG for which this would be appropriate. Raj: Ralph has looked at NetLMM Ralph: I appreciate the compliment, but our model of operation is that options like this that are not fundamental to operation of protocol have to come from parent wg that has requirement for the option; our job is to provide input to make sure the option is compatible with DHCP architecture and options guidelines. Bernie: are these options always expected to appear together? Would a mobile node ever send just APN? [yes] In that case is there a presumed attachment type? Raj: By default, the access network will assume it is an initial network entry unless it has other information from another access router. Bernie: might want to simplify other option, maybe all you need to say is here's the APN as one option, and this is a handoff as opposed to non-handoff. John: Should this option carry a name or an IP address? Alper: you referred to APN which is a 3GPP term, but this draft also applies to WiMAX, terminal can select attaching to visited CSM vs. home CSM. So its applicability goes beyond what the terminology suggests. It also applies to non-mobile IP scenarios: in WiMax we support mobile IP and non-mobile-IP attachment, which still needs network selection. ??: why not use old solution Raj: when you already have l2 mechanism you can use that, but there are other technologies, e.g. Wifi which doesn't have capability at Mac layer to send APN info. In such scenarios you would indicate home agent, you have to do at higher layer, in this case DHCP. ??: more applicable to wifi? Raj: applicable to generic networks which do not have this capability at l2. [additional discussion elided] Ralph: this is why this option needs to be presented elsewhere. Service Identfiers Option for DHCPv6 ---------------------------------------------------------------------------- Observation by several sources: this seems to be out of scope for the WG. Need to talk after the WG meeting to discover exactly what the motivation is, what the customer WG might be, whether the work belongs here. Scenario and Solution: Simple IP Multi-homing of the Host --------------------------------------------------------- Ralph: the IPv6 side of this should go to 6man, probably. Ted: Regarding IPv4, it's not clear whether the dhc WG is qualified to comment on this on a technical level in terms of routing. Ralph: will talk to ADs. Hiu: Jari allowed to present here to get feedback. Bernie: seems to me a respin of RFC3442, which is the classless static routing option, except this adds ToS. Jari, John, Ralph, Hui will discuss where the work belongs Guidelines for Creating New DHCP Options ------------------------------------------------------------------------------ Ted: provided comments to list (wordsmithing) Consensus at the meeting is that the draft is ready for WG last call. DHCPINFORM Message Clarifications ------------------------------------------------------------------------ Kim: I think clarifying this is a good idea. I'm sure I don't agree exactly with what's written here. E.g., I don't recall any place where we've looked at the source address of the DHCP packet, and I wouldn't start now. Or at least I'd think really hard before we start. Questions about where we send it back to are a good idea, I don't think the current list is correct. It's going to take some work, I think it's worth it. Hui: There is work on home network configuration using DHCPINFORM, I support this work item, should I wait for it to finish? Ralph: The nature of the draft that you're writing, does it overlap the clarifications that are in this draft? I don't understand where there might be a conflict. Hui: don't see conflict, just using DHCPINFORM. Ralph: you're using it in draft in other WG. Hiu: yes, to get configuration information for home network. Ralph: that would be a good thing for us to look at here. The consensus at the meeting was to accept this draft as a WG work item; acceptance will be confirmed on the WG mailing list. Dynamic Host Configuration Protocol Option for Softwires -------------------------------------------------------- Ted: shutting off DHCPv4 is a potential DoS attack. Bernie: otherwise the option looks good. Ted: really think you should just take out the thing about stopping the DHCPv4 state machine. Raj: is there a threat model that exists somewhere? Explains the why you would potentially have in-band security for DHCP? Alper: there's a threat analysis draft that talked about that, but it expired years ago. Ralph: history, we decided to do threat analysis, got a reasonable way in, but didn't finish and didn't publish. It's a draft of a threat analysis, but if I remember final state, it was useful. Paul Selkirk (ISC): presence of softwire option implies no IPv4? Ted: if you have a network where you don't want IPv4, just don't set up DHCPv4 server. This draft will be considered as a softwire WG work item. Bootstrapping RFC 3118 ---------------------------------- Stefan: is operating wifi roaming, and is very interested in seeing this draft move forward. It is possible to rely on layer 1/2 security, but for universities we want people to communicate, so these measures are not always appropriate. Restina Foundation, etee (sic) roaming consortium. Stig Venaas: I agree with what Stefan said, but I'm involved in same consortium. Could be quite good as way to get 3118 deployed. In addition to security in L2, could give a touch of binding between identity and IP address which some people are interested in. Joe Salowey: we think approaches are similar, could merge. Alper: going back to Raj's question, today there are various DHCP deployments where L1 and L2 endpoints don't match DHCP endpoints, in WiMax we are looking at running DHCP server not in local network but some other operator's network. When there's such a mismatch, embedding DHCP security becomes more essential. L1 and L2 endpoints are not in a position to ensure security for signaling that goes beyond their own domain. Raj: agree that there are potential scenarios like that. But there should be transitive trust. Alper: not as good. Ted: would love to see this go forward. Bernie: V6 as well? Alper: yes. we didn't mean to make a distinction between v4 and v6, but RFC3118 is v4-only. Bernie: when you respin, make it clear that these documents apply to both RFC 3118 and RFC 3315. Alper: will do. Ralph: Joe: you've already discussed merge with Alper, is that a way forward? Joe: I think that would be excellent. Alper: agree. Ralph: okay, we formally request that you do so, once we see draft we'll review for taking on as WG work item, hope that we can review that at next IETF. Ralph: we're done. Wrap-up ------- Alper: what happened to DHCP EAP over DHCP? John: we the analysis team where we stand is we're slightly behind on delivering the analysis to ADs and WG, our plan right now is based on the feedback of the conversation with WG meeting in Dublin, we'll prepare draft based on preliminary analysis. During DUblin gave feedback to author, expectation was that there would be a revision, I haven't seen one. If one comes out, then we'll have to respin the analysis to make sure that initial feedback is valid still. Alper: is there going to be a draft? What's the format? I presume draft, since there's no January meeting. John: team has targeted based on January, assumption is it would be in draft format and ultimately shared with WG. Alper: good.