Re: review of dime-mip6-split; was RE: [Dime] Meeting Minutes

Hi Jouni,

thanks again for your extremely detailed review.

A few more comments below:

> Section 6.1.1
>
>  o For what purpose the MIP6-Feature-Vector is in DER & DEA messages?
>    Its use is not explained anywhere?
>
>   
Currently, the MIP6-Feature-Vector contains the following values:

(a) MOBILITY_CAPABILITY
(b) MIP6_INTEGRATED
(c) LOCAL_HOME_AGENT_ASSIGNMENT

Item (a) is not really required because the AAA server is able to learn 
about the Diameter client's mobility capability from the MIP6 App-ID.
Item (b) is not applicable since this is not the integrated scenario.
This leaves us with item (c). If the AAA client is not in the same 
domain as the AAA server then this could be useful. Right?

>  o The use of the MIP-Mobile-Node-Address in both DER & DEA messages
>    are not explained anywhere. I would expect that at least why it is
>    needed in DEA would be explained.
>   
The MIP-Mobile-Node-Address allows the AAA server to provide the MN's 
HoA to be conveyed to the AAA client.
Does this make sense to you?

> Section 6.2
>
>  o this section and its subsections need a major rework..
>
>  o The current text only talks about using MN-AAA auth option.
>    Is there a particular reason to neglect MN-HA auth option
>    for BUs?
>   
Ideally, dime-mip6-split should be as close to RFC 4004 with regard to 
the usage of the communication between the HA and the AAA server.
Hence, we should definitely make utilize MIP-MN-AAA-Auth (as defined in 
Section 7.6 of RFC 4004) as it is used in the AA-Mobile-Node-Request 
(AMR) message of RFC 4004.

When you look at Section 6.2.1 of dime-mip6-split then you will find the 
MIP-MN-AAA-Auth AVP.

Hence, I believe things are in place.

>  o There should be an AVP to distinguish between MN-AAA and
>    MN-HA operations towards AAA.
>   

In what sense? What AVPs from RFC 4004 would be needed?

>  o For what purpose MIP6-Feature-Vector is needed?
>   
Do you mean that we should instead use the MIP-Feature-Vector AVP from 
RFC 4004?

> `
>  o MIP-MN-AAA-Auth AVP cannot really be used.. as it just points
>    byte ranges within the BU. We do not seem to pass the BU from
>    HA to AAA in the MRM message.
>   
This is what RFC 4004 says:

7.6.  MIP-MN-AAA-Auth AVP

   The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains
   some ancillary data to simplify processing of the authentication data
   in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the
   target AAA server.  Its value has the following ABNF grammar:

         MIP-MN-AAA-Auth ::= < AVP Header: 322 >
                             { MIP-MN-AAA-SPI }
                             { MIP-Auth-Input-Data-Length }
                             { MIP-Authenticator-Length }
                             { MIP-Authenticator-Offset }
                           * [ AVP ]

I agree with you that we cannot right away use it.

I will investigate what other SDOs did, such as 3GPP2 or Wimax, with 
respect to this issue. I will come back to you on this one.

>  o for MN-AAA computation the MRM is missing an AVP to carry a CoA
>    to AAA
>   
Is this missing in RFC 4004 as well or is this specific to MIPv6 
bootstrapping?

>  o MIP-MN-to-HA-SPI & MIP-HA-to-MN-SPI are only usable for
>    MN-HA auth option that this I-D does not support at the moment
>    for Bus (btw.. I am not sure whether RFC4285 actually can have
>    different SPIs to different directions)
>   
Could you please clarify your comment regarding MIP-MN-to-HA-SPI & 
MIP-HA-to-MN-SPI? I am not sure I understood the problem.

Regarding the SPIs: I believe we should re-use RFC 4004 as much as 
possible to avoid additional implementation complexity on the AAA server 
side.
In RFC 4004 two different SPIs are used.

>  o We need a generic SPI AVP.. also for MN-AAA authentication
>   
Why?

>  o for MN-HA authentication we probably need an AVP to return
>    the shared key from AAA to HA (well.. the used MIP-HA-to-MN-MSA
>    AVP could do but its use should be specified as it is a
>    grouped AVP and not all sub-AVPs are needed)
>   
I indeed thought that we could use the MIP-HA-to-MN-MSA AVP as is 
(without modifications).

>  o MN-AAA authentication probably needs an AVP to carry the
>    timestamp from HA to AAA
>   
Why? RFC 4004 only defines one timestamp for accounting (see 
Event-Timestamp AVP).

>  o MN-AAA authentication probably needs an AVP to carry the
>    authentication data from HA to AAA
>   
Which authentication data?

>  o We probably need an AVP to carry the mobility data or a
>    MAC of the mobility data from HA to AAA
>   
I guess this refers to the previously mentioned MIP-MN-AAA-Auth AVP. Right?

>  o Use of MIP-Session-Key? I assume it is used to MN-HA calculation
>    in a BA as the shared secret.
>   
The MIP-Session-Key AVP is contained in a couple of grouped AVPs. It's 
semantic depends on the grouped AVP it is carried in.

>  o Giving explanations of AVP usage and even RFC4285 compliant
>    examples of auth option processing would be most beneficial.
>    The RFC4285 has always been somewhat foggy ;)
>   
RFC 4285 is, in my opinion, a replica of the corresponding MIPv4 
authentication procedure (regarding the communication from the HA to the 
AAA server).

>  o A reference to draft-ietf-mip6-whyauthdataoption would be usefull
>
>   
I don't think we need that since this is mostly a job of RFC 
4285/RFC4285bis.

>  I think it would be beneficial to check what e.g. 3GPP2 did
>  for their MIP6 HA-AAA interface. After all, they use RFC4285.
>
>   
I will do that.

Ciao
Hannes

> Cheers,
> 	Jouni
>
>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
>> Sent: Thursday, August 16, 2007 12:59 AM
>> To: dime@ietf.org
>> Subject: [Dime] Meeting Minutes
>>
>>
>> Please check the meeting minutes:
>> http://www3.ietf.org/proceedings/07jul/minutes/dime.txt
>>
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime
>>
>>     

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime