Subject: [Int-area] dhcp-auth

From: "Alper Yegin" <[email-masked]>
Date: Fri, 25 Jul 2008 00:41:53 +0300

Now that I see this proposal is back on stage (for the 5th time now), let's
see if we can get answers to some fundamental issues.

Last time I had sent a long list of issues, and there was no response.

http://www.ietf.org/mail-archive/web/int-area/current/msg01255.html

Let's start just looking at the issues about Figure 3...

- What is the DHCP-wise functionality of the NAS? Text claims it is a "DHCP
relay" but I see it terminating some of the DHCP messages and also
generating some other messages. This is not compliant with DHCP. 

- How does the NAS handle EAP retransmissions? It needs to send unsolicited
DHCP messages to the DHCP client. This is not compliant with DHCP.

- I see NAS inserting additional DHCP option (EAP Success) on DHCPOFFER as
it forwards that message from DHCP server to DHCP client. This again breaks
DHCP.

Alper

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Richard Pruss <[email-masked]>
Date: Fri, 25 Jul 2008 09:05:55 +1000

Ahh Alper email from you again.  I am certainly not going to spend  
time sluggin away joylessly with you. I think we
can take it as read that you will always hate it.

For the other folk I had a brief summary of the changes almost  
finished for dhcwg list which I have now send.

> generating some other messages. This is not compliant with DHCP.

As we explained to you many times most vendors BRAS's act as a DHCP  
proxy and terminate all messages and look like a server to the client.

> DHCP messages to the DHCP client. This is not compliant with DHCP.
Actually that issue is open and we can discuss what a compliant  
implementation would mean in terms of retransmission timers so that  
right thing always happens at the right layer.

> it forwards that message from DHCP server to DHCP client. This again  
As we explained to you many times most vendors BRAS's act as a DHCP  
proxy and terminate all messages and look like a server to the client.

Lets take this to the dhcwg list as that is where the review happens  
next week.

- Ric

---

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Jul 2008 09:55:51 +0300

Hello folks,

It is a given that this is a controversial topic. You may disagree with 
the next guy. But please keep the discussion polite.

Thanks,

Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 26 Jul 2008 02:28:00 +0300

I don't appreciate your comments. Let's stay on the technical course.

> proxy and terminate all messages and look like a server to the client.

That's not accurate according to Figure 3. I see "some" DHCP messages
terminating on the NAS (e.g., DHCPEAP*) and "others" going through (e.g.,
DHCPDISCOVER) within the same DHCP flow.

I don't think it is as simple as your two-sentence explanation anyways. As
requested earlier, IETF needs to see a document where this DHCP proxy model
is defined. I'm aware of one DHCP proxy model and it is nothing like what
your document is suggesting. 

Can you please send us a document that describes the DHCP proxy model? IETF
needs to buy in the DHCP proxy model before any other proposal built on top
of that gets accepted.

> right thing always happens at the right layer.

OK, please explain.

> proxy and terminate all messages and look like a server to the client.

Again, NAS does not really terminate "all" messages (see above). And this
"box in the middle" inserting DHCP options towards the DHCP client breaks
DHCP.

> Lets take this to the dhcwg list as that is where the review happens

Really? What happened to the escalation of this discussion to int-area and
the outcome of the poll from last IETF? I hope Jari can clarify this. 

Alper