Subject: Re: [dhcwg] BBF reqs on DHCP relay (was RE: Adopt draft-pruss-dhcp-auth-dsl as a working group item?)

From: "Alper Yegin" <[email-masked]>
Date: Mon, 1 Mar 2010 10:52:46 +0200

Ted,

> On Feb 27, 2010, at 4:12 PM, Alper Yegin wrote:
> >> I take it from this line of argument that you feel that something
> that
> >> is a superset of a DHCP relay is disqualified from acting as a DHCP
> >> relay.   Could you explain why this is so?
> >
> > Can you please explain to us what DHCP proxy is in detail, and how it
> is
> > considered a superset of DHCP relay?
> 
> You just answered a direct, easily answered question with another
> question.  Let me ask you the question again, and try to phrase it more
> clearly, in hopes of eliciting an answer this time.
> 
> Suppose there is a device on the network which performs all the
> functions of a DHCP relay agent.   Suppose this device also performs
> other functions.   Does the fact that it performs other functions mean
> that it does not satisfy a requirement for a DHCP relay agent?   If so,
> why?

Yes

We also need to understand how it remedies the problems with DHCP relay, if
at all.

> Now, in answer to your question, the protocol specification says what
> the "DHCP proxy" does.   If you feel that the specification is unclear,
> it would be helpful to know what you feel is missing, or what about it
> doesn't make sense to you.
> 
> It might be helpful to refer to the analysis document, which talks
> about some known problems with the "DHCP proxy" as it is currently
> specified, so that we don't find ourself revisiting ground that has
> already been covered.   Quite a bit of verbiage in the document was put
> there to address previous questions you've asked about the proxy.

Huh? There is not even a word "proxy" in the analysis I-D, and I don't know
what "protocol specification" you are referring to for me to read "DHCP
proxy". I suspect there is a confusion.

So, having answered your question (which I don't think has any value until
the following ones are answered), now my questions are:
1. What is a DHCP proxy, how does it work (in detail, not in two-sentence
hand-waving terms)?
2. How does EAP gets transported over it, details please.
3. Let's do an analysis of that too in DHC WG.
4. Is BBF members willing to take DHCP proxy as a replacement of DHCP relay?
Current TR-101 requirements are for DHCP relay, not for its undefined
superset. 

> 
> Like you, I am eager to hear Ric's answers to the concerns raised in
> the analysis document.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 1 Mar 2010 12:27:23 -0700

> We also need to understand how it remedies the problems with DHCP relay, if

Did you miss the "if so, why?" part of the question?   Could you please answer this question, and not just blow it off once again?

And what do you mean by "it remedies the problems with DHCP relay?"   What "it"?   What problems?   Please say what these things are -- I have no idea what you are talking about, and I'm probably not the only person reading this response who has that problem.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 2 Mar 2010 13:57:38 +0200

Ted,

> Did you miss the "if so, why?" part of the question?   Could you please
> answer this question, and not just blow it off once again?

I misread the question. I meant to say "no". I mean, a superset of DHCP
relay does satisfy requirements of a DHCP relay.

[there is no blowing off or anything... just a mistake... no need to react]

> And what do you mean by "it remedies the problems with DHCP relay?"

DHCP relay has issues as described in your analysis ID. A superset of DHCP
relay is likely to have the same issues, unless the extras (that make up the
superset) coincidentally or intentionally fixes those issues.

> What "it"?   What problems?  

The ones that are already described in your ID, that leads to the
conclusion:

   For this reason, we strongly recommend that the authors abandon the
   idea of implementing this protocol extension in the relay agent.
   Also, please note that this is true for the DHCPv6 exchange as well
   as the DHCPv4 exchange; we only document the DHCPv4 exchange for
   brevity.

> Please say what these things are -- I
> have no idea what you are talking about, and I'm probably not the only
> person reading this response who has that problem.

I thought the "problems with DHCP relay" are all clear to everyone who read
the analysis ID. There is a section on "DHCP relay agents" (4.3) that ends
with the conclusion I captured above. 

Can we also talk about the questions I posed, but you removed from the
thread w/o answering:

1. What is a DHCP proxy, how does it work (in detail, not in two-sentence
hand-waving terms)?
2. How does EAP gets transported over it, details please.
3. Let's do an analysis of that too in DHC WG.
4. Is BBF members willing to take DHCP proxy as a replacement of DHCP relay?
Current TR-101 requirements are for DHCP relay, not for its undefined
superset. So, expecting vendors to implement DHCP proxy even though it is
not a requirement in TR-101 is a new (undocumented) requirement.

Answering your question does not have much value until we also understand
these above.

You pointed me to "analysis document" and "protocol specification" for "DHCP
proxy", but I suspect you mixed up DHCP proxy and DHCP relay terms. 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 2 Mar 2010 14:51:49 +0200

> Requires DHCP revoke, which requires keys for DHCP message
> authentication, which we want to share over EAP.

You need to document the details in your I-D.

> You moaned about draft on that done by Joe and I on and said that you
> were going to
> revive your own one.

I need to find time to do that.
An older version is here:

http://tools.ietf.org/html/draft-yegin-eap-boot-rfc3118-03

Not sure how different a revised version would look like. 
Lack of interest in DHC WG led to lack of motivation, hence not much
progress there.
Btw, also, now there is another proposal that attempts to secure FORCERENEW.

Alper

> 
> We are watching with interest,
> Ric
> 
> On 28/02/2010, at 2:37 AM, Alper Yegin wrote:
> 
> > Ric
> >
> > I don't remember seeing your response to the following.... did I miss
> it?
> >
> >> IPAuth-7:    Must support revoking authentication
> >> IPAuth-15:   Must offer an option to re-authenticate periodically or
> on
> >> demand.
> >>
> >> Not sure how these are satisfied.
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dhcwg