RE: [Pana] on PANA's requirement to use the unspecified address

Soliman Hesham <H.Soliman@flarion.com> Tue, 11 November 2003 10:16 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26064 for <pana-archive@lists.ietf.org>; Tue, 11 Nov 2003 05:16:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVZ4-0001GS-Kk; Tue, 11 Nov 2003 05:16:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJVYN-0001Fj-1J for pana@optimus.ietf.org; Tue, 11 Nov 2003 05:15:19 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26045 for <pana@ietf.org>; Tue, 11 Nov 2003 05:15:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJVYJ-0000iO-00 for pana@ietf.org; Tue, 11 Nov 2003 05:15:15 -0500
Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AJVYJ-0000i9-00 for pana@ietf.org; Tue, 11 Nov 2003 05:15:15 -0500
Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <WGJRFQXC>; Tue, 11 Nov 2003 05:14:38 -0500
Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922EBE@ftmail.lab.flarion.com>
From: Soliman Hesham <H.Soliman@flarion.com>
To: 'Prakash Jayaraman' <prakash_jayaraman@net.com>
Cc: 'Alper Yegin' <alper@docomolabs-usa.com>, Thomas Narten <narten@us.ibm.com>, pana@ietf.org
Subject: RE: [Pana] on PANA's requirement to use the unspecified address
Date: Tue, 11 Nov 2003 05:14:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: pana-admin@ietf.org
Errors-To: pana-admin@ietf.org
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>


 > This email is in response to Hesham's suggestion about assigning IP
 > address before authentication phase:
 > 
 > A typical NAS deployed in a large network usually serves multiple
 > "Internet Service Providers" and "Application Service 
 > Providers". Every
 > ISP owns a collection of IP address pools. Each collection is usually
 > referred to as a "domain".  A number of ISP's may use a 
 > single address
 > space and hence a single routing context. Some NAS's support multiple
 > routing contexts in the same physical device to allow the use of
 > overlapping address spaces by multiple ISPs. (See the last paragraph
 > about Application Service Providers).
 > 
 > So, it is important for the NAS device to find out which ISP 
 > to allocate
 > the IP address from. 

=> Agreed. I also agree that this is a typical wholesale/retail
split scenario where the wholesaler would want to use 
the right address pool for the retailer and therefore
needs to know the client's id first. There is no dispute
with the scenario itself, the question is whether PANA
should be designed to do that as a default behaviour. 

If a certain optimisation requires that we require auth
before address allocation then it can be added to the 
base PANA. But having that as a default behaviour
introduces its own set of (significant) problems. 

The models you refer to do not use an upper layer auth
protocol (please correct me if I'm wrong here). The 
only ones that do (I've cited a couple) allocate addresses
first then authenticate. Why? because as Alper said "they
don't have a choice". I wonder whether we could "magically"
provide that choice, i.e. there is a cost involved. 

Hesham 


   For PPP users, this is done by looking 
 > at the FQDN
 > and associating the domain-part of it to an ISP.
 > 
 > DHCP based access does not have this concept. It is primarily for
 > host-configuration in a single routing context. All the 
 > hosts on a given
 > interface must use a single ISP (and hence a single routing 
 > context), if
 > they use DHCP.  Cable modem operators own the NAS device as well as
 > function as the only ISP. However, there are also wholesale models in
 > which the NAS device is owned by one entity and the Internet 
 > Service is
 > provided by multiple ISP's sharing the same NAS.
 > 
 > If there is a single NAS and a single ISP, 
 > address-depletion-based DoS
 > attack is equivalent to having a wrong-password.  If there 
 > are multiple
 > ISPs, the problem is more fundamental than that - NAS does not know
 > which address to choose. In addition, this choice has to be dynamic
 > (i.e. not statically configured) depending on the user's identity.
 > 
 > Extending the host-configuration a bit beyond IP address 
 > assignment, the
 > host should be configured depending on the user. A person usually
 > connects to a domain creating a login-session. The domain 
 > has IP address
 > pools, DNS servers, WINS servers, DHCP servers, email-server,
 > access-control-lists, firewall rules etc. etc. and these 
 > parameters are
 > specific to domains. NAS needs a way of figuring out the 
 > services to be
 > offered to a user and it uses FQDN today. To offer the services
 > successfully, host-configuration must be done after NAS 
 > performs a AAA
 > procedure.
 > 
 > - prakash
 > 
 > 
 > >
 > > Hesham
 > >
 > > PS: FWIW my cable modem  operator does exactly that, address
 > > assignment first, then login. I've also seen it wherever
 > > they have HTTP redirect used for authentication.
 > >
 > > _______________________________________________
 > > Pana mailing list
 > > Pana@ietf.org
 > > https://www1.ietf.org/mailman/listinfo/pana
 > 
 > 
 > _______________________________________________
 > Pana mailing list
 > Pana@ietf.org
 > https://www1.ietf.org/mailman/listinfo/pana
 > 

_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana