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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 18 Aug 2006 14:42:27 -0400

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

---

From: Julien Bournelle <[email-masked]>
Date: Sat, 19 Aug 2006 12:00:28 +0200

Hi all,

> NAS-Port-Type AVP so that we need this additional AVP?

 For the integrated scenario, the issue is different. The reason is
 that, in this case, we're doing AAA operations for network access and
 we use that to provide HA info. After getting network access, the MN
 falls in the split case and use IKEv2 with the HA (and we have AAA
 again described in draft-ietf-dime-split-OO.txt). 

 However, it could be interesting for the AAA server to know if the NAS
 support the "Integrated case"' operations. This is why we thought that
 we could add an AVP sent from the NAS to the AAA indicating this feature.
 This could be done during CER/CEA exchange. But if we do this, if we
 have intermediaries AAA equipments, the final AAA server won't know.

 So it seems better to add an AVP in DER or AAR messages (messages sent
 by the NAS to the AAA infrastructure). Having said that, a new
 NAS-Port-Type may be needed.

> Apologize for jumping in late....still trying to understand the whole

 No problem Kuntal, your opinion on this subject is really needed. I
 hope my quick explanation will help you to catch the whole issue.

 Regards,

 Julien

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Aug 2006 10:07:03 +0200

Hi Kuntal,

Chowdhury, Kuntal schrieb:
> 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
> Apologize for jumping in late....still trying to understand the whole
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?

Ciao
Hannes

---

From: <[email-masked]>
Date: Mon, 21 Aug 2006 08:46:19 +0300

Hannes,

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

Just to stir the pot a bit .. I agree with you, we are discussing how
have a Diameter extension and how it fits into the existing deployment.
If using MIPv6 with Diameter creates new manditory attributes and/or
changes the basic state machine, I assume a new application ID should be
used.
I think that if a new application ID is used, it still could be
reasonable
to include information how this new MIPv6 Diameter Application could be
collocated
with the existing MIP(v4) Application.

However, general question - have we gotten past the point where we know
that 
manditory attributes are required?  I just want to verify that.

thanks,
John

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Aug 2006 11:34:27 +0200

Hi John,

> changes the basic state machine, I assume a new application ID should be

I fully agree with you. If certain criteria are fulfilled then we need 
to work on a Diameter Mobile IPv6 application. We just don't know 
whether these criteria are actually fulfilled given the other 
constraints we have.

> with the existing MIP(v4) Application.

That's certainly a good point; We do not have "a lot of meat" in the 
current document.

> manditory attributes are required?  I just want to verify that.

I don't think so.

Ciao
Hannes

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 21 Aug 2006 11:14:05 +0200

Hi John, all,

> with the existing MIP(v4) Application.

 The MIPv4 Application is different of the eventual MIPv6 Application.
 The difference is mainly in the Authentication process, MIPv4 defines
 its own messages AMR/AMA which basically carries a MN-AAA
 Authentication AVP. This MN-AAA-Auth AVP is sent in the Reg-Request
 message by the MN to the HA (or FA).
 In MIPv6, EAP is used for authentication.
 So I don't think we could collcoate MIP6 Application with MIP4
 Application.

> manditory attributes are required?  I just want to verify that.

 For the split scenario (draft-ietf-dime-split-00.txt), if we don't have 
 an App-ID and want the AAA
 server be able for sure that it is performing AAA for mip6 service and
 not for network access, we need to define a new Type for the
 Service-Type AVP or NAS-Port-Type AVP. These AVPs are already
 mandatory.

 Julien

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 21 Aug 2006 11:01:50 -0400

Application-ID should be the way we do this.  That is what it was
designed for.

Not sure what the issue is with intermediaries.

I don't think I agree with the proxy argument.  Why would proxies have
to 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.

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

> 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
> 
> 
> > > Application IDs. Every proxy on the path needs new code to handle 
> > > the new application,
> while
> > > Service Type seems to be the correct way but in RADIUS 
> and Diameter 
> > > service-type also can be authenticate-only or
> authorize-only.
> > > 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:
> > > "
> > > 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:
> > >
> > > "
> > > 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
> "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."
>

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 21 Aug 2006 12:20:49 -0400

> changes the basic state machine, I assume a new application ID should be

I think there are other conditions under which a separate app ID is in 
order, e.g. if mandatory AVPs have been removed from the definition of 
messages or, more importantly, if the semantics of the new app are 
"sufficiently different" from those of the original application.

Regarding the latter case consider, for example, the definition of 
AA-Request in RFC 4005. The AAR definition lists pretty much all AVPs as 
being optional meaning one can reuse AAR to do basically anything.

3GPP's Gq spec defines its own version of the AA-Request which reuses 
*none* of the 4005 specific AVPs but includes a bunch of its own AVPs, 
also all optional. Gq was given its own app ID which I think was 
appropriate because although nominally they're reusing AAR and some 
other messages, effectively it's a very different application. This is 
even though a Gq AAR is, technically speaking, a valid 4005 AAR, also - 
except for the app ID, that is.

(I see now that 4005's AAR has a mandatory Auth-Request-Type AVP and 
Gq's AAR does not but that doesn't really change the point.)

Thanks,
Anders