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

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 11 Apr 2001 14:06:32 +0200

Here are some comments and suggestions for the aaa-mip draft.

"This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the [email-masked] mailing list."

Not really true, is it? :-) especially not the email address

Section 1.2
"If AAAH does not know the address of the home agent (perhaps because
   it will be allocated by AAAF within the visited domain as described
   in section 1.3), then AAAH sends an AMA message back to AAAF which
   does not contain a MIP-Reg-Reply AVP."

It will send a HAR not an AMA.

Section 1.4

Maybe there should be a note that CHAP style authentication cannot be used
since the client will not receive a challenge.

Section 1.5
Should you really force the AAAF to keep session state?

Section 2.1
"If the MIP-Previous-FA-FQDN AVP is found in the request, the Diameter
   client requests that the server return the registration key that was
   assigned to the previous Foreign Agent for use with the Mobile Node
   and Home Agent. The registration key is identified through the use of
   the MIP-Mobile-Node-Address AVP."

the key should be identified by the User-Name AVP

B.T.W. what should the result code be, what I'm thinking about is that
section 2.2 says

"An AMA message with the Result-Code AVP indicating success MUST also
   include the MIP-Reg-Reply AVP."

and if AAAF should be able to return the keys it has to do so without a
MIP-Reg-Reply AVP.

Section 3.1 and Section 4.1 both have a error code of 4004 and 4002-4003 are
used in the base protocol.

Section 5.5-6

Clarification needed. What should the reply code be? A note that the FA
should send the MIP-Reg-Request directly to the HA when it has received the
needed keys.

Section 5.7

"If the mobile node includes a Generalized MN-FA Key Request [15]
   extension with the AAA subtype in its Registration Request, the"

Should it be the Generalized MN-FA Key Request or will it change when the
AAA Registration Keys for Mobile IP is rewritten?

Section 5.8.1
"The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
   indicates the algorithm by which the targeted AAA server (AAAH)
   should attempt to validate the Authenticator computed by the mobile
   node over the Registration Request data."

Pat, didn't we agree on rewriting this to conform with the way the SPI is
used in MIP, i.e. the SPI indicates a security context which contains Key,
Lifetime, Algorithm, Algorithm mode ...

Section 5.10
"The Filter-Rule AVP (AVP Code 400) is of type OctetString, encoded in
   the UTF-8 [29] format, and provides filter rules that need to be
   configured on the Foreign Agent for the user. One or more such AVPs
   MAY be present in an authorization response."

I believe that it should be possible to configure the home agent as well,
I'm not sure that the home agent would like to trust the FA to do the
filtering.

more on section 5.10

"If no rule matches, the packet is dropped if the last
   rule evaluated was a permit, and passed if the last rule was a deny."

This sounds kind of strange, shouldn't you allways drop the packet if no
match was found?

Section 6.0
typo in 3rd paragraph: generatied -> generated

section 6.1
"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."

Same as in 5.8.1, shouldn't it be Mobile IP Generalizeed Key Reply after the
key dist. draft is rewritten?

". The resulting Registration Reply is
   added to the MIP-Reg-Reply AVP and added to the AHA."

AHA should be AMA

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

Generalized MN-HA Key Reply -> Generalized Key Reply with subtype MN-HA

section 6.2
"
   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."

Generalized MN-FA Key Reply Extension -> Generalized Key Reply Extension
with subtype MN-FA

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 26 Apr 2001 09:26:59 -0700 (PDT)

> It will send a HAR not an AMA.

Actually the paragraph should read:

"If the AAAH does not know the address of the home agent (perhaps because it
will be allocated by AAAF within the visited domain as described in
section 1.3), then AAAH sends an HAR message to AAAF which contains a
MIP-Reg-Request AVP."

> since the client will not receive a challenge.

Why can't the Home Agent issue Challenges in its advertisements?

> Should you really force the AAAF to keep session state?

I see the issue, and can enforce that only the HA can receive an STR. However,
this will NOT permit the AAAF to issue a disconnect. How would a Foreign Agent
terminate service?

> and if AAAF should be able to return the keys it has to do so without a

ok, so would a request for keys include a MIP-Reg-Request? If not, then the
fix is simple, otherwise it is quite a bit more difficult. The reality is that
you do not know whether the request will be sent to the AAAH or not.

(Is it possible that transfering keys can be done outside of AAA? Perhaps
context transfer, or via the FA blob that MIP was looking at some time back?)

> used in the base protocol.

DSI Events and Result-Codes do not share the same address space, so there is
no conflict.

> should send the MIP-Reg-Request directly to the HA when it has received the

I believe this is the same question as above. See my previous question.

> AAA Registration Keys for Mobile IP is rewritten?

The name will be the same, I believe.

However, I will look at this once more when I am done with the other draft.

> Lifetime, Algorithm, Algorithm mode ...

No, I *thought* our agreement was in relation to the MIP AAA Keys draft, which
would now include all of this information. no?

> I'm not sure that the home agent would like to trust the FA to do the

right.

> This sounds kind of strange, shouldn't you allways drop the packet if no

Please query Barney Wolff in a separate thread on this one. 

> key dist. draft is rewritten?

Let's wait and see what the outcome of the MIP AAA Keys changes result.

> Generalized MN-HA Key Reply -> Generalized Key Reply with subtype MN-HA

see above.

> Generalized MN-FA Key Reply Extension -> Generalized Key Reply Extension

ditto.

Thanks for the comments!

PatC