Subject: Question for vendors and operators

From: <[email-masked]>
Date: Wed, 3 Apr 2002 19:00:38 -0600

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: Reinaldo Penno <[email-masked]>
Date: Thu, 4 Apr 2002 09:57:56 -0800 (PST)

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

> to doing authentication via PPPoE or PPP or 802.1x

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

---

From: Prakash Jayaraman <[email-masked]>
Date: Thu, 11 Apr 2002 15:42:38 -0700

> to doing authentication via PPPoE or PPP or 802.1x or via http

In our NAS environment, we are looking for a solution to authorize,
authenticate a user (a person) before we allow him/her to use 
the network. Note that NAS supports multiple providers for
customers and so it supports dynamic provider selection. It
also supports multiple contexts (multiple address spaces,
overlapping or not) for administrative, billing and security 
reasons.

The medium between the users and NAS is either P2P (traditional
dialup lines, DSL, ATM links etc.) or broadcast (cable-modem
network).

1) PPP - currently widely in use.
   * Only one PPP connection is allowed per link.
   * NAS authenticates the user using CHAP and assigns
       IP address using IPCP.
   * CHAP phase is also used to do "dynamic provider selection".

2) To support more than one user,
   * If you need to support more than one user with just PPP, 
     NAT gets used at the customer-premises. CPE equipment
     to do this are widely available these days. 
   * PPPoE 
       - supports more than one user.
       - DISCOVERY stage also works as a signalling protocol to perform
         dynamic service selection. But in our implementation, we do not
         use this feature. We prefer to use out-of-band means to 
         do service selection.

3) DHCP - not very widely in use.
   * NAS acts either as DHCP relay agent or as server (depending on the
     configuration).

Problems with PPPoE:
   Have to install a special client on the CPE and it creates management
     trouble as it is not part of most clients.
   More software layers on the NAS - we would like to use less software
     if possible. 
   Hardware switching becomes very tricky due to the extra 6-byte
header.
     (Part of the reason is that when encapsulated in LLC-AAL5, the
      destination IP address is on the second cell. This is not an
      issue if we don't have this 6-byte header).
     Such tricks are not trivial and result in use of additional
hardware
     resources. The solutions that we have are not easy to do and we
     prefer not having to go through such issues in the next-gen 
     hardware.
   Since we are using PPPoE only to support multiple-clients at the 
     customer-side, I prefer the customers use PPP+NAT to PPPoE or
     DHCP.
   
Problems with PPP:
   We are using PPP for AAA and address assignment only, in a NAS
     application.
   We only support IP within PPP. Support for other protocols is of
   no practical use for the NAS application today.
   That being the case, we would like to support IP directly, but it
   is not that big a deal to support PPP (with or without NAT) and 
   we don't intend to stop supporting it. 

   PPP supports assignment of IP-address, DNS and WINS addresses only.
   Sometimes, we need to support some more configuration parameters
   for which we think DHCP would be the way to go. 

   I don't think we will remove support for PPP even in a distant
   future, but we would like to discontinue support for PPPoE as soon
   as possible.

   Supporting PPP+NAT, requires intelligent CPE throughout the
     life of the connection. This could become a major issue
     for network and user administration.

Problems with DHCP:
   * Does not have the authentication mechanism and so can't use it
     in untrusted environment. But then there are ISPs already
     that have begun to use DHCP on P2P links for the sole reason
     that there is absolutely no administrative overhead.
   * We are being asked to AAA the users before
     network-access is granted. We are using a proprietary application
     layer method to do so and that is not simple either and it does not
     seem to work in all situations.

Problems in a network with statically assigned IP-address:
   * We would like to AAA the users before the machine is
     allowed to access the network.
   * Application layer proprietary AAA mechanism might work,
     but we would like to see a standard solution.

AAA-ing the machine using layer-2 parameters is probably useful,
but it is not sufficient for providing user-specific services. Any
AAA phase before network-access (with and without the use of DHCP, 
before or after DHCP if DHCP is used) will be useful for our
application. 

Any such mechanism should provide an NAS with both of the following.
 * dynamic service-provider selection (for IP-address assignment).
 * complete layer-2 independent two-way AAA mechanism.

- prakash