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

From: Basavaraj Patil <[email-masked]>
Date: Tue, 29 Jul 2008 05:19:48 -0500

Hi Ric,

On 7/29/08 4:43 AM, "ext Richard Pruss" <[email-masked]> 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-masked]]
>>>>> Sent: Saturday, July 26, 2008 2:28 AM
>>>>> To: 'Richard Pruss'
>>>>> Cc: [email-masked]'; [email-masked]'
>>>>> 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-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/int-area
>>>> 
>>>> 
>> 
>> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

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

---

From: <[email-masked]>
Date: Sun, 3 Aug 2008 04:23:10 +0200

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-masked] 
> [mailto:[email-masked]] De la part de Basavaraj Patil
> Envoyé : mardi 29 juillet 2008 12:20
> À : ext Richard Pruss; Alper Yegin
> Cc : [email-masked]; [email-masked]
> Objet : Re: [Int-area] [dhcwg] dhcp-auth, part 2
> 
> 
> Hi Ric,
> 
> 
> >> new DHCP options, messages, changes to the state machines, etc.
> >> 
> > 
> 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 
> >>>>>>> - 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.
> >>>>>>> 
> >>>>>> 
> >>>>>> DHCP proxy and terminate all messages and look like a 
> server to 
> >>>>>> the client.
> >>>>> 
> >>>>> 
> >>>>> messages terminating on the NAS (e.g., DHCPEAP*) and "others" 
> >>>>> going through (e.g.,
> >>>>> 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.
> >>>>> 
> >>>>> IETF needs to buy in the DHCP proxy model before any other 
> >>>>> proposal built on top of that gets accepted.
> >>>>> 
> >>>>> 
> >>>>>>> unsolicited DHCP messages to the DHCP client. This is not 
> >>>>>>> compliant with DHCP.
> >>>>>>> 
> >>>>>> that right thing always happens at the right layer.
> >>>>> 
> >>>>> OK, please explain.
> >>>>> 
> >>>>> 
> >>>>>>> DHCPOFFER as it forwards that message from DHCP 
> server to DHCP 
> >>>>>>> client. This again breaks DHCP.
> >>>>>>> 
> >>>>>> DHCP proxy and terminate all messages and look like a 
> server to 
> >>>>>> the client.
> >>>>> 
> >>>>> breaks DHCP.
> >>>>>> happens next week.
> >>>>> area and the outcome of the poll from last IETF? I hope 
> Jari can 
> >>>>> clarify this.
> >>>>> 
> >>>>> Alper
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>>> 
> >>>>>> - Ric
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>>> 
> >>>>>>> Alper
> >>>>>>> 
> >>>>>>>

---

From: Richard Pruss <[email-masked]>
Date: Tue, 5 Aug 2008 18:22:41 +1000

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, <[email-masked]> <[email-masked] 
 > 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
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Aug 2008 06:46:35 -0700

> this is one of the reasons allot of the DSL vendors are supporting the

Can you expand on this?   I don't see how this can be true, since both  
protocols would require new software that doesn't currently exist.

---

From: <[email-masked]>
Date: Wed, 6 Aug 2008 01:30:51 +0200

Hi Ric, 

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

If you read (again) carefully my mail you will see that it is exactly my proposal (not documented yet in the draft): a pause in the DHCP state machine between DHCPDISCOVERY and DHCPOFFER and the use of PANA to carry on EAP messages. DHCPDISCOVER will provide the required 82 option to the AAA client and there is no interaction between PANA and DHCP at the client side. Or did I miss your last comment?

Lionel

> 
> - Ric
> 
> 
> On 03/08/2008, at 12:23 PM, 
> <[email-masked]> 
> <[email-masked]  > wrote:
> 
> > Hi All,
> >
> > 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.
> >
> > BNG/BRAS, the same DHCPDISCOVER/SOLLICIT can trigger in the 
> same way a 
> > PANA/EAP authentication, as soon as the use of unspecified IP 
> > The first one is that PANA will not introduce modification 
> to the DHCP 
> > client and the DHCP state machine. The other one is that

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 05 Aug 2008 16:16:46 -0400

On Tue, Aug 05, 2008 at 06:22:41PM +1000, Richard Pruss wrote:
> - 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.
>
> 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-masked]> 
> <[email-masked]> wrote:
>
>> Hi All,
>>
>> 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, 
>> BNG/BRAS, the same DHCPDISCOVER/SOLLICIT can trigger in the same way a 
>> The first one is that PANA will not introduce modification to the DHCP 
>>> Envoy�«± : mardi 29 juillet 2008 12:20
>>> �ª¢ : ext Richard Pruss; Alper Yegin

---

From: Richard Pruss <[email-masked]>
Date: Wed, 6 Aug 2008 13:00:42 +1000

On 06/08/2008, at 9:30 AM, <[email-masked]> <[email-masked] 

> If you read (again) carefully my mail you will see that it is  
> exactly my proposal (not documented yet in the draft): a pause in  
> the DHCP state machine between DHCPDISCOVERY and DHCPOFFER and the  
> use of PANA to carry on EAP messages. DHCPDISCOVER will provide the  
> required 82 option to the AAA client and there is no interaction  
> between PANA and DHCP at the client side. Or did I miss your last  
> comment?

Now the difference between the two proposals is that the PANA one has  
an IP encap for EAP with no source IP address, so IP without an IP  
address and the DHCP one encaps in a DHCP option in a new DHCP message.

Well if nothing else we certainly seem to have moved closer together  
in terms of proposal over time.  Now if we can get PANA to consider  
the EAP encap in DHCP instead of an IP packet we can merge the drafts,  
as the rest of the state proposal is the same.

Ric

---

From: Richard Pruss <[email-masked]>
Date: Wed, 6 Aug 2008 13:19:01 +1000

On 05/08/2008, at 11:46 PM, Ted Lemon wrote:

> Can you expand on this?   I don't see how this can be true, since  
> both protocols would require new software that doesn't currently  
> exist.

Sure, a couple of points

a) Line id
For example on the DSLAM, current implementations add Option 82 to  
DHCP and so for the EAP over DHCP, no software is needed on the  
DSLAM.  For the PANA approach a PANA snooping implementation is needed  
or PANA needs to be integrated with DHCP on the BRAS to get the  
information from DHCP option 82.

b) A new protocol
 From a development and test perspective there is a huge difference  
between a totally new protocol, new IP behaviour verses putting a new  
handler to glue DHCP messages from one's existing DHCP implementation  
to an existing EAP implementation.

So in summary it is not simply a question of software, the EAP  
proposal impacts less elements and reuses existing software.

Regards,
Ric

---

From: Alan DeKok <[email-masked]>
Date: Wed, 06 Aug 2008 09:31:48 +0200

Richard Pruss wrote:
> So in summary it is not simply a question of software, the EAP proposal
> impacts less elements and reuses existing software.

  Let's assume that PANA is the best solution.  Let's also assume that
it's easy to deploy PANA on the client machines, and all intermediate
devices.  The question that's left is: What is the remaining expense to
deploy PANA?

  A: New server software at every ISP, with fail-over, redundancy, etc.
  A: Sysadmin training, knowledge, etc.

  Where do they get this software and expertise?  Right now, many sites
use Open Source DNS, DHCP, and RADIUS software.  There is no equivalent
PANA software.  Where do they get the expertise to administer these
systems?  No sysadmin is familiar with PANA.  There's no readily
available pool of information on the net that helps them through common
configurations or problems.  There is no PANA book from O'Reilly.  There
are no PANA Q&A mailing lists.  There is no group of sysadmins who
understand PANA, and can help newcomers.

  In contrast, leveraging existing AAA systems means that they simply
upgrade their existing AAA software.  Any "new" configurations (e.g.
EAP) are widely documented on the net, with readily available examples,
how-to's, complaints about bugs, fixes, mailing lists, books, user
communities, etc.

  Building that knowledge base is tremendously expensive, and it
*doesn't* show up as a line item on the budget.  It shows up as every
sysadmin getting 50% less work done for a month as they bootstrap their
PANA knowledge.

  I'm not assuming that the DHCP proposal is cost-free.  But on the
server side, the costs are significantly lower than PANA.

  Alan DeKok.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 12 Aug 2008 17:07:50 +0300

> option 82 data.  The EAP proposal is a small step from what deploys

That's not true, and people are seeing it day by day. That small step was
promised to be a simple definition of a new DHCP option to carry EAP, and
even by now it quickly grew to become new DHCP message definitions, state
machines, options, end points. And it is not done yet, there are still many
fundamental problems to be solved.

> this is one of the reasons allot of the DSL vendors are supporting the

Could we directly hear from those vendors? Last time you spoke on their
behalf, it wasn't appreciated.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 12 Aug 2008 17:10:16 +0300

> as the rest of the state proposal is the same.

Now that you understand that your proposal is simply re-inventing PANA, can
you explain to us why IETF should not recommend use of RFC5191 and hack
DHCP?

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 12 Aug 2008 17:12:46 +0300

> information from DHCP option 82.

BRAS can still get the info from DHCP Option 82. That does not require "PANA
integration" because the info deposited on the BRAS by the DHCP is used by
the RADIUS. 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 12 Aug 2008 17:46:43 +0300

Alan,

> devices.  

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

> The question that's left is: What is the remaining expense to
> deploy PANA?
> 

And if we grow a PANA protocol out of DHCP, none of that happens? You are
assuming that just because some hack-under-the-cover-of-an-extension uses
the same DHCP header none of (or, a little of) the above is required. 

> understand PANA, and can help newcomers.

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. 

Many times IETF protocols get accepted into other SDO's architecture without
waiting for book publications, training courses, materials, etc. That's
hardly a show-stopper for the industry.

Btw, there already is open source PANA implementation. 

> how-to's, complaints about bugs, fixes, mailing lists, books, user

PANA transports EAP and does not impact RADIUS/Diameter (if that's what you
mean by "AAA systems").

> sysadmin getting 50% less work done for a month as they bootstrap their

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.

> server side, the costs are significantly lower than PANA.

Please see above.

Regards,

Alper

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Aug 2008 17:38:34 +0200

> Agent co-located with EAP Authenticator (e.g., BRAS).

  Sorry.  I haven't read the PANA specs in detail.

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

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

> sysadmin/developer/etc.'s knowledge/books/notes/scripts/etc on DHCP is

  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.

>> server side, the costs are significantly lower than PANA.

  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.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 13 Aug 2008 01:01:46 +0300

Alan,

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

> packets.  They already do EAPoL to RADIUS.  So what's so new about

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. 

> uses DHCP as a transport protocol for EAP.  In that sense, it's closer

Indeed! There is no reason for that EAP transport be DHCP. 

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

> DHCP to me.  It looks like EAPoL, with some horrible encoding format.

Yes, it has nothing to do with DHCP.

Alper

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Aug 2008 10:48:03 +0200

> Then it is hard to be evaluating cost of PANA implementation/deployment

  I've read the drafts enough to be somewhat familiar with PANA.  Even
without that, the server-side analysis is simple.

> Yes, from RADIUS perspective, EAP arrives on another protocol, be it EAPOL,

  I'm looking at it from a deployment perspective.  New servers are
expensive, even if the source code is available for free... which it
isn't with PANA.

> Indeed! There is no reason for that EAP transport be DHCP. 

  I'll leave that argument to others.  My point is simple: DHCP and
RADIUS are already deployed on the server side.  PANA isn't.

> Again, this is just the RADIUS angle... Translating EAP/foo to EAP/RADIUS is

  Are there EAP to PANA gateways?  That would seem to be hard, given the
state machine requirements of PANA.  The EAPoL state machine seems to be
simpler than the PANA one... and it's already deployed.

> Yes, it has nothing to do with DHCP.

  I'm glad we agree on that.

  Alan DeKok.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 13 Aug 2008 13:20:01 +0300

> simpler than the PANA one... and it's already deployed.

"EAP to PANA gateways"? Not sure I understand how EAP and PANA protocols
relate to each other in a "gateway" context. EAP is payload to PANA. It's
not like EAP is translated to PANA.

Alper

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Aug 2008 12:44:42 +0200

> not like EAP is translated to PANA.

  That was a typo, sorry.  I mean PANA to RADIUS gateways.  If those
existed, it would seem a simple way to deploy PANA, by leveraging legacy
protocols.

  Alan DeKok.