Subject: RE: PANA and handover

From: <[email-masked]>
Date: Wed, 12 Mar 2003 14:23:27 +0200

Hanness and Julien, 

I think this is a reasonable approach. Together with CT, the AAA session must be updated also. We have a draft about this:

	draft-liu-aaa-diameter-session-mobility-00.txt

Any comments are welcome to the aaa wg mailing list.

BR,
- Dan

> -----Original Message-----
> From: ext Tschofenig Hannes [mailto:[email-masked]]
> Sent: 12 March, 2003 14:14
> To: 'Julien Bournelle'; Hannes Tschofenig
> Cc: [email-masked]
> Subject: RE: PANA and handover
> 
> 
> hi Julien!
> 
> please see my comments inline:
> 
> - snip - 
> 
> >  
> > > for (b) an interaction with a intra-domain mobility 
> > protocol is possible.
> > > the protocol machinery is very simple. further work on this 
> > topic requires
> > > that we make progress on the pana protocol first.
> > 
> > ok, basically, I thought that it could be a flag in the 
> > PANA_start from the PaC
> > indicating that it has been previously authenticated  and 
> information
> > permitting to the PAA to be sure of this. Sure there are problems 
> > concerning EP configuration, session key etc... and what 
> > information the PaC
> > must furnish. 
> 
> if we provide some interaction with the intra-domain mobility 
> protocol then
> it would be nice to have some sort of context transfer. thereby it is
> possible to make use of work done in the seamoby group to 
> forward context
> transfer information from the old access router to the new 
> one. the context
> which needs to be transferred is 
> - pana sa 
> - maybe device identifier information (needs to be adjusted 
> after mobility)
> - ipsec (if ipsec sa is established after pana exchange)
> 
> to specify exactly what information needs to be transferred 
> (at this stage)
> is hard since we haven't discussed all details of a pana 
> protocol yet. hence
> i guess this is subject for future work. we should, however, 
> keep it in
> mind. 
> 
> if no such context transfer procedure is available then the 
> best which can
> be provided is communication to the local aaa server (instead 
> a full aaa
> roundtrip to the home aaa server). this is also not too bad. 
> 
> i think that other proposals using tokens, tickets, cookies 
> etc., which have
> been considered in the environment of seamoby, are less 
> favorable since they
> require some information to be exchanged to the end host 
> (over a possible
> scarce radio resource) and in most cases provide the same 
> functionality as
> ct (some even provide less). 
> 
> i fully agree with you that some attention should also be 
> paid to mobility
> environments where performance (computational, bandwidth and latency)
> matters. with respect to the refresh messages i guess we have already
> thought about mobility handling a bit. 
> 
> what do you think? does this sound like a resonable approach?
> 
> ciao
> hannes
> 
> > 
> 
>

---

From: <[email-masked]>
Date: Wed, 12 Mar 2003 15:49:22 -0600

Hello,

While this optimization helps in re-establishing the session fairly
quickly, this is a feature that is not immedialtely required. This is
the first sign of feature-creep into the protocol. I think the critical
thing for this WG to do now is to get a working solution out ASAP. And
after that we could look at other things that would be nice to have in 
the protocol.

-Basavaraj

> 
> Hi,
> 
>  If a PaC do a handover and change of AP (e.G. in case of 802.11b)
> it could change of PAA and EP. In such a case the new PAA will
> try to authenticate him whereas it has already been authenticated
> to the previous PAA. MAybe it could be a benefit to add the abality
> to the PaC to inform the new PAA of the previous PAA. As such the 
> new PAA could retrieve information from previous PAA without 
> reauthenticate the PaC. 
> 
> [email-masked]
> 
>