RE: Review of Issue: Review of draft-chowdhury-mip6-radius-02

[<Pasi.Eronen@nokia.com>]

Hi Avi,

Thanks for taking care of the issues. A couple of comments below:

> 11) For the split scenario, the document should define what to put
> in Service-Type and NAS-Port-Type attributes (and maybe also
> Calling-Station-Id and Called-Station-Id).
> 
> [avi] Service Type we should not touch.  NAS-Port-Type should be
> HA-MIP6 or something like that.
>
> We need to find out what is going on in Diameter with this.

It wouldn't hurt to specify what Service-Type the HA should use
("Framed" looks like an obvious choice). And yes, a new NAS-Port-Type
might be needed.

> Not sure about calling Station-ID or Called Station id, I don't
> think we should specify anything for those.  SDOs or specific
> deployements may use those attributes.

In the split scenario, Calling-Station-ID would be the obvious place
to send the MN's CoA from the HA to the AAA server. If we want this to
work in interoperable manner, the spec should say so.

> 13) The document should either point to RFC 2548, or explicitly say
> that this document does not contain an interoperable solution for
> the split scenario, since it does not specify (either here or by
> referencing some other document) how to send the MSK from the RADIUS
> server to the HA.
> 
> [Avi] What do you mean by that?  In the split scenario this document
> does not send an MSK to the HA.
> 
> [Avi] I don't think we should specify how the MSK is carried.  The
> specific EAP methods do that see EAP-AKA EAP-TLSbis etc...  We could
> say in the absence of a method to transport MSK, the method
> specified by RFC 2548 SHOULD be used.  Note that that is not enough,
> since we have to specify what goes in the SEND KEY and RECEIVE KEY.

EAP methods don't carry the MSK to the HA (who needs it to complete
the IKEv2 exchanges with the MN). For send/recv key, we might
adapt/borrow text from RFC 4072:

   o  Diameter EAP-Master-Session-Key AVP can be translated to the
      vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key
      attributes [RFC2548].  The first up to 32 octets of the key is
      stored into MS-MPPE-Recv-Key, and the next up to 32 octets (if
      present) are stored into MS-MPPE-Send-Key.  The encryption of this
      attribute is described in [RFC2548].

> 15) And last (but not least, as everyone who has followed RADEXT knows
> :-): the document does not have a Diameter considerations section.
> 
> Done From vlan06.txt  Modified for our purposes.

The text was fine for vlan-06, but in this case, we also have
draft-ietf-dime-mip6-integrated and draft-ietf-dime-mip6-split
to consider.

The text you proposed more-or-less makes both of them redundant.
I'm not saying that's a bad thing :-) but clearly some coordination
between DIME and MIP6 WGs is needed on this issue (unless we really
want to have two different ways to do MIP6 in Diameter).

Best regards,
Pasi

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>