Subject: [AAA-WG]: Invoking AAA during every handoff?

From: "Judy Fu" <[email-masked]>
Date: Mon, 14 Jan 2002 15:34:45 -0600

I need some help to clarify a question. Will AAA infrastructure need to
be invoked to reauthenticate a mobile node during every handoff when
previous authorization is still valid, if so, then a mobile node needs to
include
MN-AAA extension in registration request message everytime during
handoff ? In
draft-ietf-aaa-diameter-mobileip-08.txt, page 9, section 1.3, it says
"the first registration request from a mobile node will therefore cause
an AMR to be sent to its AAAF." So I guess the answer is yes. Then why
is it yes? I guess not for authentication reason because the MN can be
authenticated by HA with the valid MN-HA key. If so, then the only
reason may be that  the new FA needs to establish new AAA path in order
to collect accounting data. Am I correct on that?

Another quick question, in section 1.2 on page 7 of the same draft, it
says "In the event that the AMR generated by the FA is for a session
that has was previously authorized by the AAAH, it MUST include
Destination-Host AVP, with the identity of the AAAH." I am not clear how
the Destination-Host AVP will be used since later it says AMR message
might be received by a different AAAH during handoff. Will the different
AAAH have to send the message back to the original AAAH specified in
Destination-Host AVP, and if so, why?

Many thanks.
Judy

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Fri, 18 Jan 2002 15:04:36 -0600

Judy Fu [[email-masked]] wrote:
>Thanks for your reply. Then do you think MN has to go through AAA
everytime
>there is a handoff if without context transfer? 

Having the MN interact with AAA during the process of HO would be
quite inefficient. 
However it depends on the type of service. If you have a RT service
ongoing during a HO and if you have to go through AAA, the service
would be impacted. However if the application or service is non-RT,
delays that will result during the HO because of MN-AAA interaction
will be less critical.

>The AAA round trip delay may
>not be a big issue since MN has to send binding update to HA everytime
it
>does HO anyway as specified in "Mobility support in IPv6"
>draft. Unless

With Fast HO (specified in the Mobile IP WG), the need for having a BU
sent to the HA immediately after moving is reduced. So with fast HO,
the MN will continue to receive packets sent to it even if the BU to
the HA is delayed.

>there is way to eliminate the binding update/ack round trip delay for
HO.
>
>In "draft-ietf-aaa-diameter-mobileip-08.txt" section 1.3, support for
mobile
>IP handoffs, it says" Many FA do not communicate, which makes it quite
>difficult for AAA information to be exchanged between these entities.
>Therefore, it MUST be assumed that a FA is not aware that a
registration
>request from a mobile node has been previously authorized. The first
>registration request from a mobile node will therefore cause an AMR to
be
>sent to its AAAF". It seems to me it means by default (without context
>transfer or other enhancement) AAA will be invoked every time there is
a
>handoff. In addition, if without invoking AAA, i.e. there is no path of
new
>FA-AAAF-AAAH, it is not clear how the new FA report accounting data of
the
>MN to AAA infrastructure. I wonder if I understand correctly.
>
>Thanks again.
>Judy

-Basavaraj

---

From: "Faccin Stefano (NRC/Dallas)" <[email-masked]>
Date: Fri, 18 Jan 2002 18:00:51 -0600

Raj,

I agree with your comments below regarding the inefficiency of having to
re-authenticate the MN with the home domain at every HO. However, I
would like to add a comment.

> would be impacted. 

One could think that, for RT services and the cases where the MN
performs an HO to a domain where the new FA cannot talk to the old FA
for some reasons, the new FA allows the MN to keep the services for at
least the time it takes to re-authenticate the MN. If the authentication
succeeds, the service is not impacted. If the authentication fails, the
service can be interrupted immediately. Some ISPs may not like the idea,
but this could be some type of interim or "special-cases" solution for
RT HO in cases where re-authentication is needed and no impact on the RT
services is a must. 

Stefano