Re: Proposal: Capabilities Attribute

[Jari Arkko <jari.arkko@piuha.net>]

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

*) I too dislike complexity in the prepaid scheme. But having
reviewed requirements and interest from various different
scenarios, I tend to agree with Avi that we can't make it
simpler.

--
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/>