Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID

From: <[email-masked]>
Date: Fri, 3 Sep 2004 09:53:56 +0300

Bernard,

> I think a good deal of what you say makes sense.  And in practice, the
> current Diameter standards-to-be and RADIUS RFCs are 
> structured like this.
> 
> For example, those NASes that support ARAP typically support all the
> ARAP attributes in RFC 2869; those that support EAP support all the EAP
> attributes in RFC 3579;  WLAN APs typically implement all of RFC 3580;
> NASes supporting IPv6 typically support all of RFC 3162, etc.
> 
> The same can be said of "bundles of functionality" such as Diameter
> SIP/RADIUS Sterman.
> 
> But I'm not clear that all the "extensions" proposed in RADEXT WG fit into
> this paradigm.  Perhaps that is itself a problem.

In my opinion, a Diameter Application should be a set of functionalities 
that are not yet currently defined by existing applications.  Therefore
bundling new command codes or new sets of mandatory AVPs would qualify
as a new application, in my opinion.  Adding single codes or single mandatory
AVPs seems like a bad way to go, especially if you think of deployment
and operation of AAA services.

That being said, I think if we want to see wide-scale deployments of the
new RADIUS extensions, defining them in bundles makes a lot more sense,
otherwise implementations may implement one new attribute while another
may not, which of course will lead to interoperability failures.

John

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 09:57:21 +0300

Thomas,

> Due to concerns about the administrative overhaed I suggested 
> decreasing the burden for appication IDs ias a possible solution.

What would be your model for this?

[some text cut]

> This is basically the old argument that there may be many application IDs.
> However I agree that this scenario may leed to extremly high numbers.
> It may depend on the application if many disctrete extensions 
> are anticipated. This may indeed be a reason for extra 
> negotiation mechanisms within applications.

Right now, there is no standard way to do extended negotiation.  If there
were one, we could could use this to negotiation sub-feature support.  However,
as there is no solution at present to do this.  Do you feel that this feature
is needed?  

John

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 10:49:38 +0300

Hi,

> As described in the analysis, in this particular case, there 
> does not seem to be a downside to adding a new IETF Standard AVP with the 
> 'M' bit set without allocating a new Application-ID.  If the AVP
> is supported, it will work;  if it isn't supported, an error message will 
> result, but that is what is desired.

One potential downside is the performance of the implementation.

If a peer receives a message with unsupported application-id it can
be sure right away that it can't support the message. If a peer receives
a message with supported application-id that has mandatory AVP
it does not support, the peer must parse the whole message before it
finds out it must reject the message.

I'm not sure if this is a problem in practise.

BR,
Mikko

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Bernard Aboba
> Sent: 02 September, 2004 20:00
> To: Belling Thomas
> Cc: AAA ([email-masked])
> Subject: RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs 
> requires new
> A pplication-ID
> 
> 
> > However I agree that this scenario may lead to extremly 
> high numbers.
> > are anticipated. This may indeed be a reason for extra negotiation
> > mechanisms within applications.
> 
> In RADEXT WG we are looking at WLAN extensions for things like VLANs,
> re-direction, etc.  There could easily be half a dozen or 
> more of these
> extensions.  They often need to carry the 'M' bit because they affect
> security and cannot be ignored if not understood by the NAS.
> 
> Under RFC 3588, it is not clear how to extend Diameter EAP to 
> handle this.
> Some vendors will support some extensions and not others, so 
> a "versioning"
> mechanism does not seem feasible.  Neither does allocating a 
> new Application-ID
> for each combination of AVPs with the 'M' bit set.  For 
> example, for half
> a dozen new 'M' bit AVPs, we would be talking about (6 1) + 
> (6 2) + (6 3)
> + (6 4) + (6 5) + (6 6) = 6 + 15 + 20 + 15 + 6 + 1 = 63 
> Application-IDs.
> 
> As described in the analysis, in this particular case, there 
> does not seem
> to be a downside to adding a new IETF Standard AVP with the 
> 'M' bit set
> without allocating a new Application-ID.  If the AVP is supported, it
> will work;  if it isn't supported, an error message will 
> result, but that
> is what is desired.
> 
> IMHO this issue is fairly major, since it limits the ability 
> of Diameter
> to continue evolving.
> 
>

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Fri, 3 Sep 2004 10:17:15 +0200

Hi all,

> 
> Right now, there is no standard way to do extended 
> negotiation.  If there were one, we could could use this to 
> negotiation sub-feature support.  However, as there is no 
> solution at present to do this.  Do you feel that this 
> feature is needed?  
> 

From my point of view, the problem of versioning has appeared due to the
"unclear" specification of the extensibility mechanism (i.e. adding new
AVP with the M-bit set). To avoid the need for a new application-ID when
a new feature is added to an existing Diameter application, a solution
was to define versions of the same application and to specify a specific
version negotiation at the application layer. But this solution was
forced by the "new M-bit AVP -> new application-ID" dogma.

If the base protocol specification clarifies that the addition of new
M-bit AVPs doesn't require a new application-ID and the approriate error
handling for unsupported AVPs (as proposed by Bernard), this will
deprecate the use of version.

Lionel

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 12:30:55 +0300

Lionel,

> deprecate the use of version.

According to our AD, adding new mandatory AVPs causes interoperability
problems, therefore the current text remains as is.  If we would like 
to modify that behavior, we most likely need to document the new functionality
in an RFC.

John

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Fri, 3 Sep 2004 12:06:45 +0200

Hi John,

> According to our AD, adding new mandatory AVPs causes 
> interoperability problems, therefore the current text remains 
> as is.  If we would like 
> to modify that behavior, we most likely need to document the 
> new functionality in an RFC.

My mistake! You're right.
But the purpose of the new document will be the same: clarify the
issues, and update RFC 3588. And I think that Bernard is currently
drafting something.

Lionel

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 13:10:23 +0300

Hi Lionel,

> issues, and update RFC 3588. And I think that Bernard is currently

Yes, this is something that we have been discussing as AAA chairs.

John

---

From: Belling Thomas <[email-masked]>
Date: Fri, 3 Sep 2004 13:00:36 +0200

Hi all

There seems to be an understanding in the group that a new application ID is mandated if a new AVP mith ´M´Flag is added.

However, the text in RFC 3556 seems to indicate it is optional:
"
Should a new Diameter usage scenario find itself unable to fit within
   an existing application without requiring major changes to the
   specification, it may be desirable to create a new Diameter
   application.  Major changes to an application include:

   -  Adding new AVPs to the command, which have the "M" bit set.
"
This seems to be in line with explanatory text for the ´M`bit, that also speaks about AVPs without ´M´bits outside applications:
"
      The 'M' Bit, known as the Mandatory bit, indicates whether support
      of the AVP is required.  If an AVP with the 'M' bit set is
      received by a Diameter client, server, proxy, or translation agent
      and either the AVP or its value is unrecognized, the message MUST
      be rejected.  Diameter Relay and redirect agents MUST NOT reject
      messages with unrecognized AVPs.

      The 'M' bit MUST be set according to the rules defined for the AVP
      containing it.  >>> In order to preserve interoperability, a Diameter
      implementation MUST be able to exclude from a Diameter message any
      Mandatory AVP which is neither defined in the base Diameter
      protocol nor in any of the Diameter Application specifications
      governing the message in which it appears. <<< ...

      Diameter implementations are required to support all Mandatory
      AVPs which are allowed by the message's formal syntax and defined
      either in the base Diameter standard or in one of the Diameter
      Application specifications governing the message.
"

If the understanding within the group is a new application ID for the AVPs with the ´M´bit is mandatory, (the below interoperability concerns may justify that), one could improve the wording. Is that something for the errata?

Or is it preferable to keep the wording as it is, and grant a certain degree of freedom fpr application designers in this difficult field?

Thomas

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Friday, September 03, 2004 11:31 AM
> To: [email-masked]; [email-masked]
> Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit 
> AVPs requires new A pplication-ID
> 
> 
> Lionel,
>

---

From: Belling Thomas <[email-masked]>
Date: Fri, 3 Sep 2004 13:58:38 +0200

Hi John,

answers inline.

Thomas

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, September 03, 2004 8:57 AM
> To: [email-masked]; [email-masked]; [email-masked]
> requires new A pplication-ID
> 
> 
> Thomas,
> 

Specification required alone might be enough.
On the other hand AVPs require "experts review, specification required", and the resulting application ID(s) are likely to be documented in the same document, so the practical difference may be small.

Vendor specific application IDs on "first come, first served" basis are already available, and may be sufficient for applications without widespread usage.

In short, giving the issue a second thought I am no longer convinced a change is required.
However, I doubt the administrative burden ia as large as claimed previously.

> negotiation.  If there

3GPP pre-ageed (final approval to be expected next week) such a mechanism. They group new AVPs in so-called "feature sets" and introduce a capabilty negotiation within the application on feature-set granularity. The new AVP do not use the ´M´bit even if they are required to be understood, as the capabilty negotiation guarantees that.

The requirement for such extra negotiation mechanisms may depend upon the application. 3GPP is likely to update specifications due to new releases and to correct errors and designes for large network where gradual updates are an issue. Therefore, 3GPP applications may require such mechanisms more urgently than other ones.

---

From: Belling Thomas <[email-masked]>
Date: Fri, 3 Sep 2004 16:36:00 +0200

(second attempt, my first email seems to be lost in the AAA server)

Hi John,

answers inline.

Thomas

---

From: "Javier Gonzalez Gallego" <[email-masked]>
Date: Tue, 7 Sep 2004 13:53:27 +0200

Thomas,
The actual text in RFC3588 seems to imply your conclusion, but it is not
fully clear. However what seems to be clear to me is the agreement in the
need to correct it. If we look to the mails arounf 19 of August, there's a
number of opinions and  emails in agreement with Bernard Adoba's sentence
asking for a correction:

> Included in the list of conditions requiring a new Application-ID is:
> 
> "   -  Adding new AVPs to the command, which have the "M" bit set."
> 
> Given the discussion since the publication of RFC 3588, I now believe 
> that the above sentence is in error.  A new Application-ID should not 
> be required due to addition of AVPs to an application, whether the 
> mandatory bit is set or not.

When and how this correction will be done is what seems to be still open.

At least, that is my recollection of the debate.
Javier

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Belling Thomas
Sent: 03 September 2004 13:01
To: [email-masked]'; [email-masked];
[email-masked]
Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires
new A pplication-ID

Hi all

There seems to be an understanding in the group that a new application ID is
mandated if a new AVP mith ´M´Flag is added.

However, the text in RFC 3556 seems to indicate it is optional: " Should a
new Diameter usage scenario find itself unable to fit within
   an existing application without requiring major changes to the
   specification, it may be desirable to create a new Diameter
   application.  Major changes to an application include:

   -  Adding new AVPs to the command, which have the "M" bit set. " This
seems to be in line with explanatory text for the ´M`bit, that also speaks
about AVPs without ´M´bits outside applications: "
      The 'M' Bit, known as the Mandatory bit, indicates whether support
      of the AVP is required.  If an AVP with the 'M' bit set is
      received by a Diameter client, server, proxy, or translation agent
      and either the AVP or its value is unrecognized, the message MUST
      be rejected.  Diameter Relay and redirect agents MUST NOT reject
      messages with unrecognized AVPs.

If the understanding within the group is a new application ID for the AVPs
with the ´M´bit is mandatory, (the below interoperability concerns may
justify that), one could improve the wording. Is that something for the
errata?

Or is it preferable to keep the wording as it is, and grant a certain degree
of freedom fpr application designers in this difficult field?

Thomas

> to modify that behavior, we most likely need to document the new 
> functionality in an RFC.
> 
> John
>

---

From: "Warren, Dan, VF UK - Technology (TS)" <[email-masked]>
Date: Fri, 10 Sep 2004 12:35:40 +0100

Thomas Belling wrote;-

'3GPP pre-ageed (final approval to be expected next week) such a mechanism. They group new AVPs in so-called "feature sets" and introduce a capabilty negotiation within the application on feature-set granularity. The new AVP do not use the ´M´bit even if they are required to be understood, as the capabilty negotiation guarantees that.

The requirement for such extra negotiation mechanisms may depend upon the application. 3GPP is likely to update specifications due to new releases and to correct errors and designes for large network where gradual updates are an issue. Therefore, 3GPP applications may require such mechanisms more urgently than other ones.'

Accompanying the proposal in 3GPP is a considerable set of guidleines on what constitutes a 'feature' and what would motivate the creation of a new application-id.  This has led to the definition of some working practises on how AVPs, features and applications are created and how forward compatibility within (3GPP defined) Diameter applications can be achieved.  If/when it is decided to introduce a similar mechanism for identification of features in IETF, it might be useful to have a some similar guidance about what is a feature and what warrants a new application.  When that time comes, I'm sure one of the 3GPP-ists on the list will be happy to provide the text.

Cheers

Dan Warren

---

From: <[email-masked]>
Date: Fri, 10 Sep 2004 17:02:17 +0300

Hi Bert,

> Javier,
> 
> Our AD has stated that we can make a simple erratta to RFC 3588 to make this change.  So at 
>
> <bert> I think you meant "can NOT make" !!??
> <bert>
> 
> present, this is not an option on that is on the table.  If we would like to change the RFC,
> then we will need to produce a new RFC.

You are correct, I meant:

	Our AD has stated that we can not make a simple erratta to RFC 3588 to make this change.  

John