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 13:10:02 -0400

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]
> Sent: Monday, August 21, 2006 11:06 AM
> To: Chowdhury, Kuntal; Hannes Tschofenig
> Cc: [email-masked]
> Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
ID"vs."NAS-
> Port-Type AVP/Service-Type": Summary
> 
> Service-Type should not be used.
> 
> If you add a new value to the NAS-Port-Type then you need a new
> Application-ID anyway.  You have to make sure that the packet reaches
an
> entity that can understands the new value.  Otherewise you could end
up
> delivering the packet to a legacy server that doesn't not understand
the
> MIPv6 application.
[KC>] Hmmm...it will be an interesting situation when the Mobility
Service Provider (MSP) deploys AAA servers that do not understand MIP6!

> Once you have a new Application-ID you really don't need NAS-Port-Type
> (as pointed out correctly by Julien).
> 
[KC>] How about NAS-port AVP? Do we need a new application ID if we
decide to use a specific value in NAS-port AVP to indicate MIP6
bootstrapping?

> I don't understand what the concern about modification of Diameter
> Agents.
> 
[KC>] My main goal is this: If we can use Diameter EAP (DER/DEA) or
NASREQ (AAR/AAA) transactions to download MIP6 bootstrapping parameters
(HA, HL etc.) that will be ideal. I am trying to avoid extra
transactions from NAS and HA if possible. Hope you will appreciate this
goal. If we end-up mandating some non-mandatory AVPs in EAP/NASREQ, only
then we should define new application ID for MIP6 bootstrapping, IMHO.

> If you use Application Id then Relays wont have to change right?
> 
> Proxies would have to change if and only if they are going to be
proxies
> for that Application.  But that is the definition of a Proxy right?
> 
> 
> > -----Original Message-----
> > From: Chowdhury, Kuntal [mailto:[email-masked]]
> > Sent: Monday, August 21, 2006 10:45 AM
> > To: Hannes Tschofenig
> > Cc: [email-masked]
> > Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
> > ID"vs."NAS-Port-Type AVP/Service-Type": Summary
> >
> >
> >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:[email-masked]]
> > > Sent: Sunday, August 20, 2006 3:07 AM
> > > To: Chowdhury, Kuntal
> > > Cc: Julien Bournelle; [email-masked]
> > > Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> > vs."NAS-
> > > Port-Type AVP/Service-Type": Summary
> > >
> > > Hi Kuntal,
> > >
> > >
> > > Chowdhury, Kuntal schrieb:
> > > > Hi Hannes, Julien,
> > > >
> > > > Application-ID is one way, but as has been discussed so far it
> > requires
> > > > changes in the intermediaries.
> > >
> > > True.
> > >
> > >   A new value in NAS-Port-Type AVP seems
> > > > more logical and easier to implement, IMHO.
> > >
> > > Easier to implement: True.
> > >
> > >   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.
> > > Please read my copy-and-paste summary of the discussion.
> > >
> > > In some sense we are discussing fundamentals of how to extend
> > Diameter.
> > > The application ID is used for routing. If we don't define a new
> > app-ID
> > > then we cannot route network access messages and MIP6
bootstrapping
> > > messages differently. Some folks think that this is important.
> > > What do you think?
> > >
> > [KC>] In case of split scenario, I see the use case where the
> > AAA transaction for network access at the NAS is going to a
> > different AAA server than the same at the HA, since ASA !=
> > MSA in split. In case of integrated scenario, it is essential
> > that the AAA transactions from the NAS and from the HA get
> > routed to the same AAA server (ASA == MSA). So we need to
> > keep this in mind.
> >
> > >From the AAA message routing point of view, I thought the
> > @realm part
> > >of
> > the username (NAI) was sufficient to route AAA messages to
> > different AAA systems. There are other reasons for separate
> > APP-ID for MIP6 bootstrapping, e.g. if we decide to mandate
> > AVPs needed for MIP6 bootstrapping in DER/DEA (as an
> > example). I don't know why we would do that i.e. mandate MIP6
> > bootstrapping AVPs in DER/DEA.
> >
> >
> > > Ciao
> > > Hannes
> > >
> > > >
> > > > -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

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 21 Aug 2006 20:10:50 +0200

HI Kuntal,

> then we should define new application ID for MIP6 bootstrapping, IMHO.

 I think we should not mix the integrated and split scenario case.

 In the integrated, we're doing AAA for network access and we provide to
 the NAS the HA info. So in this case, I don't think we need a new
 App-ID. NASREQ or EAP Application is used. However, it may be
 interesting that the AAA server knows if the NAS support
 functionalities described in the draft-ietf-mip6-integrated.

 In the split, we're doing AAA for the Mobile IPv6 service and thus the
 discussion.

 Julien