Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated

[jouni korhonen <[e-mail]>]

Pasi, all,


On Dec 12, 2008, at 12:29 PM, <[e-mail]> <[e-mail] 
 > wrote:

> Dan, Jari, Jouni & others,
>
> The situation seems to be that the RADIUS work will be probably used
> by different SDOs than the Diameter work, so (1) translation may not
> be needed, and (2) translation may not be even possible, because the
> documents have different semantics (this is the case for the latest
> draft versions; and may continue to be the case if the SDOs using
> RADIUS have slightly different requirements).
>
> While these arguments are not really about the technical solutions but
> the process of writing the documents, it seems the RADIUS parts are
> considerably less mature (and the required semantics may still  
> change),
> while 3GPP apparently already knows what semantics it needs.
>
> I guess this could be a possible reason for leaving the MIP6-Agent- 
> Info
> AVP in the Diameter number space.
>
> Jari, would this work for you?
>
> Looking back at the emails, the following things (not related to
> this RADIUS/Diameter topic) were still not handled in the -11 version:
>
> - Describing the semantics of the MIP6-Home-Link-Prefix in request
>  messages.

Would the following text in Section 4.2.4 work for you?

Old:

    The HAAA MAY act as a central entity managing prefixes for MNs.  In
    this case, the HAAA returns the prefix allocated for the MN and
    returns it the NAS.  The NAS/ASP uses then, for example, mechanisms
    described in [I-D.ietf-mip6-bootstrapping-integrated-dhc] to deliver
    the home link prefix to the MN.

New:

    The HAAA MAY act as a central entity managing prefixes for MNs.  In
    this case, the HAAA returns the prefix allocated for the MN and
    returns it the NAS.  The NAS/ASP uses then, for example, mechanisms
    described in [I-D.ietf-mip6-bootstrapping-integrated-dhc] to deliver
    the home link prefix to the MN. The NAS/ASP MAY propose a specific
    prefix allocation to the HAAA by including the MIP6-Home-Link-Prefix
    AVP in the request message. However, the HAAA is MAY override the
    prefix allocation hint proposed by the NAS/AAA and return a  
different
    prefix in the response message.


>
> - If the message contains information about multiple HAs, which home
>  agent(s) the prefix(es) in MIP6-Home-Link-Prefix AVP(s) belong to.
>  (One way to solve this would be to move it inside the Grouped AVP;
>  another way would be to prohibit its use if the message contains
>  multiple HAs; other solutions may be possible)

Actually, I have a vague recollection that independent of number of the
HAs, there would be only one prefix. I cannot find anything to back up
this now, though.

Thus, we could move the MIP6-Home-Link-Prefix AVP inside the MIP6- 
Agent-Info
AVP (in that case, we could actually consider using the Framed-IPv6- 
Prefix
AVP instead of the MIP6-Home-Link-Prefix AVP). Or we could add text that
says using the MIP6-Home-Link-Prefix AVP when there are multiple HAs  
does
not make much sense.

>
>
> - Clarifying the use of "realm" for MIP-Home-Agent-Host (the text
>  proposed by Jouni on 2008-11-27 looks OK to me)

Ok great.

Cheers,
	Jouni


>
>
> Best regards,
> Pasi
>
>> -----Original Message-----
>> From: ext Romascanu, Dan (Dan) [mailto:[e-mail]]
>> Sent: 11 December, 2008 11:32
>> To: jouni; Eronen Pasi (Nokia-NRC/Helsinki)
>> Cc: [e-mail]; [e-mail];
>> Korhonen Jouni (NSN - FI/Espoo);
>> julien.bournelle@orange-ftgroup.; [e-mail]
>> Subject: RE: [AAA-DOCTORS] New version of
>> draft-ietf-dime-mip6-integrated
>>
>> Pasi,
>>
>> What is the way forward? Have all your questions been
>> clarified, or do you expect more information from the
>> document editors?
>>
>> Dan
>>
>>
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of jouni
>>> Sent: Sunday, December 07, 2008 12:33 PM
>>> To: <[e-mail]>
>>> Cc: [e-mail] Chowdhury;
>>> [e-mail]; [e-mail];
>>> julien.bournelle@orange-ftgroup.; [e-mail]
>>> Subject: Re: [AAA-DOCTORS] New version of
>>> draft-ietf-dime-mip6-integrated
>>>
>>> Pasi,
>>>
>>> On Dec 5, 2008, at 2:06 PM, <[e-mail]>
>>> <[e-mail]  > wrote:
>>>
>>>> Jouni,
>>>>
>>>> Thanks for the pointers!
>>>>
>>>> I took a look at these specs, and it seems they're using
>> only some
>>>> parts of draft-ietf-dime-mip6-integrated.
>>>
>>> Hopefully you  found the latest ones. At least those on 3GPP
>>> site that I found, were 1-2 meeting cycles behind  (checked
>>> this morning the official specs download pages). Anyway,
>>> other SDOs who picked up this standards track I-D, are still
>>> according to my limited knowledge completely align with the
>>> I-D (even if they may not use all possible features).
>>>
>>>> None of these seem to describe a case where information
>> about more
>>>> than one Home Agent is sent (which would benefit from
>>> grouped AVPs),
>>>> and neither use the MIP6-Home-Link-Prefix AVP. (29.273
>>> Section 9.2.2
>>>> ABNF does allow more than one MIP6-Agent-Info AVP, but the text
>>>> doesn't describe any other case than a single PDN GW.)
>>>>
>>>> Do you know if e.g. 3GPP plans to add more semantics from
>>> dime-mip6-
>>>> integrated to these specs? Or is dime-mip6-integrated actually
>>>> describing more functionality than other SDOs are currently
>>> planning
>>>> to use?
>>>
>>> I cannot say what other SDOs plan to do in the future.
>>> Current I-D describes more functionality what the above spec
>>> decided to use at the moment. However, whether they e.g. end
>>> up signaling one or more "agent infos" is allowed by current
>>> the I-D. That's up to their deployment view, which might not
>>> be the same for others in the future.
>>>
>>> Cheers,
>>> 	Jouni
>>>
>>>
>>>>
>>>> Best regards,
>>>> Pasi
>>>>
>>>> From: ext jouni korhonen [mailto:[e-mail]]
>>>> Sent: 02 December, 2008 14:18
>>>> To: Eronen Pasi (Nokia-NRC/Helsinki)
>>>> Cc: [e-mail];
>>> [e-mail]; [e-mail]
>>>> ; [e-mail]; Korhonen Jouni (NSN - FI/Espoo);
>>> [e-mail]
>>>> ; [e-mail]
>>>> Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-
>>>> integrated
>>>>
>>>> in 3GPP 29.272, 29.273 and in 3gpp2 X.P0047..
>>>>
>>>>
>>>>
>>>> On Tue, Dec 2, 2008 at 1:05 PM, <[e-mail]> wrote:
>>>> Julien and Jouni,
>>>>
>>>> Could you provide a pointer to 3GPP specs that define how these
>>>> AVPs are used in 3GPP?
>>>>
>>>> I tried searching, but found nothing except 23.402, which only
>>>> mentions this draft in a single sentence. Presumably, the details
>>>> of exactly which of the AVPs are used and how are in some Stage 3
>>>> spec, but I can't seem to find it...
>>>>
>>>> Best regards,
>>>> Pasi
>>>>
>>>>> -----Original Message-----
>>>>> From: ext [e-mail]
>>>>> [mailto:[e-mail]]
>>>>> Sent: 27 November, 2008 15:17
>>>>> To: [e-mail]; Eronen Pasi (Nokia-NRC/Helsinki)
>>>>> Cc: [e-mail]; [e-mail];
>>>>> [e-mail]; Korhonen Jouni (NSN -
>>>>> FI/Espoo); [e-mail]; [e-mail];
>>>>> [e-mail]
>>>>> Subject: RE: [AAA-DOCTORS] New version of
>>>>> draft-ietf-dime-mip6-integrated
>>>>>
>>>>> Dear all,
>>>>>
>>>>> Thanks for your clarifications, I think I better understand
>>>>> your concern now. You are true
>>>>> that we are not defining a new Diameter application here and
>>>>> that finally we just add AVPs to Diameter EAP/NASREQ. In
>>> particular
>>>>> the MIP6-Agent-Info AVP of Type Grouped. From my point of view,
>>>>> this AVP makes sense from a Diameter point of view and I'm not
>>>>> really confortable to split it to ease Diameter/RADIUS
>>> translation.
>>>>>
>>>>> First, I'm not sure that the most common deployment case
>>> will have
>>>>> to translate between RADIUS-MIP6 and Diameter MIP6
>> integrated. As
>>>>> you know, 3GPP does not use RADIUS MIP6. It would be interesting
>>>>> to see if someone has a valid scenario.
>>>>>
>>>>> Second, Diameter NASREQ/EAP already have some Grouped AVPs. So
>>>>> the translation agent already have to cope with this.
>>>>>
>>>>> SO, I think that your comment is really valid and that we could
>>>>> probably add a recommandation somewhere in RFC3588Bis
>> but I'm not
>>>>> sure that this could be a MUST.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Julien
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Jari Arkko [mailto:[e-mail]]
>>>>>> Envoyé : jeudi 27 novembre 2008 14:01
>>>>>> À : [e-mail]
>>>>>> Cc : [e-mail]; [e-mail]; BOURNELLE
>>>>>> Julien RD-CORE-ISS; [e-mail];
>>>>>> [e-mail]; [e-mail];
>>>>>> [e-mail]; [e-mail]
>>>>>> Objet : Re: [AAA-DOCTORS] New version of
>>>>>> draft-ietf-dime-mip6-integrated
>>>>>>
>>>>>> What he said.
>>>>>>
>>>>>> jari
>>>>>>
>>>>>> [e-mail] wrote:
>>>>>>> Glen Zorn wrote:
>>>>>>>
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> Nothing in this thread so far has come to even close to
>>>>>> answering my
>>>>>>>>> main concern: specifying two similar solutions (and
>>>> translation
>>>>>>>>> between them) means more complexity and more work.
>>> Why is this
>>>>>>>>> complexity and work needed?
>>>>>>>>>
>>>>>>>> Which complexity and work would that be?  Translation
>>>>>> between RADIUS
>>>>>>>> and Diameter cannot be avoided, if that's the
>>> problem you see.
>>>>>>>>
>>>>>>>
>>>>>>> We're clearly not on the same page here. Let me try to
>>>>>> explain why I
>>>>>>> believe why this is unnecessary complexity and work:
>>>>>>>
>>>>>>> Consider another draft that has been discussed in RADEXT:
>>>>>>> draft-aboba-radext-wlan. It would be possible to write a new
>>>>>>> Internet-Draft that would define Diameter AVPs (in
>>> 255 range,
>>>>>>> possibly using grouped AVPs and other Diameter-only
>>> features)
>>>> for
>>>>>>> exactly the same purpose.
>>>>>>>
>>>>>>> I am claiming this would be a very bad idea, because it
>>>>> would mean
>>>>>>> more complexity and more work, and with little benefits.
>>>>>>>
>>>>>>> When you're defining attributes for use in existing
>>>>>> messages (no new
>>>>>>> Diameter application or anything), IMHO it should be done
>>>>>> in the 0-255
>>>>>>> range, even if that means Diameter features like grouping
>>>>>> need to be
>>>>>>> avoided.
>>>>>>>
>>>>>>> If I understand your position right, you're saying it would
>>>>>> be OK to
>>>>>>> have two different numbers for e.g. the
>>> Allowed-Called-Station-
>>>> Id
>>>>>>> attribute?
>>>>>>>
>>>>>>>
>>>>>>>>> So far, I have heard only explanations about how this
>>>>>> situation came
>>>>>>>>> to happen: somewhere down the line, two WGs ended up
>>>>>> taking on the
>>>>>>>>> work, and one of them (DIME) made decisions that made
>>>>>> sense locally
>>>>>>>>> (when considering only Diameter aspects), and their
>>>>> draft came to
>>>>>>>>> IESG first.
>>>>>>>>> Interestingly enough, the other WG (MEXT) has
>> been working
>>>> on a
>>>>>>>>> RADIUS+Diameter solution (not a RADIUS-only solution!),
>>>>>>>>>
>>>>>>>> Any work using RADIUS Attributes from the standard
>>>>>> typespace may be
>>>>>>>> trivially claimed to be a "RADIUS+Diameter solution" if no
>>>>>>>> translation other than that specified in RFC 4005 &
>>> RFC 3588 is
>>>>>>>> performed.
>>>>>>>>
>>>>>>>
>>>>>>> Yes. And I think such solutions often make sense.
>>>>>>>
>>>>>>>
>>>>>>>> In fact, however, draft-ietf-mip6-radius-06.txt (if that
>>>>>> is what you
>>>>>>>> are referring to) requires further translation:
>> "MIP6-HA and
>>>>>>>> HOA-IPv6 must be translated between their RADIUS
>>>>> representation of
>>>>>>>> String to a Diameter Address format which requires that the
>>>>>>>> AddressType field be set to 2 for IP6 (IP version 6)".
>>>>>>>>
>>>>>>>
>>>>>>> That's a bad design choice in mip6-radius-06 that could be
>>>> easily
>>>>>>> fixed. If it used the same approach as was used for e.g.
>>>>>>> Framed-IP-Address, no translation (beyond copying) would
>>>>> be needed.
>>>>>>>
>>>>>>>
>>>>>>>> Furthermore, a pretty good case could be made that
>>> the draft in
>>>>>>>> question is not only not a "RADIUS+Diameter solution", but
>>>>>> not even a
>>>>>>>> "RADIUS-only solution" due to the novel semantics it
>>>>>> assigns to the
>>>>>>>> Access-Accept message.
>>>>>>>>
>>>>>>>
>>>>>>> The "novel semantics" probably refer to the "split
>>>>>> scenario" (which is
>>>>>>> indeed more complex, and could be in a separate document).
>>>>>>>
>>>>>>>
>>>>>>>>> and if they had sent their document to IESG first, we
>>>>>> probably would
>>>>>>>>> not even consider publishing
>>> draft-ietf-dime-mip6-integrated.
>>>>>>>>>
>>>>>>>> It didn't get to the IESG first because it's not
>> ready for
>>>> prime
>>>>>>>> time.  I do find it interesting that a Security Area
>>> Director
>>>> is
>>>>>>>> ready to approve a document with such weak security
>>> properties,
>>>>>>>> however.
>>>>>>>>
>>>>>>>
>>>>>>> The "weak security properties" refer to the "split
>>>>> scenario".  The
>>>>>>> "integrated scenario" are ready for prime time, and are
>>>>>> delayed only
>>>>>>> by editorial decision to keep them in the same text file.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Pasi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> AAA-DOCTORS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/aaa-doctors
>>>>
>>>>
>>>
>>> _______________________________________________
>>> AAA-DOCTORS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/aaa-doctors
>>>
>>

_______________________________________________
AAA-DOCTORS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/aaa-doctors