Minutes for DHC WG at IETF-89 (London), March 3, 2014 0900-1130. DHC WG met on Monday March 3 at 0900. The session was attended by 60 people and lasted 2 hours and 32 minutes. The working group co-chairs, Tomek Mrugalski and Bernie Volz lead the session. The meeting materials are available at https://datatracker.ietf.org/meeting/89/materials.html. Bernie provided a brief working group status: since IETF-88, we had one RFC published (7083, Modification of default values of SOL_MAX_RT and INF_MAX_RT), one I-D is in review queue, 4 I-Ds sent to AD and/or IESG. Tomek discussed that the chairs were concerned that WGLCs receive not enough reviews, just handful of +1s and reviewed several options Ted: stateful issues draft is a bad one to make a policy on, you have to read it carefully, think carefully to understand what effect it has. Comparing - DNS-PD is straightforward. So my main concern with the way stateful issues LC went - it was around for a while , I was WG chair when it was adopted. The reason there was not enough response during the LC maybe because everyone who was interested, already responded. If you went back in the history you might find there was more support on it. So you might go back and prod the people who had discussed it, rather than multicast. Tomek: The LC was done for this specific version; the fact someone read it half a year ago is useful but not enough. Francois Dupont: Should have a review team Tomek: We will find who is willing to review it and we will the names down. The decision was to not start WGLC until there is enough review volunteers. There was a brief discussion on interest and next steps for draft-ietf-dhc-dns-pd-01: Sheng Jiang: think it is useful work. Can volunteer to review it Ted Lemon: I think the document is mature, though will need more work. Definitely needs work from someone else. Ole thought it is useful? Ole Troan: Was thinking the discussion with homenet chairs, if it makes sense. Ted: DHC did adopt it before we changed the charter, not convinced it is in the charter anymore. But definitely interesting in homenet, so if we find someone to do it it is off DHC plate Ole: We will find someone to do it. Next, Tomek gave a status update for the DHCPv6bis design team work. Good progress but slow process. Team published an XML2RFC version of 3315 as draft-dhcwg-dhc-rfc3315bis-00 which will server as baseline. Also team produced xml of 3363. Tomek re-iterated that the stateful issues draft constitutes quite a few items on the tracker and is important for this work. Tomek announced that the design team will meet on Wednesday, March 5 at 1400-1600 in the Praed Room. Tomek's second presentation was about DHCPv6 Failover. The failover-design draft reached AD review, but was essentially rejected. Authors and AD decided to split it into trimmed down failover-design (info) and failover-spec (std) drafts. Tomek then presented on draft-ietf-dhc-topo-conf-01 and asked whether the WG should pursue this work. 10 people expressed interest, no one suggested it should be dropped. The chairs asked for volunteers to review this work. The following agreed to review the existing version and send comments to the mailing list: Tomek, Simon Perreault, Andre Kostur (via jabber), Sheng Jiang, Cong Liu, Suresh Krishnan, and Bernie Volz. The plan is after a revision, it will be last called. Sheng Jiang presented draft-ietf-dhc-sedhcpv6-01 and believes it is ready for WGLC. Michael Richardson: Is that appropriate for the server that does not support leap of faith to return its size of the faith list zero. Sheng: Yes, we can just say "return nothing" but that means the client has to wait for a while. Martin Shuravski: I read the draft a couple of times, was not immediately clear what we were auth issues in 3315 that this addresses; would be useful to have a session with the issues from 3315, and a section referring to that saying "this proposal addresses this issue, etc." Some more clarification would be useful. Section 3 tells a lot about ability to dynamically exchange the keys so you do not have to manually configure every host, but it does not give enough though to security issues. Another: Does it give a thought if the client supports this mechanism and the server does not - and does this have any implications for the client? Sheng: Yes, server may still choose to process in the unsecured way. Ted Lemon: This is the same question as I was asking yesterday - about the applicability statement; is to state "this is where it is used" and later "this is how it is used" re. faith model - it might be good to have an error code - "I’m am not accepting the cert", "I am not willing to accept the certificate but you can try another", and "i am not willing to accept any of your certificates". Another thing you could do: If the server has a record of the client id and the key it could propose the key to use. Bernie: It would be a security issue. Ted: It’s not gonna send the key, it will send the name of the key. Probably it is not a big issue if sending the name. Francis dupont: Is there any IPR about this proposal? There is one for the first draft. Sheng: No there is no IPR as far as I know. Conclusion: The next version to be written and reviewed, then might be ready for LC. 6 volunteers signed up for review, so chairs will go ahead with WGLC soon. The reviewers were: Marcin Siodelski, Suresh Krishnan, Ted Lemon, Michael Richardson, Tomek Mrugalski, and Qi Sun. Bernie presented on DHCPv6 Load Balancing for Andre Kostur. Work has been resume after spending more than a year in limbo. There was WGLC over a year ago, but there were several comments, so updated rev was published on Monday. We have 4 volunteers for review: Sheng Jiang, Andrew Yourtchenko, Bernie Volz, Tomek Mrugalski. That's less than chairs would like to have, but since this draft has been around for a long time and is very similar to its v4-counterpart, it is enough and we'll go with another WGLC. Then, Bernie presented on the stateful issues draft. This draft fixes several important snags in stateful DHCPv6. Since those changes would affect everyone, chairs felt that the bar is set higher than for average draft. There was very few reviews and only a handful +1s during WGLC, so chairs decided to fail it. This appears to made an impact as 8 people promised to do the review. That should be more than enough to pass a new WGLC once chairs announce one. The volunteers were: Tim Winters, Marcin Siodelski, Cong Liu, Sheng Jiang, Suresh Krishnan, Jason Weil, John Brzozowski, and JINMEI, Tatuya, Timothy Winters: I posted about the client issue if NA got declined what we do with PD. This is important for the CPEs, so having some clarification with this document is helpful. JJB: Would like to see sooner. As the deployments continue, we will see dhcp-related issues related to other environments. Question about the document itself: is the goals documenting awareness and then rolling in the changes ? Bernie: The goal is to document what changes should occur in 3315. The doc says "replace x text with y text" and gives the rationale. But it only does it in 3315 context, which makes it hard to make it explicit about NA/PD because PD does not exist in 3315. Maybe it makes sense to say "here is how it should work" as opposed to having the text. JJB: Would be happy to help out. Sheng presented on Stateless reconfiguration (individual submission). There are some improvements since last meeting, but it is still not clear whether the WG is willing to work on it. The work will continue as individual for now. Bernie: you’re proposing multicast - it may be problematic… also the registration - maybe some registration that might happen to either use multicast or not. Maybe think about some of those ways. Ted Lemon: Couple of things. 1) Multicast is not as big as you making it up to be, we would not expect it too much. This is more of an exceptional situation. 2) Objection I heard here that was most plausible: "you need to add this to the clients". Given the existence of the IRT, this is very fine polish. Generally speaking, network administrator does not have to make emergency changes. They can keep it running for the IRT period, and that’s why we did IRT. I think there is maybe value in the particular case for the cable modem? Sheng: One, yes, emergency change may not be worth. But to correct the error configuration earlier. If you set up the initial parameters wrong. Ted: Rogue server model brings up the security model. Then the clients need to figure the trust model. And the amount of security is substantial. The client needs to preconfigured with the key or have done with a key, so this is a whole sequence of events that needs to happen in order to create this situation. Andrew: Clear the O flag, then reset it again. Maybe worth discussing this kind of behaviour. Lorenzo: The mechanism is not reliable because it relies on the hosts getting updated; also for the DNS server info is in the RA already. Sheng: I can’t answer your question, maybe we should take to the list. Lorenzo: If we do not remember the use cases maybe we should not be doing this. Michael: If we go with the multicast, then SAVI group needs to be informed. Bernie: It's an individual submission. Yusuke DOI: We have a use case - it’s about LLN (?) - it’s for the mesh network nodes. We have a network security mechanism based on (?PANA?) we can distribute pre shared keys to make the trust management. So, we think this draft fits our mesh network-based use case. Lorenzo: I forgot to ask - the security model is null - right ? in the stateful case you need to update the nonse, and in case some random server shows up then they can not reconfigure. So you can silently update the hosts with null config an they are gone. Sheng: My fault, last IETF we agreed to use PKI-based, and I forgot to update it. Lorenzo: We should say that the mechanism MUST be secured. Sheng: Maybe too strong, maybe there is a security underneath. Ted: It triggers a denial of service attack. Then, the Customer Edge Router ID option was presented by Michael Kloberdans. It's a proposal that overlaps Homenet, HIPNET and generic CPE deployment. The draft has some DHCP issues (tries to do auth by itself, rather than using standard auth option or reusing secure-dhcpv6 being developed). The AD will follow up to determine the best place for this work to proceed. There were several issues raised on the CER draft: - Why authentication as part of this option and how does this relate to standard DHCPv6 AUTH support? (Ted and Marcin raised this issue). - How to handle multiple edge routers (Michael & Ted)? - What is CER ID used for and what is the scope for this; all routers? (Mark Townsley) Daniel Migault presented on the Homenet Naming DHCP Options draft. It is intended for Homenet WG, so it was presented in DHC as info only. Several DHCP-specific comments were provided: - Use either address or FQDN (Ted). - Lorenzo raised some issues regarding zone transfers. - There was a discussion on TSIG / SIG(0) security. A new draft about dynamic Allocation of shared IPv4 address was presented by Qi Sun. This is DHC-specific part of the solution. It is expected to be reused by other solutions being developed in Softwires. The room was inclined to adopt that work. Will do adoption call on the mailing list soon. This document extends RFC 2131. DHCPv4 over DHCPv6 source address option is an extension to the DHCPv4-over-DHCPV6 solution that is sent to IESG. This is a very fresh proposal, there was not enough time for thorough discussion and no discussion on ML, so this topic will be discussed further. The last 4 minutes presentation was delivered by Tsinghua University, which implemented DHCPv4-over-DHCPv6 server and client. It is a nice data point for the draft that is awaiting IESG review now. These minutes were compiled by Bernie Volz from his own notes, those taken by Andrew Yourtchenko, and the INTAREA Wiki summary written by Tomek Mrugalski. Thanks much to both Andrew and Tomek for what they provided.