Subject: [AAA-WG]: Extension requirements?

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 14 Feb 2001 08:56:52 -0800

At the interim meeting, we made a distinction between 
things that would be required of a NAS and those that
would be required of a proxy and a server. 

The logic was that a NAS is typically an embedded 
device and therefore operates under different 
contraints than a proxy or a server, which 
presumably have much greater CPU, memory and 
disk resources available to them.

In the same spirit, I would propose that 
AAA proxies and servers MUST implement the
Accounting, NASREQ and MobileIP extensions,
while NASen MUST implement the Accounting
extension and at least one of the NASREQ 
and MobileIP extensions. 

While I can understand why a NAS would only
implement those extensions appropriate for
the kind of device (e.g. I wouldn't expect
a dialup NAS to implement the Mobile IP
extension), requiring that a proxy or
server implement Accounting, MobileIP
and NASREQ seems reasonable to me. 

Doing this will go a long way towards
ensuring interoperability. Today, 
some RADIUS proxies don't recognize 
all of the attributes defined in 
RFCs 2865-2869, and this causes
considerable headaches. It would be
nice to avoid those interoperability
problems with DIAMETER.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 22 Feb 2001 10:19:37 -0800

> extension and at least one of the NASREQ

Seems reasonable to me.

> nice to avoid those interoperability

If it is allowed, that is: remember that it is unnecessary for standard
proxies to recognize anything from most of those documents because they are
Informational, primarily due to the IESG (as I recall).

---

From: [email-masked]
Date: Thu, 22 Feb 2001 23:08:07 -0500 (EST)

It does seem reasonable that current AAA clients and servers would
implement the functions Bernard suggested as requiring.  However, I
don't think we should put these into the protocol requirements.

Does the base protocol specification function without any extension?  
At at least some level the base protocol should work standalone
(although it does not have any session startup support, that is all in
extensions).

We have NASREQ and MobileIP as separate extensions so that people only
need to implement the functionality actually needed and to provide
separation of functionality from other future extensions.

Since I don't expect to ever run any MobileIP devices, I would be
rather hard pressed to develop a server I really felt comfortable
saying meets the MobileIP requirements.

When we extend the AAA protocol to support other functionality we
might find a requirement that servers support NASREQ and MobileIP
rather archaic.  It should be noted that Radius is used to support a
whole lot of other authentication requirements and although those
requirements are not currently in our scope we don't want to build in
artificial limits.

In our currently deployed radius systems our Accounting servers are
distinct from our Authentication servers.  Although they do share some
source code they really are distinct entities and in some cases are
run by very distinct organizational entities.

On Wed, 14 Feb 2001, Bernard Aboba wrote:

> Date: Wed, 14 Feb 2001 08:56:52 -0800
> From: Bernard Aboba <[email-masked]>
> To: "Aaa-Wg@Merit. Edu" <[email-masked]>
> Subject: [AAA-WG]: Extension requirements? 
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 22 Feb 2001 21:47:03 -0800

The reason I suggested simplifying the extensions picture
is because of the resulting protocol complications. 

The issue is really whether we expect people to deploy
proxies and servers with disparate capabilities. So
Proxy1 supports a different set of extensions from
Proxy2, or AAA server 1 supports different extensions
from AAA server 2. 

This complicates load balancing and failover 
considerably. I don't think the complexity is
justified because most load balancing systems 
assume some amount of homogeneity. 

Some of the same issues arise for accounting. One
reason that people use RADIUS auth and not accounting
is that RADIUS accounting is inferior in reliability,
so they might want to use something else (like SNMP).
 
We've put a lot of work into improving the reliability
of DIAMETER accounting, to the point where I believe
that it is the most reliable accounting protocol that
exists. If we really believe that people will choose
not to use it, then I would question whether we're
doing something wrong. 

Right now, Accounting functionality is integral to
DIAMETER. This has a number of advantages. For example,
if Accounting is split out, then we might need to put
in an auth ACK message, which tells the AAA server
what the NAS has actually implemented. If Accounting
is mandatory, then such a message is unnecessary.

In my opinion, the base protocol is not all that useful
without at least one of the NASREQ or MOBILEIP extensions.
That is why I would like to require at least one of these
on a NAS, in addition to ACCOUNTING support. Can you think
of a situation in which the NAS would only support the
base protocol? 

With respect to the server. My understanding is that the
MOBILEIP extensions are among the most popular features
of DIAMETER. I am interested to hear from DIAMETER 
implementors who are *not* planning to implement these
extensions. Based on what I've seen so far, it seems 
to me that such an implementation might 
be untenable in the market place. If so, we might as
recognize this and require NASREQ, ACCOUNTING
and MOBILEIP on the AAA server. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of [email-masked]
Sent: Thursday, February 22, 2001 8:08 PM
To: [email-masked]
Subject: Re: [AAA-WG]: Extension requirements?

---

From: Stephen McCann ITN <[email-masked]>
Date: Fri, 23 Feb 2001 08:43:45 +0000

> is mandatory, then such a message is unnecessary.

Yes, I agree.  I also believe that the accounting extension
is essential.

I'm currently working on WLAN integration with 3G systems
utilising the 'IETF' method (i.e. loose coupling approach).
In addition to using the accounting extension of DIAMETER,
I've be very interested in also resurrecting the QoS extensions
from 1998. Hopefully this work will be an infeed to the Hiperlan/2
project within ETSI BRAN.

I know this is 'not centre stage' at the moment, but I'd be
interested to collect comments on any future directions of
QoS within DIAMETER.

Regards

Stephen McCann
Roke Manor Research Ltd (A Siemens Company)
Southampton
UK

-- 
The information contained in this e-mail is confidential to Roke Manor 
and must not be passed to any third party without permission.  This 
communication is for information only and shall not create or change 
any contractual relationship.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Feb 2001 03:22:40 -0800

> Proxy2, or AAA server 1 supports different extensions

I think that that is a reasonable expectation.  OTOH, it's also reasonable
to expect that a Diameter message won't fail half-way down a proxy
chainbecause the proxy in question doesn't support a given extension.

<text deleted>>

> DIAMETER.

Unless something has changed dramatically in the past week or so, I don't
believe this statement is accurate: the last time I checked, accounting was
an _extension_ rather than part of the base protocol.  That ain't what I
call integration...

> This has a number of advantages. For example,
> be untenable in the market place.

But many RADIUS servers are home-grown, part of closed systems.  If history
is a guide, many Diameter servers will be, too.  So why would the developers
thereof care about the market?  Why should they be required to implement
something they will never use, just to be conformant?

> If so, we might as

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 25 Feb 2001 10:24:19 -0800

>chainbecause the proxy in question doesn't support a given extension.

Any suggestion on how to accomplish this?

>an _extension_ rather than part of the base protocol.  That ain't what I

Yes, it is an extension. Are proposing moving it into the base protocol?

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Feb 2001 17:36:42 -0800

> Any suggestion on how to accomplish this?

One way would be to require all proxies to support all extensions, but this
is an onerous demand on developers and probably wouldn't work anyway, given
the liklihood of vendor-specific (and even implementation-specific)
extensions and thelag between standardization and deployment.  A better way
might be to require all conformant proxies to ignore unknown extensions and
forward the messages based on other criteria (which I think has been
suggested before).

> Yes, it is an extension. Are proposing moving it into the base protocol?

Yup.

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 26 Feb 2001 08:09:58 +0200

> > Yes, it is an extension. Are proposing moving it into the base protocol?

Well, we got three things here: the document structure, division to
what we call extensions in the technical Diameter sense, and the
mandatory status of various parts. Accounting is a separate
document (like e.g. strong security) and its own extension, but a
mandatory part of the protocol.

I don't think anybody has different opinions about the mandatory
status of the accounting part.

However, I kind of like the current document and extension structure. 
I hate big RFCs. And having even mandatory parts be their own
documents and extensions sometimes forces us to structure the
protocol in a better way, plus it eases writing conformance statements,
describing what parts of the procotol a particular node uses, and so on.

Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Feb 2001 22:56:03 -0800

> mandatory part of the protocol.

Where does it say that, though?  As it stands, the base Diameter protocol is
an AA protocol, not an AAA protocol.  I can't really understand why you
would want an integral part of a _new_ protocol to be an extension.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 26 Feb 2001 14:22:44 +0200

Glen Zorn wrote:

> an AA protocol, not an AAA protocol. 

Uh... Nowhere? This is a problem. I was sort of expecting
section 2 in the base spec to talk about this.
 
> I can't really understand why you

Just for modularity in general, the base spec is already 57 pages...

Jari
-- 
Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480
Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: [email-masked]
NEW, UPDATED PRIVATE WWW http://www.arkko.com. Standard disclaimers apply.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 26 Feb 2001 06:49:37 -0800 (PST)

> Just for modularity in general, the base spec is already 57 pages...

*was* 57 pages.... many more after the interim meeting.

Also, there is nothing that prevents us from adding a statement in the base
protocol that states that the Accounting extension MUST be implemented. This
would eliminate merging both docs into one.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 26 Feb 2001 06:56:18 -0800 (PST)

> forward the messages based on other criteria (which I think has been

One thing that was proposed is to allow proxies to advertise a special
Extension Identifier, that states it is a proxy and can handle ANY extension.
Note, however, that *some* proxies will NOT want this behavior, since they
will want to enforce some local policies, so such proxies may instead want to
advertise their individual extensions.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 26 Feb 2001 07:08:06 -0800 (PST)

> Yes, it is an extension. Are proposing moving it into the base protocol?

As I stated in an earlier e-mail, I would much prefer to have two specs, but
have accounting be mandated in the base. This could be done via a new
sub-section in section 2, called Accounting Support, which states that ALL
Diameter implementations MUST support Accounting, which is documented in [x].

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 26 Feb 2001 09:45:22 -0800

> Just for modularity in general, the base spec is already 57 pages...

Modlarity is good, but there's a lot to be said for having all the
necessities in one place.  I'd rather have a single document that completely
describes the base protocol (and I think we agree that accounting is really
basic to Diameter) rather than two.  The additional text would probably
amount to 11-13 pages...

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 26 Feb 2001 09:45:32 -0800

> advertise their individual extensions.

Isn't this just a special case of the behavior described above?  After all,
you can only apply local policy to things you understand; if you don't
understand it, just pass it on and assume that someone down the line will.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 26 Feb 2001 09:45:27 -0800

> would eliminate merging both docs into one.

if (want_full_proto) goto accounting_doc
else
goto confused

;-)

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 26 Feb 2001 09:45:36 -0800

> Diameter implementations MUST support Accounting, which is

Why?

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 26 Feb 2001 10:28:13 -0800 (PST)

> > Diameter implementations MUST support Accounting, which is

Because I don't see the point in combining the two specs, just for argument
sake. What is the difference between a single spec, and two that require each
other.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 26 Feb 2001 15:30:16 -0800 (PST)

> understand it, just pass it on and assume that someone down the line will.

Right, but it doesn't seem to make sense that a proxy would have to advertise
an extension it doesn't support. Therefore, I am stating that we MAY want to
allocate a special wildcard extension number (say all ones?).

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 26 Feb 2001 15:32:44 -0800 (PST)

> if (want_full_proto) goto accounting_doc

if (know_how_to_read_section_x_of_base_protocol)
	implement_accounting_doc
else
	give_up_and_find_another_career

:)

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 26 Feb 2001 23:02:01 -0800

> allocate a special wildcard extension number (say all ones?).

OK, so you're saying that some NAS/proxies might _only_ want to talk to a
proxy that actively supports a give extension?

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 27 Feb 2001 07:04:06 -0800 (PST)

> proxy that actively supports a give extension?

That's the way the protocol works today. A NAS/proxy does not know whether it
is communicating with a proxy, or home server. So the wildcard would allow the
functionality that's been discussed.

PatC