Subject: [Dime] Review of draft-ietf-dime-mip6-split-04

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jul 2007 08:23:17 -0700

Hello,

I reviewed draft-ietf-dime-mip6-split-04.txt recently. The document
needs a lot of work.

At a high level, I suggest splitting the document into two. One
document to address the use of IKEv2/IPsec with MIPv6 and the other
to address the use of RFC 4285 with MIPv6. There are numerous
reasons for this. The document seems to define a new app-id for use
only when RFC 4285 is used. But throughout the document, it seems to
indicate that the AAA servers must support this app-id and indicate
support for it. There are few places in the document which says for
use with IKEv2/IPsec, the Diameter EAP application is re-used. No
new app-id.

The second issue is process related. RFC 4285 is Informational. If
this document needs to be on the Standards Track, it can't have
normative dependency on RFC 4285. So you are better off with Dime
extensions for RFC 4285 being in a separate Informational document.

This document only addresses the use of EAP-based authentication
between the mobile node and the home agent. This is not adequate.
RFC 4877 says other authentication methods are possible, more
specifically the use of pre-shared keys and certificates for IKEv2
authentication. The HA - AAA interface must support delivering the
shared key, that can be used for IKEv2 authentication, at the
minimum. This would need some extensions. Obviously the Diameter EAP
application cannot be used.

There are a couple of sentences about support for accounting on the
home agent. I understand having text in the document that says
the HA - AAA interface must provide accounting support. But the
document says the HA must support accounting and must collect
"accounting records". :)

Regarding support for RFC 4285, I don't understand how the AVPs
from MIPv4 Diameter application can be re-used. For example, the
MIP-MN-to-HA-MSA talks about a nonce. Will the timestamp from the
RFC 4285 binding update be used as a nonce? In MIPv4, the nonce is
sent from the AAA server to the mobile node. There is no similar
thing in RFC 4285. (I could be wrong). You would need to define a
new AVP that carries the MIPv6 home address, since we now have a
128-bit address. The MIP-Mobile-Node-Address from 4004 cannot be
used.

Vijay

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Jul 2007 17:28:06 +0200

Thanks for the review. I will respond to your detailed comments a bit 
later.

I also noticed that including the IKEv2/IPsec and RFC 4285 made the 
document far more complex to read and understand.

---

From: <[email-masked]>
Date: Wed, 25 Jul 2007 17:41:20 +0200

I do agree most of the Vijay's findings here. The addition of 
RFC4285 did mess up the doc for good. Maybe a split of the draft
would be the way to go.

RFC4004 MIP-Mobile-Node-Address can be used actually. The AVP
type is Address that can carry both IPv4 or IPv6 addresses.
The RFC3588 encoding provides native support for this.

Cheers,
	Jouni

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 25. heinäkuuta 2007 18:23
> To: [email-masked]
> Subject: [Dime] Review of draft-ietf-dime-mip6-split-04
> 
> 
> Hello,
> 
> I reviewed draft-ietf-dime-mip6-split-04.txt recently. The 
> document needs a lot of work.
> 
> At a high level, I suggest splitting the document into two. 
> One document to address the use of IKEv2/IPsec with MIPv6 and 
> the other to address the use of RFC 4285 with MIPv6. There 
> are numerous reasons for this. The document seems to define a 
> new app-id for use only when RFC 4285 is used. But throughout 
> the document, it seems to indicate that the AAA servers must 
> support this app-id and indicate support for it. There are 
> few places in the document which says for use with 
> IKEv2/IPsec, the Diameter EAP application is re-used. No new app-id.
> 
> The second issue is process related. RFC 4285 is 
> Informational. If this document needs to be on the Standards 
> Track, it can't have normative dependency on RFC 4285. So you 
> are better off with Dime extensions for RFC 4285 being in a 
> separate Informational document.
> 
> This document only addresses the use of EAP-based 
> authentication between the mobile node and the home agent. 
> This is not adequate.
> specifically the use of pre-shared keys and certificates for 
> IKEv2 authentication. The HA - AAA interface must support 
> delivering the shared key, that can be used for IKEv2 
> authentication, at the minimum. This would need some 
> extensions. Obviously the Diameter EAP application cannot be used.
> 
> There are a couple of sentences about support for accounting 
> on the home agent. I understand having text in the document 
> that says the HA - AAA interface must provide accounting 
> support. But the document says the HA must support accounting 
> and must collect "accounting records". :)
> 
> Regarding support for RFC 4285, I don't understand how the 
> AVPs from MIPv4 Diameter application can be re-used. For 
> example, the MIP-MN-to-HA-MSA talks about a nonce. Will the 
> timestamp from the RFC 4285 binding update be used as a 
> nonce? In MIPv4, the nonce is sent from the AAA server to the 
> mobile node. There is no similar thing in RFC 4285. (I could 
> be wrong). You would need to define a new AVP that carries 
> the MIPv6 home address, since we now have a 128-bit address. 
> The MIP-Mobile-Node-Address from 4004 cannot be used.
> 
> Vijay
>