Alper Yegin wrote: > There is no such thing as "PANA deployment on intermediate devices". There > is PANA Client co-located with EAP peer (e.g., RG) and PANA Authentication > Agent co-located with EAP Authenticator (e.g., BRAS).
Sorry. I haven't read the PANA specs in detail. >> A: New server software at every ISP, with fail-over, redundancy, etc. >> A: Sysadmin training, knowledge, etc. > > And if we grow a PANA protocol out of DHCP, none of that happens? Yes. ISP's already have RADIUS && DHCP servers. I'm assuming that the BRAS would take the DHCP-EAP packets, and transform then into RADIUS packets. They already do EAPoL to RADIUS. So what's so new about another transport? > If that's strategy we need to follow, than let's stop defining any new > protocols right now, instead start reusing existing protocol headers for > anything we need, forever. The IETF has a pretty bad track record of creating *new* protocols that are widely deployed. It has a much better track record of "fixing" horrible hacks that others have invented. > Btw, there already is open source PANA implementation. OpenDiameter? I don't think so. It's a research implementation of the protocol. It's *not* a server that can be deployed in real-world environments. > Alan, maybe you are still remembering the day when the author of the > dhcp-auth was claiming it to be as simple as defining and transporting EAP > payload. Those days are long gone. Please take a look at the latst I-D. Now > PANA (or PPP) is growing out of DHCP with its own messages, options, state > machines, end points -- all distinct from standard DHCP. So, any > sysadmin/developer/etc.'s knowledge/books/notes/scripts/etc on DHCP is > useless for dhcp-auth. Yes. I've read the draft. It *stops* the DHCP state machine, and uses DHCP as a transport protocol for EAP. In that sense, it's closer to EAPoL than to DHCP. And EAPoL is well understood. DHCP parsers are well understood. Packing EAP into DHCP options is worth a few grumbles, but isn't rocket science. Transforming DHCP packets into RADIUS instead of doing EAPoL into RADIUS is worth a few more grumbles, but it's not hard. Implementing a brand-new protocol with a brand-new packet format, TLV format, and state machine is *hard*. Getting it widely deployed is even harder. >> I'm not assuming that the DHCP proposal is cost-free. But on the >> server side, the costs are significantly lower than PANA. > > Please see above. I don't see how you've refuted any of my points. PANA is *ideally* the best solution. The DHCP+EAP proposal is less work. Maybe I'm misunderstanding this proposal, but it *doesn't* look like DHCP to me. It looks like EAPoL, with some horrible encoding format. Alan DeKok. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
