On Tue, Aug 05, 2008 at 06:22:41PM +1000, Richard Pruss wrote: > 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.
Actually Lionel's proposal does not necessarily require modifications to DHCP implementations, if DHCPDISCOVER is queued outside the DHCP implementations and the queue is used as a trigger for PAA-initiated PANA session. Once PANA authentication succeeds, the DHCPDISCOVER is forwarded to DHCP server to continue the standard DHCP messaging for IP address assignment. Since PAA-initiated PANA session is triggered by setting a boolean variable (i.e., PAC_FOUND) in PAA state machine, and the queueing event is just one external trigger for setting the variable, his proposal does not require any change to PANA state machines either. Regards, Yoshihiro Ohba > > - Ric > > > On 03/08/2008, at 12:23 PM, <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> 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 : [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] De la part de Basavaraj Patil >>> Envoyé : mardi 29 juillet 2008 12:20 >>> À : ext Richard Pruss; Alper Yegin >>> Cc : [EMAIL PROTECTED]; [email protected] >>> Objet : Re: [Int-area] [dhcwg] dhcp-auth, part 2 >>> >>> >>> Hi Ric, >>> >>> >>> On 7/29/08 4:43 AM, "ext Richard Pruss" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] >>>>>>>> Sent: Saturday, July 26, 2008 2:28 AM >>>>>>>> To: 'Richard Pruss' >>>>>>>> Cc: '[email protected]'; '[EMAIL PROTECTED]' >>>>>>>> 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 >>>>>>>>>> [email protected] >>>>>>>>>> https://www.ietf.org/mailman/listinfo/int-area >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> dhcwg mailing list >>>> [EMAIL PROTECTED] >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> _______________________________________________ >>> Int-area mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/int-area >>> > > _______________________________________________ > dhcwg mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
