Subject: RE: Question for vendors and operators

From: MORAND Lionel FTRD/DAC/ISS <[email-masked]>
Date: Fri, 5 Apr 2002 16:06:34 +0200

Hi,

Considering the various studies on the various inter-technology mobility
scenarios, and in particular the ongoing work on 3GPP/WLAN interworking
specifications (works have start in Juan.01), I think that the work done in
PANA WG will bring the generic block needed to build a more global solution
for inter-access mobility, taking into account mobility management,
accounting, customized service offerings, etc. 

Indeed mobility management is first and foremost based on the ability to
authenticate the same user roaming between access points. Of course, various
authentication schemes already exist according to the access technology
and/or the access network considered, and they are sometimes L2-dependent.
This causes problems when you take into account the inter-access mobility
context.

In the 3GPP/WLAN interworking for instance, one option for providing a
common authentication mechanism is to re-use the SIM-based architecture in
the WLAN access network and to adapt consequently 802.1x to support the 3GPP
authentication procedures. However, another alternative is to define and
introduce a new mechanism, L2-agnostic and being so generic: it will be
useful for the specific case of 3GPP/WLAN interworking and for any other
type of interworking (3GPP/ADSL for instance) without requiring heavy
investigation/deployment cost overrun. And the scope of PANA seems to fulfil
such requirements.

From a operator/ISP point of view, PANA will then enable a global service
offering, whatever the access technology considered (WLAN, LAN, ADSL, GPRS,
etc.), based on a generic user information profile with universal user
security parameters (IDs, username/password, etc).

To conclude, I think that a generic solution is definitely needed and that
the PANA WG seems to be on the right track.

Regards,

Lionel Morand

France Telecom R&D
+33145296257
[email-masked]

-----Message d'origine-----
De : Reinaldo Penno [mailto:[email-masked]]
Envoyé : jeudi 4 avril 2002 19:58
À : [email-masked]; [email-masked]
Objet : Re: Question for vendors and operators

without my co-author/presenter hat...

I've been involved in my (big) share of all kinds of
broadband wireline (some wireless) deployments: cable,
adsl, ethernet, mmds.

IMO the value that PANA brings is twofold: it provides
ONE authentication method, and allows carriers to
provide personalized services based on an access
agnostic authentication method through
username/password.

More on this.. 

One of the requirements that I get 9 out of 10 times
is that the provider/ISP wants some form of
authentication/login (specially independent of the
access technology). That's how they bill users, gather
users statistics, make partnership with content
providers, adequate their portals, provide "open
access" to several ISPs, etc, etc

Some cable/adsl providers deploy PPPoE/PPPoA *just
because* of the authentication/login capabilities. If
there was a layer 3 method to get authentication
(username/password) they would rip PPPoE/PPPoA out of
their networks today. 

They need some username/password in order to provide
any of the so-called personalized service like content
filtering, page assembly, news, etc

Last but not least some carriers that I've worked with
provide adsl and cable or wireless and adsl and they
would like ONE authentication method, one client to
distribute if needed. 

Anyway, I see PANA solving a real world problem that
was long due, which is different from some other WGs, 
as the saying goes (ask you to get sick in order to
abe able to give you medicine) 

regards,

Reinaldo

--- [email-masked] wrote:
> 
> Hello,
> 
> We would like to hear from vendors and operators if
> PANA would be
> something that solves a problem in their networks
> and hence would like
> to see it standardized. 
> Would PANA be something that operators would deploy
> as an alternative
> to doing authentication via PPPoE or PPP or 802.1x
> or via http
> redirect? 
> 
> -Basavaraj
> 

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

---

From: "Wang, Cliff" <[email-masked]>
Date: Mon, 8 Apr 2002 15:47:26 -0000

I work for an IP service software company. Our product enables service
providers to deploy IP based service via policy based provisioning.
Currently we support remote access IP service. Our vision is to support a
broad range of remote access technology. We view PANA as a future IP service
we can deploy and manage when the technology is implemented in the boxes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2002 8:01 PM
To: [email-masked]
Subject: Question for vendors and operators

Hello,

We would like to hear from vendors and operators if PANA would be something
that solves a problem in their networks and hence would like to see it
standardized. 
Would PANA be something that operators would deploy as an alternative to
doing authentication via PPPoE or PPP or 802.1x or via http redirect? 

-Basavaraj

---

From: [email-masked]
Date: Tue, 9 Apr 2002 01:20:46 +0900

Hi,
We are a company specializing in AAA for wired & wireless network, based in
seoul,korea.
We plan to offer 802.1x soultion(Funk Steel betled RADIUS) to major
carriers such as Korea Telecom, Dacom and Hanaro, among others.
I think PANA BURP is much better than 802.1x since it is Layer2
independent.
Definitely, PANA would be a viable soultion to PPPoE and 802.1x, at least
in korea.

rgds,

Sun Kim
VP / Business Development
Cloudwave Inc. Seoul
82-2-501-2552(office)
82-16-358-6317(mobile)

                    "Wang, Cliff"                                                                                  
                    <CWang@smartpi       수신인:       "[email-masked]'" <[email-masked]>,  
                    pes.com>              [email-masked]                                              
                                         참조인:       "Beadles, Mark A" <[email-masked]>                 
                    2002-04-09           제목:          RE: Question for vendors and operators                     
                    12:47 AM                                                                                       

broad range of remote access technology. We view PANA as a future IP
service

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 8:01 PM
To: [email-masked]
Subject: Question for vendors and operators

Hello,

-Basavaraj

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 8 Apr 2002 14:36:00 -0400

John,

I apologize because I will not be able to give you detailed answers since
Flash-OFDM is not yet a public technology (which is another reason I do not
like wearing my vendor's hat here). In terms of authentication/encryption we
have similar needs to any other wireless link layer (e.g.: 802.11). The only
difference is that instead of Access Points you get Access Routers with
wireless interface (we call them RadioRouters). I claim that PANA can cover
our needs and at the same time cover the end node's needs across multiple
technologies.

George
-----Original Message-----
From: John Vollbrecht [mailto:[email-masked]]
Sent: Friday, April 05, 2002 10:18 PM
To: George Tsirtsis
Cc: [email-masked]'; [email-masked]
Subject: Re: Question for vendors and operators

Hi George -

Thanks for sending this.  I do have some clarifying questions below -- John

George Tsirtsis wrote:

> All,
>
> I have been encouraged to give Flarion's opinion/use of PANA which
requires
> me to wear my vendor's hat...which feels a bit uncomfortable on an IETF
> mailing list... Still, I endure...
>
> /--------------------------...
> Here at Flarion we have developed a new link layer that we call
Flash-OFDM.
> This is a wireless link layer designed for Wide Area Networks (WAN),
> cellular-type deployment and it is designed specifically for *data* i.e.:
> The Internet
>
> The technology is designed to localized all L2 effects to the air link
ONLY
> i.e.: between the mobile node and an Access Router that each include a
> Flash-OFDM interface, while the rest of the network is simply IP routers
and
> back end systems. Each Flash-OFDM interface on the Access Router/base
> station is a cell or sector of a cell.

To be sure I understand - does this mean that an L2 connection is
established
prior to authentication? Does each L2 connection uses a unique cell or
sector of
a cell?

>
>
> We happen to run IP directly over Flash-OFDM so we DO NOT use PPP, while
we
> use Mobile IP for mobility management. NOTE that due to the one-hop nature
> of the link layer, there is no backend link layer infrastructure to
protect
> using link layer security. Still, since this is intended for wide-area
> deployment by operators we need to be able to authenticate end users and
we
> also need to encrypt the airlink.

Is authentication after L2 connection ok or does the L2 connection need to
be
authenticated?  Is encryption done at L2?  Is an authorization dialog needed
to
support the link encryption?

>
> Clearly, we can use yet another link layer specific mechanism to carry
> whatever authentication we decide to use, but given the single hop focus
of
> this L2 technology we gain nothing by doing it this way. On the other hand
> Flash-OFDM and our mobility management system is ideal for
inter-technology
> handoffs (e.g.:Flash-OFDM to 802.11), and by using link layer
> authentication, we need two different authentication transports for two
> different technologies.
>

Are you talking here about link encryption or authentication dialog?  It
would
seem Flash-OFDM is already a different transport technology, so how would
PANA
play here?

>
> So, if PANA existed today we would consider very seriously to adopt it and
> so allow an operator to provide a single authentication client that can be
> used for our own technology as well as for roaming to/from other
> technologies. PANA would offer our customers (operators) one piece of
client
> authentication code and the ability to have exactly the same per user
> settings and behavior, whatever the underlying technology.

This sounds more like what you would like is a Client interface that works
accross all technologies - with a common authentication technique.  What
role
would you see PANA playing? Would it do user authentication?  L2 Data
encryption?

>
> \-------------------------...
>
> Removing my vendor's hat...aahh...feels better...
>
> I also believe that the Internet must have a way to authenticate end
points
> to control points (especially the access router) in the infrastructure and
> vice versa.  This is a fundamental function that is needed, no matter what
a
> single vendors wants.
> Regards
> George
> Sent: Thursday, April 04, 2002 2:01 AM
> We would like to hear from vendors and operators if PANA would be
> something that solves a problem in their networks and hence would like
> to see it standardized.
> Would PANA be something that operators would deploy as an alternative
> to doing authentication via PPPoE or PPP or 802.1x or via http
> redirect?
>
> -Basavaraj

---

From: <[email-masked]>
Date: Mon, 8 Apr 2002 20:00:18 -0500

And all we are trying to do in this WG is to develop a solution
that would basically enable what you describe below. So I do
believe there is a real need for such a solution to be standardized
in the IETF.

-Basavaraj

> From: ext Robert Boxall [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 2:18 PM
> Subject: RE: Question for vendors and operators
> 
> 
> I have developed and have had implemented an EAPoUDP system that is in
> use in several locations in the states. This works between our public
> access gateway and client application (either windows or java in
> webpage).
> 
> This is fully compatible with funk and several other major RADIUS
> servers and provides a clean layer 3 solution. We took this 
> approach as
> 802.1x was/is a nightmare to use and a somewhat 802.11 centric kludge,
> we also wanted layer 2 agnostic solution. We have also added several
> nice features such as the ability to push URLs to users. We also have
> an IPSEC tunnel ability with AES that we developed. Keys are generated
> after mutual authentication.
> 
> We found many problems with 802.1x and our EAPoUDP system during this
> exercise and I intend to fix this on the second iteration of my work.
> 
> Robert
> 
> 
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, April 08, 2002 11:21 AM
> To: Wang, Cliff
> Cc: [email-masked]; "Beadles, Mark A"@smartpipes.com;
> [email-masked]
> Subject: RE: Question for vendors and operators
> 
> 
> Hi,
>                     <CWang@smartpi       수신인:
> "[email-masked]'" <[email-masked]>,  
> Currently we support remote access IP service. Our vision is 
> to support
> a
> something

---

From: <[email-masked]>
Date: Tue, 9 Apr 2002 17:34:10 -0500

>Let me confirm my understanding of what you have stated by rephrasing.
>
>In situations that call for the use of PPP,
>the Authentication Protocol is:  (PAP), CHAP, EAP, etc.
>The protocol that carries the authentication protocol is:  PPP LCP
>
>In situations that do not call for the use of PPP, 
>the Authentication Protocol is:  EAP, etc.
>The protocol that carries the authentication protocol is:  PANA

Yes. 

>
>So PANA proposes a protocol for carrying authentication for network access
>_in non-PPP scenarios_.  Is this an accurate statement?

Yes.... But remember that the non-PPP here implies only the
authentication aspect of PPP. So there are two scenarios that should
be considered:
1. A client connects to the network via PPP and authenticates at L2
   using PPP LCP. The network in addition may also require an L3
   authentication for various reasons (other than network access
   control). If that is the case PANA carries the authentication
   protocol.
2. Client connects to the network via PPP. Authentication for network
   access is done above L2. PANA would be the protocol that carries the
   authentication protocol.

PPP is one example. 802.1x could be another. 
At no place is the suggestion that PANA replace PPP LCP or 802.1x.

>
>+ Mark Anthony Beadles  + [email-masked] +
>+       Chief Architect + SmartPipes, Inc.        +
>+   Vox 614.923.5657    +     Fax 614.923.6299    +
>
>

-Basavaraj