Subject: [AAA-WG]: text proposal to Issue 338

From: Tony Johansson <[email-masked]>
Date: Wed, 08 May 2002 14:30:31 -0700

All,

Here is the text proposal to solve  issue 338: Diameter Mobile IP
application & backwards compatibility.

Any objections / comments.

Regards,

/Tony

In section 1.0  Introduction:

Change:

  "Furthermore, the nature of mobile IP also means that the mobile node
   will do handoffs between different foreign agents and to guarantee
   that a registered user always ends up in the same initial AAAH the
   Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to
   assist the AAAH in routing the messages to a mobile node's home agent

   the mobile node MUST always include the HA NAI [AAANAI]."

To:

  "Furthermore, the nature of mobile IP also means that the mobile node
   will do handoffs between different foreign agents. To guarantee that
   a registered user always ends up in the same initial AAAH, the mobile

   node SHOULD always include the AAAH NAI [AAANAI]. Finally, to assist
   the AAAH in routing the messages to a mobile node's home agent the
   mobile node SHOULD always include the HA NAI [AAANAI]."

In section 1.2 Inter-Realm Mobile IP:

Change:

  "A mobile node, which has been previously authenticated and
   authorized, MUST always include the assigned home agent in the HA
   Identity subtype of the AAA NAI extension, and the authorizing Home
   AAA server in the AAAH Identity subtype of the AAA NAI extension, in
   the registration request message [AAANAI] which is sent to the FA
   every time the Mobile Node needs to re-authenticate. So, in the event

   that the AMR generated by the FA is for a session that was previously

   authorized, it MUST include the Destination-Host AVP, with the
   identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent-
   Host AVP with the identity and realm of the assigned HA found in the
   HA-NAI."

To:

  "A mobile node with AAA NAI extension support [AAANAI], which has been

   previously authenticated and authorized, MUST always include the
   assigned home agent in the HA Identity subtype of the AAA NAI
   extension, and the authorizing Home AAA server in the AAAH Identity
   subtype of the AAA NAI extension, when re-authenticating. So, in the
   event that the AMR generated by the FA is for a session that was
   previously authorized, it MUST include the Destination-Host AVP, with

   the identity of the AAAH found in the AAAH-NAI, and the MIP-Home-
   Agent- Host AVP with the identity and realm of the assigned HA found
   in the HA-NAI. If on the other hand the mobile node does not support
   the AAA NAI extension, the FA may not have the identity of the AAAH
   and the identity and realm of the assigned HA. This means that
   without support of the AAA NAI extension, the FA may not be able to
   guarantee, that the AMR well be destined to the same AAAH, which
   previously authenticated and authorized the mobile node, since the FA

   may not know the identity of the AAAH."

In section 1.4 Allocation of Home Agent in Foreign Network:

Change:

  "In the event that the mobile node has been previously authorized by
   the AAAH and now needs to be re-authenticated, and requests to keep
   the assigned home agent in the foreign network, the mobile node MUST
   include the HA NAI and the AAAH NAI in the registration request to
   the FA. Upon receipt, the FA will create the AMR including the MIP-
   Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH
   NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include the
   MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF
   authorizes the use of the requested home agent, the AAAF MUST set the

   Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP."

To:

  "In the event that the mobile node (with AAA NAI extension support
   [AAANAI]) has been previously authorized by the AAAH and now needs to

   be re-authenticated, and requests to keep the assigned home agent in
   the foreign network, the mobile node MUST include the HA NAI and the
   AAAH NAI in the registration request to the FA. Upon receipt, the FA
   will create the AMR including the MIP-Home-Agent-Address AVP, the
   Destination-Host AVP based on the AAAH NAI and instead of the MIP-
   Candidate-Home-Agent-Host AVP include the MIP-Home-Agent-Host AVP
   based on the home agent NAI. If the AAAF authorizes the use of the
   requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-
   Network bit in the MIP-Feature-Vector AVP."

---

From: Johan Johansson <[email-masked]>
Date: Mon, 13 May 2002 10:58:00 +0000

Hi Tony.

I have no objections to the sections I cut out. Regarding the remainder 
below, would it be possible to reformulate this to make it clearer what 
a MN without AAA-NAI support needs to do and what the effect of not 
supporting AAA-NAI is? I may be wrong, but it seems to me that with the 
proper support from the home network, in particular AAAH assigned by nai 
hashing, the only thing that is truly impossible to solve is to keep the 
HA if the AAAH goes down.

In any case, you've made the entire section conditional on the support 
of AAA-NAI. Surely we need a way to assign a home agent in a foreign 
network even in a backwards-compatibly solution? If not we should add a 
sentence saying that without AAA-NAI you cannot allocate a home agent in 
the visited net.

j

---

From: Tony Johansson <[email-masked]>
Date: Wed, 15 May 2002 14:31:36 -0700

Hi Johan,

I'm sorry for my late reply.

So, how about the following clarifications:

"1.0 Introduction:

....

Furthermore, the nature of mobile IP also means that the mobile node will do
handoffs between different foreign agents. To guarantee that a registered
user always ends up in the same initial AAAH, the mobile node SHOULD always
include the AAAH NAI [AAANAI]. Finally, to assist the AAAH in routing the
messages to a mobile node's home agent the mobile node SHOULD always include
the HA NAI [AAANAI]. If the mobile node does not support the Mobile IP AAA
NAI extenstion [AAANAI], this MAY limit the functionality that can be offered
to such a mobile node"

1.4 Allocation of Home Agent in Foreign Network:

....

In the event that the mobile node with AAA NAI extension support [AAANAI] has
been previously authorized by the AAAH and now needs to be re-authenticated,
and requests to keep the assigned home agent in the foreign network, the
mobile node MUST include the HA NAI and the AAAH NAI in the registration
request to the FA. Upon receipt, the FA will create the AMR including the
MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI
and include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the
AAAF authorizes the use of the requested home agent, the AAAF MUST set the
Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.

In the event that the mobile node that does not support the AAA NAI extension
has been previously authorized by the AAAH and now needs to be
re-authenticated, and requests to keep the assigned home agent in the foreign
network, the mobile node sends a registration request without the AAA NAI and
the HA NAI. Upon receipt, the FA will create the AMR including the
MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested
home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the
MIP-Feature-Vector AVP."

Would this make it clear enough.

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Thu, 16 May 2002 00:02:30 +0000

>NAI extenstion [AAANAI], this MAY limit the functionality that can be offered
Klockrent as we would say in swedish. This part is perfect in my opinion.

>home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the
This is also much clearer. On the surface it looks a bit redundant but 
the separation of the two cases makes it easier to understand. Besides, 
my attempt at merging the two paragraphs wasn't very successful, so 
let's go with this one.

j

---

From: Pete McCann <[email-masked]>
Date: Thu, 16 May 2002 11:14:15 -0500 (CDT)

Hi,

I am glad to see that issues of backwards-compatibility are being
addressed.  One comment below...

 > my attempt at merging the two paragraphs wasn't very successful, so 

If only the HA's IP address appears, not the HA NAI, will it always be
possible for the FA to properly set the value of
Home-Agent-In-Foreign-Network?  I assume we need to cover the case
where the MN has moved to a new FA, maybe in the same or different
network, but wants to keep the HA it was assigned at the first FA.
With the HA NAI, the FA can compare the realm value to its own and
determine the proper setting of Home-Agent-In-Foreign-Network.  How
does the current FA know this was an HA in the foreign network, and
not an HA in the home network, just from the IP address?

Maybe a better approach would be to set the bit if the FA has some
knowledge (e.g., based on a table of IP address prefixes) that the HA
is in its OWN network.  Otherwise, the bit should be cleared.  Note
that the HA may not need a new HAR to keep it active; it might just be
willing to provide service for the duration of the Mobile IP session,
even if it doesn't hear from AAA for a long time.  The Mobile IP
registration messages would go directly to it and would be
authenticated based on MN-HA authentication extension.  I realize this 
is less functionality than if we had the HA NAI, but it should still
be a valid deployment scenario.

-Pete

---

From: Tony Johansson <[email-masked]>
Date: Thu, 16 May 2002 12:25:40 -0700

Hi Pete,

Please find my comments embedded...

/Tony

Pete McCann wrote:

> Home-Agent-In-Foreign-Network?

It is the AAAF that authorizes and sets the Home-Agent-In-Foreign-Network flag bit
and without the HA NAI the AAAF must be able to make that judgment based on only the
HA's IP address (e.g. through reverse DNS lookup, but this is impl. specific and it
has also been concluded that reverse DNS lookup may not at all work (please see
previous mail threads)). So, I guess my answer would be -  maybe. See further
comments below.

> I assume we need to cover the case

> determine the proper setting of Home-Agent-In-Foreign-Network.

Correct, however it is the AAAF that does this not the FA.

> How

The FA would only know if this is a subsequent registration from the MN. If not, the
FA wouldn't know and must ask it's AAAF for help. So, again with only the HA's IP
address the AAAF may have problems to figure out how to authorize this. This is an
old debate in which we have come to the consensus on the list and at the IETF53 that
the Mobile IP AAA NAI extension should be supported by the mobile node :)

I guess if you can make sure to always end up in the same AAAF (and that it is
statefull) when you move in the same foriegn network and that you also can make sure
to always and up in the same AAAH (also being statefull), then the need for the HA
NAI and the AAAH NAI would be of  less importans and it would be possible to fully
make use of the Diameter Mobile IPv4 application without the AAA NAI extension.

/Tony

---

From: Pete McCann <[email-masked]>
Date: Thu, 16 May 2002 14:48:04 -0500 (CDT)

Hi, Tony,

I realize I am coming a bit late to an old discussion, but comments below...

 > Correct, however it is the AAAF that does this not the FA.

Sorry about my confusion - yes, AAAF.  But my point then applies when
the user changes AAAF.

 > make use of the Diameter Mobile IPv4 application without the AAA NAI extension.

I am not saying we shouldn't do AAA NAI, it is obviously the best
approach that gives the most flexibility in setting policies.  I am
just trying to find the right wording for the case where we don't have
it due to a legacy MN that only implements MN-AAA and its own NAI.  I
don't think we should prohibit those less-than-perfect mechanisms,
such as reverse IP address lookup, or that we should prohibit someone
from using an HA in a previously visited network just because *some*
network policies might not allow it.  I would rather see wording that
says, for instance,

  "Home-Agent-In-Foreign-Network flag SHOULD be set if the AAAF has
   knowledge that the HA is in its own domain." 

Knowing the HA's NAI is one way, but there could be others.  The 3
different networks (those containing AAAH, AAAF and HA, respectively)
may be perfectly happy to authorize service, even though the visited
network has no idea who owns the HA and there is no direct contact
with the old AAAF in the HA's network.  Even if we can't guarantee
finding the same stateful AAAH for the access-request, so not even the
home network knows who owns the HA, the policy might be to grant
access.

-Pete

---

From: Tony Johansson <[email-masked]>
Date: Thu, 16 May 2002 14:06:47 -0700

Hi Pete,

In principle and IMHO, there isn't anything in draft -10 (with new proposed text to issue
338)  that wouldn't let you authorize the usage in the way you reasoning below. If you
disagree, please let me know where the wording is to strong or unclear.

/Tony

---

From: Pete McCann <[email-masked]>
Date: Fri, 17 May 2002 09:53:39 -0500 (CDT)

Hi, Tony,

 > disagree, please let me know where the wording is to strong or unclear.

I hope you are correct, but I still think there may be issues with

 > home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the

I would rather propose that the last sentence be changed to,

"If the AAAF authorizes the use of the requested home agent, and if it 
has knowledge that the requested home agent is in its own
domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the 
MIP-Feature-Vector AVP."

Also, in re-reading the rest of Section 1.4, it seems that
re-authorization always requires an HAR to the home agent, wherever it 
happens to be.  Is this a good idea, as we may not be able to reach
the HA through the Diameter infrastructure if we don't have HA NAI?
It would seem better in some cases, such as when the MN is using a
previously allocated HA, to authorize the access via AAA but do Mobile 
IP registration as in RFC 2002, i.e., send the RRQ directly to the HA
from the FA.  While this doesn't allow the AAA infrastructure to make
detailed decisions based on the domain of the HA, it may be allowed in 
some cases by the 3 networks.  I guess what I am saying is, in the
absence of both HA NAI and a guaranteed stateful AAAH, we have no way
to distinguish the "previously allocated in foreign network" HA from
one that is simply statically allocated, and which may not be
connected to the AAA infrastructure in any way.  Does the current text 
allow such HAs (such as a personal HA in my basement, not connected to 
a carrier AAA infrastructure) to get used?  I would hope so, but if
not, maybe the change is too big to get done at this point.  Maybe I'm 
raising an old, closed issue here again... please let me know.

-Pete

---

From: Tony Johansson <[email-masked]>
Date: Tue, 21 May 2002 11:11:50 -0700

Hi, Pete,

> domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the

I agree, thanks.

> raising an old, closed issue here again... please let me know.

I would say this is both pretty hefty protocol changes and old closed issues, and in either case
I strongly recommend that we reject this, if we plan to be done in the near future. It is true,
without the AAA key distribution extension and the AAA NAI extension the functionality that can
be offered to such legacy mobiles is limited, but nevertheless these mobiles can be offered at
least the level of service as of today (and even more depending on how you can set up and
configure your Diameter servers).

Regards,

/Tony

---

From: Pete McCann <[email-masked]>
Date: Tue, 21 May 2002 13:39:47 -0500 (CDT)

Hi, Tony,

 > > domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the

Ok.

 > configure your Diameter servers).

Ok, I can accept that.  I guess you are saying it may still be
possible to do what I want with proper configuration of Diameter
servers, even if HAR isn't implemented as outlined in the document
(and it wouldn't strictly comply with the message flows there).  I
think this is reasonable for now, given that we need to close the
document ASAP.

-Pete

---

From: Tony Johansson <[email-masked]>
Date: Tue, 21 May 2002 19:23:13 -0700

Pete McCann wrote:

> Ok, I can accept that.

Very good.

> I guess you are saying it may still be
> (and it wouldn't strictly comply with the message flows there).

Well, not issuing HAR would be part of the hefty protocol change:) So, that you still have to do, if
you want to stay interoperable.

Regards,

/Tony

> I