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

RE: Guidelines suggested text for checklist:

Appendix A - Design Guidelines

   The following text provides guidelines for the design of attributes
   used by the RADIUS protocol.

A.1. Transport of simple data

   The following kinds of data fit within the existing RADIUS data
   model, and can be encapsulated in a [RFC2865] format RADIUS
   attribute, or in a [RFC2865] format RADIUS VSA:

      * 32-bit unsigned integer, most significant octet first.
      * Enumerated data types, represented as a 32-bit unsigned integer
        with a list of name to value mappings.  (e.g. Service-Type)
      * 64-bit unsigned integer, most significant octet first.
      * IPv4 address in network byte order.
      * IPv6 address in network byte order.
      * IPv6 prefix.
      * time as 32 bit unsigned value, most significant octet first, in
        seconds since 00:00:00 UTC, January 1, 1970.
      * string (i.e. binary data), totalling 253 octets or less in
        length. This includes the opaque encapsulation of data
        structures defined outside of RADIUS.
      * UTF-8 text, totalling 253 octets or less in length.
For a checklist, I was think of a list of questions, with references to the document itself. So I'd prefer that this list not be repeated twice. Instead you could say "Does the attribute match a type described in Section X?" 


   For [RFC2865] RADIUS VSAs, the length limitation of the "string" and
   "text" types is 247 octets instead of 253 octets, due to the
   additional information included in the Vendor-Specific attribute.


This sentence should probably be in the main text.


A.2. Transport of new authentication protocols

   New authentication or security functionality in RADIUS requires
   require code changes on both the RADIUS client and server, regardless
   of the attribute format.  As a result, in most cases the use of
   complex attributes to represent these methods is acceptable.
This statement should be moved to the main text. Here you could put the question "Does the attribute define a complex data type for purposes other than authentication or security? See Section Y for a description of why this is problematic." 


A.3. Improper data types

   The following kinds of data do not fit within the RADIUS data model,
   and should be replaced with the suggested alternatives, or should not
   be used at all.
I'd consolidate this with the previous data type section, and rephrase as a question: 
"Does the attribute use any of the following data types?"

Example:

* Signed integers of any size?  These SHOULD NOT be used.



      * Signed integers of any size.
        SHOULD NOT be used.
      * 8 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save three bytes.
      * 16 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save two bytes.
      * Tagged data types as in [RFC2868].
        These data types SHOULD NOT be used in new specifications.  The
        attribute grouping method defined in [EXTEN] SHOULD be used
        instead.
      * Complex data structures defined only within RADIUS.
        The additional functionality defined in [EXTEN] SHOULD be used
        instead.  This recommendation does not apply to new
        authentication or security functionality, as described above in
        Section A.2.
      * Multi-field text strings.
        Each field SHOULD be encapsulated in a separate attribute.
        Where grouping of fields is desired, the additional
        functionality defined in [EXTEN] SHOULD be used instead.
      * Polymorphic attributes.
        Multiple attributes, each with a fixed data type SHOULD be
        defined instead.

A.4. Vendor-Specific formats

   Vendor-Specific attributes SHOULD follow the [RFC2865] suggested
   format, or the [EXTEN] format if more functionality or a larger
   attribute space is necessary.  Vendor-Specific attributes matching
   any of the following formats SHOULD NOT be used.
Large SDOs with multiple groups would probably do better with a 16-bit attribute space. Given this, is the suggested format still a SHOULD, or do we say "suggested format, using an 8 or 16-bit attribute space." 



      * Vendor types of more than 16 bits.
      * Vendor lengths of less than 8 bits.  (i.e. zero bits)
      * Vendor lengths of more than 8 bits.
      * Vendor-Specific contents that are not in Type-Length-Value
        format.

A.5. New functionality in RADIUS.

   Some implementations have extended RADIUS by a number of methods.
   The following practices are NOT RECOMMENDED:

      * Defining new commands in RADIUS.
        This restriction includes new commands created by overloading
        the Service-Type attribute to define new values that modify
        the functionality of Access-Request packets.
Since the document is about attributes, I think this should say "Defining new RADIUS commands using attributes." We're not talking about restricting new standards-track documents defining new commands (e.g. RFC 3576). 


      * Using RADIUS as a transport protocol.
        This restriction is partially a subset of the previous one.
        Note that using RADIUS to transport authentication methods
        (e.g. EAP) is explicitly permitted, even if those methods
        require the transport of relatively large amounts of data.
Since the focus is on attributes, I'm not sure what this refers to. Would this apply to the GEOPRIV document, for example? 


      * Extending the RADIUS packet length limitation past 4096 octets.
        A multi-packet sequence of Access-Request / Access-Challenge
        SHOULD be used instead.  If that is not possible, then a method
        other than RADIUS SHOULD be used to transport the data.

A.6. Allocation of attributes

   RADIUS attribute specifications SHOULD allocate attributes from the
   vendor space, rather than requesting an allocation from the RADIUS
   standard attribute space, for attributes matching any of the
   following criteria:

      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.
This duplicates existing text, so I'd rephrase as a question: "Does the attribute match any of the following critiera? If so, then...." 


   Even if attributes are allocated from the vendor space, it is often
   useful for SDOs to publish the specification as an informational RFC,
   as with [RFC4679].

   Note that the first bullet point above relaxes many of the previous
   guidelines on data types, but only within a narrowly defined scope.
   Extensions to RADIUS that may not be appropriate for widespread use
   may be acceptable within a limited context.




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