1. XML Schema for Accessing SMIv2 Data Models IETF69 Chicago BOF David Harrington

2. Agenda Blue Sheets, Jabber, Notes takers Agenda Bashing Purpose of the BOF –The Case for MIB Access –The Case for XSD Format –The Case for Security Requirements –The Case for a WG –Resources –Proposed Charter BOF documents Open Discussion

3. Agenda Purpose of the BOF –The Case for MIB Access –The Case for XSD Format –The Case for Security Requirements –The Case for a WG –Resources –Proposed Charter BOF documents Open Discussion

4. Purpose of the BOF 1.Is there an operational need for MIB Access? 2.Is there an operational need for XML and XSD formats of select SMIv2 MIB information? 3.Is there an operational need for security requirements realted to MIB access? 4.Should there be a working group to focus community interest? 5.Are there resources to do the work? 6.Is the proposed charter acceptable for a WG?

5. Agenda Purpose of the BOF –The Case for MIB Access –The Case for XSD Format –The Case for Security Requirements –The Case for a WG –Resources –Proposed Charter BOF documents Open Discussion

6. The Case for MIB Access IETF Management Framework calls for MIB shared by multiple protocols The economics of reuse

7. IETF Strategy 1988: Data vs. Protocols RFC1052 (1988): Separate Data from Protocols –One “Management Information” database –Multiple Protocols can transport the data –Management Area develops a single MIB

8. IETF Strategy 1994: Data vs. Protocols Modular Information Model –Modular “Management Information” database –WGs develop MIB Module to manage their protocol –Multiple protocols can access the MIB modules

9. The Case for MIB Access IETF has spent twenty years standardizing information in the MIB Device vendors have spent twenty years developing proprietary data models in the MIB Much of the information in the MIB has been used by NMSes to provide interoperable management across vendors’ devices New management protocols should leverage existing interoperable semantics and instrumentation where applicable to their protocol.

10. The Case for MIB Access MIB data models provide a SMI-syntax interface to underlying instrumentation Vendors have spent lots of money providing the instrumentation “hooks” to supply interoperable values for the MIB data model interfaces. Most vendors do not want a new series of “hooks” for similar semantic information; they want reuse of existing hooks, where applicable. Operators have learned the interoperable semantics of many MIB objects; e.g., they know what a particular counter does and does not count. We should leverage what they already know; we should provide reuse of the semantics.

11. Agenda Purpose of the BOF –The Case for MIB Access –The Case for XML and XSD Formats –The Case for Security Requirements –The Case for a WG –Resources –Proposed Charter BOF documents Open Discussion

12. The Case for XML/XSD Format The 2002 IAB Network Management Workshop proposed exploration of alternative approaches –A Configuration Protocol based on XML –Data Models based on XML –Also continue developing the SMI –See RFC 3535 XML and XSD are being widely used so there are many tools available to work with XML and XSD. XML and XSD are being widely taught, so CS students coming out of school will already know XML and XSD

13. IETF Strategy 2002: Explore Alternatives Certain alternatives should be explored –IETF-standard XML-based protocol and data models for configuration –Continue evolution of MIB as a data modeling language –Fix data model standardization (faster, more complete)

14. IETF Proposed Strategy 2006: Right tool for the task May 2006 IESG Retreat, OPS Area meetings Network Management Complexities –Need to select the right tool for a given task –Need robust reusable building blocks –Break separation of applications and NM protocols

15. Netconf Notifications 2007: Carrying Syslog and SNMP data Netconf Notifications –Access to non-netconf streams of data –MUST convert the data into XML format

16. Carrying TLV Management Data SNMP varbinds: type, OID, value XML elements:, value (no type included, external XSD needed)

17. Restricting TLV Data TLV in varbinds encoded in ASN.1 types MIB modules describe object restrictions: –ASN.1 INTEGER => Unsigned32 (1..10) –OCTET STRING  SIZE(32) –ASN.1 INTEGER => Counter64 –OCTET STRING => SnmpAdminString

18. Restricting TLV Data TLV in XML encoded in XML elements Label and value passed in XML elements No type passed in XML elements XML Schema describes object restrictions: –Xs:unsignedint xs:restriction minInclusive value=0; maxInclusive value=10 –xs:string minLength value=0, MaxLength value=32 –Xs:complextype name=“InetAddressIPv4z “ –Xs:simpletype name=“SnmpAdminString”

19. Validating TLV Data Restrictions MIB objects XML elements Validate using MIB module Validate using XML Schema

20. Validating TLV Data Restrictions when accessing MIB data MIB objects XML elements Validate using MIB module Validate using XML Schema

21. The Case for XML and XSD Formats: Samples Using Smidump to Convert MIB to XSD –Sample (full) translation of SMIv2 to XSD –Need to decide what [not] to translate Datatypes for Netconf Data Models –Useful SMIv2 Textual Conventions in XSD Accessing MIBs using NETCONF Netconf Notifications

22. Agenda Purpose of the BOF –The Case for MIB Access –The Case for XSD Format –The Case for Security Requirements –The Case for a WG –Resources –Proposed Charter BOF documents Open Discussion

23. The Case for Security Requirements The MIB contains much sensitive information about a network The IETF required secure SNMP because MIB access can lead to cascading security breaches and enable DoS attacks MIB Access permits attackers to look for weaknesses, detect implementation limits, and learn how they can attack routing and switching stacks, modify security settings, create DoS attacks, and cover their tracks.

24. The Case for Security Requirements Security is a Process, not a product - a chain is only as strong as its weakest link. SNMPv3 is a “product” that can provide security for MIB data. Other protocols can create weaknesses in MIB security by ignoring operator- configured security that protects against unauthenticated and unauthorized access to the information in the MIB

25. The Case for Security Requirements Security process needs to be balanced and consistent. Ten deadbolts on a front door are useless if burglars can use an unlocked window SNMP is designed to allow operators to configure lightweight-to-strong security of the MIB depending on their environment. Other protocols should recognize and respect the MIB security parameters configured by operators

26. Agenda Purpose of the BOF –The Case for MIB Access –The Case for XSD Format –The Case for Security Requirements –The Case for a WG –Resources –Proposed Charter BOF documents Open Discussion

27. Case for a Working Group Should these just be independent submissions? –Might represent narrow view –Would benefit from wide review –Faster to get done without process issues Should there be a WG? –Wider pool of input from experienced team –organized review process –Processes to assure focus and consensus

28. The Case for a WG XSD for MIB access should be consistent regardless of protocol XSD for MIB access should consistently reflect restrictions from the MIB module Many ways to express restrictions using XSD Multiple Netconf Data Modeling Efforts –Different approaches to XSD support Pure XSD, unrestricted use, normative XSD Adapted subset of XSD Generated XSD as Informative, not normative We should standardize the XSD for MIB Access Need to reach community consensus on format

29. Agenda Purpose of the BOF –The Case for MIB Access –The Case for XSD Format –The Case for Security Requirements –The Case for a WG –Resources –Proposed Charter BOF documents Open Discussion

30. Resources Proposed deliverables Are there authors? Are there prototype implementers? Are there reviewers? Should these be Independent submissions? Should there be a WG? –WG charter

31. Proposed Documents XML Datatypes for Management Information –Useful XML equivalents of SMIv2 datatypes –Useful XML equivalents of SMIv2 Textual Conventions Need to decide which datatypes and which Textual Conventions will be useful

32. Proposed Documents How to Convert MIB Modules to XSD Need to decide how XSD would be used –Validating data passed over protocols –Importing MIB module definitions into XSD- capable tools, such as databases and visualization tools Need to decide what [not] to translate Need to decide how to translate

33. Proposed Documents Security Requirements for MIB Access SNMPv3 identifies security requirements, details threats and provides mitigation Should all protocols meet similar requirements? Which requirements can be different? Multi-protocol write access to MIB data could be cause volatile interactions Multi-protocol read access to MIB data might disclose information despite operators having specified read controls on MIB data via VACM

34. Proposed Documents Accessing MIBs using NETCONF How to apply XML/XSD translations and MIB Access Requirements to NETCONF MIB access Separate netconf capability (special verbs) allows operators to enable/disable MIB access if netconf access control is not consistent with access control of other protocols (SNMP) Netconf-specific - probably better as an NEE or Netconf WG item

35. Resources Chairs –AD decision; Volunteer to AD if interested Authors –Yan Li is willing, capable, and available –Seeking additional authors and co-authors Reviewers –Seeking volunteers Implementers –Some of this is already in smidump and libsmi –Huawei plans to prototype –Seeking volunteers

36. Resources: Overlap with Other WGs XSDMI WG –Focused on MIB access for multiple protocols, not just Netconf Netconf WG –Closing (or NEE becomes new Netconf WG) NEE WG –Netconf protocol extensions –Partial locking, monitoring more important than Netconf MIB Access Netconf Data Modeling –Focused on developing a new SMI approach –Not focused on MIB translations

37. Resources: Competition for Resources Netconf/NEE/Netmod has resources who have been active for years in Netconf and have existing implementations to work from. Many contributors do not have existing implementations, and starting from scratch or even open source is too high a barrier to entry The translation from SMI to XML/XSD requires less skill than designing protocol extensions or a new SMI, so the barrier to entry is lower Converting the well-understood SMI to the poorly understood XSD would be a good training ground for emerging contributors that cannot compete effectively with the leaders

38. Agenda Purpose of the BOF –The Case for MIB Access –The Case for XSD Format –The Case for a WG –Resources –Proposed Charter BOF documents Open Discussion

39. Proposed WG Charter

40. Agenda Purpose of the BOF –The Case for MIB Access –The Case for XSD Format –The Case for Security Requirements –The Case for a WG –Resources –Proposed Charter BOF documents Open Discussion

41. Thank You Questions? mailto: ietfdbh@comcast.netietfdbh@comcast.net