Subject: [AAA-WG]: Comments on draft-mobileip-03

From: "Martin Julien (ECE)" <[email-masked]>
Date: Wed, 9 May 2001 17:58:01 +0200

Hi,

First, I must say that I would have really liked to join the 
conference call held yesterday, but I must apologize for not being
ready on time for it. Anyhow, I read the latest draft and
have some comments.

1-Already much better than some previous versions. Thanks!

2-In the Abstract section, in the last sentence, you refer to the
Diameter Accounting Extension. I guess you should make it a bit more
clearer that it is not an extension anymore.

3-In the Abstract section, in the last sentence, it says that the
Accounting messages should be used by the FA and the HA to report
usage info. Does that mean that both need to use the same Session-Id
in the accounting messages? I don't know the story around the 
Acct-Multi-Sess-Id AVP. Same comment applies to the 3rd par. of page 3.

4-Last paragraph of section 1.0, the attendant can also be an HA, when
the MN is in the Home Domain and the HA is co-located. That should apply
to all the document where you refer to the attendant, while having in 
parenthesis the FA.

5-In section 1.2, page 5, the last paragraph starting with "If the AAAH...",
I think it is a bit confusing here. Here is what I would suggest for the last
few paragraphs of page 5.

   "...

   If the Mobile Node was successfully authenticated, the AAAH checks
   if the Home Agent was located in the foreign domain, by checking
   the Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.
   If it is set to 1, then the Home Agent is located in the foreign
   domain then AAAH sends an HAR message to AAAF which contains a 
   MIP-Reg-Request AVP.

   If the Home Agent was not located in the foreign domain, the AAAH checks
   for the MIP-Home-Agent-Address AVP. If one was specified, the AAAH
   checks that the address is that of a known Home Agent, and one that
   the Mobile Node is allowed to request. If no Home Agent was
   specified, and if the MIP-Feature-Vector has the Home-Agent-Requested
   flag set, and if allowed by policy in the home domain, the AAAH
   SHOULD allocate a home agent on behalf of the Mobile Node.  This can
   be done in a variety of ways, including using a load balancing
   algorithm in order to keep the load on all home agents equal. The
   actual algorithm used and the method of discovering the home agents
   is outside the scope of this specification.

   The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains the 
   Mobile IP Registration Request message data encapsulated in the 
   MIP-Reg-Request AVP, to the assigned or requested Home Agent. The AAAH 
   MAY allocate a home address for the mobile node, and include it in a 
   MIP-Mobile-Node-Address AVP within the HAR, or else leave this allocation
   responsibility for the Home Agent.
   
   ..."

6- Second paragraph of page 6, I'm still wondering why a DIAMETER_ERROR_BAD_HAR
is required? What is it supposed to mean? We do not have this type of generic
error for any other extension, and I don't see why we should have this for MIP.
If the request is rejected, I guess the normal result-code defined in the Base
should be used instead. The comment applies also to section 4.1.

7- Page 8, second par., the thing is that I think that AAAH can determine that
the MN has moved to a new domain by using the Origin-FQDN and the 
MIP-Previous-FA-FQDN. However, I'm wondering if the MIP-Previous-FA-FQDN is
enough, since the FQDN is highly dependent on the realm of the MIP-Previous-FA-XXXX,
right? You can only tell that the MN is moving between domain based on the Realms.

And now, let's say that the HA is located in the former domain, then how can the 
AAAF knows that the MN has registered in an other domain? The MIP-Previous-FA-FQDN
can not really help, since it will be in that domain from where it moved. The
AAAF does not have any mean of knowing the originator of the AMR, AFAIK. I guess
that a MIP-Registering-FA-FQDN AVP should be added for that purpose.

8-Section 2.1, I think it is not clear exactly when the FA needs to invoke the
AAA infrastructure. I think it would be necessary to mention that it would 
be possible for a MN registration to invoke the AAA infrastructure only when 
a User-Name, a MIP-Home-Address, a MIP-Home-Agent-Address, a MIP-FA-Challenge 
or session keys are requested. Otherwise, the registration would go directly 
from the FA to the HA.

The MIP-FA-Challenge AVP Should be added to the table in section 10.1 (0-1).

Also, I guess that the MN-AAA extension should also be mention in the list of
AVPs.

9-Section 2.2, the last sentence of the first paragraph is redundant with the
second one. The second one is much more complete. Also the third par. should instead
read as:

"The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key
if they were requested in the AMR. IF they were also sent in the HAR, 
the HAA must also include them unchanged."

10-The AVP [MIP-MN-to-HA-Key] is listed twice in the message description.
Also, the Original-Session-Id is not listed in the table 10.1

11-Section 3.1, for the DIAMETER_ERROR_AUTH_FAILURE, I guess it should say to
inform the mobility agents (HA (co-located) or the FA).

12-Section 5.5 and 5.6, beside the comment #7, I would add that the MN MAY or MUST
include that information? In it is only a MAY, then I guess we should not
count on it for checking if the MN has moved to a new FA, unless it is
specified that it MUST in the case where the MN wants to seemlessly moved
to a new FA. Also, it mentions "under the same administrative domain", which
would not be useful to check if the HA allocated in a previous foreign domain
can still provide service to the MN. Check comment #7 again for that.

13-Section 5.7, I guess that when the MIP-Mobile-Node-Address and the MIP-Home-Agent-
Address AVPs are not in the message, the AAAF and the AAAH knows that Home-Agent is
requested and that a Mobile-Node-Home-Address is requested. I don't see the need for
those 2 flags.

14-Page 20, par.3, I don't think it is the correct meaning. My understanding, after
talking with Tony Johansson, is that the Home-Agent-In-Foreign-Network is used when
the MN requests a Home-Agent, and that the AAAF detects that it is located in its
foreign domain, before it forwards the AMR to the AAAH.

15-In section 5.8, I am wondering where the MN-AAA authenticator is? The MN-AAA 
authentication extension added by the MN does not seem to be included in any
of the AVPs. Am I missing something? 

16-Section 6.0, second paragraph, why do you refer to encryption? The thing is that
it is a bit confusing what is required. Do you mean that either the message encryption 
is required via the Base protocol, or the AVP encryption is required via the E2E security
extension? In fact, the session keys, in terms of AVPs, destined to the FA and the HA 
can NOT be encrypted in the AVP unless the E2E security is used, or the message is completely
encrypted by the Base protocol.

17-Section 6.2, 2nd par., should be HAA instead of AHA. Also, the FA should add the 
FA-MN-authentication extension to the reg-Reply.

18-Section 6.3, the last par. is wrong. It should be the HA that should add the 
HA-FA-Authentication extension.

19-Section 7.0, 2nd par., the same question about the encryption??? The table should
be in alphabetical order. Also, the AVP defined in section 7.2 should be added to the
table.

20-Section 7.2, the figure should be updated according to the description of the grouped-AVP.

21-Section 7.2.1 and 7.2.2, refer to section 7.2 instead of 6.2.

22- Section 8.2 and 8.5, should be "by the user" instead of "to the user".

23-Some updates to the table 10.1 as follows:

                                 +-----------------------+
                                 |      Command-Code     |
                                 |-----+-----+-----+-----+
   Attribute Name                | AMR | AMA | HAR | HAA |
   ------------------------------|-----+-----+-----+-----+
   Authorization-Lifetime        | 0-1 | 1   | 1   | 1   |
   Destination-FQDN              | 0-1 | 1   | 0-1 | 1   |
   Destination-Realm             | 1   | 0   | 1   | 0   |
   Error-Reporting-FQDN          | 0   | 0-1 | 0   | 0-1 |
   Auth-Extension-Id             | 1   | 1   | 1   | 1   |
   Filter-Rule                   | 0   | 0-1 | 0-1 | 0-1 |
   MIP-FA-to-HA-Key              | 0   | 0-1 | 0-1 | 0-1 |
   MIP-FA-to-MN-Key              | 0   | 0-1 | 0-1 | 0-1 |
   MIP-Feature-Vector            | 0-1 | 0   | 0   | 0   |
   MIP-FA-HA-Preferred-SPI       | 0-1 | 0   | 0   | 0   |
   MIP-FA-MN-Preferred-SPI       | 0-1 | 0   | 0   | 0   |
   MIP-HA-to-FA-Key              | 0   | 0   | 0-1 | 0   |
   MIP-HA-to-MN-Key              | 0   | 0-1 | 0-1 | 0   |
   MIP-Home-Agent-Address        | 0-1 | 0-1 | 0-1 | 0-1 |
   MIP-MN-AAA-Auth               | 1   | 0   | 0   | 0   |
   MIP-MN-to-FA-Key              | 0   | 0   | 0-1 | 0   |
   MIP-MN-to-HA-Key              | 0   | 0-1 | 0-1 | 0   |
   MIP-Mobile-Node-Address       | 0-1 | 0-1 | 0-1 | 0-1 |
   MIP-Previous-FA-Address       | 0-1 | 0   | 0   | 0   |
   MIP-Previous-FA-FQDN          | 0-1 | 0   | 0   | 0   |
   MIP-Reg-Reply                 | 0   | 0-1 | 0   | 0-1 |
   MIP-Reg-Request               | 1   | 0   | 1   | 0   |
   Origin-FQDN                   | 1   | 1   | 1   | 1   |
   Origin-Realm                  | 1   | 1   | 1   | 1   |
   Proxy-Info                    | 0+  | 0+  | 0+  | 0+  |
   Result-Code                   | 0   | 1   | 0   | 1   |
   Route-Record                  | 0+  | 0+  | 0+  | 0+  |
   Session-Id                    | 1   | 1   | 1   | 1   |
   Session-Timeout               | 0   | 1   | 1   | 1   |
   User-Name                     | 1   | 0   | 1   | 0   |
   ------------------------------|-----+-----+-----+-----|

24-Some updates to the tables 10.1 as follows:

                                 +-----------------------+
                                 |      Command-Code     |
                                 |-----+-----+-----+-----+
   Attribute Name                | ACR | ACA | API | ASI |
   ------------------------------|-----+-----+-----+-----+
   Accounting-Input-Octets       | 1   | 0-1 | 0   | 0   |
   Accounting-Input-Packets      | 1   | 0-1 | 0   | 0   |
   Accounting-Output-Octets      | 1   | 0-1 | 0   | 0   |
   Accounting-Output-Packets     | 1   | 0-1 | 0   | 0   |
   Accounting-Session-Time       | 1   | 0-1 | 0   | 0   |
   Accounting-State              | 0   | 0   | 1   | 0   |
   MIP-Feature-Vector            | 1   | 0-1 | 0   | 0   |
   MIP-Home-Agent-Address        | 1   | 0-1 | 0   | 0   |
   MIP-Mobile-Node-Address       | 1   | 0-1 | 0   | 0   |
   MIP-Previous-FA-Address       | 0-1 | 0-1 | 0   | 0   |
   MIP-Previous-FA-FQDN          | 0-1 | 0-1 | 0   | 0   |
   ------------------------------|-----+-----+-----+-----+

I don't think the Accounting-State AVP should be here, since it is included in the Base protocol.
Anyway, it should be in the ASI, not the API. Also, I don't understand why the MIP-Feature-Vector
could be useful? Any idea?

25-Section 13.0, the same thing, what does the following really mean?
"The keys are distributed in an encrypted
format through the Diameter protocol, and SHOULD be encrypted using
the methods defined in [9]."

Have a good day!
Martin

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 9 May 2001 16:21:39 -0700

> 1-Already much better than some previous versions. Thanks!

No, thank you! Seriously, if it wasn't for all the great comments that are
sent on the list, the specs wouldn't be as good as they are.

> clearer that it is not an extension anymore.

check.

> Acct-Multi-Sess-Id AVP.

ok, well there is a fair amount of new text that was generated yesterday
following the call, and how session ids were handled was one area of
concern. Here is an example (pardon the nroff commands :)

<new>
During the creation of the HAR, the AAAH MUST use a different session
identifier than the one used in the AMR/AMA (see figure 2). Of course,
the AAAH MUST use the same session identifier for all HARs initiated
on behalf of a given mobile node's session. A mobile node's session is
identified via its identity in the User-Name AVP, the
MIP-Mobile-Node-Address and MIP-Home-Agent-Address AVPs. This is necessary
in order to allow the session state machine, defined in the base
protocol [1], to be used unmodified with this extension. Therefore, an STR
from a foreign agent would free the session from the foreign agent, but not
the one towards the home agent (see figure 3).

.in 6
.KS
.nf
     STR, Session-Id = foo       STR, Session-Id = bar
     --------------------->      <--------------------
+----+      +------+      +------+                    +----+
| FA |      | AAAF |      | AAAH |                    | HA |
+----+      +------+      +------+                    +----+
     <---------------------      --------------------->
     STA, Session-Id = foo       STA, Session-Id = bar
.ce
Figure 3: Session Termination and Session Identifiers
.fi
.KE
</new>

> Same comment applies to the 3rd par. of page 3.

I suspect our page lengths are different because I don't have paragraphs
on page 3 (just a table of contents). Could you be more specific?

> to all the document where you refer to the attendant, while having in 

ok. I fixed the main document, but section 1.0 is giving me some problems.
I currently have:

"In this document, the role of the "attendant" [3] is performed by either
the home or foreign agent for the Mobile-IP Extension, and these terms
will be used interchangeably."

>    responsibility for the Home Agent.

yup, much better. Thanks.

> error for any other extension, and I don't see why we should have this for MIP.

If a Home Agent was requested, and the home agent is not available, then
the error is returned. This could occur if the mobile requested a home agent
that it is not allowed to, or if the home agent is no longer available.

> should be used instead. The comment applies also to section 4.1.

But MIP is special since the AAAH forward a message to the diameter client
that is requested by the mobile. So if the Diameter client is not accessible,
we could either return a non-reachable error, but I would prefer a more
specific MIP error.

Others?

> right? You can only tell that the MN is moving between domain based on the Realms.

Correct, so you will have to remove all the data, and the first dot, in the
fqdn, and that will produce the realm.

Did I miss the question?

> that a MIP-Registering-FA-FQDN AVP should be added for that purpose.

I really don't understand the problem (sorry, a little dense today), but
I see that you believe that a new AVP would be required that contains the
identity of the foreign agent, right? And why is that?

> or session keys are requested. Otherwise, the registration would go directly 

I believe that the new text that was added following yesterday's call now
makes this much clearer. I am waiting for some comments from my co-author,
and will release a preview for comments.

The base spec is quite clear though that the AAA infrastructure would be
contacted when the Authorization-Lifetime has expired.

> Also, I guess that the MN-AAA extension should also be mention in the list of

yes.

> the HAA must also include them unchanged."

fixed both, thanks.

> Also, the Original-Session-Id is not listed in the table 10.1

ok, and the Original-Session-Id goes away in the next base, as a result of
the conference call.

> inform the mobility agents (HA (co-located) or the FA).

correct.

> can still provide service to the MN. Check comment #7 again for that.

My parser unfortunately cannot decode comment 7, but I see your point. The
issue here, is that a MUST will rule out *any* mobile that doesn't support
this yet to be defined AVP (actually, I think it is in the route optimization)
I-D, and requiring support of RO would be a mistake.

> requested and that a Mobile-Node-Home-Address is requested. I don't see the need for

ok, I see your point. The information is redundant. However, I don't really
like that a zero HA or home address doesn't require that the AVP be present,
since a -1 value DOES require that it be present.

Do others agree that these two bits should be removed?

> foreign domain, before it forwards the AMR to the AAAH.

It now reads:

"If the mobile node requests a home agent in the foreign network either
by setting the home address field to all ones, or by specifying
a home agent in the foreign network, and the AAAF authorizes
the request, the AAAF MUST set the Home-Agent-In-Foreign-Network
bit to one."

> of the AVPs. Am I missing something? 

You use MIP-Authenticator-Offset to find the MN-AAA authenticator data
in the Registration Request, which is found in MIP-Reg-Request.

> encrypted by the Base protocol.

correct, I forgot to remove this text. The new text reads:

"If the AAAH does not communicate directly with the foreign agent, and
it does not wish for intermediate proxies to have access to the session
keys, they SHOULD be protected using the end-to-end security extension [9]."

> FA-MN-authentication extension to the reg-Reply.

correct.

> HA-FA-Authentication extension.

correct.

> be in alphabetical order.

That whole paragraph can go away, and the table should be in order.

 Also, the AVP defined in section 7.2 should be added to the
> table.

What table? I see all AVPs present in the table.

> 20-Section 7.2, the figure should be updated according to the description of the grouped-AVP.

correct.
> 21-Section 7.2.1 and 7.2.2, refer to section 7.2 instead of 6.2.

ooops

> 22- Section 8.2 and 8.5, should be "by the user" instead of "to the user".

Output packets and octets are those sent to the user, not by the user.
You are confusing these with the input counters.

> 23-Some updates to the table 10.1 as follows:

No, you can have more than on Filter-Rule AVP.
>    User-Name                     | 1   | 0   | 1   | 0   |

The ASI and API can be removed, as can that AVP.

> could be useful? Any idea?

One could wish to know what services were requested by the user. Home Agent
allocation? Home Address allocation? Perhaps it is more expensive to request
a home agent in a visited network?

Having said this, it is a GREAT reason to leave those two items in the 
Feature-Vector.

> the methods defined in [9]."

That sentence is fixed to:

"The keys SHOULD be be protected using the
methods defined in [9]."

Thanks for the great feedback!

PatC