FW: Review of draft-nakhjiri-radius-mip4-01.txt

[Jari Arkko <jari.arkko@piuha.net>]

I reviewed this draft for the mobility directorate, as
its attempting to become a WG item in the MIP4 WG.
See review below.

Does anyone else want to comment on this? Was there
a history of this draft in RADEXT, or has anyone reviewed
this in the AAA Doctors team?

-------

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