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

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 11 Apr 2001 15:18:48 +0200

Sorry for the partly duplicate mail, slipped on the keyboard and managed to
send the previous mail before I was finished with it. Anyway, here is the
rest :-)

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

In the ABNF for the AMR {Session-ID AVP} should be <Session-ID AVP>

Section 1.4

Maybe there should be a note that CHAP style authentication cannot be used
since the client will not receive a challenge. Or should this only be stated
in RFC 3012?

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 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? what did we agree on? was
it Generalized Key Request with subtypes depending on what key?

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

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

AHA -> HAA

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

Queue?!? Sounds like this should be under section 6.2 and it should be:
"Upon receipt of the AMA, the foreign agent recovers the Foreign-Mobile
 registration key, and uses this key to create a Mobile-foreign
 authentication extension to the Registration Reply message."

Section 7.1.1
"The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type OctetString, and
   contains the Keying material described in the "Unsolicited MN-FA Key
   from AAA Subtype" in [15]. The FA SPI field of the data structure in
   [15] MUST be set to the same value as the MIP-Peer-SPI AVP within the
   FA-to-MN-Key AVP."

Change according to the new AAA keys for MIP draft (when there is a new
version :-))

Section 7.1.2
same as 7.1.1

Section 7.2

I believe that we should add AVPs in the Grouped AVP that indicates what
algorithm type/mode, replay protection, to use. As it is today, the MIP
agents can only assume that some default mode is used. This is in the same
way as we agreed that the MIP Key Reply extension should be extended in the
AAA Keys for MIP draft (or if it was in Charlies "generalized key draft")

Section 10.2

In the table it is indicated that all of Session-Time, Packet, and Octets
AVPs MUST be present in ACR and ACA. Is it really mandatory to allways
measure both time, packets and bytes. If you only do time based accounting,
why should you have to send the other two types? Or should you send them
with a value of zero?

/Fredrik

---

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

and here is the rest....

>  authentication extension to the Registration Reply message."

It is in the right section, but it should read:

"Upon receipt of the AMA, the foreign agent recovers the Foreign-Home
 registration key, and uses this key to create a Foreign-Home
 authentication extension to the Registration Reply message."

> Change according to the new AAA keys for MIP draft (when there is a new

ok

> AAA Keys for MIP draft (or if it was in Charlies "generalized key draft")

You are correct.

> why should you have to send the other two types? Or should you send them

Well, I don't see how it hurts to send them all, and the billing package uses
the information that it wants to generate the bills. 

PatC