[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 56: Capabilities Attribute



I agree that cutting functionality is a good way to
achieve a deadline. Are there any remaining issues
wrt. the security properties of unknown support for
filters etc?

--Jari

Sanchez, Mauricio (PNB Roseville) wrote:

Bernard pointed out...




Issue 56: Capabilities Attribute
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com Date first submitted: January 28, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00034.html
Document: CUI, IEEE 802
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Farid mentioned in his last message that we might want to move ahead on defining a general Capabilities attribute. Here is a strawman proposal:




<...strawman proposal removed for brevity...>


  String2

The String2 field is one or more octets. The actual format of the
information is site or application specific as described in
[RFC2865] Section 5.26.
[Glen Zorn]
Why only client & request?
[Bernard Aboba]
The usage scenario I had in mind was a NAS announcing to a server that it supported various attributes. This could be useful, for debugging purposes (oops, I forgot to upgrade that NAS!), or backward compatibility (server won't send a new attribute to a NAS that doesn't support it).


Can you describe how a server could use a Capabilities attribute?
Proposed Resolution: Discuss



The question of a capability attribute is one that puts the timeliness for completion of the ieee802 draft in jeopardy. The design team has decided to punt in the short-term and not have a direct dependence on a capability attribute. Proposed text follows:

"2.1. Capability Advertisement

RADIUS does not currently define a method by which a NAS can advertise
its capabilities and in many instances, it would be desirable for the
home network to know what capabilities are supported by the NAS to
ensure proper operational behavior. The attributes defined in this
document are intended to be used to enforce policy by the NAS. If a NAS
does not recognize these attributes it will most likely ignore them and
the desired policy will not be enforced. A method for the NAS
advertising the capability to support these attributes would help the
AAA server understand if the intended policies can be enforced.
Inasmuch, we expect this lack of generalized capability advertisement to
be rectified and when available, should minimally be used in conjunction
with the NAS-Filter-Rule(TBD) attribute. "


MS

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>






--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>