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

[Hannes Tschofenig <[e-mail]>]

Hi Jouni,

[e-mail] wrote:
> Hi Hannes,
>
> See my replies inline. 
>
>   
>> Sent: 30. elokuuta 2007 12:50
>>
>> 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?
>>     
>
> Fine. This question was motivated because MIP6-Feature-Vector is
> a new AVP to HA-AAA interface but the document does not really
> describe anything about it. IHMO there must be some text to describe
> its desired use in that interface.
>
>   
Do you agree with me that item (c) at least would be useful to communicate?

A different subject is how the Diameter Mobile IPv4 MIP-Feature-Vector 
plays into this picture when the MIPv6 Authentication protocol is used 
since we said that we would want to maximize the usage of Diameter 
Mobile IPv4.

>>>  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?
>>     
>
> Yes. You should add that also to the document ;)
>
>   
OK.

>>> 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.
>>     
>
> The way RFC4285 calculates MN-HA and MN-AAA are different.
> MN-HA is more or less local with fixed algorithms, except
> that you might receive the shared-key from the AAA. On the
> other hand you can let AAA do all MN-AAA calculations.. or
> divide it between HA and AAA. It should be clarified what AVPs
> to use and what to put into those when processing MN-HA or
> MN-AAA received from the MN.
>
> Even if we are reusing RFC4004 AVPs we cannot assume that
> it is directly clear what to do.
>
>   
This is a larger issue and I plan to address it in a separate mail.


>> 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?
>>     
>
> I don't think there's one.
>
>   
Hmmm. I am not sure I understood the problem why once would need to 
differentiate the two.

>>>  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?
>>     
>
> No, I just want a line of text saying for what and how the AAA
> expects to use the MIP6-Feature-Vector. We have defined few
> values for integrated scenario and explained their use in that
> domain. Would be nice to have the same for split scenario aswell.
>   
It is true that it might be useful to say what values should be used and 
what their semantic is.
In some sense that raises the question why we would like to re-use the 
same AVP in the first place since
* some values of the MIP6-Feature-Vector as defined in the NAS<->AAA 
document just don't make sense in the HA<->AAA document.
* other values cannot just be used without explaining the semantic.

>   
>>>  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.
>>     
>
> RFC4004 passes the whole BU message in the AMR to AAA. 3GPP2
> passes only those parts of the message that are needed to
> for MN-AAA authentication. 3GPP has no clue ;) And WiMAX does
> its own thing. All those are deployment dependant. It  might 
> be really hard to come up with a proper HA-AAA interface for
> RFC4285 that is actually usable.
>   
That's indeed a difficult issue. I personally do not like the way how 
things were design in RFC 4004 with respect to this issue.
Still, RFC 4004 puts the entire Registration Request into the keyed hash 
calculation. I wanted to re-use RFC 4004 as much as possible I do, 
however, see the problems.

>   
>>>  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?
>>     
>
> RFC4004 passes the whole BU to AAA.. so it finds the CoA etc by
> parsing the data. I think this is not the right way ;)
>   
So far we tried to be as close to RFC 4004 as possible in the believe 
that people would just be able to re-use most parts of their 
implementation (at least the part that provides the HA<->AAA interface). 
Now, in this particular space this is obviously not possible given that 
the MIPv4 Registration Request just looks different than the MIPv6 
Binding Update. Now, we have can decide whether we want to follow the 
same design approach (in this case by passing the entire BU to the AAA 
server) or whether we want todo something different.

In fact, there are already two different approaches (in my understanding 
of RFC 4721) already:

Section 8 of RFC4721 says that the home agent can hash all the Mobile IP 
data before sending it to the  HA. As an argument the size restrictions 
for RADIUS are provided.

> If AAA does MN-AAA authentication it needs CoA and HoA to
> verify the authentication data provided by the HA and MN.
>
>   
When we consider NAT traversal then I wonder whether the CoA is actually 
of big value. There will also be NAT traversal with IPv4/IPv6 scenarios 
where the MIPv6 dual stack is used.

>>>  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.
>>     
>
> Well.. for MN-AAA authentication you would use MIP-MN-AAA-SPI (that is
> part of MIP-MN-AAA-Auth grouped AVP. So if you authentication MN using
> MN-AAA you don't use MIP-MN-to-HA-SPI etc, right? 
>   

I re-read all the MIPv4 RFCs yesterday and it was somewhat hard to 
figure out what the expect behavior was but my interpretation is that the
security association between the MN and the HA is, apart from 
theoretical investigations, not keyed based on the SPI but the NAI is 
used instead.

Translating this to MIPv6  the text from Section 3.1 and Section 8 of 
RFC 4721 is relevant. It says that a "special" SPI is used (CHAP_SPI) 
and a specific key derivation function is given. It seems also that the 
NAI is used in that particular case to select the keying material.

> And the current text in the draft does not difference between
> MN-HA and MN-AAA authentications. They would need slightly
> different set or way of using AVPs. These should be clarified.
>
>   
>> 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.
>>     
>
> Yes.. my question in parenthesis was something more general related
> to RFC4285. 
>
>   
Good question.

>>>  o We need a generic SPI AVP.. also for MN-AAA authentication
>>>   
>>>       
>> Why?
>>     
>
> Sorry, missed the MIP-MN-AAA-SPI in the MIP-MN-AAA-Auth grouped
> AVP. That can be used for MN-AAA.
>
>   
>>>  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).
>>     
>
> Within the MIP-HA-to-MN-MSA AVP we don't seem to need MIP-Algorithm-Type
> as RFC4285 has a fixed one. Hmm.. maybe we could state that for the
> MN-HA authentication the algorithm is always set to HMAC-SHA-1 (2)
> within RFC4285 scope.
>   
The problem with this approach is that we are now supposed to provide 
crypto agility for all protocols. This allows that the algorithms can be 
changed as part of the protocol.

I wonder whether the authors of RFC 4285bis will get away with it.

>   
>>>  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).
>>     
>
> Some deployments might want to use timestamp as one parameter that
> is used by the AAA to derive session keys.
>
>   
Correct. Since there is no timestamp field in Diameter Mobile IPv4 there 
are two possible cases:
* the authors forgot to put it in there.
* somehow the functionality is provided in a different way and hence an 
explicit timestamp AVP is not needed.

I could guess that the fact that the Registration Request is essentially 
"piggybacked" to the AAA server the timestamp is therefore included as 
well.
Do you agree with me?

>>>  o MN-AAA authentication probably needs an AVP to carry the
>>>    authentication data from HA to AAA
>>>   
>>>       
>> Which authentication data?
>>     
>
> >From the Message Auth option.. if AAA does the MN-AAA authentication
> it probably wants to have the authentication data.
>   
Correct.

>   
>>>  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?
>>     
>
> Not really. MIP-MN-AAA-Auth AVP does not provide way to
> transfer e.g. calculated MAC mobility data calculated
> HA to AAA, if HA wished to do that calculation.
>
>   
Correct. This functionality cannot be found in RFC 4004 since it was 
specified in RFC 4721.

>>>  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.
>>     
>
> Probably those semantics should be explained.
>
>   
>>>  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).
>>     
>
> It is close but not replica.
>
>   
I think we should post a mail to the MIPv6 list and ask the authors 
whether they believe that there is a difference and if so, what the 
differences are.

>>>  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.
>>     
>
> Ok.
>
>
>   
Ciao
Hannes

> Cheers,
> 	Jouni
>
>
>   
>>>  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:[e-mail]] 
>>>> Sent: Thursday, August 16, 2007 12:59 AM
>>>> To: [e-mail]
>>>> Subject: [Dime] Meeting Minutes
>>>>
>>>>
>>>> Please check the meeting minutes:
>>>> http://www3.ietf.org/proceedings/07jul/minutes/dime.txt
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/dime
>>>>
>>>>     
>>>>         
>>     


_______________________________________________
DiME mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dime