Alan, > > 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.
Then it is hard to be evaluating cost of PANA implementation/deployment versus dhcp-auth. > >> 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? I have a feeling that you are only looking at this from RADIUS perspective. Yes, from RADIUS perspective, EAP arrives on another protocol, be it EAPOL, PANA, or DHCP. > > 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. Indeed! There is no reason for that EAP transport be 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. Again, this is just the RADIUS angle... Translating EAP/foo to EAP/RADIUS is trivial, for all cases. > 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. Yes, it has nothing to do with DHCP. Alper > > Alan DeKok. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
