Subject: Re: Problem Statement and Scope of WG

From: John Schnizlein <[email-masked]>
Date: Thu, 04 Apr 2002 13:41:06 -0500

It would be helpful if a short list of examples of the "other link-types"
that lack link-layer authentication mechanisms were inserted here.
The question persists: what is the size of the gap to be covered by PANA?

John

At 07:39 PM 4/3/2002, [email-masked] wrote:
>...
>Currently only IEEE 802 type links have a native encapsulation for EAP. 
>None of the other link-types define how to carry EAP although they might 
>have their own protocols for access authentication and authorization. 
>Even when the link-layers have their own protocols, using EAP provides 
>a standard, flexible, and extensible tool for authentication. This is 
>where PANA will be used to provide the link-layer agnostic encapsulation
>for EAP. By using PANA, individual link-layers don't have to define 
>their own speciic encapsulations to take advantage of EAP.

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 4 Apr 2002 16:53:58 -0500

John,

People, at the moment have no choice...If you want to run native IP over ATM
you can not authenticate the end points. PANA would allow you to do that.
People involved with DSL (I personally used to be back in BT) can tell you
that IP over frame over DSL would be much simpler, cheaper and better from
IP perspective solution than the current solutions but the alternative can
not authenticate the end points and thus is not practical.

People also use PPPoE for exactly the same reason....but maybe you do not
mind that either? Some of us do :)

George

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]]
Sent: Thursday, April 04, 2002 8:26 PM
To: George Tsirtsis
Cc: [email-masked]
Subject: RE: Problem Statement and Scope of WG

That might be an appropriate list, but my impression is that hosts
attach to these through either PPP or 802.1 bridging. 

Does anyone actually connect IP hosts directly to FR or Cable? 
The case for IP/ATM (without IP/PPP/ATM) is stronger, but didn't 
the market already choose against this for host attachments?

John

At 02:03 PM 4/4/2002, George Tsirtsis wrote:
>You mean things like DSL, ATM, FR, Cable?
>
>-----Original Message-----
>From: John Schnizlein [mailto:[email-masked]]
>

---

From: <[email-masked]>
Date: Thu, 4 Apr 2002 17:05:34 -0600

James,

Thanks for the improvement suggestions. We will incorporate it in the
next revision. A few rseponses inline:

>Raj & Alper,
>
>I think it would  be helpful to explicitly list nongoals of PANA. For
>example, I assume that one nongoal is to replace existing link layer
>authentication mechanisms for network access authentication.
>

Completely agree. However for scenarios involving PPPoE for network
authentication, PANA MAY be a better alternative.

>I would also dispute the following goal of PANA:
>
>> - Per-packet authentication/encryption:
>>   To provide data integrity and confidentiality, and to prevent
>>   service theft after clients gain access to the network. PANA
>>   can also enable per-packet authentication/encryption.
>
>The implication I get from this goal is that PANA is proposing to
>replace the IPsec gateway mode, whereas, what I think you are really
>talking about is an alternative key distribution mechanism for session
>keys. That is, I get the impression that PANA will do the actual
>encryption/authentication. I think you need to be much clearer about
>this.

Maybe the wording needs some improvement. What we are saying is that
PANA can be a mechanism for delivering keys to a host and the AP. This
key could be used by other encryption/ciphering mechanisms. So PANA
would not be really the one doing per-packet auth/encryption, but
rather enabling such functionality where required.

>
>Also, the wording on the following paragraph is somewhat cumbersome:
>
>> PANA is even much more needed for link-layers that support
>> neither access nor per-packet authentication. It can be used as the
>> only means to provide access authentication. Per-packet
>authentication/
>> encryption can be achieved by the use of IPsec or other ciphering
>> mechanisms.
>>
>
>I would suggest:
>
>    An even stronger case can be made for PANA for link layers that
>    support neither access nor per-packet authentication. PANA can
>    be used with such link layers as the exclusive means to provide
>    access authentication.
>.

Agreed.

>            jak

-Basavaraj

---

From: <[email-masked]>
Date: Thu, 4 Apr 2002 17:20:07 -0600

John,

>The question persists: what is the size of the gap to be covered by

The size of the gap may be limited to begin with simply because you
have all the entrenched mechanisms already in place. 
However DSL networks today use PPPoE for example in order to do
authentication among other functions. Do you really need PPPoE in DSL
networks? I would think not. So this is an area that may benefit
from PANA. 
And another example would be Bluetooth. The Bluetooth forum is
currently investigating authentication mechanisms. A protocol like
PANA may be useful for BT. I believe they are leaning towards 802.1x,
but what other choices do they have (other than PPP)?

-Basavaraj