Re: Manual network access logins (Was: Re: [RAM] The mapping problem: rendezvous points?)

Jari Arkko <jari.arkko@piuha.net> Wed, 23 May 2007 08:30 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmF7-0000CJ-2t; Wed, 23 May 2007 04:30:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmF6-0000CD-7t for ram@iab.org; Wed, 23 May 2007 04:30:48 -0400
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqmF4-0003lI-Q1 for ram@iab.org; Wed, 23 May 2007 04:30:48 -0400
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2FECF1986A3; Wed, 23 May 2007 11:30:46 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E716F1986A2; Wed, 23 May 2007 11:30:45 +0300 (EEST)
Message-ID: <4653FBB5.5000408@piuha.net>
Date: Wed, 23 May 2007 11:30:45 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Manual network access logins (Was: Re: [RAM] The mapping problem: rendezvous points?)
References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <B79E458E-F18C-4617-B953-F311E5623E9A@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <A590D37E-7DEC-4695-998E-DA12A205F306@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> <20070518180916.GF69215@Space.Net> <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> <464E9D96.8070207@piuha.net> <4652E178.5080209@gmail.com> <4652FC8D.3090600@piuha.net> <6966E31B-F1D4-434B-9649-6C2B4B614F13@cisco.com> <4653F4AB.4070006@gmail.com>
In-Reply-To: <4653F4AB.4070006@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: Tony Li <tli@cisco.com>, ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Brian, Tony,
>> I'm not an expert in this area, but isn't this type of thing already
>> addressed by 802.1x?

Yes, and 802.11i, EAP, RADIUS, built-in facilities in
802.16 and [23]G* link layers, many different optimizations
of the various parts of the process, and so on.

>>
>> Even if not, it's not hard to see the we will want to have automated
>> authentication mechanisms that allow us to change networks without
>> manual intervention.  
>
> But if the authentication is done for an ID instead of a locator,
> the AAA problem is somewhat transformed, I think.
>
>> So while we might not be there yet, this is a AAA problem that
>> someone should go off and solve.  The network architecture itself
>> should still allow for these transitions to be as seamless as
>> possible, including session migration.
>
> Indeed. Which, for real time apps, means that the latency for any
> AAA handoff needs to be pretty small. And maybe basing it on an
> invariant ID would help with that.

We need to be careful with the word identifier here. Currently,
network access is mostly based on either payment or subscriber
identity. But those identities are very different from IP layer
identifiers. Of course, the network access and IP layer setup
processes can be (and has been) tied together for optimization
reasons. Hopefully such optimizations do not create a 1-1
permanent binding between the subscriber identities and your
IP layer addressing or your future IP layer identifiers. This
would be bad for privacy reasons, for instance.

Jari


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram