Subject: [Int-area] Ted's slides on dhcp-auth

From: "Alper Yegin" <[email-masked]>
Date: Tue, 23 Mar 2010 22:58:13 +0200

Hi Ted,

"Separate EAP Processing from DHCP protocol
- DHCP Client hands EAP Messages to EAP client
- Relay hands EAP responses to EAP server"

Of course. What would be the other way anyways (DHCP code implementing EAP
stack?) 

Please take a look at RFC 3748 and you can see DHCP is acting as "EAP
lower-layer" according to the EAP stack.

". This Fixes previous three slides"

No, not at all. 

- Still you need the DHCP relay to send packets (for transporting EAP
retransmissions, initiating EAP re-authentication),
- Proxy vs. relay confusions continues,
- You need to run EAP authentication twice (unless you want to have close
coordination between the DHCPv4 and DHCPv6 implementations -- gating one by
the other, until the latter completes EAP authentication).

Alper

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Mar 2010 14:31:05 -0700

> retransmissions, initiating EAP re-authentication),

I agree that this is still needed, but why is it a problem?

> - Proxy vs. relay confusions continues,

The relay does the extra function of caching the client's authentication status , triggering EAP, and relaying EAP packets, sure. That's the point of this protocol.   Why is this a problem, when it was not a problem for DHCPLEASEQUERY?   Relays that implement DHCPLEASEQUERY reach over into non-DHCP protocols just as this proposal does.

> the other, until the latter completes EAP authentication).

The combination of client identifier, which is the same for RFC4361-compliant v4 clients and all v6 clients, and circuit ID, which is also the same, since it uniquely identifies a particular link, form an identifier which is specific to the node running the v4 and v6 clients.   So this does in fact resolve the dual stack issue.   This is _why_ we did RFC4361--so that we could tell that a DHCPv4 client and a DHCPv6 client were configuring the same node.

Anyway, why are we still arguing about this?   From what I could tell at the end of the meeting, unless some new proponent comes forward on this, it's a dead issue.   It looks like there's some interest in stepping back ten paces and coming up with a requirements document (which obviously would not be DHCP specific).    Do you object to that?

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 24 Mar 2010 20:08:54 +0200

> Anyway, why are we still arguing about this?   From what I could tell
> at the end of the meeting, unless some new proponent comes forward on
> this, it's a dead issue.   

Fine. I won't bother explaining anymore.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Mar 2010 11:16:05 -0700

> Fine. I won't bother explaining anymore. 

Excellent.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 24 Mar 2010 14:24:00 -0700

On Tue, Mar 23, 2010 at 02:31:05PM -0700, Ted Lemon wrote:
> Anyway, why are we still arguing about this?   From what I could
> tell at the end of the meeting, unless some new proponent comes
> forward on this, it's a dead issue.

I am starting to wonder about that.

Suppose that it is shown that DHCP is "only" a transport protocol
in your words from your presentation yesterday.

Would not then any transport protocol suffice?  If the EAP exchange
does not affect DHCP materially and vice versa, then surely it doesn't
matter if the transport is DHCP - it is as good as out of band.

Would not then a transport protocol explicitly designed for the
purpose of carrying EAP be superior in every way to the prospect of
changing the DHCP protocol to become EAP's transport layer?

I think a proof that the EAP and DHCP state engines need not be
reconciled is a proof that the draft should be let to expire.  Not a
claim that the problem is resolved.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Mar 2010 15:37:25 -0700

> in your words from your presentation yesterday.

You are taking what I said out of context.   I said that if we decouple the EAP and DHCP state machines, then DHCP is functioning only as a transport for EAP.   I didn't say that DHCP is a transport.   It's not--it's a configuration protocol.   However, in this context it would be functioning largely as a transport, with one caveat, which I mentioned.

> matter if the transport is DHCP - it is as good as out of band.

DHCP *does* affect EAP materially, because the DHCP client identifier and the Relay agent circuit ID are needed by EAP.   If you don't use DHCP as a transport, you have to get that information some other way.

> changing the DHCP protocol to become EAP's transport layer?

In every way but that one, yes.

> claim that the problem is resolved.

Again you've misconstrued what I said.   What I said is that it's academic because nobody is advocating going forward with the proposal at the moment.   So there's no reason to argue about it.   I am _not_ saying that there's no reason to argue about it because it's all better now, and can proceed without further discussion.   Given the lack of consensus both in the intarea meeting and on the dhc mailing list, it would be absurd to make that claim.

---

From: Richard Pruss <[email-masked]>
Date: Thu, 25 Mar 2010 08:40:27 +1000

> Anyway, why are we still arguing about this?   From what I could tell at the end of the meeting, unless some new proponent comes forward on this, it's a dead issue.   It looks like there's some int…

Well while this was not the outcome we were hoping for, I do want to stand back from the fray and thank Ted and his fellow authors for what has clearly been allot of work.  Both the analysis document and
the latest round of slides brought fresh technical thinking to the subject.  While I obviously do not agree with all points in the documents I do want to commend Ted on his handling of the matter and also for
his handling of the fractious protagonists.

Regards,
Ric