IETF Logo Mail Archive

Re: [Pana] Mobility Handling in PANA

Julien Bournelle <Julien.Bournelle@int-evry.fr> Thu, 15 July 2004 09:19 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05688 for <pana-archive@lists.ietf.org>; Thu, 15 Jul 2004 05:19:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl2Ex-0003ui-Rk; Thu, 15 Jul 2004 05:09:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl28n-0002JL-BN for pana@megatron.ietf.org; Thu, 15 Jul 2004 05:03:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05050 for <pana@ietf.org>; Thu, 15 Jul 2004 05:02:54 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl28k-0004PO-Ph for pana@ietf.org; Thu, 15 Jul 2004 05:02:54 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl27j-00044g-00 for pana@ietf.org; Thu, 15 Jul 2004 05:01:52 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx with esmtp (Exim 4.12) id 1Bl26b-0003Px-00 for pana@ietf.org; Thu, 15 Jul 2004 05:00:41 -0400
Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by smtp2.int-evry.fr (Postfix) with ESMTP id CF31D2FD42; Thu, 15 Jul 2004 11:00:06 +0200 (CEST)
Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1Bl24f-000ELJ-U8; Thu, 15 Jul 2004 10:58:41 +0200
Date: Thu, 15 Jul 2004 10:58:41 +0200
From: Julien Bournelle <Julien.Bournelle@int-evry.fr>
To: Giaretta Gerardo <Gerardo.Giaretta@TILAB.COM>
Subject: Re: [Pana] Mobility Handling in PANA
Message-ID: <20040715085841.GQ45745@ipv6-5.int-evry.fr>
References: <625BE97BF4795E43970345790166B9BCD4DF41@EXC2K01B.cselt.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <625BE97BF4795E43970345790166B9BCD4DF41@EXC2K01B.cselt.it>
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 4.5, autolearn=not spam, BAYES_00 -4.90)
X-MailScanner-From: jb@ipv6-5.int-evry.fr
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Cc: Alper Yegin <alper.yegin@samsung.com>, yohba@tari.toshiba.com, pana@ietf.org
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
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>
Sender: pana-bounces@ietf.org
Errors-To: pana-bounces@ietf.org

Hi,


see comments inline,

On Wed, Jul 14, 2004 at 09:50:50AM +0200, Giaretta Gerardo wrote:
> > 
> > > Thus we propose this:
> > > 
> > > 
> > >      PaC           nPAA              pPAA
> > >      ----------------------------------------
> > >            PDI
> > >       -------------->
> > >            PSR
> > >      <---------------
> > >           PSA [old Session-ID, Nonce, CTAR]
> > >       --------------->
> > > 
> > >                            CT-Request
> > >                         -------------->
> > >                                CTD
> > >                         <--------------
> > > 
> > >       PBR[new Session-ID, Key-Id, Nonce, PPAC, MAC]
> > >      <-------------
> > >       PBA[new Session-ID, Key-Id, PPAC, MAC]
> > >       ------------->
> > 
> > This is the flow I had in my mind, but I don't see the need 
> > to have an explicit CTAR AVP in the PSA.
> > 
> > Looking at the draft, CTAR carries:
> > - PaC's address. Why do we need this? The Pac is identified 
> > with its session id.
> > - PAA's address. I don't think we need this either. Session 
> > id reveals the ID of the pPAA. It's just a matter of mapping 
> > that to an IP address (use DNS).
> > - Authorization token. MAC AVP already does the job.
> >
> 
> CTAR (and thus a CTAR AVP in our draft) is always required by CTP as
> specified in draft-ietf-seamoby-ctp-10.txt. It is not possible to use
> CTP without sending a CTAR message both in predictive and reactive mode.
> This is because in CTP the transfer is authorized trough the
> authorization token that is shared between pAR and MN. However, I
> completely agree with you that the information carried by CTAR can be
> obtained by other means as you stated above. 
> 
> I think here the issue is whether we want to apply the Seamoby CTP or to
> define a context transfer mechanism only for PANA (which exploits PANA
> features).

I would like to add that we need CTAR message if we want to support
predictive handover. 


-- 
julien.bournelle@int-evry.fr

_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana

v2.23.0 | Report a Bug | By Email