AAA Design Team Data Modelling Issues & Solutions

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 < '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 DisplayStringip-address Octetstring is an IP addresstime Unsigned32 is a timestampconstrained Only listed values are legalvendor-flag Allows V flag to be setmandatory-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.