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

From: Belling Thomas <[email-masked]>
Date: Thu, 2 Sep 2004 18:35:03 +0200

Dear Bernard,

I indeed wanted to discuss if having many appication IDs has that many negative impacts.

> Application-IDs are already allocated by expert review.  Are you
> suggesting that something less should be required (First Come, First
> Served)?

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

> Since there are already stricter allocation requirements for new commands,
> mandatory AVPs, etc.  it's not clear to me that we need to increase the
> difficulty of allocating Application-IDs depending on the underlying
> reason for the request.

This may be seen as arguments that an Application ID does not require strict criteria.

The more interesting issue probably is the administrative burden in a network.

> > (a) Routing:
> > A relay agent may use the application ID to route a request towards a ser=
ver
> > that supports the new or old version of the application. This may be usef=
ul
> > during a transition period when a network is beeing updated.
> 
> For this to work, intermediaries in the path first have to be updated
> to support both the old and new versions.  Otherwise, the request will
> be rejected before it gets to the "new" server.

Routing table may also be updated due to information from a capability exchange, but this has certain limitions because the capability exchange in only hop-by-hop.

By the way: Propagating information by relay agents is nowhere described, but I assume it is not ruled out either. The requirement would be that a CER is also allowed for an existing connection, not only when establishing it.

> Application-IDs are a last resort because of their intrinsic limitations.
> Applications which have discrete "versions" can be handled gracefully by
> allocating a new Application-ID.  However, in the case of applications
> which may have a number of "extensions" the number of required
> Application-IDs (and associated intermediary upgrades) gets out of hand
quickly.

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.

Best regards, Thomas

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Sep 2004 10:00:20 -0700 (PDT)

> However I agree that this scenario may lead 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.

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: Barney Wolff <[email-masked]>
Date: Thu, 2 Sep 2004 16:17:55 -0400

> IMHO this issue is fairly major, since it limits the ability of Diameter

It strikes me as an implementor that having 6 AVPs that might be supported
individually in any combination (which is 2^6=64, counting "none" :)
is a nightmare.  Allowing this scattershot approach seems impractical
and merely pushes the pain of deciding which combinations of AVPs make
sense onto the implementors rather than the RFC writers.  Interoperability
should mean something more than just getting a reject.

At the very least, sets of AVPs that are used for some "feature" MUST all
be implemented or all be not implemented, if the software is to avoid
the combinatorial explosion.

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Sep 2004 19:29:23 -0700 (PDT)

> the combinatorial explosion.

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.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Sep 2004 14:38:03 +0300

> this paradigm.  Perhaps that is itself a problem.

I'm not completely convinced yet that the combinatorial
explosion is a real problem.

The first question to ask is whether the functions are orthogonal
or if there's some need that the peers must consider them
in relation to each to other. For some of the new attribute work,
it looks to me that they are orthogonal. For instance, I don't
see a reason why a geographic location attribute processing
would affect bandwidth attributes. If this is true, it means
that good implementations do not get any more complex because
they support combinatorial use of these attributes. Testing-wise
it may bring additional test cases. Then again, even if you
define all the attributes in the same RFC does not remove the
possibility that they are actually included/excluded on an
individual basis, so it seems like

The only issue is how to find out what the other side supports.
I see three possibilities:

(1) Not negotiable. You do it or I will not work with you.
     An error leads to disconnect.

(2) Trial-and-error. The algorithm is simple, but if you had
     a lot of attributes the other side did not support, there
     could be a lot of iterations.

(3) Fine-grained (beyond RFC 3588) and e2e capabilities
     negotiation.

You'll notice that the above applies irrespective of the granularity
of the RFCs; if all new attributes are grouped to one RFC then
alternative 2 converges faster, however... Note also the alternatives
present a trade-off between convergence time and complexity. I
would not necessarily jump on the fine-grained capabilities negotiation
before we have some proof that the other alternatives present a
real practical problem.

On the other hand, if there is some reason to believe that the
functions somehow depend on each other, then we may have a more
interesting problem at our hands. Then it should be clear that they
should go to the same RFC if at all possible.

The other question is which of the proposed attributes actually
are mandatory. Not all of them are.

Summing up, I do not feel that the use of M=1 on IETF-defined
new standard attributes is a problem. But we should design the
RFCs so that a logical group of functions goes into one RFC
without too many dependencies to other RFCs.

--Jari