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

[jouni <[e-mail]>]

Hi Lionel,

On Dec 15, 2008, at 7:34 PM, <[e-mail]> <[e-mail] 
 > wrote:

>>

[snip]

>>>
>>> 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.
>
> Proposed editorial correction if the basis is ok:
>
> New (modified):
>
>    The HAAA MAY act as a central entity managing prefixes for MNs.  In
>    this case, the HAAA returns to the NAS the prefix allocated to  
> the MN.
>    The NAS/ASP delivers then the home link prefix to the MN using  
> e.g. mechanisms
>    described in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. The  
> NAS/ASP MAY propose to the HAAA a specific
>    prefix to allocate to the MN by including the MIP6-Home-Link-Prefix
>    AVP in the request message. However, the HAAA MAY override the
>    prefix allocation hint proposed by the NAS/ASP and return a  
> different
>    prefix in the response message.


Works for me.

>>> - 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.
>
> Question: in which situation would we have multiple (distinct) HAs  
> in the response?

e.g. when you receive HA information from both home and visited  
networks. That
usecase is described in the I-D.

>>
>> 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.
>
> Is there a specific reason to let anyway the prefix information  
> outside the MIP6-Agent-Info Grouped AVP?
> Is it foreseen to receive (in the response from the AAA) the prefix  
> witout the Home agent info?
> If not, I think it is a reason good enough to find all the required  
> AVP in the same grouped AVP..

I am also leaning towards to this solution i.e. including prefix  
information inside the
grouped AVP.

Cheers,
	Jouni



>
>
> BR,
>
> Lionel
>
>>
>>>
>>>
>>> - 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
>>

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