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 10:45:24 -0400

> -----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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Aug 2006 20:22:01 +0200

Hi Kuntal,

> server than the same at the HA, since ASA != MSA in split.

In this case the identities are different though. You cannot use the 
same identity to hit two different domains.
Hence, there is no problem as such.

  In case of
> we need to keep this in mind.

Here is the question whether they are indeed the same server. Some folks 
they argue that it is not the same one

> systems.

IMHO, for the ASA != MSA scenario it is.

Ciao
Hannes

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 21 Aug 2006 12:06:27 -0400

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.

Once you have a new Application-ID you really don't need NAS-Port-Type
(as pointed out correctly by Julien).

I don't understand what the concern about modification of Diameter
Agents.

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? 

> 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
> 
> 
> 
> [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
> > >
> > >
> > >>> Application IDs. Every proxy on the path needs new code 
> to handle 
> > >>> the new application,
> > > while
> > >>> 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 
> 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.
> 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:
> > >>> "
> > >>> 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:
> > >>>
> > >>> 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:
> > >>>
> > >>> "

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 22 Aug 2006 09:21:30 +0200

Hi Kuntal and Hannes,

> they argue that it is not the same one

Some background: the integrated scenario was defined during the
bootstrapping DT discussion because some proposed solutions were
applicable only in the case the entity that authenticates the user for
network access is the same entity that authenticate the user for
mobility service. In my view, the initial assumption was that the same
AAA server authenticates the user for both services, since during the
authentication for network access some MIP6 related information are
sent to the NAS.

However, in a AAA stateless architecture, it would be possible to have
also different AAA servers; I guess in this case the solution for
integrated scenario would still work: the first AAA server (that
authenticates the user for network access) sends the MIP6-related
information to the NAS, and the second AAA server (that authenticates
the user for mobility service) just terminates the EAP exchange
carried on IKEv2 between MN and HA.

Therefore, I think the servers may be different, but the AAA
infrastructure/business entity is the same. Am I missing something?

> IMHO, for the ASA != MSA scenario it is.

agree for the split scenario.

--Gerardo