Re: [Mip6] mip6-aaa frameworks

"Junghoon Jee" <jhjee@etri.re.kr> Tue, 15 February 2005 18:24 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 NAA07425 for <mip6-web-archive@ietf.org>; Tue, 15 Feb 2005 13:24:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17hu-00088e-Ip for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 13:45:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15L2-0005m5-0Q; Tue, 15 Feb 2005 11:14:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D14gG-0001ob-O7 for mip6@megatron.ietf.org; Tue, 15 Feb 2005 10:32:05 -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 KAA13561 for <mip6@ietf.org>; Tue, 15 Feb 2005 10:32:02 -0500 (EST)
Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D151J-0007tP-Ao for mip6@ietf.org; Tue, 15 Feb 2005 10:53:50 -0500
Received: from FlyToWorld ([192.168.250.19]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 00:32:12 +0900
Message-ID: <001301c51373$6fb1feb0$13faa8c0@FlyToWorld>
From: Junghoon Jee <jhjee@etri.re.kr>
To: Julien Bournelle <julien.bournelle@int-evry.fr>, Alper Yegin <alper.yegin@samsung.com>
References: <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com><11d201c51329$c83d61e0$291d9069@sisa.samsung.com> <20050215110504.GD6344@ipv6-3.int-evry.fr>
Subject: Re: [Mip6] mip6-aaa frameworks
Date: Wed, 16 Feb 2005 00:31:36 +0900
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 15 Feb 2005 15:32:12.0437 (UTC) FILETIME=[850DD450:01C51373]
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: mip6@ietf.org
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>
Content-Type: multipart/mixed; boundary="===============0896010096=="
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 2.2 (++)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0

Hi Julien and ALL.
Please see my comments inline.

> > 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
> 
> we can add:
> draft-jee-mip6-bootstrapping-pana-00.txt

Thank you for pointing out this.

>> > 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.
> 
> I'm not sure that this is a particular framework since the BU is carried
> in the AAA protocol. This piggybacking can be done with Framewrok 1 and
> 2.

Right, I agree with you.
This is not a separate framework but a possible optimzation case about framwork 1 and 2.

One more thing about this.
Piggybacking the BU meessage to the AAA request was previously proposed by
the previous expired draft, draft-le-aaa-diameter-mobileipv6-03.txt.
This approach inherits this feature from the previous MIPv4 + AAA work which can be found in the draft-ietf-aaa-diameter-mobileip-20.txt
But in case of MIPv6, the feasibility of the piggybacking the BU message to the AAA request depends on the varying situation.
As one example about this, 
In case of bootstrapping, if we use the IPsec SA to protect the BU following the RFC 3775, 
it is not possbile to piggybacks the BU to the AAA request message because the IPsec SA can be setup after the
bootstrapping process.
I think configuration of a CoA and IPsec SA can be an issue related with this.

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