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

[jouni korhonen <[e-mail]>]

Tina,

Few comments inline:

On Dec 16, 2008, at 4:08 AM, Tina TSOU wrote:

> Hi all,
> Some comments are below.
>
> 1) Section 4.2.1, when the MIP-home-agent-host AVP (w/o the MIP-home- 
> agent-address AVP) is returned, does the NAS need to notify Diameter  
> server if it gets a new home agent address via DNS from MIP-home- 
> agent-host AVP?
> In a certain case (e.g. PMIP-MIP interaction), it may be necessary  
> to get the same HA/LMA to guarantee session continuity.

This matter is not in scope of this document. The problem is  
interesting and important though. There was a recent I-D in NetLMM to  
discuss stuff around LMA discovery and the issue you brought up. See http://tools.ietf.org/html/draft-korhonen-netlmm-lma-discovery-00

>
> 2) Section 4.2.5,
> Case 1, a request message contains,
>     LOCAL-bit  HA-Info
>       1          -
> and the answer message contains,
>       1         H-HA + L-HA
> while, how does the NAS identify in which MIP6-Agent-Info AVP the H- 
> HA presents?

Using the MIP-Home-Agent-Host AVP. The text has been word smithed to  
be slightly more accurate during the IESG discussion (that's what Pasi  
referred 2008-11-27 text being OK).


>
> case 2, a request message contains, (allocated by NAS)
>     LOCAL-bit  HA-Info
>       1         L-HA1
> and the answer message contains, (allocated by visited network)
>       1         L-HA2
> or the answer message contains, (allocated by home network and  
> visited network)
>       1         H-HA + L-HA2
> while, does it mean 'two L-HA can be used' or 'only L-HA2 can be  
> used' by the NAS?
> or is this case allowed?

hmm? Ok, saw your followup mail on this.

Cheers,
	Jouni

>
> Wish you a joyful greeting season! :D
>
> B. R.
> Tina
> ----- Original Message -----
> From: jouni
> To: <[e-mail]>
> Cc: [e-mail] ; [e-mail] ; [e-mail] 
>  ; [e-mail] ;[e-mail]
> Sent: Tuesday, December 16, 2008 3:30 AM
> Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6- 
> integrated
>
>
> 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

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