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

[Tina TSOU <[e-mail]>]

Hi all,
For my previous 2nd comment, I re-considered it, I made comments to myself. (Sorry;)


B. R.
Tina
  ----- Original Message ----- 
  From: Tina TSOU 
  To: [e-mail] ; jouni 
  Cc: [e-mail] ; [e-mail] ; [e-mail] ; [e-mail] ; [e-mail] 
  Sent: Tuesday, December 16, 2008 10:08 AM
  Subject: Re: [AAA-DOCTORS] New version of draft-ietf-dime-mip6-integrated


  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
  [Tina: When looking at Figure2 and 4 again, I think NAS could be co-located with VAAA in this scenario.]

  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?
  [Tina: When looking at second paragraph in section 5.3 again,
  "Whether the NAS/ASP then offers a locally assigned HA or the Diameter

     server assigned HA to the MN is, in this example, based on the local

     ASP policy."

   

  My comment above is perhaps be out of scope, or it could be solve in some other document.]



  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