Subject: RE: [AAA-DOCTORS] [Dime] AD Review of dime-qos-parameters-06.txt

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 9 Nov 2008 20:50:09 -0800

Glen Zorn said:

"Still looks like (bad) RADIUS to me."

Can someone explain the relationship of this document to (bad or good)
RADIUS?

Looking at the DIME WG charter, there is an item for the Diameter QoS
application
(http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt), 
Which in turn has normative references to QoS Attributes for Diameter
(http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-08.txt)
and this document.

None of these documents request allocation of any RADIUS attributes, or
describe RADIUS Attribute formats.  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 10 Nov 2008 08:41:23 +0200

Hi Bernard,

We have currently three documents in DIME that relate to QoS: The Diameter
QoS application specifies, as the name indicates, a Diameter application for
usage with QoS. The QoS attribute draft provides the encoding of classifiers
and AVPs relevant for QoS. The actual QoS parameters for an initial profile
are defined in the QoS parameters draft. These drafts in DIME focus on
Diameter usage. We have dependencies from the 3GPP on these documents. 

It is, however, quite easy to imagine that QoS parameters might also be
useful in a RADIUS context. In fact we had a document some time ago that
described how to re-use the same QoS parameter format for RADIUS. The
document is, however, expired now and would need a significant update given
the changes we have seen in the DIME documents. 

When it comes to the format then our believe so far was that the format of
the QoS parameters was not really important as the authorization decision
and related admission control procedures by the AAA server will require code
changes. Code changes to the AAA client will be needed as well since the
parameters need to be feed into a Traffic Control module.

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Bernard Aboba
>Sent: 10 November, 2008 06:50
>To: 'ext Romascanu, Dan (Dan)'; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [AAA-DOCTORS] [Dime] AD Review of 
>dime-qos-parameters-06.txt
>
>Glen Zorn said:
>
>Can someone explain the relationship of this document to (bad 
>or good) RADIUS?
>
>Looking at the DIME WG charter, there is an item for the 
>Diameter QoS application 
>None of these documents request allocation of any RADIUS 
>attributes, or describe RADIUS Attribute formats.  
>
>
>
>_______________________________________________
>AAA-DOCTORS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/aaa-doctors
>

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Nov 2008 14:43:14 -0600

> the changes we have seen in the DIME documents.

It's very simple: if these attributes/AVPs are meant to be used in RADIUS
then do the work in radext (or at the very least, follow the RADIUS design
guidelines); note that those attributes could be carried w/o any fuss in
Diameter as well.  If they are meant to be used in Diameter, then design
them as Diameter AVPs, using the features that Diameter enables (grouped
AVPs, etc.).  What you have done is neither, and have (predictably) ended up
with a mess.

> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 10 Nov 2008 15:57:30 -0500

Glen Zorn writes...

> It's very simple: if these attributes/AVPs are meant to 
> be used in RADIUS then do the work in radext (or at the 
> very least, follow the RADIUS design guidelines); ...

I agree.  If functionality is required in *both* RADIUS and Diameter, it
will need to be cast in the "least common denominator" format of RADIUS
attributes, subject to the RADIUS Design Guidelines.

Is there an actual requirement for these QoS attributes in RADIUS
environments?

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 11 Nov 2008 07:02:39 -0500

Hannes Tschofenig writes...

> * This approach is totally inline with the RADIUS design guidelines.
> The RADIUS design guidelines document does not require every info
> element to following the standard encoding, as you know.

The RADIUS Design Guidelines document is pragmatic.  It *strongly* suggests
(SHOULD not MUST) that attributes which could reasonably be implemented in a
data-dictionary driven RADIUS server as data dictionary entries be encoded
in the standard encoding.  Exceptions are made for (a) attributes which
would absolutely require code changes in the server, (b) attributes used as
authentication credentials payloads, and (c) attributes which are opaque to
the RADIUS server and RADIUS client.

This is not a matter of aesthetics or personal design choice -- it is
dictated by the usage.

BTW, *my* definition of opaque means that the data field of the attribute,
as described in the RADIUS document is a single string, whose contents are
defined in some non-RADIUS document.  Once the RADIUS attribute definition
starts breaking the attribute data payload into sub-fields it really isn't
opaque anymore.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 11 Nov 2008 14:20:58 +0200

Hi David, 

>The RADIUS Design Guidelines document is pragmatic.  It 
>*strongly* suggests (SHOULD not MUST) that attributes which 
>could reasonably be implemented in a data-dictionary driven 
>RADIUS server as data dictionary entries be encoded in the 
>standard encoding.  Exceptions are made for (a) attributes 
>which would absolutely require code changes in the server, (b) 
>attributes used as authentication credentials payloads, and 
>(c) attributes which are opaque to the RADIUS server and RADIUS client.

I don't think that attributes can be opaque to the RADIUS client since the
client has todo something with them. 

The attributes are opaque to the RADIUS server and the respective component
(dealing with policy-based admission control) needs to be implemented (=code
changes). 

>
>This is not a matter of aesthetics or personal design choice 
>-- it is dictated by the usage.
>
>BTW, *my* definition of opaque means that the data field of 
>the attribute, as described in the RADIUS document is a single 
>string, whose contents are defined in some non-RADIUS 
>document.  Once the RADIUS attribute definition starts 
>breaking the attribute data payload into sub-fields it really 
>isn't opaque anymore.

Currently, we do not yet define the RADIUS attributes (and that would be a
RADEXT document) but they will then be defined as a string and within that
string there will be the content of the QoS parameters. 

Ciao
Hannes

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 11 Nov 2008 09:14:25 -0500

Hi Hannes,

> I don't think that attributes can be opaque to the RADIUS 
> client since the client has todo something with them.

Maybe this is a matter of semantics.  Just as the RADIUS Server does not
comprise the complete set of server-side AAA functionality (e.g. policy
servers, location servers, authentication back-ends, etc. are logically
separate), the RADIUS Client does not comprise the complete set of AAA
functionality in the NAS.  The RADIUS Client delivers authorization
information to the components of the NAS that enforce access control.

When you define the RADIUS Server and RADIUS Client in this narrow sense,
i.e. the code that deals with RADIUS PDUs, I think you can claim the certain
attributes are opaque to the RADIUS Client (but certainly not to the NAS).

-- Dave

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 11 Nov 2008 16:52:56 +0200

Hi Mikko, 

the reason is that we essentially "copied" the format defined in the NSIS
group as they have been working on the definition of the QoS parameters. 
In the past folks in DIME did not have a problem with the format and I also
specifically asked for feedback on this issue. 

In fact, I even compiled a version of the draft with Diameter encoding once:
http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05
As one can see from that document it isn't totally easy either to use
Diameter AVPs as the format that is being referenced comes directly from a
various RFCs and there is the obvious question whether the format should be
taken as is or also "translated". For example, take a look at Section
3.11.3. of http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05
(PHB-Class AVP). 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] 
>Sent: 11 November, 2008 16:24
>To: [email-masked]; [email-masked]
>Subject: RE: [Dime] [AAA-DOCTORS] AD Review of 
>Hi,
>Would it be useful to add some text to the draft to explain 
>and justify the usage of the encoding format that you've 
>chosen for the qos parameters?
>
>It is not obvious why is it be better to define separate qos 
>parameter header and formats instead of using normal Diameter 
>AVP header and formats to transfer the data.
>
>
>BR,
>Mikko
>
>
>>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of 
>>ext Hannes Tschofenig
>>Sent: 11 November, 2008 14:21
>>To: 'David B. Nelson'; [email-masked]
>>Subject: Re: [Dime] [AAA-DOCTORS] AD Review of 
>>>*strongly* suggests (SHOULD not MUST) that attributes which could 
>>>reasonably be implemented in a data-dictionary driven RADIUS 
>server as 
>>>data dictionary entries be encoded in the standard encoding.  
>>>Exceptions are made for (a) attributes which would 
>absolutely require 
>>>code changes in the server, (b) attributes used as authentication 
>>>credentials payloads, and
>>The attributes are opaque to the RADIUS server and the respective 
>>component (dealing with policy-based admission control) needs to be 
>>implemented (=code changes).
>>
>>>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Nov 2008 16:42:34 -0600

> http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05

As luck would have it, I think that was the one I read :-) -- no wonder I
had no problem.

> 3.11.3. of http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05

What's wrong with it?  It seems at least as comprehensible as section 4.13
of -06...

...

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Nov 2008 17:02:11 -0600

Tschofenig, Hannes (NSN - FI/Espoo) [mailto:// [email-masked]]
writes:

> Glen,
> 
> >It's very simple: if these attributes/AVPs are meant to be
> >used in RADIUS then do the work in radext (or at the very
> >least, follow the RADIUS design guidelines); note that those
> >attributes could be carried w/o any fuss in Diameter as well.
> >If they are meant to be used in Diameter, then design them as
> >Diameter AVPs, using the features that Diameter enables
> >(grouped AVPs, etc.).  What you have done is neither, and have
> >(predictably) ended up with a mess.
> 
> You obviously don't care too much about my arguments.
> 
> There are three things:
> 
> * The QoS can be carried in RADIUS and Diameter.

If that is the intention, then these should be RADIUS attributes.

> element to following the standard encoding, as you know.

I think that you've got at least two people who disagree with you on that.

> 
> * Where todo certain documents is a matter of taste and not really a
> bit
> issue (at least so far).

??!  You're not seriously suggesting that Diameter AVPs & RADIUS attributes
are technically equivalent, are you?

> We had a RADIUS draft, as I mentioned, but we focused all our efforts
> on
> the Diameter work.

That's the main problem: the -05 draft contained Diameter AVPs but -06
doesn't.  In fact, this is exactly the kind of application for which
Diameter was designed & I find it rather annoying what's being proposed are
poorly designed RADIUS attributes masquerading as Diameter AVPs.

---

From: Avi Lior <[email-masked]>
Date: Fri, 14 Nov 2008 13:54:40 -0500

Folks are throwing around terms like RADIUS server and RADIUS client all over the place.

What is really lacking is a defintion - that we can all agree - of what is a RADIUS Server and a RADIUS Client.

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: November 11, 2008 9:14 AM
> To: [email-masked]
> Maybe this is a matter of semantics.  Just as the RADIUS
> Server does not comprise the complete set of server-side AAA
> functionality (e.g. policy servers, location servers,
> authentication back-ends, etc. are logically separate), the
> RADIUS Client does not comprise the complete set of AAA
> functionality in the NAS.  The RADIUS Client delivers
> authorization information to the components of the NAS that
> enforce access control.
>
> When you define the RADIUS Server and RADIUS Client in this
> narrow sense, i.e. the code that deals with RADIUS PDUs, I
> think you can claim the certain attributes are opaque to the
> RADIUS Client (but certainly not to the NAS).
>
> -- Dave
>
>
>
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in
> a single line as the message text body.