1 / 16

Some Thoughts on Data Representation

Some Thoughts on Data Representation. 47th IETF AAAarch Research Group David Spence Merit Network, Inc. Survey of Existing Protocols. RADIUS Simple attributes COPS Structured objects DIAMETER Groupings of attributes using tagging SNMP ASN.1 BER. Structured vs. Grouped Objects.

gilead
Download Presentation

Some Thoughts on Data Representation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related