1. Some Thoughts on Data Representation 47th IETF AAAarch Research Group David Spence Merit Network, Inc.

2. Survey of Existing Protocols RADIUS –Simple attributes COPS –Structured objects DIAMETER –Groupings of attributes using tagging SNMP –ASN.1 BER

3. Structured vs. Grouped Objects Structured objects derive from data structures in programming. Groupings of objects is somewhat broader. –Group according to interrelations among the data. –Group for routing (forwarding) purposes. –Group for security. Object level encryption Digital signatures Different groups can be protected with different keys because the objects in the group where generated by or destined to different parties.

4. The Value of a Structure Identifier Structured objects usually contain an object identifier that identifies the whole object. Object grouping techniques may not support the notion of a group identifier. Example: A structured “port” object with several fields vs. a group of simple attributes that describe a port.

5. Fixed vs Flexible Data Organization An advantage of structured objects is that the structure can be defined and fixed in advance. –If port speed is a field of the port object, then you know that the information will be available to you. A disadvantage of structured objects is that there may be no provision for optional fields. Structured objects can be made more flexible by providing for optional fields.

6. The Need to Support Nested Groupings Object groupings are usually very flexible in terms of what may be included in a group. But sometimes there isn’t much structure. –What objects must belong to a group? –What objects may belong to a group? –There may be only one level of nesting. Example: Diameter supports grouping through the use of a tag field in the attribute header. –Only one tag field implies only one level of nesting.

7. Some Other Techniques for Grouping Objects Encapsulation –Can support multiple levels of nesting. –The group itself can be given an object identifier. –Rules as to which objects must and may be included in a group object allow the advantages of structured objects to be realized with grouping. Markers –Include begin and end group markers in the object stream like parentheses. –Markers can be nested like parentheses. –The begin marker could include a group identifier field.

8. Structuring vs. Grouping: Conclusions The concepts are different, and they naturally lend themselves to different uses. Realization techniques may be powerful enough for the two concepts to provide overlapping functionality. It might be a good idea for a next generation AAA protocol to support both ideas.

9. Self-Defining Syntax Distinction between gross and fine syntax definition. RADIUS is grossly self-defining in that it is possible to skip over an attribute that you don’t understand. For purposes of this discussion, however, RADIUS is not self-defining.

10. Examples of Self-defining Syntax ASN.1 XML Corba

11. Is it useful to have self-defining Syntax without self-defining Semantics? Argument: The consumers of AAA data must understand the semantics of the data in order to process it. If you have to code the semantics, then you can code the syntax. (Exception: Yes, it should be possible to skip over objects you don’t understand.)

12. But some consumers may not need to understand the semantics. Data Display Policy Decision Point

13. Conclusion Self-defining syntax may be useful for some purposes. But there is a cost! –More bytes on the wire bandwidth hog storage hog –More complicated implementation

14. Alternatives to Self-defining Syntax Full self-defining vs. some objects that are self- defining Another alternative is to standardize the definitions of objects. –Defining authorities could make object definitions available in a standardized, formal syntax that could be machine- readable. –This makes it possible for a server to support new objects (syntactically, at least) without needing to add code. –The overhead of transmitting and storing the object syntax is eliminated.

15. A Strawman Statement of Requirements for Data Representation in AAA Protocols An AAA protocol should represent data in a way that can be both simple and powerful. An AAA protocol should conceptually support named, structured objects. An AAA protocol should conceptually support the definition of complex objects with mandatory and optional fields.

16. An AAA protocol should support arbitrary groupings of objects. It should be possible to apply security features to groups of objects. It should be possible to make message forwarding decisions about groups of objects without knowledge of the syntax or semantics of the objects comprised by the group. It should be possible to encode AAA objects in a compact form even if less compact forms are also supported. It should be possible to encapsulate arbitrary data from other protocols within an AAA protocol.