Subject: [Mip4] review of draft-nakhjiri-radius-mip4-01.txt

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Oct 2005 14:10:13 +0300

I reviewed this draft. As I think I've said before, I believe
we need this type of functionality. Overall, the draft
is in reasonable shape, but needs more details in
several areas. The main worry that I had was that
I could not determine the functional and architectural
similarity/interoperability between this and RFC 4004,
Diameter MIP4. (But it could also be because I'm not
an expert in RFC 3957/4004.)

My gut feeling is that this draft needs another revision
before it can be adopted as a WG item.

Please find some questions and comments below:

Technical:

>     <User-Name>, (preferably MIP-MN-NAI from RRQ) 

"Preferrably" sounds vague. Supposedly this MUST or
SHOULD be the MIP-MN-NAI if it was given, and otherwise
its ... something else. Make this more exact (or refer to
the section that describes this better later).

>    If a RADIUS forwarding server does not have enough information to
>    route the packet, it shall send an Access Reject towards the NAS.

Do we need to specify inter-proxy RADIUS routing here?
Is there something new compared to existing RADIUS routing?

>   4.1 RADIUS server and routing requirements
>     
>    ...
>  
>    User-Password (2), CHAP-Password(3), CHAP challenge(60), and ARAP-
>    Password(70) MUST not be present in an Access-Request packet
>    containing the attributes discussed in this document.

Presumably the server is not sending Access-Request packets?

>   6. Diameter compatibility considerations
>    
>  
>    Diameter Mobile IP application has defined new command codes for
>    support of Mobile IP signaling such as, AA-Mobile node request (AMR),
>    AA-Mobile Node answer (AMA), Home agent MIP-request (HMR), Home agent
>    MIP-answer (HMA). RADIUS currently does not any messages that
>    correspond to these Diameter commands. However RADIUS provides the
>    flexibility of defining new command codes. The solution in this draft
>    is designed based on the assumption that the RADIUS community (and
>    RADEXT) is not interested in defining new RADIUS messages hence we

This is fine. Nevertheless, you should define what the mapping
is, e.g., when you see an Access-Request with certain RADIUS MIP4
attributes, then you map this into a specific Diameter command.

>    will be using RADIUS access request and RADIUS access accept for
>    providing messaging from mobility agents to RADIUS server and vice
>    versa. This would impose new complexity on the Diameter-RADIUS
>    interaction. On the other hand, we tried to follow the Diameter
>    attribute type definition model to extent possible for RADIUS. One
>    exception is the fact that RADIUS does not have any support for
>    grouped attributes, the way Diameter does. 

This is fine too, but I fail to see what exactly is the relationship
and compatibility between the two protocols. There's a close
relationship between the attributes, but they are not identical.
For instance, what's the corresponding attribute to MIP-HASH-RRQ?
Also, if you compare Fig 2a to Figure 1 in RFC 4004, they look
quite different. Is this because you've chosen a different example
but both protocols can do the same operation, or is this a more
fundamental difference? Also, RFC 4004 talks about home agent
allocation, does this draft support it?

> 3. Protocol overview

To ease the process in the future (e.g. IESG) it
would probably make sense to provide a clearer
distinction of what new this document gives and
what's already defined in other RFCs (e.g. MIPKEYS,
Diameter MIP, 3012).

>   7.     IANA considerations
>    
>    This draft introduces new RADIUS attributes. Therefore there is need
>    for defining new attribute type numbers by IANA.

Needs more work. They want details, which attributes. I would also
suggest same name space Diameter enumerated values, e.g.,
MIP-Feature-Vector.

>    
>         MN            FA          HA      AAAF       AAAH 
>         --            ---        ----     ---        ----
>         |              |          |        |          |
>         |Ad+Challenge |           |        |          |
>         | <---------   |          |        |          |
>         | RRQ-----.  |           |        |          |
>         |              |Access Request(RRQ)| Access   |
>         |              | ----------------> | Req (RRQ)|
>         |              |          |        |-------. |
>         |              |          |        |Acc. Accpt|
>         |             |           |        |(key mtrl |
>         |             |           |        | for FA   |
>         |             |           |        |< --------|
>         |              | Access Accept     |          |
>         |              | <-----------------|          | 
>         |           |  RRQ     |        |          |
>         |              | -------->|        |          |
>         |              |          | Acc. Request(RRQ) |
>         |              |          |  ----------->     |
>         |              |          | Acc. Accept       |
>         |             |          |(key mtrl for HA)  |
>         |              |(RRP)     |< -----------------|
>         |     RRP      |<-------  |        |          |
>         | < --------   |          |        |          |

I'm hoping that the home AAA server does not
need to remember anything between the two
Access-Requests.

Editorial:

>    The HA may reside in the mobile nodeÆs home domain, in which case HA 

Non-ascii char. Multiple occurrences.

>   3.1 Co-located mobile nodes 

The bulleted (.) list in this section has some
indentation issues.

> Note that, this

s/,//

>             user-name attribute.  

I would prefer exact capitalization here because we are referring
a RADIUS attribute with a specific name (User-Name). Multiple
occurrences.

>         (4.2). Attributes included inside ææ<>ÆÆ are optional.  

The list folllowing this was hard to read. Consider adding
bullets, table format, or empty lines to make it clearer.

And non-ASCII chars.

>                   MIP-MN-HA-nonce,
>                   MIP-MN-HA-ALGORITHMID,
>                   MIP-MN-HA-REPLAY,
>                   MIP-MN-HA-MSA-LIFETIME
>                   Message-Authenticator (80)

Inconsistent capitalization. Follow the usual
RADIUS style (e.g. MIP-MN-HA-Nonce or
MIP-MN-HA-Replay)?

>    request without creating RADIUS messaging. The details of the 

s/creating/initiating/ (or ... without sending RADIUS messages)

>   5. Attributes
>     
>    
>      . User-name 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |            String ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    Name 

I think its great that you discuss each attribute separately in
the document, including the ones that have already been defined
and which just need explanation of how they are used here.
However, I would avoid repeating the format and type numbers etc,
and concentrate only on the expected content guidelines.

--Jari

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 13 Oct 2005 12:24:52 -0400

Hi Ari,

Thank you very much for the detailed set of comments. First of all, we are running behind on the schedule for mip4-00 since we were planning on a V02 individual for this time around, so we were counting on another week, so for that reason, we will do another rev before we will submit mip4-00 draft, so your first concern is addressed there.

In my opinion and based on the comments we received so far, the document is rapidly maturing from the MIP standpoint, but needs more work from RADIUS/ Diameter standpoint and so the more review it gets from that community the better. I was not sure if posting the draft to RADEXT for comments was ok by MIP chairs??

Most of the work we are doing for V02 deals with attribute definitions and Diameter translation. I will go through your comments and address them as I am going through the draft and will either fix and ask questions if I don't know how (if you don't mind).

My first question is related to text that we had dealing with NAIs at HA/ FA.
The HA and FA are supposed to act as RADIUS clients and they may see NAI within RRQ extensions. We had some text about the routability of the NAI. We are now wondering if the RADIUS client (HA or FA) can pass any judgment if an NAI is valid/ appropriate/routable...
Or it must just extract the NAI from RRQ, build the Access Request with NAI as User-Name and pass it along?

Thanks,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Thursday, October 13, 2005 6:10 AM
To: [email-masked]
Subject: [Mip4] review of draft-nakhjiri-radius-mip4-01.txt

I reviewed this draft. As I think I've said before, I believe we need this type of functionality. Overall, the draft is in reasonable shape, but needs more details in several areas. The main worry that I had was that I could not determine the functional and architectural similarity/interoperability between this and RFC 4004, Diameter MIP4. (But it could also be because I'm not an expert in RFC 3957/4004.)

My gut feeling is that this draft needs another revision before it can be adopted as a WG item.

>     <User-Name>, (preferably MIP-MN-NAI from RRQ)

"Preferrably" sounds vague. Supposedly this MUST or SHOULD be the MIP-MN-NAI if it was given, and otherwise its ... something else. Make this more exact (or refer to the section that describes this better later).

>    RADEXT) is not interested in defining new RADIUS messages hence we

This is fine. Nevertheless, you should define what the mapping is, e.g., when you see an Access-Request with certain RADIUS MIP4 attributes, then you map this into a specific Diameter command.

>    grouped attributes, the way Diameter does. 

This is fine too, but I fail to see what exactly is the relationship and compatibility between the two protocols. There's a close relationship between the attributes, but they are not identical.
For instance, what's the corresponding attribute to MIP-HASH-RRQ?
Also, if you compare Fig 2a to Figure 1 in RFC 4004, they look quite different. Is this because you've chosen a different example but both protocols can do the same operation, or is this a more fundamental difference? Also, RFC 4004 talks about home agent allocation, does this draft support it?

> 3. Protocol overview

To ease the process in the future (e.g. IESG) it would probably make sense to provide a clearer distinction of what new this document gives and what's already defined in other RFCs (e.g. MIPKEYS, Diameter MIP, 3012).

>    for defining new attribute type numbers by IANA.

Needs more work. They want details, which attributes. I would also suggest same name space Diameter enumerated values, e.g., MIP-Feature-Vector.

>         MN            FA          HA      AAAF       AAAH 

I'm hoping that the home AAA server does not need to remember anything between the two Access-Requests.

>   3.1 Co-located mobile nodes

The bulleted (.) list in this section has some indentation issues.

s/,//

>             user-name attribute.  

I would prefer exact capitalization here because we are referring a RADIUS attribute with a specific name (User-Name). Multiple occurrences.

>         (4.2). Attributes included inside ææ<>ÆÆ are optional.  

The list folllowing this was hard to read. Consider adding bullets, table format, or empty lines to make it clearer.

And non-ASCII chars.

>                   Message-Authenticator (80)

Inconsistent capitalization. Follow the usual RADIUS style (e.g. MIP-MN-HA-Nonce or MIP-MN-HA-Replay)?

>      . User-name 

I think its great that you discuss each attribute separately in the document, including the ones that have already been defined and which just need explanation of how they are used here.
However, I would avoid repeating the format and type numbers etc, and concentrate only on the expected content guidelines.

--Jari