PPT Version

advertisement
RADEXT WG
RADIUS Attribute Guidelines
draft-weber-radius-attr-guidelines-01.txt
Greg Weber
November 8th, 2005
v1
IETF-64, Vancouver
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: Dec ’04 completion
IETF-64, Vancouver
2
RADIUS Attribute Guidelines
•
•
•
•
draft-weber-radius-attr-guidelines-01.txt
Have you read the draft? :-)
Aimed at charter item
Current revision primarily collects data
points from early radius-ext threads
• Strawman recommendations
• Guidelines (when to do what) largely
absent so far
IETF-64, Vancouver
3
RADIUS Attribute Guidelines
Data Model Alignment
• Vendor space somewhat varied :-)
Vendor
Packet
Cable
Vendor
Vendor
3GPP
VSAs
Microsoft
3GPP2
Tags
Vendor
3GPP2
Simple TLV
COMPLEX DATA
IETF-64, Vancouver
GROUPING
4
RADIUS Attribute Guidelines
Recommendations
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD) |
Length
|V|E|C|
(reserved flags)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Id (opt)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Length
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
•
•
•
•
Standardize existing VSA recommendation
Ease vendor to standard transition
Accommodate most VSA behavior
Plan for increased attribute number space
IETF-64, Vancouver
5
RADIUS Attribute Guidelines
00 to 01
• Largely editorial changes
• Would like to get some confirmation that
the problem statement is captured before
proceeding much further.
Open Issue: 106, Vendor Specific Values
• Standardize a method for vendors to
define custom values for standard
attributes?
IETF-64, Vancouver
6
RADIUS Attribute Guidelines
Vendor Specific Values
• VSE (enumerations) described in RFC 2882
embeds vendor ID in value, e.g.
val=((vendor-id << 16) | num)
• Require revision of RFC 3575 (RADIUS IANA
policy) and therefore a standards track doc?
IETF-64, Vancouver
7
RADIUS Attribute Guidelines
Fragmentation
• Simpler method than attribute flagging?
• EAP-Message is a non-AAA endpoint conversation, so opaque
assembly makes sense. For AAA endpoint, the less opaque,
the more checking that can be performed.
• DHCP (RFC 3396) Encoding Long Options.
Concatenate any adjacent attributes of the same type.
• Do we need to support long & short attributes of the same type
in the same message?
• How much do we rely on attribute ordering (consecutiveness)?
• How does this apply to VSAs –which are already the same
type?
IETF-64, Vancouver
8
RADIUS Attribute Guidelines
Grouping
• Named vs. unnamed tagging
• Known contents vs. arbitrary contents
• Can newly defined groups of data contain
previously defined (standard) attributes?
IETF-64, Vancouver
9
RADIUS Attribute Guidelines
Guidelines
•
•
•
•
•
When to use which format (SHOULD/MUST)
When to move from vendor to standard
When to define vendor specific values
When to use the extended type space
How to translate to/from Diameter
(see draft-mitton-diameter-radius-vsas-00.txt)
IETF-64, Vancouver
10
RADIUS Attribute Guidelines
To think about, get consensus, do...
•
•
•
•
Diameter translation
Agree on recommended approach
Actual guidelines
Address vendor specific values
IETF-64, Vancouver
11
RADIUS Attribute Guidelines
Finally,
• Is this a reasonable starting point for this
charter work item?
• Volunteers for this work?
• Discussion
IETF-64, Vancouver
12
RADIUS Attribute Guidelines
Backup Slides
IETF-64, Vancouver
13
RADIUS Attribute Guidelines
Motivation – why do we need guidelines?
• Divergent data models
• Attribute space exhaustion
• Diameter alignment
IETF-64, Vancouver
14
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
IETF-64, Vancouver
Simple TLV
15
RADIUS Attribute Guidelines
Scope
• Backwards compatibility
– Intermediate nodes
– Dictionary based implementations
– Unaware endpoints
•
•
•
•
Existing VSA usage
Transport Impact
Non-AAA applications
Diameter compatibility
IETF-64, Vancouver
16
Download