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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Aug 2006 22:51:07 +0200

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?

     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?

   - 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

---

From: Tony Zhang <[email-masked]>
Date: Thu, 17 Aug 2006 15:01:34 +0800

[Tony]Agree

[Tony]In my understanding, less chance on Diameter MIPV6 and EAP ACCSS use same Server. my choice use new application ID ,but still better define new Service Type and NAS Port Type(because maybe it will share same account server).
[Tony] in my understand,AAA server should understand this.

     Is this an issue for us?
[Tony]Proxy agent compare to Realy agent,it should unsterstand the application.so I think no issue for us!

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, August 17, 2006 4:51 AM
To: [email-masked]
Subject: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs. "NAS-Port-Type AVP/Service-Type": Summary

Hi all,

Here is my impression:

     Is this a problem?

     Is this an issue for us?

Ciao
Hannes

Jari jumps in:
"

Avi responds:
"

Avi writes:
"

Jari writes:
"

- New application ID.

Avi to Jari:

"

Yoshi says:
"

Julien wrote:
"
" and Pasi responded:
"

John agrees with Pasi.

Avi writes:
"

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 17 Aug 2006 09:41:12 +0200

Hi Tony,

Tony Zhang schrieb:
> * RFC 3588 leaves a question regarding the extensibility open. This
> needs to be captured in the revision of the base specification. 
> [Tony]Agree * The main issue seems to be
> 
> IPv6 Bootstrapping' messages differently? If we want to route them
> differently then we need to define 'Diameter MIPv6 Bootstrapping' as
> a Diameter application. [Tony]In my understanding, less chance on
> Diameter MIPV6 and EAP ACCSS use same Server. my choice use new
> application ID ,but still better define new Service Type and NAS Port
> Type(because maybe it will share same account server).

But setting an additional value in the Service Type/NAS Port Type in 
addition to using a new Application ID would not help. Using either / or 
would not be useful either since the AAA client does not know when the 
AAA server of the two services are different.

> and/or NAS-Port-Type AVPs and the defined values. Is this a problem? 
> [Tony] in my understand,AAA server should understand this. - 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.

The problem with proxies is that they need to understand the new 
Application ID since otherwise they will not process the Service Type 
values.

Mandating the servers to understand the specific values is difficult; 
See also the discussion.

If the AAA server does not understand the specific value it just treats 
the access like an ordinary network access. It is up to the MIPv6 guys 
to indicate whether that's fine with them.

> 
> Is this an issue for us? [Tony]Proxy agent compare to Realy agent,it
> should unsterstand the application.so I think no issue for us!

It is a deployment problem. For a protocol designer it might not be a 
problem...

Ciao
Hannes

> -----Original Message----- From: Hannes Tschofenig
> [mailto:[email-masked]] Sent: Thursday, August 17, 2006
> 4:51 AM To: [email-masked] Subject: [Dime] Mobile IPv6 Bootstrapping -
> "Application ID" vs. "NAS-Port-Type AVP/Service-Type": Summary
> 
> 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.
> 
> If we want to route them differently then we need to define 'Diameter
> MIPv6 Bootstrapping' as a Diameter application.
> 
> 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.
> 
> 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. "
> 
> 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 
> - 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: "
>>> 
> " 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.
> 
> 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.
> 
>  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.
> 
> 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
> 
> 
>

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 18 Aug 2006 18:54:24 +0200

Hi hannes,

 thanks for this clarifying mail.

> IPv6 Bootstrapping' messages differently?

 I tend to think that it is safer to assume that some operators may
 desire that.

> and/or NAS-Port-Type AVPs and the defined values.

 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

-- 
julien.bournelle at int-evry.fr

---

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

Hi Julien,

>  Maybe i missed the problem you raised.

This item is only relevant if you use the Service-Type / NAS-Port Type 
approach. The problem raised in the mailing list discussion was 
regarding the type of authorization performed by the AAA server. If the 
AAA server understands the new values then everything is fine. If it 
does not understand them then the authorization decision would be 
treated as a normal network access scenario. Is this desirable?

Ciao
Hannes

Ciao
Hannes

---

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

Hi hannes, all,

On Sun, Aug 20, 2006 at 10:03:09AM +0200, Hannes Tschofenig wrote:
<snip>

> treated as a normal network access scenario. Is this desirable?

 I think operators need to know if it's normal network access scenario
 or Mobile IPv6 Service. Reasons that I can see are:

 - charging
 - policies to apply on the service equipment (network access: NAS, mip6
   service: HA)

 regards,

 Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 22 Aug 2006 14:15:59 -0400

> IPv6 Bootstrapping' messages differently?

I have two questions.

- Can someone show a compelling reason for why the two types of
messages need to be routed differently?

- If the first question is answered, can we define 'Diameter Mobile
IPv6 Bootstrapping' as a new application but using totally new
messages that carry only information specific to MIPv6 bootstrapping
rather than carrying the information in Diameter EAP messages?  (This
might not be so much optimized but it would be good in terms of
modularity in that we can add any new bootstrapping application in the
same way without touching Diameter EAP application.)

Best regards,
Yoshihiro Ohba