RADEXT WG RADIUS Attribute Guidelines

1
RADEXT WGRADIUS Attribute Guidelines
draft-weber-radius-attr-guidelines-02.txtdraft-wo
lff-radext-ext-attribute-00.txt

• Greg Weber
• March 21st, 2006

IETF-65, Dallas
v1
2
RADIUS Attribute Guidelines

• WG Charter Item
• RADIUS design guidelines. This document will
  provide guidelines for design of RADIUS
  attributes. It will specifically consider how
  complex data types may be introduced in a robust
  manner, maintaining backwards compatibility with
  existing RADIUS RFCs, across all the classes of
  attributes Standard, Vendor-Specific and
  SDO-Specific. In addition, it will review RADIUS
  data types and associated backwards compatibility
  issues.
• Milestone Oct 06 completionOriginally Dec 04

Guide-01
ExtAttr-00
Guide-02
Guide-00
DraftRevisions
Milestones
IESG Submissions
WG LC1
IETF-65, Dallas
3
RADIUS Attribute Guidelines

• draft-weber-radius-attr-guidelines-02.txtdraft-wo
  lff-radext-ext-attribute-00.txtdraft-evbergen-rad
  ext-extended-attribute-02.txt
• Aimed at charter item
• The Guidelines draft collects data points from
  early radius-ext threads current behavior,
  solution scope, and guidelines
• The Wolff draft proposes a Diameter-based
  encoding
• The Van Bergen draft proposes a RADIUS-like
  tagging mechanism
• Have you read the drafts? -)

IETF-65, Dallas
4
RADIUS Attribute Guidelines

• Motivation why do we need guidelines?
• Divergent data models
• Attribute space exhaustion
• Diameter alignment

IETF-65, Dallas
5
RADIUS Attribute Guidelines

• Data Model
• Two attribute spaces standard vendor
• Small number of data types
• Consistent TLV payload use enables
• interoperability, intermediate nodes (proxies)
• simple implementation attributes can be added
  without new parsing code
• Many exceptions

Simple TLV
IETF-65, Dallas
6
RADIUS Attribute Guidelines

• Data Model Alignment
• Vendor space somewhat varied -)

Vendor
PacketCable
Vendor
Vendor
3GPPVSAs
Microsoft
3GPP2
Tags
Vendor
3GPP2
FRAGMENT
ENCRYPT
COMPACT
SHARED
Simple TLV
COMPLEX DATA
GROUPING
IETF-65, Dallas
7
RADIUS Attribute Guidelines

• Scope
• Backwards compatibility
• Intermediate nodes
• Dictionary based implementations
• Unaware endpoints
• Existing VSA usage
• Transport Impact
• Non-AAA applications
• Diameter compatibility

IETF-65, Dallas
8
RADIUS Attribute Guidelines

• New Section 7 new attributes SHOULD comply with
  the attribute design guidelines given in RFC 2865
  unless one or more of the following applies
• The standard attribute space for new attributes
  has been exhausted.
• The proposed maximum attribute length exceeds
  that available for attributes specified by RFC
  2865.
• The native data type of the data element is
  defined for Extended attribute, but not standard
  RADIUS, e.g. Integer64.
• Logical grouping is required.
• In the cases above, it is RECOMMENDED that the
  extended attribute encoding specified by the
  Wolff draft be used.

IETF-65, Dallas
9
RADIUS Attribute Guidelines

• Further recommendations
• The Vendor-Specific Enumeration (VSE) encoding
  mechanism as proposed by Section 2.2.1 of RFC
  2882 SHOULD NOT be used. Instead, vendors should
  comply with the recommendations of RFC 3575.
• Per-attribute encryption mechanisms other than
  specified by RADIUS standards SHOULD NOT be used.
• The message lengths specified by RADIUS standards
  MUST NOT be exceeded.
• Variable attribute content SHOULD NOT be
  specified. Separate attributes SHOULD be defined
  instead.
• SDOs are RECOMMENDED to use the standard
  attribute space for attributes that are intended
  to be supported by multiple vendors.

IETF-65, Dallas
10
RADIUS Attribute Guidelines

• From the Wolff draft Four distinct types of
  syntax
• Abstract syntaxFirst most important what
  information is to be represented?
• Display syntaxHow the info is presented to a
  human also useful for inter-application transfer
• Transfer syntaxBits on the wire derived from
  Abstract syntax, not vice versa!
• Internal syntaxImplementation determined, nobody
  elses business

IETF-65, Dallas
11
RADIUS Attribute Guidelines

• Criteria for evaluating extended attribute format
• Top prioritiesRemove 255 limit on attribute type
  numberRemove 253 limit on attribute value
  lengthSupport rich set of standard attribute
  value typesSupport groupingEasy transition of
  attributes from VSA to standard
• Mid prioritiesEase of gatewaying to
  DiameterSupport multi-level (nested)
  groupingM-bit (mandatory attributes)build on /
  re-use existing work
• Low prioritiesMinimal attribute header
  sizeElegance, alas

IETF-65, Dallas
12
RADIUS Attribute Guidelines

• From the Wolff draft Advantages of a
  Diameter-based encoding
• Satisfies all top mid priority criteria
• All new RADIUS features need Diameter spec too
  minimizes author work
• Grouped sub-attributes are together in specified
  order, making validation display straightforward

IETF-65, Dallas
13
RADIUS Attribute Guidelines

• Diameter AVP header

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
-------------------------
-------
AVP Code
-------------------------
------- V M P r r r r r
AVP Length
-------------------------
-------
Vendor-ID (opt)
-------------------------
------- Data ...
--------

• Larger code length fields
• Optional Vendor-ID
• M-bit
• More standard data types

IETF-65, Dallas
14
RADIUS Attribute Guidelines

• Issues addressed by the Wolff draft
• Extended-Space attribute encaps extended
  attributes
• Diameter-based AVP encoding
• EAP-Message like concatenation
• Alignment padding
• Additional data types
• M-bit support
• Questions
• Extended attributes in Access-Reject?
• Range of Diameter code points?

IETF-65, Dallas