AAA Design Team Data Modelling Issues

1
AAA Design TeamData Modelling Issues Solutions
Erik Guttman Sun Microsystems Member of AAA
Design Team
2
Outline

• 5 mins Goals for discussion
• 5 mins Issues
• What we need to do
• What are the criteria for evaluation of
  solutions?
• 5 mins Diameter.xml - Erik
  Guttman
• 5 mins Network Access Data Model -
  Dave Spence
• 5 mins Mapping of SMIng to Diameter -
  Juergen Schoenwaelder
• 5 mins Evaluation of solutions

3
Goals

• Big Goal Address vital concerns in a timely
  way. Defer work on non-vital issues, avoid
  solutions which will not deliver rapidly.
• Present AAADT Issues and Solutions
• Present Formal Data Notation Proposals
• For specification
• For debuggers, storage, sniffers...
• NOT for on-the-wire representation
• Evaluate proposals - if time permits

4
Issues

• Read draft-ietf-aaa-issues-04.txt
• Separate base protocol and specific messages
• Allows proxies, sniffers, receivers, etc to know
  something, even if the command or extension is
  unrecognized
• Data types
• less specific, more types, replace 'Complex'
• Formal notation for Diameter AVPs (Cmds?)
• verify definitions, automate implementations, aid
  debugging/sniffing, enhance extensibility
• non-goals universal generality, presentation

5
Issues, continued

• Must AVPs be ordered in a message?
• 'M' bit
• Should we improve message specifications?

6
Formal Notation Evaluation Criteria

• Is it possible to specify existing DIAMETER
  messages?
• Is the formal notation tied to stable standards
  (which won't change in near-medium term)?
• How much less efficient is the data typing than
  DIAMETER as specified?

7
Solution Message Separation

• DIAMETER message header flags field unused.
• Assign flag bits
• 0x04 E Expect Reply
• 0x02 I Interrogation (otherwise ACTION)
• 0x01 R Response
• 4 lt 'Indication', 4 Request, 5 Reply, 6
  Query, 7 Answer
• Examining the flags yields the type of msg.May
  be useful for logging, security policy...

8
Solution Data Types

• Was
• Data, String, Address, Integer32, Integer64, Time
  and Complex.
• Change to
• Address, Integer32, Unsigned32, Integer64,
  Unsigned64, Float32, Float64, Float128,
  OctetString, Grouped and List.

9
Solution Data Type, 2

• Grouped struct, List array
• Should these impose order or not?
• Is List really needed? Grouped seems to be.
• Worst case waste of space of Grouped type
• Complex has 1 AVP header, 2 four byte elts12
  bytes header 8 bytes data 20 bytes
• Grouped has 3 AVP headers, 2 four byte elts36
  bytes header 8 bytes data 48 bytes
• 140 larger is the worst case

10
Solution Ordering

• Flexibility vs. simplicity (of parsers, etc.)
• RADIUS flexibility has been useful
• Many commands can only be interpreted after all
  AVPs have been processed
• Recommendation Do not add a new requirement to
  impose ordering of AVPs

11
Solution Formal Data Notation

• 3 presentations
• Unfortunately, only one is currently available as
  an internet draft
• Discuss how they meet criteria
• Attempt an evaluation

12
DIAMETER XML

• See draft-ietf-aaa-solutions-01.txt, appendix A,
  other proposals may follow
• Specifies DTD for base DIAMETER and extension
  AVPs.
• Includes xml data for all currently specified
  AVPs.
• To do Add command codes.

13
DIAMETER XML, 2

• A set of base extension AVPs
• Each AVP has a name and type, and optionally a
  description and a set of values.
• AVP elements specify 'may-encrypt' attribute, and
  may set additional attributes printable
  OctetString is DisplayString ip-address
  Octetstring is an IP address time
  Unsigned32 is a timestamp
  constrained Only listed values are legal
  vendor-flag Allows V flag to be set
  mandatory-flag Optional, disallowed, req'd

14
DIAMETER XML, 3

• This approach can represent all existing and
  forseeable AVPs.
• Based on stable and accepted data representation
  standard - XML
• Easily extensible to new AVPs, standard
  extensions, vendor extensions, etc.