Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application ID"vs."NAS-Port-Type AVP/Service-Type": Summary

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Mon, 21 Aug 2006 12:41:32 -0400

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]
> Sent: Monday, August 21, 2006 10:02 AM
> To: Chowdhury, Kuntal; Julien Bournelle; Hannes Tschofenig
> Cc: [email-masked]
> Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
ID"vs."NAS-
> Port-Type AVP/Service-Type": Summary
> 
> Application-ID should be the way we do this.  That is what it was
> designed for.
> 
[KC>] Are you talking about creating an application ID for MIP6 or you
are talking about application ID for MIP6 bootstrapping?

> Not sure what the issue is with intermediaries.
> 
> I don't think I agree with the proxy argument.  Why would proxies have
> to change?
> 
[KC>] the proxy needs to act like a relay if it does not understand the
app ID...isn't that a change? Albeit it is not a code change but it is a
behavior change.

> They would only have to change if they are going to be proxies of this
> new Application.  Which is exactly what they should do.
> 
[KC>] If I am a MSP, I have to make sure that my proxies understand this
new app ID, right? If not, I won't have to do anything more than
supporting Diameter base and NASREQ.

> If you don't want the intemediary to change -- they will not support
> this new Application then they would simply be relay agents right?
> 
[KC>] OK.

> 
> 
> > -----Original Message-----
> > From: Chowdhury, Kuntal [mailto:[email-masked]]
> > Sent: Friday, August 18, 2006 2:42 PM
> > To: Julien Bournelle; Hannes Tschofenig
> > Cc: [email-masked]
> > Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
> > ID"vs."NAS-Port-Type AVP/Service-Type": Summary
> >
> > Hi Hannes, Julien,
> >
> > Application-ID is one way, but as has been discussed so far
> > it requires changes in the intermediaries. A new value in
> > NAS-Port-Type AVP seems more logical and easier to implement,
> > IMHO. I am not sure about the Service-Type AVP. I am
> > wondering what cannot be conveyed via NAS-Port-Type AVP so
> > that we need this additional AVP?
> >
> > Apologize for jumping in late....still trying to understand
> > the whole issue.
> >
> > -Kuntal
> >
> >
> > > -----Original Message-----
> > > From: Julien Bournelle [mailto:[email-masked]]
> > > Sent: Friday, August 18, 2006 11:54 AM
> > > To: Hannes Tschofenig
> > > Cc: [email-masked]
> > > Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> > vs."NAS-
> > > Port-Type AVP/Service-Type": Summary
> > >
> > > Hi hannes,
> > >
> > >  thanks for this clarifying mail.
> > >
> > >
> > > On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> > > > Hi all,
> > > >
> > > > I went through the discussion again and noticed that we haven't
> > reached
> > > > a conclusion.
> > > >
> > > > Here is my impression:
> > > >
> > > > * RFC 3588 leaves a question regarding the extensibility open.
> > > >   This needs to be captured in the revision of the base
> > specification.
> > > >
> > > > * The main issue seems to be
> > > >
> > > >   - Do we want to route 'Diameter EAP' message and
> > 'Diameter Mobile
> > > > IPv6 Bootstrapping' messages differently?
> > >
> > >  I tend to think that it is safer to assume that some
> > operators may
> > > desire that.
> > >
> > > >
> > > >     If we want to route them differently then we need to define
> > > > 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> > > >
> > > >   - The AAA server differentiates ordinary network access
> > and MIPv6
> > > > bootstrapping functionality (with respect to authorization and
> > > > accounting). In order to do so it must understand the
> > Service-Type
> > > > and/or NAS-Port-Type AVPs and the defined values.
> > > >
> > > >     Is this a problem?
> > >
> > >  Not sure to understand this problem. For me, if we have
> > the App-Id we
> > > don't need Service-Type nor NAS-Port Type.
> > >  IF we don't have the App-ID, yes we need to define new values.
> > >
> > >  Maybe i missed the problem you raised.
> > >
> > >  regards,
> > >
> > >  Julien
> > >
> > > >
> > > >   - There are problems with proxies and newly defined Diameter
> > > > Application IDs. Every proxy on the path needs new code to
handle
> > > > the new application,
> > while
> > > > just adding an extra AVP or new Service-Type value does not
hurt.
> > > >
> > > >     Is this an issue for us?
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > > PS: Here is copy-and-paste version of some discussion snippets
to
> > allow
> > > > others to catch-up.
> > > >
> > > > Julien starts the discussion with a question about
> > Application IDs.
> > > >
> > > > Pasi suggests to consider Service-Type and/or
> > NAS-Port-Type AVPs as
> > > > well.... the problem starts.
> > > >
> > > > Avi states that the problem is that neither Service-Type or
> > Port-Type is
> > > > mandatory.
> > > > "
> > > > Service Type seems to be the correct way but in RADIUS
> > and Diameter
> > > > service-type also can be authenticate-only or
> > authorize-only.
> > > > So what if the HA wanted to authenticate-only or
> > authorize-only for
> > the
> > > > MIP service?  I would lose the ability to also indicate
> > that this is
> > an
> > > > HA.
> > > >
> > > > So Port-Type seems to be the way to go....
> > > > "
> > > >
> > > > Jari jumps in:
> > > > "
> > > > One of the reasons why an existing application would be
> > preferred is
> > > > that then a AAA server that does not care about the type
> > of service
> > > > can be used without changes. Yet servers that do care can look
at
> > > > the AVPs and make more detailed authorization decisions.
> > > >
> > > >
> > > > RFC 3588 states that  "Creation of a new application should be
> > > > viewed as a last resort." and that "In order to justify
> > allocation
> > > > of a new application identifier, Diameter applications
> > MUST define
> > > > one Command Code, or add new mandatory AVPs to the ABNF."
> > Note that
> > > > mandatory AVPs can be viewed in different ways, and that
> > we should
> > > > not be too strict about them.
> > > > For instance, Framed-Protocol is an optional AVP in RFCs 4005
and
> > > > 4072. Yet, you could argue that if you are doing PPP then
> > you need
> > > > to use this attribute and set it to PPP. But that didn't make
the
> > > > attribute mandatory.
> > > > Do we have a similar situation for the IKEv2/MIPv6 attributes
and
> > > > values? They are not necessary from the NASREQ/EAP
> > perspective, but
> > > > in the specific context you need to use the attributes.
> > In my mind,
> > > > this does not make the attributes mandatory from a Diameter
> > > > application point of view. If we start creating new
> > applications for
> > > > every different situation, we'll have lots of applications and
> > > > interoperability problems. Its better to add new optional
> > AVPs and
> > > > describe in text when they should be used. The only
> > exception that I
> > > > see is security related AVPs that must be understood by the
other
> > > > side or else the session should be terminated.
> > > > "
> > > >
> > > > Avi responds:
> > > > "
> > > > Mandatory does not mean required in the Command.  It means that
it
> > must
> > > > be understood by the receiver.  We need to clarify that.
> > > > "
> > > >
> > > > Gerardo and Lionel agree with Jari.
> > > >
> > > >
> > > >
> > > > Avi writes:
> > > > "
> > > > If I have two EAP based application in my network, one that is
> > > > handling pure EAP application, the other is extended to handle
the
> > new
> > > > behavior then I need a way to route the (same) command
correctly.
> > > > "
> > > >
> > > > Jari writes:
> > > > "
> > > > Ah, but that is a new requirement. If you believe that
> > you need to
> > > > route EAP authentication from a 802.11 AP differently than from
> > > > IKEv2/MIPv6, then you need one of these:
> > > >
> > > > - Use different user/domain names for the users of
> > > >   the different services.
> > > >
> > > > - Point to different servers from the AP and SGW (but
> > > >   this works less well if you have proxies and roaming).
> > > >
> > > > - New application ID.
> > > >
> > > > - Some weird form of Diameter and RADIUS source routing
> > > >   based on what type of node sent the message.
> > > >
> > > > However, it is far from clear to me why you would really need to
> > > > route the authentication differently *for the same user*. Many
> > > > authentication mechanisms can also have state, which would imply
> > > > that at the end they need to end up in the same device
> > anyhow. Can
> > > > you expand on why you need to handle the same users in different
> > > > authentication servers?
> > > > "
> > > >
> > > > Avi to Jari:
> > > >
> > > > "
> > > > BTW in the context of the original question raised, the
> > attribute(s)
> > > > will not be optional. Here is the snippet:
> > > >
> > > > >> >>  In our case, the AAA server must perform AAA
functionality
> > for
> > > the
> > > > >> >> Mobile IPv6 service. The AAA server must know that
> > it has to
> > > > >> >> authorize the mip6 service and the accounting (ASR/ASA) is
> > also
> > > for
> > > > >> >>  mip6 and not for network access.
> > > >
> > > > If the Diameter message comes from the HA then the HA MUST
include
> > the
> > > > NAS-Port-type attribute. So the command ABNF is being
> > changed. Also
> > the
> > > > behavior is being changed of the Server.  It MUST recognize the
> > (new)
> > > > value of the NAS-Port-Type.
> > > > "
> > > >
> > > >
> > > > Yoshi says:
> > > > "
> > > > If what is important is service-specific routing (I am
> > not convinced
> > > > with it yet), I'd suggest defining a new authorization-only
> > > > application used only for carrying service-specific attributes
> > > > (analogous to NASREQ usage in RFC 4072).  The downside is that
it
> > > > needs another message roundtrip than carrying the attributes in
> > > > DER/DEA.
> > > > "
> > > >
> > > >
> > > > Julien wrote:
> > > > "
> > > > > >
> > > > > > I don't think it's clean to require use of different
> > > > > > users'identifiers in order to distinguish which services is
> > > > > > provided. For me, it looks like a 'hack'.
> > > > " and Pasi responded:
> > > > "
> > > > I fully agree -- but having separate user identifiers
> > should not be
> > > > necessary. If, for example, an operator wants to perform
> > different
> > > > authorizations for WiFi and WiMAX (e.g., some users can
> > access only
> > > > WiFi but not WiMAX), that's simple to do: just check
> > Service-Type,
> > > > NAS-Port-Type, and other relevant authorization AVPs.  There's
> > > > absolutely no need to create a new Diameter application.
> > > >
> > > > If the AAA server is really strict about WiFi vs. WiMAX
> > separation,
> > it
> > > > can have a policy that requires the NAS-Port-Type AVP to
> > be present
> > > > (if the request does not contain it, access is denied). Although
> > this
> > > > in some sense make NAS-Port-Type AVP "mandatory", it's not
> > "mandatory"
> > > > in the sense that would require a new Diameter application.
> > > >
> > > > While IKEv2 and MIP6 are not WiFi and WiMAX, I don't
> > think there are
> > > > any significant differences from Diameter point-of-view. There's
a
> > box
> > > > providing some service; authentication works with EAP;
> > authorization
> > > > AVPs indicate what exactly is being authorized. What's
> > missing is a
> > > > document describing how the different authorization AVPs
> > are used in
> > > > this particular situation; sort of like RFC 3580 (IEEE
> > 802.1X
> > > > RADIUS Usage Guidelines), but for Diameter with IKEv2.
> > > >
> > > > One important reason NOT to create new applications:
> > proxies. Every
> > > > proxy on the path needs new code to handle the new application,
> > while
> > > > just adding an extra AVP or new Service-Type value doesn't.
> > > > "
> > > >
> > > > John agrees with Pasi.
> > > >
> > > > Avi writes:
> > > > "
> > > > A mandatory attribute (a must understand attribute) that
> > has a new
> > > > enumeration is in my mind is like adding a new attribute that
must
> > be
> > > > understood.  There is no wigle room here.  The command
> > carrying that
> > > > attribute must reach the implementation that knows how to
> > interpret
> > the
> > > > attribute.  This is  because an implmentation that does not
> > understand
> > > > Service-Type = X must return an error.
> > > >
> > > > It is obvious that the rules in 3588 are not sufficient
> > to describe
> > when
> > > > to use a new Application ID or not.  And we should not
> > have to have
> > a
> > > > debate on this topic.
> > > >
> > > > BTW if we do what you say then in networks where I have NASREQ
> > > > performing Network Access and now I want to roll out MIPv6 I
would
> > have
> > > > to upgrade all my old NASREQ deployed applications.  This
> > is wrong.
> > I
> > > > should be able to add a MIPv6 compliant diameter
> > application without
> > > > having to force upgrading my NASREQ applications.
> > > > "
> > > >
> > > >
> > > > _______________________________________________
> > > > DiME mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > > --
> > > julien.bournelle at int-evry.fr
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> > "This email message and any attachments are confidential
> > information of Starent Networks, Corp. The information
> > transmitted may not be used to create or change any
> > contractual obligations of Starent Networks, Corp.  Any
> > review, retransmission, dissemination or other use of, or
> > taking of any action in reliance upon this e-mail and its
> > attachments by persons or entities other than the intended
> > recipient is prohibited. If you are not the intended
> > recipient, please notify the sender immediately -- by
> > replying to this message or by sending an email to
> > [email-masked] -- and destroy all copies of
> > this message and any attachments without reading or
> > disclosing their contents. Thank you."
> >
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> >

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime