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

Some Thoughts on Data Representation

  • Upload
    gilead

  • View
    26

  • Download
    3

Embed Size (px)

DESCRIPTION

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. - PowerPoint PPT Presentation

Citation preview

Page 1: Some Thoughts on Data Representation

Some Thoughts on Data Representation

47th IETF

AAAarch Research Group

David Spence

Merit Network, Inc.

Page 2: Some Thoughts on Data Representation

Survey of Existing Protocols

• RADIUS– Simple attributes

• COPS– Structured objects

• DIAMETER– Groupings of attributes using tagging

• SNMP– ASN.1 BER

Page 3: Some Thoughts on Data Representation

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.

Page 4: Some Thoughts on Data Representation

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.

Page 5: Some Thoughts on Data Representation

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.

Page 6: Some Thoughts on Data Representation

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.

Page 7: Some Thoughts on Data Representation

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.

Page 8: Some Thoughts on Data Representation

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.

Page 9: Some Thoughts on Data Representation

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.

Page 10: Some Thoughts on Data Representation

Examples of Self-defining Syntax

• ASN.1

• XML

• Corba

Page 11: Some Thoughts on Data Representation

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.)

Page 12: Some Thoughts on Data Representation

But some consumers may not need to understand the semantics.

• Data Display

• Policy Decision Point

Page 13: Some Thoughts on Data Representation

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

Page 14: Some Thoughts on Data Representation

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.

Page 15: Some Thoughts on Data Representation

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.

Page 16: Some Thoughts on Data Representation

• 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.