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

["jouni korhonen" <[e-mail]>]

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