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
- [Pana] on PANA's requirement to use the unspecifi… Thomas Narten
- Re: [Pana] on PANA's requirement to use the unspe… Mohan Parthasarathy
- Re: [Pana] on PANA's requirement to use the unspe… Alper Yegin
- RE: [Pana] on PANA's requirement to use the unspe… Soliman Hesham
- Re: [Pana] on PANA's requirement to use the unspe… Alper Yegin
- Re: [Pana] on PANA's requirement to use the unspe… Jari Arkko
- RE: [Pana] on PANA's requirement to use the unspe… Soliman Hesham
- Re: [Pana] on PANA's requirement to use the unspe… Alper Yegin
- Re: [Pana] on PANA's requirement to use the unspe… Alper Yegin
- Re: [Pana] on PANA's requirement to use the unspe… Prakash Jayaraman
- RE : [Pana] on PANA's requirement to use the unsp… MORAND Lionel FTRD/DAC/ISS
- Re: [Pana] on PANA's requirement to use the unspe… Mohan Parthasarathy
- RE: [Pana] on PANA's requirement to use the unspe… Soliman Hesham
- Re: [Pana] on PANA's requirement to use the unspe… Thomas Narten