Subject: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-01.txt

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 8 Mar 2001 21:10:34 +0100

Hi Pat,

I have some comments on this document, and hopefully they might be useful.

1) I think that page 8 should be a new section about a Mobile Node moving to a Foreign Network.

2)Page 8, par.2, the MIP-Previous-FA-NAI must be change for MIP-Previous-FA-FQDN. You should use find and replace for this one, since there are more than one.

3) Page 8, in figure 5, the message between the HA and AAAF must be HAA, instead of HAR.

4) Page 8, par.2, last sentence. I don't really understand what you mean there. I guess you meant that Home Agent and the requesting Foreign Agent are in different domain. The thing is that it is likely that the Home Agent and the MIP-Previous-FA-FQDN were in the same domain at the last registration, right?

5) In section 1.3, the meaning of home address 255.255.255.255 is described, but the meaning of 0.0.0.0 should also be added for clarity. BTW, those conditions are mentioned at several places in the document. I like the concept of the state machine as in the Base spec.

6) Section 1.4, the second paragraph suggests to release the all resources in the Home Diameter server upon the receipt of the STR from the Home Agent. I guess it should be clear that the referred Home Agent is the "active" Home Agent, since there might be 2 Home Agents at the same time while roaming. During handoffs between different FAs in different domains, and let's say that the Home Agent in the old Foreign domain can not be maintained there, then a new Home Agent has to be started in the Home Domain or the new Foreign domain and the AAAH needs to send a STI to the old Home Agent, which replies with a STR. In that case, the Home Diameter should not release resources, right?

7) Many references to MIP-Reg-Req should be changed for MIP-Reg-Request. Find and replace.

8) Many references to MIP-Reg-Rep should be changed for MIP-Reg-Reply. Find and replace.

9) Many references to Peer-SPI should be changed for MIP-Peer-SPI . Find and replace.

10) In section 2.3, a home address of 255.255.255.255 should also request a new address.

11) Section 2.3 par.2, "If a AAAF receives a HAR..." should be "If a AAAF receives a AMA..." Right?

12) Section 3.1, it it Hop-by-Hop Failures?, or Per-Hop Failures? Should all those errors be sent through a DSI?

13) Section 3.1, just wondering, why error numbers are 6xxx series?

14) Section 4.6, A reference to Previous Foreign Agent Notification Extension would be nice.

15) Section 4.7, "If the mobile node sets the home agent field equal to 0.0.0.0 ..." should also include 255.255.255.255, like mentioned in section 1.3

16) Section 4.7, "...Home-Address-Requested flag or the Home-Agent-Request flag..." should rather be "Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested flag"

17) "If the mobile node requests a home agent in the foreign network by
   setting the home address field to all ones,..." I guess it should be home agent instead, right? Also, in the document, 255.255.255.255 is used and some other places it is all ones. Can it be one or the other for clarity?

18) Section 5.0 par.2, "Absence or the AVP, or a value of zero indicates infinity
   (no timeout)." It the message definition, it says that this AVP is mandatory.

19) Section 5.0 par.2, "If no preferred SPI value is indicated the registration keys the foreign agent needs..." I think that the part "the registration keys the foreign agent needs" does not really fit in this sentence.

20) Section 5.1 par.3, "MIP-HA-to-MN-Key AVP in the AMR message..." should be "in the AMA message" (reference to section 1.3 p.7)

21) Section 5.1 par.3, "When the AAAF receives the AMR,..." should also be "the AMA"

22) Section 5.1 par.5, "MIP-MN-to-HA-Key AVP into the AMR message" should be "the AMA"

23) Section 5.1 par.5, "...in the MIP-HA-to-MN-Key AVP from the AVP received from AAAH, AAAF then recodes the registration key into a new MIP-HA-to-MN-Key AVP ". Both MIP-HA-to-MN-Key should be replaced by MIP-MN-to-HA-Key.

24) Section 5.2 par.2, "...MIP-MN-to-FA-Key AVP in the AMR message..." should be the "AMA message"

25) Section 5.2 last par., "...key available to AAAF." should be "available to FA"

26) Section 5.3 par.4, "...MIP-HA-to-FA-Key AVP as part of the AMR..." should be "to the AMA"

27)  Section 2.1, why is the Session-ID is required with {}, but not with [], like in other messages?

28) Section 2.1, why the "Authorization-Lifetime" required?

29) I am wondering why the Destination-Realm AVP is required in Answer messages?

30) In section 2.2, the Origin-FQDN AVP and the Origin-Realm AVP must be required.

31) In section 2.5, what is the point of sending a HAI without the MIP-Home-Agent-Address? Should it be required?

32) In the case where a mobile node handoffs to a different FA within the same administrative domain, is it required to reach the Home server with the AMR?, or can it be handled in the AAAF? It might be interesting to show this scenario, right?

I think this is it for now.
Cheers,
Martin

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 30 Mar 2001 11:05:22 -0800 (PST)

First, thansk for the great comments. See my responses below. I will delete
the items that were obvious errors, and do not need my response.

> 1) I think that page 8 should be a new section about a Mobile Node moving to

I *could* but this is just another case of a Home Agent in a visited network,
so I find it difficult to find a clean separation point.

> 
> 4) Page 8, par.2, last sentence. I don't really understand what you mean
> there. I guess you meant that Home Agent and the requesting Foreign Agent
> are in different domain. The thing is that it is likely that the Home Agent
> and the MIP-Previous-FA-FQDN were in the same domain at the last
> registration, right?

Of course, but this paragraph has to do with a third network. Is the scenario
what's confusing you, or the text?

> 6) Section 1.4, the second paragraph suggests to release the all resources
> in the Home Diameter server upon the receipt of the STR from the Home Agent.
> I guess it should be clear that the referred Home Agent is the "active" Home
> Agent, since there might be 2 Home Agents at the same time while roaming.
> During handoffs between different FAs in different domains, and let's say
> that the Home Agent in the old Foreign domain can not be maintained there,
> then a new Home Agent has to be started in the Home Domain or the new
> Foreign domain and the AAAH needs to send a STI to the old Home Agent, which
> replies with a STR. In that case, the Home Diameter should not release
> resources, right?

I think that I view multiple bindings (to home agents) are different Diameter
sessions. Each would get their own Session-Id, and have their own separate
session state.

> 13) Section 3.1, just wondering, why error numbers are 6xxx series?

Section 4 was introduced to define the DSI-Events. Error class 6 was
temporarily added to identify error cases that require hop-by-hop processing,
but this was later removed out of the base and replaced with the DSI, hence
the new 4.0 section.

> 14) Section 4.6, A reference to Previous Foreign Agent Notification

What does this mean? You mean a Mobile IP extension?

You have plenty of comments on section 5.1, which was a mess. My proposed
cleaned up text is as following 

<proposed text>
If the mobile node does not have a Mobile-Home registration key, then
the AAAH is likely to be the only entity trusted that is available to
the mobile node.  Thus, the AAAH has to generate the Mobile-Home
registration key, and encode it for eventual consumption by the mobile
node and home agent.

If the home agent is in the home domain, then AAAH can directly encode
the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP and
include that AVP in the HAR message for delivery to the home agent.

If, on the other hand, the home agent is to be allocated in the
visited domain, the AAAH does not transmit the HAR to the home agent,
but instead transmits the HAR to the AAAF. When the AAAF receives the HAR,
it first allocates a home agent, and then issues the HAR for that home agent.

The AAAH also has to arrange for the key to be delivered to the mobile node.
Unfortunately, the AAA server only knows about Diameter messages and AVPs,
and the mobile node only knows about Mobile IP messages and extensions[4].
For this purpose, AAAH encodes the Mobile-Home registration key into
a MIP-MN-to-HA-Key AVP, using its security association with the mobile node,
which is added to the HAR message, and delivered either to a local home
agent, or to the AAAF in the case where the home agent is in the visited
network. The AAAH has to rely on the home agent (that also understands
Diameter) to transfer the key into a Mobile IP Generalized MN-HA Key Reply
extension in the Registration Reply message. The home agent can format the
Reply message and extensions correctly for eventual delivery to the mobile
node. The resulting Registration Reply is added to the MIP-Reg-Reply AVP
and added to the AHA.

After the HAA message is parsed by the AAAH, and transformed into an AMA,
the AMA message containing the MIP-Reg-Reply AVP will eventually be received
by the attendant (i.e., the foreign agent). The foreign agent can then use
that AVP to recreate a Registration Reply message, containing the Generalized
MN-HA Key Reply extension, for delivery to the mobile node.

In summary, the AAAH generates the Mobile-Home registration key and
encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. These
AVPs are delivered to a home agent by including them in a HAR message
sent from either AAAH or AAAF. The home agent decodes the key for its own use.
The home agent also copies the encoded registration key from the
MIP-MN-to-HA-Key AVP into a Generalized MN-HA Key Reply extension appended
to the Mobile IP Registration Reply message. This Registration Reply message
MUST also include the Mobile-Home authentication extension, created using
the newly allocated Mobile-Home registration key. The home agent then
encodes the Registration Reply message and extensions into a MIP-Reg-Reply
AVP included as part of the HAA message to be sent back to the AAA server.
</proposed text>

You also had many comments on section 5.2, which has now been greatly
simplified to:

<proposed text>
The Mobile-Foreign registration key is also generated by AAAH (upon request),
so that it can be encoded into a MIP-MN-to-FA-Key AVP, which is added to the
HAR, and copied by the home agent into a Generalized MN-FA Key Reply
Extension [15] to the Mobile IP Registration Reply message. Most of
the considerations for distributing the Mobile-Foreign registration key
are similar to the distribution of the Mobile-Home Registration Key.

If the MIP-FA-to-MN-Key AVP is present in the HAR, the home agent MUST ensure
that the same AVP is present in the AHA. The AAAH MUST ensure that this AVP
is present in the AMA, which is sent to the foreign agent.
</proposed text>

Similarly, section 5.3 was greatly simplified to:

<proposed text>
If the home agent is in the home domain, then AAAH has to generate the
Foreign-Home registration key.  Otherwise, it is generated by AAAF.

In either case, the AAA server encodes the registration key into a
MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message
sent to the home agent, and waits for the HAA message to be returned.

If the MIP-FA-to-HA-Key AVP was present in the HAR, the same AVP MUST
be present in the corresponding AHA, which is eventually transformed by
the AAAH into an AMA message that is transmitted back to the foreign agent.

Upon receipt of the AMA, the foreign agent recovers the Foreign-Home
registration key, and uses this key to create a Mobile-Foreign
authentication extension to the Registration Reply message.
</proposed text>

> [], like in other messages?

As per the base protocol, the Session-ID is ALWAYS mandatory to be present.

> 28) Section 2.1, why the "Authorization-Lifetime" required?

hmmmm.... I suppose it shouldn't really be mandatory, but could be present as
a recommendation from the Foreign Agent, or AAAF.

> 29) I am wondering why the Destination-Realm AVP is required in Answer

hmmmm.... noit quite sure, but it doesn't seem to hurt :)

> 32) In the case where a mobile node handoffs to a different FA within the
> same administrative domain, is it required to reach the Home server with the
> AMR?, or can it be handled in the AAAF? It might be interesting to show this
> scenario, right?

Why would the AAA server even need to be contacted?

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 30 Mar 2001 11:24:42 -0800 (PST)

one more thing.

> a recommendation from the Foreign Agent, or AAAF.

Looking over the connectathon comments, this was an issue and has since been
corrected. The AVP is optional in the HAR.

PatC