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

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 5 Apr 2001 18:05:29 +0200

> > 
> > 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...
> 
> I think it would be much cleaner to have a new AVP, rather 
> than the old one. 

Just to make sure, I guess you meant that 
the Session-Id that has been authorized by the AAAH should
remain the valid Session-Id for the active MIP session, right?
Let's call "authorized Session-Id", the Session-Id that has
been officially authorized previously by the AAAH.

Let's say that the MN moves to a new FA within
the same domain. When the AAAF receives a MIP Registration 
from a MN, the message includes a MIP-Previous-FA-FQDN AVP,
which identifies the previous FA. It also includes the 
User-Name AVP, which is supposed to be used for identifying
the FA-MN and FA-HA keys that need to be sent to MN. 
That authorized Session-ID would be sent back to 
the new FA in the AMA message from the AAAF, packaged in a new 
"MIP-Previous-Session-ID" AVP. The new Session-ID would be just
ignored? I guess that the "authorized"
Session-ID could be kept in the AAAF, along with the FA-XX keys.

Using that new AVP, it remains possible to support
roaming between FAs within the same domain without involving
unnecessarily the AAAH. Also, the accounting part is 
not impacted at all, since the Session-Id remains the same.
No accounting start and stop are required, neither re-authentication
and re-generation of keys. I think that is a very efficient and
clean way of supporting it.

About the STI to the old FA, why can't it be handled by the 
Mobile IP standard? I guess an STI should be sent to the Diameter 
client (FA) only if the session needs to be interrupted, or if you
prefer, prematurely terminated. However, there is no need of 
terminating the Accounting session.

But if we support roaming between FA the way described 
previously, then we still have the problems that the AAAF
does not seem to be that "stateless", there is a problem
of synchronizing data between the AAAF and the AAAH, 
especially in terms of active FA, and it is not obvious
that we would gain that much in performance compared to
complexity, if we start adding new messages and AVPs.

I would say that I like the previous suggestion, if we
would add that the AAAF does not keep any information
at all on the session, and that the AAAH remains the 
master of the session. That means that each Registration
needs to go to the AAAH (AMR), which performs the authentication
and overides the Session-Id with the authorized one, while
updating its reference to the actual FA and triggering a STI
to the previous FA. The key for the session would be the User-Name,
as already proposed for the AAAF. It seems to be more work, but it is
similar to the case with the HAA story, which means more generic
and less complexed traffic cases. In fact, moving from one
FA in one domain to another FA in another domain would also
work perfectly in that context. Even the keys could be 
transmitted that way, at the exception of the FA-HA, in the
case where the HA is in the foreign domain, which I don't 
really understand why we must comply to that???

I guess you understand that I now question to use of the 
MIP-Previous-FA-XX AVPs, since they don't seem to bring 
much information else than telling the FA that they used
to be connected to a former FA, for which the FA can not
do much about, beside knowing that if it was in the same
domain, then it should take care of sending himself the
MIP Registration to the HA, when it receives the required key
from the AAAF, right?

And as a note, I think that a "key" for a session in the AAAH
makes much more sense as a User-Name for the primary key, and as a
Session-ID for the secondary key. I guess that making the
User-Name mandatory in every message in a good thing.

> > 
> > 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.
 
How can you achieve a stateless AAAF, when you need to keep at
least the FA-MN and FA-HA keys for the particular MIP session?
AFAIK, there is no way of pulling the data from the previous
FA, and transfer them to the new FA, right? That means that the
AAAF needs to keep a state. Then, what's the big deal with 
keeping the information about the FA as well and then the AAAH 
would only need to know the AAAF? The AAAF would become in charge
of forwarding it to the good FA.

> 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
> 

Regards,
Martin

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 6 Apr 2001 16:58:21 +0200

>clean way of supporting it.

Why don't you need to stop accounting? I agree that if you have accounting
based on bytes or packets it is ok to let the timer expire in the FA, but if
you have time based accounting you have to terminate the accounting session
with the old FA otherwise it will overlap with the new FA's accounting
session. It can also be solved in the server but I believe that it is more
complicated for the server to keep track of what overlaps what instead of
just terminating one session.

Another thing that needs some clarification, if there is a solution. How
will the HA know which SA to use. In the case where a mobile moves from one
Fa to another under the same administrative domain it may receive the
session keys for the old Fa from the AAAF. It will then proceed to send the
mip reg req to the HA. The HA will see that the message came from the new FA
and try to locate the SA shared with that FA. It will not find it since it
was established with the old FA. Eventhough the HA can see the address of
the old Fa in the previous-fa-XXXX it is not clear that it can establish a
SA with the new Fa because it has to use the same SPI as before and that one
might be busy. Or have I missed something here?

/Fredrik

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 6 Apr 2001 08:33:31 -0700 (PDT)

All,

I have been thinking about this quite a bit, and it really isn't clear why
this is a AAA problem.

It seems like the easiest way for this to occur, would be for the AAAH to send
the STI to the HA, and have the HA issue some message to the FA asking for
disconnect. The Mobile IP WG is already looking at this problem, and as far as
I can tell, has even adopted Steven Glass' proposal as a WG work item.

So, if this problem is already solved in Mobile IP, do we *really* need to
complicate the Diameter protocol to *also* provide existing functionality?

So can we simply add text in the Mobile IP extension stating that the AAAH can
send the STI to the HA instead of the FA. The AAAF can send the message to the
FA. This way both of our bases are covered without any protocol changes.

Thanks,

PatC

---

From: Tony Johansson <[email-masked]>
Date: Sat, 07 Apr 2001 17:09:27 -0700

> just terminating one session.

But is their anything in the specs that really prevents you from sending STI to
the old FA.
If you don't what to handle overlaps in your AAAF implementation?

> might be busy. Or have I missed something here?

You also have the user NAI in the MIP registration request sent to the HA and
the user NAI is globally unique....

BR,

/Tony

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 9 Apr 2001 16:25:13 +0200

>the user NAI is globally unique....

Yes, but this is not the security association shared with the mobile node
but the one shared between the FA and HA, thus has nothing to do with the
user.

You can not guarantee that a security between the HA and the old FA is
unique between the HA and the new FA. The same SPI must be used in the first
request in order for the HA to be able to distinguise between different
security contexts it shares with the FA. What we can do is to have the new
FA add a <MIP-Preferred-SPI Ext> in the first request from the new FA to the
HA, the HA can then use the <Previous-FA-XXXX Ext> together with the old SPI
to retreive the context and store it under the Preferred SPI under the SA
with the new FA.

/Fredrik