Re: MIP6-AAA Fwk 3 (was RE: [Mip6] mip6-aaa frameworks)

"Mohan Parthasarathy" <mohanp@sbcglobal.net> Wed, 16 February 2005 20:04 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 PAA13826 for <mip6-web-archive@ietf.org>; Wed, 16 Feb 2005 15:04:36 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Vko-0007zA-8u for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 15:26:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Uyo-0007Ou-9Z; Wed, 16 Feb 2005 14:36:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Szn-0003xs-Ct for mip6@megatron.ietf.org; Wed, 16 Feb 2005 12:29:51 -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 MAA29708 for <mip6@ietf.org>; Wed, 16 Feb 2005 12:29:48 -0500 (EST)
Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1TL2-0002X1-Gt for mip6@ietf.org; Wed, 16 Feb 2005 12:51:52 -0500
Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 16 Feb 2005 17:29:46 -0000
Message-ID: <004601c5144d$1c5866c0$861167c0@adithya>
From: Mohan Parthasarathy <mohanp@sbcglobal.net>
To: Alper Yegin <alper.yegin@samsung.com>, mip6@ietf.org
References: <163001c51441$2955dd50$291d9069@sisa.samsung.com>
Subject: Re: MIP6-AAA Fwk 3 (was RE: [Mip6] mip6-aaa frameworks)
Date: Wed, 16 Feb 2005 09:29:46 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
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: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit

 
> > > 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.
> > >
> > Can you elaborate on the complexity issue ?
> 
> - By the time network access AAA is executed:
>   - MN must know its HA (may not be possible if the HA 
>     discovery is done after the access is authorized -- e.g., 
>     DHCP, DNS-based schemes)

The access network most likely allows DNS requests to pass through.
Perhaps i am biased by how WLAN hotspots work today..

>   - MN must know its care-of address. (may not be possible if the
>     CoA allocation depends on the network access authentication.

Good point. 

> - AAA_home server must decapsulate the BU and forward it to the HA. What
> is the source address in BU packets? (may be a ingress-filtering
> concern).
> - The BUack from the HA: is it sent back to MN directly, or forwarded to
> AAA_home and piggybacked in the AAA response to MN?

These two steps are part of Diameter Mobile IPv4 application today and don't
know how to asses their complexity. And you need this as part of option 4 also.

> - The results of mobility management and access authorization may need
> to be coordinated? What happens when one succeeds and other fails?
> - What is the transport for BU? EAP, or EAP lower layers, PPP+RADIUS, ?
> 
You mean the transport on the access link (between MN and access router).
Yes, that needs to be decided. 

> I don't claim these are impossible to answer, but clearly each answer
> would lead to additional complexity.
> 
My concern is on how we assess that something is complex :-)

-mohan

> Alper
> 
> 

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