Re: [Mip6] mip6-aaa frameworks

"James Kempf" <kempf@docomolabs-usa.com> Tue, 15 February 2005 20:06 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03894 for <mip6-web-archive@ietf.org>; Tue, 15 Feb 2005 15:06:07 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Ib-0007xS-N3 for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:27:57 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18Yu-0007vv-38; Tue, 15 Feb 2005 14:40:44 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D175E-0001K6-V1 for mip6@megatron.ietf.org; Tue, 15 Feb 2005 13:06:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01533 for <mip6@ietf.org>; Tue, 15 Feb 2005 13:05:53 -0500 (EST)
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17QD-00069M-4w for mip6@ietf.org; Tue, 15 Feb 2005 13:27:43 -0500
Message-ID: <02e601c51389$21dd84a0$016115ac@dcml.docomolabsusa.com>
From: James Kempf <kempf@docomolabs-usa.com>
To: Alper Yegin <alper.yegin@samsung.com>, mip6@ietf.org
References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com>
Subject: Re: [Mip6] mip6-aaa frameworks
Date: Tue, 15 Feb 2005 10:06:47 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Content-Transfer-Encoding: 7bit
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Content-Transfer-Encoding: 7bit

Hi Alper,

Overall comment:

I think this is a good way of classifying the proposed solution space, but I
like the scenario approach in draft-giaretta-mip6-aaa-ha-goals better for
classifying the problem space. I think what we need now is some matching of
solutions to problem space, to see where there are gaps or overlaps.

Specific comments below.

>
> This is an attempt to enumerate possible MIP6-AAA frameworks, and start
> discussions on for which one(s) IETF shall pursue standardization.
>
> Framework 1:
> ------------
> Using network access AAA to deliver MIP6 configuration parameters from
> the AAA server to the MN.
>
> MIP6 configuration is directly delivered from the AAA server to the MN
> during network access AAA, in-band with the authentication (e.g.,
> transported by EAP or EAP methods).
>
> Related I-Ds:
>
> draft-giaretta-mip6-authorization-eap-01
> draft-le-aaa-mipv6-requirements-03
> draft-ohnishi-mip6-aaa-problem-statement-00
>
> Discussion:
>
> The end2end transport between the AAA and the MN is the key. Use of EAP
> for this somewhat network access unrelated "configuration" is not
> recommended as far as I understand. One can design his own EAP method to
> do that, yet that would have limited applicability.
>
>
> Framework 2:
> ------------
> Using network access AAA to deliver MIP6 configuration parameters from
> the AAA server to the NAS. It is assumed that parameters will be
> delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA,
> etc.)
>
> Related I-Ds:
>
> draft-chowdhury-mip6-bootstrap-radius-00
> draft-jang-dhc-haopt-00
>
> Discussion:
>
> This is similar to NAS learning the IP address for the connected host
> via RADIUS, and delivering it to the host via DHCP.
>
> James had a comment regarding not having to support intra-operator
> interoperability. I think regardless of the deployment, interoperability
> between vendors is the important. Also, I was not sure on the complexity
> argument.
>

Consider the following. Suppose RADIUS is used to transfer operator A's HA
addresses from operator A's AAA server to operator B's NAS. First question
is whether the addresses are delivered every time a roamed host makes a DHCP
request for the HA address? If not and there is any caching going on, then
the addresses could get stale. Second question is how the NAS differentiates
which home operator to ask for the addresses? Presumably an NAI but is that
separate or combined with DHCP? This is a big change in the basic IETF DHCP
architecture, IMHO. Managing DHCP configuration information within an
operator's domain is difficult enough.

> 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the
> suit.
>

Can someone provide more details here? As far as I know, in the current
3GPP2 MIP4 system, the PDSN is both home and foreign agent (please correct
if this is wrong), so I don't see how DHCP would come into the picture. How
are they planning on changing that for MIP6? Are they really planning on
distributing the addresses of home agents between operators or just within a
single operator?

        jak


> Framework 3:
> ------------
> Piggybacking MIP6 signaling (BU) with network access AAA. In-band with
> the network access authentication execution, the MN delivers
> (piggybacks) a BU to the AAA server. The AAA server may have to relay
> the BU to the HA (unless collocated).
>
> Related I-D:
>
> draft-le-aaa-mipv6-requirements-03
>
> Discussion:
>
> While the performance benefits are clear, limited applicability (not
> always the network access and mobility services are bundled) and
> complexity are concerning.
>
>
> Framework 4:
> ------------
> A backend AAA protocol is executed between the HA and the AAA server in
> response to the MIP6 signaling between the MN and the HA. Similar to the
> use of AAA protocols with MIPv4 co-located care-of address case.
>
> Related I-Ds:
>
> draft-giaretta-mip6-aaa-ha-goals-00.txt
> draft-yegin-mip6-aaa-fwk-00.txt
>
> Discussion:
> This one appears to be the most needed framework. It is assumed that MN
> already knows the HA address.
>
>
> Are there other frameworks to add?
>
> I am sure I have missed some references, please let us know which ones.
>
> Alper
>
>
>
>
> _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
>



_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6