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

[Tina TSOU <[e-mail]>]

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.

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?

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?

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