Subject: Re: [AAA-WG]: Previous-FA-XXXX AVP

From: Patrice Calhoun <[email-masked]>
Date: Wed, 4 Apr 2001 06:48:42 -0700 (PDT)

> First of all, there is a typo in 4.5 Previous-FA-NAI AVP should be
> Previous-FA-FQDN AVP

Yes, this has been pointed out already, and fixed in the -02 candidate.

> Then we have another question. When trying to retreive the keys from the
> AAAF for the previous FA, should you really use the Mobile-Node-Address AVP
> as identifier? Isn't it possible that there are several mobile nodes with
> the same private address under the same AAAF? It would be better to use the
> NAI. This should be changed in 4.5, 4.6. 

Yes, you are correct.

> The same applies to accounting
> (section 7.0) where it seems like the mn address is used as identifier
> instead of the Nai.

Actually, the base protocols now defines the accounting messages, and they now
call for the User-Name. So the ACR and ACA definitions include the User-name,
so I think we are covered.

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 4 Apr 2001 15:26:12 +0200

Hi,

NAI. This should be changed in 4.5, 4.6. The same applies to accounting

/Fredrik

---

From: Tony Johansson <[email-masked]>
Date: Wed, 04 Apr 2001 14:50:49 -0700

Hi Pat and all,

Here is something more on the Previous-FA-XXXX AVP issue thread that I think is
missing...

Lets say the following scenario that a registered MN is moving from one FA to
another FA within the same foreign domain and in this scenario the new FA will
issue an AMR including the Previous-FA-XXXX AVP to request to get the FA-MN and
FA-HA keys, and the Authorization-Lifetime. But what about the Session-Id?

The new FA does not know about the existing Session-Id, which has been use
previously used during the initial registration, so the new FA will generate a new
one in its AMR to the AAAF.

This leads to a couple of questions:

1. How should the AAAF deal with the new Session-Id? The AAAH does not know about
new one in this case.

One way of solving this could be to let the AAAF over write the new session id and
add on the initial session id into the Session-Id AVP in the reply back to the new
FA together FA-MN and FA-HA keys, and the Authorization-Lifetime. Or maybe a new
AVP for the initial session id is needed...

2. Furthermore, the AAAH would not get any information in this case, so it would
not know that the FA has changed only the AAAF is aware of it. Thus, if the AAAH
wants to send an STI to terminate the session for some reason it would issue the
STI towards the wrong FA.

A solution to this could perhaps be that the AAAH initially gets the information
about responsible AAAF in the foreign network, so if the AAAH needs to send an STI
it would issue it towards the AAAF and the AAAF would be responsible to resolve it
and forward it to the right FA.

Another way would be to let the AAAF to issue an Indication to the AAAH to inform
that the MN has changed FA.

Does it make sense or have I miss something.

BR,

/Tony

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 4 Apr 2001 17:18:08 -0700 (PDT)

> Here is something more on the Previous-FA-XXXX AVP issue thread that I think
> is missing...

ok.

> another FA within the same foreign domain and in this scenario the new FA
> will issue an AMR including the Previous-FA-XXXX AVP to request to get the
> FA-MN and FA-HA keys, and the Authorization-Lifetime. But what about the
> Session-Id?
> 
> previously used during the initial registration, so the new FA will generate
> a new one in its AMR to the AAAF.

This is a problem that has been plaguing (sp?) me for some time. Mobile IP is
vastly different from PPP, where the user's point of attachment changes over
time. If the AAAH is not notified of this change, then it cannot realistically
terminate the session properly.

Not to mention how to deal with accounting information.

> 1. How should the AAAF deal with the new Session-Id? The AAAH does not know
> about new one in this case.
> 
> One way of solving this could be to let the AAAF over write the new session
> id and add on the initial session id into the Session-Id AVP in the reply
> back to the new FA together FA-MN and FA-HA keys, and the
> Authorization-Lifetime. Or maybe a new AVP for the initial session id is
> needed...

I think it would be much cleaner to have a new AVP, rather than the old one. 

> 
> 2. Furthermore, the AAAH would not get any information in this case, so it
> would not know that the FA has changed only the AAAF is aware of it. Thus,
> if the AAAH wants to send an STI to terminate the session for some reason it
> would issue the STI towards the wrong FA.
> 
> A solution to this could perhaps be that the AAAH initially gets the
> information about responsible AAAF in the foreign network, so if the AAAH
> needs to send an STI it would issue it towards the AAAF and the AAAF would
> be responsible to resolve it and forward it to the right FA.

hmmmm... I would MUCH prefer to NOT assume state on the AAAF. I believe that
it would be more appropriate to define a new message, of type -Ind, which is
sent by the AAAF to the AAAH to notify it of a location change.

However, this is new functionality, and we did agree to NOT include new
functionality, but only fix bugs. So, is this a bug, or a new functionality?

> Another way would be to let the AAAF to issue an Indication to the AAAH to
> inform that the MN has changed FA.

oops, great minds think alike :)

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 5 Apr 2001 06:34:49 -0700

>functionality, but only fix bugs. So, is this a bug, or a new

We are not accepting MAJOR new capabilities at this point,
such as data modeling, e2e security, etc.

It is also accurate to say that a good case needs to be made
for addition of new features. We want to prevent creeping
featurism -- if anything, we probably need to cut more features
than we add. 

However, if a good technical case can be made for a change, and
in particular, if an argument can be made that the change enables
the protocol to better satisfy the requirements -- then we should
make that change. 

Not only will this get us a better protocol -- but it will also
satisfy the requirement that a Proposed Standard represent consensus
of the AAA WG. 

So let's keep the bar high -- but not so high that noone can jump
over it.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 5 Apr 2001 12:06:00 +0200

>sent by the AAAF to the AAAH to notify it of a location change.

I agree, the AAAF should not have to keep state.
Another thing, I believe the AAAF need to terminate the accounting session
with the old FA. Perhaps some text is needed to explain this.

for example:
11.7  Session Termination

   The Diameter Base Protocol provides a set of messages that MUST be
   used by any peer to explicitly request that a previously
   authenticated and/or authorized session be terminated. Since the
   Session-Id is typically tied to a particular service (i.e. Mobile IP,
   NASREQ, etc), the session termination messages are used to request
   that the service tied to the Session Id be terminated. The access node
   must also terminate all accounting sessions associated with the
   session indicated by the Session Id. For example, when a MN moves
   from one FA to another it will re-register, thus a new session will be
   setup between the new FA and AAAH. AAAH MUST then send a STI
   to the old FA to terminate the MIP session and also cause the old FA
   to terminate any accounting sessions it has with its local AAA for this
   MN. In the case where both FAs are under the same administrative
   domain, the local AAA MUST send a STI to the old FA in order to
   terminate possible accounting sessions since new ones will be started
   with the new FA.

>functionality, but only fix bugs. So, is this a bug, or a new

Definitely a bug, the protocol is not working rigth without it. It makes
sure the information is where it is supposed to be.

/Fredrik

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 5 Apr 2001 06:35:16 -0700 (PDT)

ok, I agree that the problem introduced by Tony needs to be fixed, but I
needed clarification on what we could/couldn't put it from now on. I will make
the necessary text changes to the -02 candidate.

PatC