[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 58: End-to-End Capabilities
Jari chimed in...
> Issue 58: End-to-End Capabilities
> Submitter name: Jari Arkko
> Submitter email address: jari.arkko@piuha.net Date first
> submitted: January 20, 2005
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg00062.html
> Document: CUI, IEEE 802
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> I agree that we need a capabilities function. But I would
> like to see a relatively coarse granularity facility, rather
> than something that sends data about individual attributes.
> For instance, I liked the list that someone made up about
> prepaid, filtering capability, redirection, etc. The right
> granularity to me appears to roughly one RFC. I say roughly
> because I do want to prepare for the possibility that, say,
> prepaid has a small number of different profiles*.
> And yes, there can be capabilities that don't map nicely to
> new attributes.
> There seems to be a few different kinds of capabilities
> negotiation, by the way. In Diameter, for instance, we have
> hop-by-hop negotiation. The primary purpose of this scheme is
> to ensure to provide information for routing purposes.
> But another type of negotiation is something that occurs
> end-to-end with a specific home system, and this is what we
> attempt to address in the various proposals right now. The
> primary purpose of this is to ensure whether we can send an
> attribute or command or expect a behavior relating to this
> specific user's session.
>
> The difference between the two approaches is that even if you
> know next-hop wise that FOO is supported, you don't know if
> FOO is supported for the particular user's session at a
> particular home domain. Note that the end-to-end negotiation
> is typically limited to the capabilities of the server that
> you currently talk to; it may well be that even if FOO
> doesn't exist on the authentication server it might exist on
> the accounting server at the same domain. This part is harder
> to solve, so I presume we are not going to require it.
> Anyway, here's my strawman approach to capabilities
> negotiation:
> 1. End-to-end Capability Attribute
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Type | Length | Capabilities string ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Type
> TBD for end-to-end capability attribute.
> Length
> The length.
> Capabilities string
> This field contains a variable length bit string. Each
> bit position, if set to 1, indicates full compliance
> with the respective feature specification.
> An initial allocation of bits for different features
> is listed below:
> Bit 0 (NASREQ) Support for basic authentication and
> authorization service [RFC 2865, I-D.NASREQ].
> Mandatory in RADIUS.
> Bit 1 (MOBILE IPv4) Support for Mobile IPv4 [I-D.MIPv4].
> Bit 2 (PREPAID) Support for prepaid services [I-D.Prepaid-R,
> I-D.Prepaid-D].
> Bit 3 (ACCOUNTING) Support for accounting [RFC 2866, RFC 3855].
> Bit 4 (FILTER-RULE) Support for generalized filters (mandatory
> in Diameter nodes and optional for RADIUS
> nodes).
> Bit 5 (REDIRECT) Support for user-session redirection
> feature (I-D.redirect).
> Bit 6 (CUI) Support for the CUI functionality (I-D.CUI).
> Bit 7 (LOCATION) Support for the location attributes (I-D.LOC).
> Bit 128 (CX) Support for the 3GPP CX application.
> Bit 129 (Sh) Support for the 3GPP Sh application.
> Bit 130 (Rf/Ro) Support for the 3GPP Rf/Ro application.
> 2. Diameter Compatibility
> This attribute functions in an equivalent manner in both
> RADIUS and Diameter. In Diameter, the base protocol layer
> may fill in the attribute values automatically based on its
> knowledge of applications running on top of it.
> Note that a single bit has been allocated for a feature
> if it is expected that it is supported in the same manner
> in RADIUS and Diameter and that translation rules exist.
> In this situation the peer does not care whether Diameter
> or RADIUS is used on the other side. Otherwise, separate
> bits have been allocated.
> 3. IANA Considerations
> IANA should create a new name space, Capabilities Bit.
> The initial values in this name space include those
> listed in Section 1. New values in the 0-128 range can
> be allocated through IETF Consensus. Other values (upto
> 2023 i.e. 253 bytes times 8 bits) can be allocated
> on a First-Come First Served basis with Specification
> Required.
> --Jari
As with issue 57, 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/>