Re: [Int-area] [dhcwg] dhcp-auth, part 2
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Int-area] [dhcwg] dhcp-auth, part 2

Lionel,
The part you simply seem to fail to understand even though many people in the DSLForum has pointed out repeatedly on the PANA proposal is: - DSL currently AAA authenticates on the DHCP discover based on the option 82 data. The EAP proposal is a small step from what deploys worldwide. - A new protocol that impacts every network node is not small deal, this is one of the reasons allot of the DSL vendors are supporting the EAP over DHCP approach.
As for this huge advantage of PANA in that it does not change the DHCP State Machine. PANA does require modifications to the DHCP implementations as your last proposal now DHCP is clearly triggered and controlled by PANA. That effectively makes DHCP part of the PANA state machine. So now a massive new protocol and changes to the DHCP and every node on the broadband network is somehow lighter than a pause in the DHCP state machine between DHCPDISCOVERY and DHCPOFFER to run some EAP messages. 

- Ric
On 03/08/2008, at 12:23 PM, <lionel.morand at orange-ftgroup.com> <lionel.morand at orange-ftgroup.com > wrote: 


Hi All,
Actually, in the DHCP-auth proposal, the DHCPEAP exchanges are triggered by the DHCPDISCOVER/SOLLICIT message and achieved by a DHCPOFFER/ADVERTISE sent back to the DHCP client in response to the initial DHCPDISCOVER. Therefore, between the DHCPDISCOVER/SOLLICIT and the DHCPOFFER/ADVERTISE, any EAPoIP transport protocol will fulfil the DSL security requirement. And as PANA is already specified for that, I'm not sure that a new solution is required, at least in IETF.
As the DHCP server/Relay and the AAA client are colocated within the BNG/BRAS, the same DHCPDISCOVER/SOLLICIT can trigger in the same way a PANA/EAP authentication, as soon as the use of unspecified IP addresses (IPv4) or link-local addresses (IPv6) are allowed for PANA in the context of DSL network (as it is discussed in the PANA WG). After the final PANA-Auth-Answer, a DHCPOFFER/ADVERTISE will be sent to the DHCP client to complete the IP address allocation procedure.
If DHCP-Auth and PANA could be seen as quite similar solutions when you are considering a basic successful authorization (i.e. impact on the HGW and the BNG/BRAS, no impact on the DSLAM), I see several advantages for PANA against DHCP. The first one is that PANA will not introduce modification to the DHCP client and the DHCP state machine. The other one is that authentication related server-initiated procedures (re- authentication/session termination) can be performed wihtout relying on DHCP exhanges and impacting therefore the client's DHCP state machine.
Of course, PANA would be a totally new protocol to support in DSL networks. But I don't think that the impacts of this introduction would be more important than the required evolution of the DHCP protocol to be able to fulfil the same EAP functionalities. And anyway, the IP session model and the whole EAP authentication procedure are brand-new functionalities to introduce in the DSL networks. 

BR,

Lionel


-----Message d'origine-----
De : int-area-bounces at ietf.org
[mailto:int-area-bounces at ietf.org] De la part de Basavaraj Patil
Envoyé : mardi 29 juillet 2008 12:20
À : ext Richard Pruss; Alper Yegin
Cc : dhcwg at ietf.org; int-area at ietf.org
Objet : Re: [Int-area] [dhcwg] dhcp-auth, part 2


Hi Ric,


On 7/29/08 4:43 AM, "ext Richard Pruss" <ric at cisco.com> wrote:




I made pretty much the same observation on Pana for DSL yesterday.


Nope. There is no modification to DHCP at all when PANA is

used. No

new DHCP options, messages, changes to the state machines, etc.



And you propose a whole new protocol that is not supported

on all the

network devices in question.


I hope you are not implying that with DHCP-auth there is no
implication or impact to hosts or network devices in
question. What you are proposing is essentially transforming
DHCP into an entirely new protocol. You are just riding on
the DHCP coattails and expect EAP to get a free ride... But I
don't believe it is that simple.

-Raj



- Ric



Alper



- Ric



Alper

















Alper


-----Original Message-----
From: Alper Yegin [mailto:alper.yegin at yegin.org]
Sent: Saturday, July 26, 2008 2:28 AM
To: 'Richard Pruss'
Cc: 'int-area at ietf.org'; 'dhcwg at ietf.org'
Subject: RE: [Int-area] dhcp-auth

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


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.



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.



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.



- How does the NAS handle EAP retransmissions? It

needs to send

unsolicited 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.


OK, please explain.



- 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.


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.


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 next week.


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









- Ric





Alper


_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area








_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area



_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.