[07:02:53] --- LOGGING STARTED
[07:03:12] --- LOGGING STARTED
[07:04:59] --- LOGGING STARTED
[07:07:58] --- LOGGING STARTED
[07:09:19] --- LOGGING STARTED
[07:11:29] --- LOGGING STARTED
[08:42:57] --- rajid has joined
[08:43:25] --- mellon has joined
[08:57:58] <mellon> We're about to start. I'm scribing.
[08:58:44] <mellon> Good morning. We've got a couple of pieces of administrative details to take care of. We have blue sheets.
[08:59:12] <mellon> For those of you who are on the wg mailing list, watching agendas, I just sent out a revised agenda 45 seconds ago as a courtesy for those who take notes based on agenda.
[09:00:11] <mellon> There are a couple of outstanding last calls.
[09:00:18] <mellon> One is for the failover protocol draft.
[09:00:40] <mellon> We've received enough comment that I can fill out the appropriate form to say that the wg has positive reporting consensus to move it forward.
[09:00:58] <mellon> I still need to do a final read of the draft before last call terminates, get comments to list during last call so we can talk about them.
[09:01:12] <mellon> Also PXE options draft is in last call. Not many comments. We still need more.
[09:01:32] <mellon> That's the draft that documents use of several option codes by PXE boot mechanism. Please read, review, comment to mailing list so we can move it forward as well.
[09:01:42] <mellon> Agenda item I just added. There are several new i-ds to be considered by wg.
[09:02:07] <mellon> (Richard Johnson) Isn't subscriber-id in last call?
[09:02:28] <mellon> Some of the changes described inplenary session are already in effect on an experimental basis in our wg because Margaret Wasserman is our AD.
[09:02:54] <mellon> Rather than simply sending draft into iesg I have a form to fill out that documents how the review went. So I am packaging all that stuff up to go along with the document.
[09:03:29] <mellon> We had a number of drafts published to wg mailing list but not officially published right after expiration time for publication time for this IETF.
[09:03:42] <mellon> Six of them. First draft described dhcp-v6 options for ipv6 transition.
[09:03:56] <mellon> Pass some ipv6 trans params to DHCP client. 6to4 and tunneling information.
[09:04:05] <mellon> Second has had some discussion on mailing list - DHCP discovery extensions.
[09:04:15] <mellon> New server-initiated communications between server and client.
[09:04:29] <mellon> Interface information option - more info about specific interface client is talking about.
[09:04:38] <mellon> I don't expect to discuss these this morning, just alert you that they exist.
[09:04:52] <mellon> Option for proxy server configuration - passes info about protocol proxies to dhc client.
[09:05:05] <mellon> DHCPv6 support for remote boot - boot options for v4 and v6.
[09:05:22] <mellon> So I'm going to tell you what the process is going to be if there are objections.
[09:05:36] <mellon> All are individual submissions. Wait until published at IETF.org after timeout period.
[09:05:45] <mellon> (Mark Stapp) haven't been accepted yet?
[09:05:55] <mellon> Yes, I have to go back to authors, republish as individual drafts.
[09:06:03] <mellon> (Mark) Someone should tell Margaret about process problem.
[09:06:09] <mellon> No problem, these haven't been published yet.
[09:06:31] <mellon> So, these will be published as individual submissions, wg will discuss, decide whether to take on as wg items.
[09:06:55] <mellon> So we conduct a wg first-call of 2-4 weeks as necessary to get sense of wg, get consensus on mailing list for whether or not to accept as wg items, roughly jan. 1.
[09:07:05] <mellon> Hearing no objections, that's what we will do.
[09:07:25] <mellon> Load-specific client identifiers for dhcpv4.
[09:07:55] <mellon> Oops, node-specific. Ted's draft. What he's done is point out in the draft that def of client ids in rfc2131 is inadequate.
[09:08:13] <mellon> Reasons in draft. RFC3315 defines a DHCP unique identifier which does much better job of identifying client and the rfc2131 version.
[09:08:29] <mellon> This draft suggests that we extend the definition of client identifier in rfc2131 to include DUID formed in the same way as in RFC3315.
[09:08:45] <mellon> Uses client id code 255 IIRC. Another way to identify clients.
[09:09:27] <mellon> I don't claim to understand ramifications. Some impact on rfc2131. We need to understand, if we are going to accept this for standards track, what those impacts are on rfc2131.
[09:10:42] <rajid> Ted's talking... Need a way to transition v4 to v6
[09:10:59] <rajid> must use a client-id
[09:11:35] <rajid> must use v6 style DUID
[09:12:25] <rajid> transition will probably be in both directions v4->v6 v6->v4 back and forth
[09:16:23] <mellon> What about section 4.3? Is this ready for wglc, modulo changes suggested by Kim?
[09:16:51] <mellon> (John Schnitzlein) I was just looking at the agenda, I didn't see Barr's effort in the agenda.
[09:17:19] --- jm has joined
[09:18:40] <rajid> question: is this a change in interoperability?
[09:19:01] <rajid> ted: no. definitely not. server must still support old style.
[09:19:19] <mellon> Rapid reply option for DHCPv4. Daniel Soohong Park speaking.
[09:19:41] <mellon> Oops, Soohong Daniel Park. :'}
[09:20:00] <mellon> Today I am talking about new options for DHCPv4, rapid reply option.
[09:20:07] <mellon> Same as the common option in DHCPv6.
[09:20:16] <mellon> The modivation is to get IP address/configuration info faster.
[09:20:44] <mellon> This draft reduces latency in performing address assignment by using a two-message exchange - DHCPDISCOVER -> DHCPACK.
[09:20:57] <mellon> This is just like Rapid Commit option in DHCPv6.
[09:21:34] <mellon> For reference, the rapid commit option for v6 is addressed.
[09:22:05] <mellon> Applicability - supported or mobility and this mobile device can obtain IP address faster just to use two-message exchange.
[09:22:40] <mellon> Someone suggested use flag, but you've already unpacked packet, so there's no speed enhancement in using flag.
[09:23:08] <mellon> When you have a large number of decice attempting to discover simultaneously, this option is useful.
[09:23:48] <mellon> Co-author, Bernie says in simple case one server exists. The default behavior of the server must be not to use rapid-reply - must be configured by administrator.
[09:24:12] <mellon> Regarding lease time, should servers have a knob to configure an initial lease time for rapid reply?
[09:24:20] <mellon> Which name - Rapid Reply or Rapid Commit.
[09:24:30] <mellon> Please make comments!
[09:24:53] <mellon> (Ted and Mark) Use "Rapid Commit."
[09:25:17] <mellon> (???) How would you deal with multiple DHCP servers?
[09:25:29] <mellon> (Mark) Doesn't work as well.
[09:25:39] <mellon> ??? was Paul from Cisco.
[09:26:14] <mellon> (Me) Might be worth mentioning that this can work nicely with failover.
[09:26:24] <mellon> Any objection to taking this on? Seeing none, we will do so.
[09:26:40] <mellon> (That was Ralph)
[09:27:00] <mellon> Next is vendor-identifying vendor options for dhcpv4.
[09:27:17] <mellon> This is a draft that described two new options for dhcpv4, modeled on options in dhcpv6 where vendor class and vendor options have self-identifying field.
[09:27:37] <mellon> Having just a single vendor-class id and assuming they go along with that vcid is limiting. You may want vendor-specific options from two different places.
[09:28:04] <mellon> E.g., DOCSIS and Cisco VSOs in same device. This allows for different VSOs back to same client.
[09:28:11] <mellon> Modeled very closely on same options in DHCPv6.
[09:28:19] <mellon> Any discussion? Questions? If not, any objection to wglc?
[09:29:09] <mellon> (Me) This is in conflict with the encoding long options rfc.
[09:29:15] <mellon> (Ralph) we'll have to consider that.
[09:30:26] <mellon> We should take this to the mailing list. It's possible to differentiate because vcid will be different.
[09:30:37] <mellon> Client identifier option in server replies.
[09:31:30] <mellon> Client identifier option in server replies.
[09:31:45] <mellon> (Me) I think it's necessary
[09:32:06] <mellon> (Mark Stapp) Pretty good discussion on ML about motivation. This is another case of the something that is an update to 2131 but that needs to be solved sooner.
[09:32:53] <mellon> If I have the state of this draft right, it is up for acceptance as wg item.
[09:32:58] <mellon> No objections, okay.
[09:33:13] <mellon> Extending the DHCP option codes. We've had this draft out. We've talked about this lo these many years, many times.
[09:33:30] <mellon> Bernie has written up a draft that summarizes the four alternatives we've discussed from time to time about how to extend option codes.
[09:33:48] <mellon> There are currently 20 option codes unassigned. A handful are reserved because we have options in the pipe that will get assigned.
[09:33:59] <mellon> I gave the statistics at a recent wg meeting about how rapidly these have been used.
[09:34:08] <mellon> Unused option codes has been accepted as informational RFC, BTW.
[09:34:13] --- bert has joined
[09:34:19] <mellon> (Kim) Does that mean that #3 in the draft has happened?
[09:34:34] <mellon> At the current consumption rate, 15 is a couple of years worth.
[09:34:48] <mellon> Proposals - encapsulate with option code 126 or 127.
[09:35:00] <mellon> Second, reclaim some option codes that are currently defined as site-specific.
[09:35:20] <mellon> Third, reclaim the codes that are assigned but not widely if at all used. E.g., impress-server.
[09:35:45] <mellon> Finally, proposal to define new magic cookie, use 16-bit options.
[09:35:58] <mellon> We have old drafts around for the first and fourth option.
[09:36:16] <mellon> (Me) We need a draft to document it, right?
[09:36:30] <mellon> (Ralph) Yes. Bernie's current draft either summarizes or explains all of these in detail.
[09:36:43] <mellon> One way to move forward would be to strike three, move what's left forward.
[09:37:03] <mellon> Would like to have discussion here about which one to do.
[09:37:51] <mellon> (Kim Kinnear) If we call these four options 1, 2, 3, 4, personally I believe we should move forward on #2 and #3.
[09:38:07] <mellon> If we can do them in one draft, cool. If not, we should go forward with #2 immediately.
[09:38:22] <mellon> (Ralph) Kim, you raise a good point, 2 and 3 aren't mutually exclusive.
[09:40:18] <mellon> (Greg ??) Option 3, a number of option codes we could reclaim, but we've only got a few options remaining.
[09:40:37] <mellon> Can we do reclamation before we run out of current available set? What's the time pressure?
[09:41:00] <mellon> (Ralph) I believe we have at least three, probably five years worth of option codes today.
[09:41:21] <mellon> (Kim) These queries got at least two, possibly three, I just see things coming along that are starting to chew into it. I'd be surprised if it was five.
[09:42:15] <mellon> (Ralph) Okay, three. Practically speaking, how long will 2 & 3 take to get through process. My intuition is two would take less time than three. If we go to three, we could spend a lot of time arguing about some of the options. There will be some that are obvious, some not so obvious. My IETF black hole alert is going off. Two would take less time, I think.
[09:42:33] <mellon> (Kim) Possible reason not to link these - do them separately.
[09:42:36] <mellon> (Ralph) Right.
[09:42:53] <mellon> (???) If you go with two, get it done, then you can do (3).
[09:43:30] <mellon> (Ralph) A potential positive aspect of using 2 is to attempt the same sort of documentation we're doing with PXE options for those options that I understand have been appropriated out of site-specific option space by various vendors.
[09:43:38] <mellon> I consider that a feature, not a bug.
[09:44:00] <mellon> It would be nice to have at least i-d's for these options.
[09:44:24] <mellon> (John Schnitzlein) The sense I'm getting is that no-one is advocating #1. #4 has historical baggage, so it's deprecated.
[09:44:30] <mellon> (Ralph) It's a failed experiment.
[09:44:53] <mellon> (John) Summary is that 2 is insurance in case it's not possible to do 3 quickly.
[09:45:05] <mellon> (Me) I think it's just that there are more options to be had in 2.
[09:45:21] <mellon> (Ralph) 2 is also simpler, although we do have to deal with undocumented options.
[09:45:51] <mellon> Anyone in favor of 1 or 4, hum. No hums.
[09:46:04] <mellon> In favor of striking 1 and 4? Lots of hums.
[09:46:16] <mellon> Okay, 1 and 4 are gone.
[09:46:35] <mellon> I don't feel we have consensus to pick 2 or 3. We should discuss on mailing list.
[09:46:44] <mellon> (Kim) Recommendation that we just pursue 2 and 3 right away.
[09:47:15] <mellon> Hum in favor of 2 and 3 independently. (Lots of hums) Objections (no hums) Done. Thank you.
[09:47:30] <mellon> Implementation Issues with RFC2131.
[09:47:58] <mellon> Unclear, potentially conflicting wording in 2131 and 2132 that make it difficult to build an implementation.
[09:48:27] <mellon> You probably can't build an interoperable implementation from 2131, it is claimed.
[09:48:37] <mellon> Has anybody read the doc? (several people, not many)
[09:48:50] --- bert has left: Disconnected
[09:49:57] <mellon> (Kim) I have a number of specific comments. My overall comment is if we are planning to actually revise 2131 ased on results of this? There are a lot of issues listed with decisions to be made. They're at the end of the document. As I read the document, if it's going to stand alone, it needs to be both decisive and clear. It needs a little more explanation. There's probably five or six major issues that need discussion.
[09:50:26] <mellon> (Ralph) If I've got this right, we have a document now that identifies some issues. Some issues need to have decisions made about them. We need to make those decisions, document the results, decide what to do with them.
[09:51:07] <mellon> Suggest we take this document, publish it as an informational document as a way of capturing for the record the set of issues as we've identified them. Then we start a wg discussion on each of the issues. Kim says four or five. Maybe we use one of these issue trackers.
[09:51:35] <mellon> We capture the results of those discussions. Again, this is a straw person. We publish those results as an i-d. Then we fold those into a revision of rfc2131.
[09:52:17] <mellon> (Mark Stapp) I think that as people read this, and folks should, perhaps people will try to indicate in their email whether they're offering a set of editorial clarifications or whether they would like to submit a significant issue.
[09:52:21] <mellon> There's a lot of stuff in this draft.
[09:52:47] <mellon> A lot of one-liners that are just editorial. There are also things that propose real changes. We should try to tease those out.
[09:53:51] <mellon> Perhaps we should impose a discipline that says we're avoiding discussions of solutions - just entertaining editorial comments and new issues. Then we will discuss how to solve the issues.
[09:54:10] <mellon> (that was ralph, now Mark) I didn't say that. I think telling people not to respond yet, I don't see the benefit.
[09:54:26] <mellon> Useful to indicate that people are suggesting editorial, new issue, opinion about issue somehow.
[09:55:32] <mellon> (Ted) How about a workshop?
[09:55:37] <mellon> (Kim) How about conference calls?
[09:56:01] <mellon> (Kim) Conference calls worked pretty well. I could imagine two or three that would drive this to conclusion pretty quickly.
[09:56:34] <mellon> (Ralph) I will take both of those under advisement. Conference calls easier - we'll see how those go, if it appears we should do a workshop, we'll do that.
[09:57:03] <mellon> Next step, be thinking in the back of your head about folding the things that come out of this into a revision of RFC2131 and RFC2131, using that as a basis for taking DHCP to full standard.
[09:57:18] <mellon> Mimi Zohar, threat analysis.
[09:59:23] <mellon> (Mimi) So basically the reason for doing this work, and it needs to be stressed because we haven't gotten much response, is that this is a charter item and we need to move forward.
[10:00:04] <mellon> Most of the threats we identified were identified in original drafts. There are a couple of threats that Bernard Aboba and Mark identified that weren't address in the drafts. We'll go through threats, weaknesses of RFC3118, and what's needed.
[10:00:23] <mellon> We're looking for other options. We know of some.
[10:00:54] <mellon> Every protocol now needs a security threat analysis. This is why it's being addressed now. The basis, the fun one to read was the one from DNS. If you haven't had a chance to read it, you'll have some fun reading it.
[10:01:07] <mellon> We used that as an example of what threat analysis should be like. These are the issues from the charter.
[10:02:03] <mellon> We identified four types of threats: DoS. E.g., spoofing valid DHCP messages. For example, decline and release. Rogue server could use DHCPFORCERENEW. We didn't address FORCERENEW because we felt FORCERENEW addressed its own security issues.
[10:02:31] <mellon> Client configuration. This is how I got involved. You have examples of being on cable. You have no way of knowing - anybody can respond to you, give you different options, can do a man in the middle attack.
[10:02:46] <mellon> This is how, if you're starting to look at web services, trying to understand, figure out how you have security in such an environment.
[10:02:56] <mellon> Also theft of service. Can't really be dealt with by DHCP.
[10:03:08] <mellon> Packet insertion/deletion as basis of DoS, prevention of lease renewal.
[10:03:16] <mellon> If anyone saw anything else we were missing, please send email to wg.
[10:03:23] <mellon> I think we have it all.
[10:03:51] <mellon> Weakness of RFC3118. Pretty clear it was just a way of getting a foot in the door. Defines simple methods. Token method - sent in clear text. Shared secret.
[10:04:13] <mellon> Shared secret shouldn't be common between all clients. So how do you distribute it? Depends on out of band distribution.
[10:04:34] <mellon> One issue is how do you distribute keying information. Other option, if this is based on keys, only DHCP server and client know key, there's no real way of forwarding this so you have inter-domain roaming.
[10:04:51] <mellon> Other issue came out - we now have two methods, there's no negotiation of which method to use.
[10:05:24] <mellon> The impetus for this work is that when we first started, we were dealing with either physically secure networks, or people just didn't care.
[10:05:36] <mellon> Now you are working in environments where there is no concept of trust in broadband or hotspots.
[10:05:51] <mellon> Anyone coming in, even with a laptop or mobile devices, can just bring up a rogue DHCP server.
[10:06:16] <mellon> One of the issues that was questioned from the document was whether or not the capabilities we identified were requirements for either client or server, or protocol itself.
[10:06:33] <mellon> You can't expect that a thin client can support all these different options. Protocol should be able to support.
[10:06:59] <mellon> Another issue is key distribution. Also, some information sent in DHCP may need to be confidential.
[10:07:21] <mellon> Document describes method for preserving some confidentiality. Limited - IP address, etc, are not confidential because required for routing.
[10:07:42] <mellon> So you can establish basic IP connectivity, then using OOB methods, DHCPINFORM, you can get data confidentiality.
[10:08:05] <mellon> So basic solutions have been suggested. One is based on certs. One is based on DNS. One is based on PANA/EAP.
[10:08:35] <mellon> All three options have some advantages and disadvantages. All require infrastructure. We need a discussion as to which of these is best, or if there should be multiple options.
[10:10:17] --- jm has left
[10:10:31] <rajid> (ted) additional option is kerberos
[10:11:31] <rajid> (ted) currently have 4 packet exchange - dns key rr may require more - need tto veriffy server after assigning ip addr
[10:11:49] <mellon> (Mark) Second some of what Ted said - trying to leverage existing DHCP messages is potentially making it more difficult to find a solution.
[10:11:59] <mellon> Definitely worth considering adding some messages for authentication.
[10:12:35] <mellon> I think there's some milage to be gained in noting that we are all soaking in ???, there is already trust established. It's possible for DHCP server and relay infrastructure to develop trust.
[10:13:06] <mellon> If we can leverage existing relay infrastructure, servers, ought to be a way to get the last critical bit of information that has made it down from radius server to access point, to get that to the DHCP server, allow server and client to complete negotiation sequence.
[10:13:19] <mellon> (Ralph) Where we are in the process, I think I just heard a volunteer to write a draft.
[10:13:33] <mellon> (Mark) I think there's a draft there, there are some of us who are looking at trying to put that together.
[10:14:16] <mellon> (Ralph) Where we are right now is trying to come to last refinement of threat analysis doc. Collecting proposals. EAP based proposal I just heard you volunteer to write it up, please do. Ted, the more messages thing that you volunteered to write up, go for it.
[10:14:45] <mellon> (Mark) Many things proposed have significant baggage, require deployment of infrastructure that doesn't exist. In many environments, some kind of access control is already taking place.
[10:14:48] <mellon> (Ralph) Send text.
[10:15:19] <mellon> (Rob Austein) Mostly thinking of DNS solution. Probably generally applicable. Fundamental problem. Doing authentication this low on the stack, you don't have many options. Have to start with something.
[10:15:44] <mellon> One is have some piece of keying material that lets you idenfity party with whom you're doing authentication.
[10:16:01] <mellon> I don't see any way to get past provisional acceptance followed by verification that may require you to start over.
[10:16:05] <mellon> (Ralph) specifics?
[10:16:26] <mellon> (Rob) DNS has this peculiar property that delegations down from parent to child, you get a signed hash of child's keys in parent's zones.
[10:16:54] <mellon> The NS record in the parent zone is not signed, so you follow it, check the hash. Maybe you detect you're screwed. This is deferred detection of having been lied to. I suspect you're stuck with this.
[10:17:16] <mellon> One thing to keep in mind with mechanisms that involve traffic outside of DHCP is strong possibility of circular dependencies.
[10:17:28] <mellon> Look at converting those to spiral dependencies. Youc an probably get it together.
[10:18:10] <mellon> Alper Yagen: I agree we should be looking into AAA-based approaches. We can tie network access/AAA to DHCP security. Approaching this from EAP perspective is what we have done with PANA. EAP creates security assn with local network, can be extended to DHCP client and server.
[10:18:29] <mellon> So our draft hasn't specified how to bootstrap. Solution based solely on EAP is not sufficient. Have to look into EAP transport as well.
[10:18:51] <mellon> One approach could be to look at other transports, like 802.1xMPP. See how EAP-based security can be realized in these environments.
[10:19:04] <mellon> ???: When we deal with authentication, we have to deal with authorization issue.
[10:19:21] <mellon> It is possible that once client has authenticated, it may or may not be authorized for obtaining a particular option.
[10:20:05] <mellon> (Mark) Agree that's an issue, rather stay away from that. Someone's going to say policy. I agree that there's some decision making that has to happen when client requests show up at server.
[10:20:26] <mellon> (Ralph) Mark, if I'm understanding correctly, if we can establish the identity, we already have ways to deal with policy issues.
[10:20:53] <mellon> Alper: On that point, we should remember we are authenticating to authorize for DHCP, not just for sake of authentication.
[10:21:22] <mellon> When we talk about authentication, we are talking about authorization. What database is used is an implementation detail.
[10:21:51] <mellon> (Ralph) How to move forward. Trying to finish threat analysis doc. Evaluate alternatives. So I believe we have some changes to make in threat analysis document, right MImi?
[10:21:55] <mellon> (Mimi) Yes.
[10:22:16] <mellon> (Ralph) When we get revised version published, what is sense of wg about threat analysis being ready for wglc, or is this premature?
[10:22:23] <mellon> How to phrase this for hum?
[10:22:40] <mellon> (Mark) One more question. I had difficulty finding gupta draft. Did I miss email?
[10:22:55] <mellon> (Ralph) We need to get vipul to republish. It's independent of this.
[10:23:26] --- narten has joined
[10:23:52] <mellon> (John Schnitzlein) If I understand, I apologize, I don't have that draft. If the current draft also includes all this good information about solutions to the threats, surely that should be pulled out, we need that for wg to go forward, but
[10:23:59] <mellon> threats rfc shouldn't have that in it, should it?
[10:24:47] <mellon> (Mimi) The draft doesn't really make reference to different possible solutions. It first discusses issues and threats. Next step is to discuss where we go from here. That's what these possible solutions are. That's the roadmap part.
[10:25:06] <mellon> (John) So my recommendation is that the road map should not be in the threats document.
[10:25:09] <mellon> (Mimi) It's not.
[10:25:44] <mellon> (John) One of the things we'll look for in last call is no unintended forward references, then we need to make sure we clearly move forward with reviewing and selecting from among the solutions to the threats.
[10:26:13] <mellon> (Ralph) Yes, that's exactly the roadmap. We'll ask the authors to publish a new revision. When published, we will decide whether that's ready for wglc. Objections? None seen, that's what we'll do.
[10:26:30] <mellon> Mimi, talk about platform integrity measurements?
[10:27:06] <mellon> I should have made clear that we're also collecting new ideas. As soon as TA document goes to wglc, we can start reading and thinking about those specific solutions.
[10:27:39] <mellon> (Mimi) One of the issues that was just brought up was policy.
[10:27:43] <mellon> (Mark) I begged you not to bring it up!
[10:28:00] <mellon> (Mimi) I'm not talking about how to implement policy, but there's another criterion that needs to be discuss once you have authentication.
[10:28:07] <mellon> I might trust you, but do I trust your computer.
[10:28:37] <mellon> So basically we're at the point that we're going to be discussing auth for dhcp messages, these were the three options.
[10:29:06] <mellon> Next issue is platform integrity. There's a lot of talk about web services. You can't really run a web service on a machine if you don't trust the machine.
[10:29:25] <mellon> We can piggyback on the work being done in web services. The platform itself needs to define what its integrity is.
[10:29:50] <mellon> This is being worked on in trusted computing wg. If you have a secure boot of the system with TPM, you have some valid information as to what's running on it.
[10:30:16] <mellon> Second issue is reporting of integrity measurements. This is being done in ws-assurance working group in ASIS(?). They're reporting on integrity measurements.
[10:30:38] <mellon> How do you piggyback on this work, supply this information to DHCP server to decide whether or not you trust integrity of the system.
[10:30:53] <mellon> One of the uses for doing this is to be able to differentiate between one host and the operating system and the security of that operating system.
[10:31:27] <mellon> So to say "this host is running what I would allow on this network." "This machine needs patched, we'll run it on a different network until it's patched" This can be done dynamically. Proactive postisolation.
[10:32:12] <mellon> (Mark) Of course, real limitation of what can be achieved with this in DHCP-land. Malicious host grabs IP address from somewhere if it has access at link. Need to decide at link level, right?
[10:33:07] <mellon> (Mimi) Integration is to separate using one of the options i was thinking about was using dynamic vlans. Those that haven't applied patch aren't necessarily infected, need to isolate them. This plays into router and switch.
[10:33:19] <mellon> Only those the DHCP server has given an address can get off this network, perhaps.
[10:33:26] <mellon> (Mark) LIke what's done in cable environments.
[10:33:38] <mellon> (Mimi) That would happen elsewhere. But first we need DHCP server to distinguis them.
[10:33:52] <mellon> (Alper) This is an approach to secure DHCP, or enhanced security of network access?
[10:34:14] <mellon> (Mimi) Has nothing to do with authentication. This is for network management, to be able to manage the networks so that the DHCP server could be part of that criteria definition.
[10:34:27] <mellon> Alper: so in that sense owuld be in addition to any network access authentication scheme using the network?
[10:34:45] <mellon> We are slipping into network access security, which is subject of AAA, 802.1X, PPP, PANA, etc.
[10:34:54] <mellon> Is this meant to be assisting those other schemes?
[10:35:17] <mellon> (Mimi) I havent' gone to the other areas. I probably should follow through with other groups. Since I was working in DHCP, thought this would be an interesting place to bring this up.
[10:35:37] <mellon> Kim Kinnear: Seems obvious that this isn't a security situation because a malicious machine... THere might be an option that would hold this PIM value.
[10:36:33] <mellon> The server would use this to make decisions. Obviously a malicious machine is going to send the best PIM possible. So you aren't trying to protect against malicious machine, but there's software that's going to tell what's out there, what level it's at, if you don't apply right updates, your machine will admit it, and DHCP server will make you go to some pain to apply the right updates.
[10:37:10] <mellon> (Mimi) Kind of. TPM concept is that the information they obtain, if you combine it with a secure boot, it's immutable, trusted piece of information. Information is signed. Key is in TPM chip.
[10:37:48] <mellon> (Kim) As far as this group's concerned is an option to send this stuff in. The more you focus on that, and less on whether that is secure end-to-end, if you can make a case for having an option, you might want to move that direction, instead of trying to get us to agree that this is globally secure.
[10:37:59] <mellon> (Mimi) Just trying to get an idea of whether this would be considered.
[10:38:17] <mellon> (Thomas Narten) How do we evaluate options? Syntax. Then semantics. What gets put into it, properties of it, and so forth.
[10:38:45] <mellon> Really the interesting discussion is about semantics. This group probably not the right place to look at that. Once this is done in some other group, then time to get buy-in from DHCP side.
[10:39:08] <mellon> The more important question si what do you want to use this option for, if you want crypto assurances of signature, that's a pretty high bar.
[10:39:44] <mellon> Would be nice to shunt misconfigured stuff off to bad vlan. But that's different than something that's signed with real assurance that operating system hasn't been mucked with.
[10:40:30] <mellon> Manet from quallcom: There are cases especially with new iso standards talking about booting from ip-based storage. DHCP is first thing that happens. Security at that level is really important. Other tests might come afterwards. So tying these two things together might make sense.
[10:40:49] <mellon> (Ralph) Suggestion: you and I and ADs to think about semantics, where to take this and have semantics reviewed.
[10:41:07] <mellon> Okay, we're down to last agenda item. Although we have 45 mintues, we may finish early.
[10:41:25] <mellon> Start everyone thinking about, doing wg brainstorming about issues around dual-stack hosts configured with DHCP.
[10:41:47] <mellon> (John) Skip DHC authentication, three proposals?
[10:43:03] <mellon> (Ralph) We discussed authentication. There are three drafts, but it turns out we don't need to discuss them now.
[10:43:13] <mellon> Configuration of dual-stack hosts.
[10:44:01] <mellon> What are the problems? You might think about running both DHCPv4 and DHCPv6. Two instances of DHCP might get different configuration information.
[10:44:09] <mellon> E.g., two different lists of DNS servers.
[10:45:50] <mellon> (Ted) Why use DHCPv4?
[10:45:57] <mellon> (Thomas) Lots of v4 options with no v6 counterpart.
[10:46:26] <mellon> (Pekka) I guess what you are suggesting implictly is that we would add functionality to DHCPv6 to do anything DHCPv4 does. E.g. v4 address assignments.
[10:48:17] <mellon> (Greg Daley) I think there may bea situation where you want to run DHCPv4 and v6 on same information. May not want to get configuration from both of them. If you already have a v4 address, then move to a v6 network, you will try to do v4.
[10:48:22] <mellon> (Ted) Really?
[10:48:45] <mellon> (Greg) For example. Then you could use those addresses to do mobile IPv4. Also more than just addresses. You have to use v6 for other options.
[10:49:00] <mellon> Whether it's good practice or not, you would use different namespaces for different domains.
[10:49:11] <mellon> (Ted) This seems like a gigantic rathole.
[10:50:53] <mellon> (Margaret) Today we expect that a lot of devices will be dual-stack. Won't be v6-only. People in this room are arguing that DHCPv6 is a good way to get DNS info. So we picture a world where devices are dual stack. Now they need a DNS server list. Current proposal - the one for DHCPv4 that only returns v4 addresses. v6 returns v6 addresses. Maybe if I'm dual-stack I don't care. I get a list from v4. I get list from v6. What do I try first? Possibly these are the same node.
[10:51:14] <mellon> (Ralph) My understnading, those with greater expertise may object, you get the same answer back no matter which server you send the query to.
[10:51:41] <mellon> Margaret: A lot of the point of DHCP is that you put policy of configuration in DHCP. May want to balance where requests go to. Lists may be ordered for a reason.
[10:51:54] <mellon> New options - what prompted this was NTP option.
[10:52:38] <mellon> Pekka: I agree with Margaret but I don't see it as problem that v6 server can't give v4 addresses. Bigger problem is that you get different information from different places.
[10:53:12] <mellon> I think the main issue is somehow trying to figure out what are the problems when you merge information from two different sources and put it in one database. E.g., DNS configuration, NTP configuration, etc.
[10:53:31] <mellon> Most things should be transport-independent, but there may be exceptions.
[10:54:18] <mellon> Kim: I can imagine, it sounds like there's enough interest to move forward. I don't have a strong feeling there. I can imagine two things we can do in v6. Also return v4-style addresses. Or return something in v6 saying use v4 first, v6 first, etc. In both cases extending v6.
[10:54:22] --- narten has left: Disconnected
[10:54:32] <mellon> What I am adamantly opposed to is making leases on v4 addresses.
[10:55:33] <mellon> (Ralph) one of the things you've just raised about the administrator we need to talk about. Can we assume that v4 and v6 service are under the same administration and therefore coordinated?
[10:56:05] <mellon> Kim: good question. Personally, I think the answer is that you can't assume that's always the case.
[10:56:48] <mellon> (Ralph) We've had a smaller version about just DHCPv4 service, assuming that if a client gets back answers from different servers with different information, it's a misconfiguration.
[10:57:32] <mellon> (Mark) Sounds like policy to me. I imaging what's going to happen is everyone is soaking in IPv4, we'll install v6 stacks and start using that also.
[10:57:43] <mellon> It'll be easier to have rollout happen if they're treated independently.
[10:59:04] <mellon> (Thomas) The first bullet is key - merging. We already have this problem in DHCPv4. Haven't thought about it carefully. Suppose you have device with two interfaces. Do you merge the two? Union of two? Most recently received? We've got v4 and v6 running, will get conflicting, overlapping information.
[10:59:09] <mellon> How do you decide which is right?
[11:00:26] <mellon> (Thomas) should we let every client decide, or have concrete guidelines rather than having different clients doing different things.
[11:02:30] <mellon> (Ralph) Is it current practice that one stack propogates over to other stack, or are they kept separate?
[11:02:56] <mellon> Pekka: for purposes of DHCP, all dual-stack hosts can be thought of as hybrid, so information is shared. So this is a problem.
[11:03:14] <mellon> Because DHCPv6 is not used at the moment, hosts are using stateless and info from DHCPv4.
[11:04:09] <mellon> Greg: I just wanted to be clear about information propogated between interfaces. I'm not sure we want to go down path of modifications. We could just define a BCP. If we are feeding DNS addresses for example, we can always encode IPv4 in IPv6. That's conceivable w/o protocol modification. I'm pretty sure we don't want to modify DHCPv4.
[11:04:28] <mellon> Margaret: sorry for running in and out, daughter broke foot, she's fine, that's why I was running in and out.
[11:04:53] <mellon> I don't think we should run off and modify anything until we think about what makes sense. It's not all that many end nodes that have two active interfaces at the same time.
[11:05:12] <mellon> We do expect that if v6 is successful, there are oging to be a lot more dual-stack hosts than there are today.
[11:05:32] <mellon> I do think we need to think about this problem and not just assume it's already been solved.
[11:05:58] <mellon> Ted Chan: it does seem we are going to use DHCPv6 for DNS options. Also applies if you use RA method.
[11:06:26] <mellon> The other thing I can see going to wireless lans and conferences is that I've got my DNS v6 address manually in resolv.conf, then DHCPv4 breaks it.
[11:07:00] <mellon> Third thing, some people using different domains, they want to offer experimental service. If you don't have different search paths, you can't control which version you use.
[11:07:20] --- ogud has joined
[11:08:02] <mellon> (greg) not sure this is an issue, but consider dynamic dns updates. If host has same hostname for v4 and v6 and we have ddns update for a and aaaa, is there preference on which one is preferred way to contact host?
[11:11:16] <mellon> (Ralph) so it's good do identify problems, solutions may not yet be possible.
[11:11:49] <mellon> (Rob) I operate one of those rare DHCP clients, and I know what it does. One of them, I believe for configuration beyond addresses, the other I don't. It's a border issue. Probably in that kind of case there's no alternative.
[11:12:30] <mellon> The whole concept of getting a search path from DHCP is kind of amazing. If you're asking your environment about what questions you should be asking, and you're getting conflicting answers, well, you've admitted your ignorance - there's not much you can do.
[11:12:53] <mellon> In the case of DNS, it's really one internet, so not such a problem. You send updates to authoritative name server regardless of which stack you're using.
[11:13:00] <mellon> There are coordination problems, but that's not a major issue.
[11:13:25] <mellon> (Thomas) To follow up on what ted was saying, there are some DHCP parameters that are stack-specific, but there are a bunch that are not, like what DNS server do I use?
[11:13:36] <mellon> That's where when you get conflicting information the question of what to do with it is important.
[11:13:51] <mellon> What you do probably has to be dealt with on a case-by-case basis.
[11:14:06] <mellon> In some cases merging is right, in some cases picking one, in some cases who knows?
[11:14:41] <mellon> ???: Main difference between v4 and v6 is layer three. Can't you say that anything that is not layer three is responsibility of server administrators to provide same information via v4 and v6?
[11:15:07] <mellon> Ralph: that relates back to question I was asking, can we make assumption that all servers are under same competent administration.
[11:15:23] <mellon> Thomas: "you must do that" doesn't solve the problem. We still have to say what to do in the case where they *don't* do it.
[11:15:57] <mellon> Ralph: we've tried not to anticipate all the possible misconfigurations and failure modes and solve them, so that's maybe a rathole we can avoid.
[11:16:15] <mellon> ???: if you get reply from v6 server, don't do v4. If you want v4 addresses, get from v6 server.
[11:16:48] <mellon> If you don't get reply from v6 server (this was Stig Vanness). then go to v4.
[11:17:16] <mellon> Ralph: I'm mulling what to do next. I think we can take a couple of minutes to figure out a next step. If there's a bright idea, I'll entertain it.
[11:17:27] <mellon> Greg: I think we have to at least document these issues.
[11:17:53] <mellon> Ralph: who's going to write that?
[11:18:19] <mellon> Tim's volunteered to write a document. Tim Chown.
[11:18:54] <mellon> Mimi, if you could email presentation I can send it in for submission.
[11:18:58] --- rajid has left: Disconnected
[11:18:59] <mellon> Looks like we're done!
[11:20:04] --- ogud has left: Disconnected
[11:21:00] --- mellon has left