Subject: [Dime] Meeting Minutes

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Aug 2007 23:59:14 +0200

Please check the meeting minutes:
http://www3.ietf.org/proceedings/07jul/minutes/dime.txt

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

---

From: <[email-masked]>
Date: Tue, 28 Aug 2007 23:55:42 +0200

Hi,

I think I was asked to review the draft-dime-mip6-split I-D. So here we
go.. Hopefully I got it right, as it is getting late here.

-------

General:

 o First impression: The I-D has issues and needs some serious work on
it.

 o About the RFC4285 support. The RFC4285 is Informational, so how was
this
   making a normative reference from a standards track I-D to an
informative
   RFC?

 o There is RFC4285bis coming out. Should the Dime I-D reference to that
   instead of RFC4285?

 o The IKEv2 based authentication talks only about EAP-based
authentication.
   However, mip6-aaa-ha-goals & RFC4877 does not have this restriction.
The
   Dime I-D should also reflect that and allow e.g. certificate based 
   authentication with IKEv2.

Section 4.

  >One task of the Mobile IPv6 bootstrapping procedure is to assign an
  >appropriate HA to the MN.  Furthermore, authorization and successful

  isn't HA known already at this phase? Finding the HA is more of
  integrated scenario task.

  >delivery of Mobile IPv6 to a MN through a HA, requires the HA to act

  "successful delivery of Mobile IPv6 to a MN through a HA.." is
supposed to
  mean what? I suggest rewriting this sentence.

  >as a client to the Diameter infrastructure interconnecting it to the
  >MSP.  As a Diameter client, the HA needs to perform the following
  >operations:

Section 5.1

  >application, as defined in [8], is re-used.  AVPs specific to Mobile
  >IPv6 bootstrapping are added to this command.

   How about something like:

   application, as defined in [8], is re-used.  AVPs specific to Mobile
   IPv6 bootstrapping are added to the EAP application commands.

  >As part of the authentication process, the MN MAY request a Home-
  >Address, a Home Prefix or suggests one, see [2], using a CFG_REQUEST

   The reference should be [3]

  >IKEv2 responder may not know if IK Ev2 is used for MIP6 service or
 
   s/IK Ev2/IKEv2

Section 5.2

   In the figure 3 would it be better to change MN-ID with MN-NAI.
   That is what it eventually tries to say. Also the MN-ID is not
   defined anywhere else than in this figure.

Section 6.

 o as said earlier, this I-D should not restrict the use of IKEv2
   to EAP only (see draft-mip6-aaa-ha-goals and RFC4877). Then we also
need
   support NASREQ commands within the Mobile IPv6 application. I know
there
   is "must" only for EAP but others are not explicitly excluded either

Section 6.1.1

 o For what purpose the MIP6-Feature-Vector is in DER & DEA messages?
   Its use is not explained anywhere?

 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.

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?

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

 o For what purpose MIP6-Feature-Vector is needed?
`
 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.

 o for MN-AAA computation the MRM is missing an AVP to carry a CoA
   to AAA

 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)

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

 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)

 o MN-AAA authentication probably needs an AVP to carry the
   timestamp from HA to AAA

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

 o We probably need an AVP to carry the mobility data or a
   MAC of the mobility data from HA to AAA

 o Use of MIP-Session-Key? I assume it is used to MN-HA calculation
   in a BA as the shared secret.

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

 o A reference to draft-ietf-mip6-whyauthdataoption would be usefull

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

Cheers,
	Jouni

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Thursday, August 16, 2007 12:59 AM
> To: [email-masked]
> Subject: [Dime] Meeting Minutes
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 29 Aug 2007 17:38:57 +0200

Hi Jouni,

thanks for the review. This is the first part of my response.

>    making a normative reference from a standards track I-D to an
We have to apply the Down-Ref procedures described in RFC 3967.

>  o There is RFC4285bis coming out. Should the Dime I-D reference to that
I have checked the changes between RFC 4285 and RFC 4285bis and I would 
agree that it is better to reference the RFC 4285bis.
We need to change that.

>    authentication with IKEv2.
That's a good point. This means that we would use only the authorization 
procedure. Is this correct?

>   mean what? I suggest rewriting this sentence.
This part has to be changed to make it more readable.

>    IPv6 bootstrapping are added to the EAP application commands.
Sounds good .

>    The reference should be [3]
Ok

>   >IKEv2 responder may not know if IK Ev2 is used for MIP6 service or
Fixed.

>    defined anywhere else than in this figure.
OK

>    is "must" only for EAP but others are not explicitly excluded either
I am not sure why we need to support NASREQ even when we add the 
certificate authentication support. We could just omit the 
authentication phase altogether.

I need more time with the rest of your comments. Will respond to them in 
a separate mail.

Ciao
Hannes

---

From: <[email-masked]>
Date: Wed, 29 Aug 2007 19:12:40 +0200

Hi Hannes,

Few quick comments.

> procedure. Is this correct?

I think it should be ok.

> authentication phase altogether.

This comes from the RFC4072 (EAP) section 2.3.3 and the comment
there:

  "The NASREQ application is used here for authorization because the
   realm-specific routing table supports routing based on application,
   not on Diameter commands."

The only text & examples in RFC4072 use NASREQ when Auth-Request-type
is set to AUTHORIZATION_ONLY.

Cheers,
	Jouni

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 30 Aug 2007 11:50:07 +0200

Hi Jouni,

thanks again for your extremely detailed review.

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

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

>    Is there a particular reason to neglect MN-HA auth option
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.

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

>    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
Is this missing in RFC 4004 as well or is this specific to MIPv6 
bootstrapping?

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

>    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
Why? RFC 4004 only defines one timestamp for accounting (see 
Event-Timestamp AVP).

>    authentication data from HA to AAA
Which authentication data?

>    MAC of the mobility data from HA to AAA
I guess this refers to the previously mentioned MIP-MN-AAA-Auth AVP. Right?

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

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

>  for their MIP6 HA-AAA interface. After all, they use RFC4285.
I will do that.

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 30 Aug 2007 15:16:53 +0200

Hi Hannes,

See my replies inline. 

> Sent: 30. elokuuta 2007 12:50
> 
> Hi Jouni,
> 
> 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.
> 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.

> The MIP-Mobile-Node-Address allows the AAA server to provide 
> the MN's HoA to be conveyed to the AAA client.

Yes. You should add that also to the document ;)

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

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

I don't think there's one.

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

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

> Is this missing in RFC 4004 as well or is this specific to MIPv6 

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.

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

> 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

Sorry, missed the MIP-MN-AAA-SPI in the MIP-MN-AAA-Auth grouped
AVP. That can be used for MN-AAA.

> I indeed thought that we could use the MIP-HA-to-MN-MSA AVP as is 

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.

> Why? RFC 4004 only defines one timestamp for accounting (see 

Some deployments might want to use timestamp as one parameter that
is used by the AAA to derive session keys.

>From the Message Auth option.. if AAA does the MN-AAA authentication
it probably wants to have the authentication data.

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

> semantic depends on the grouped AVP it is carried in.

Probably those semantics should be explained.

> authentication procedure (regarding the communication from 

It is close but not replica.

> I don't think we need that since this is mostly a job of RFC 

Ok.

Cheers,
	Jouni