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

[<[e-mail]>]

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.

> >  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 ;)

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

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

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

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

> >  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 ;)

If AAA does MN-AAA authentication it needs CoA and HoA to
verify the authentication data provided by the HA and MN.

> >  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? 

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. 

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

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

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

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

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

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


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