Network Working Group J. Schoenwaelder Internet-Draft TU Braunschweig Expires: May 31, 2001 November 30, 2000 SMIng Mappings to DIAMETER draft-schoenw-sming-diameter-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/iid-abstracts.txt This Internet-Draft will expire on May 31, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo presents an SMIng language extension that supports the mapping of SMIng definitions of classes and their attributes to DIAMETER AVPs and messages. Schoenwaelder Expires May 31, 2001 [Page 1] Internet-Draft SMIng Mappings to DIAMETER November 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DIAMETER Base Types . . . . . . . . . . . . . . . . . . . . 3 3. SMIng Data Type Mappings . . . . . . . . . . . . . . . . . . 4 4. The diameter Extension Statement . . . . . . . . . . . . . . 4 4.1 The vendor Statement . . . . . . . . . . . . . . . . . . . . 4 4.2 The avp Statement . . . . . . . . . . . . . . . . . . . . . 4 4.2.1 The avp's code Statement . . . . . . . . . . . . . . . . . . 5 4.2.2 The avp's implements Statement . . . . . . . . . . . . . . . 5 4.3 The msg Statement . . . . . . . . . . . . . . . . . . . . . 5 4.3.1 The msg's code Statement . . . . . . . . . . . . . . . . . . 5 4.3.2 The msg's includes Statement . . . . . . . . . . . . . . . . 5 4.3.3 The msg's status Statement . . . . . . . . . . . . . . . . . 5 4.3.4 The msg's description Statement . . . . . . . . . . . . . . 5 5. TUBS-IBR-SMING-DIAMETER-EXT . . . . . . . . . . . . . . . . 6 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 Schoenwaelder Expires May 31, 2001 [Page 2] Internet-Draft SMIng Mappings to DIAMETER November 2000 1. Introduction This memo presents an SMIng [1] language extension that supports the mapping of SMIng definitions of classes and their attributes to DIAMETER [2] AVPs and messages. SMIng is an object-oriented data definition language which builds on concepts that have been successfully used over the last decade within the SNMP management framework. The SMIng language is independent of management protocols and applications. Protocol mappings to additional protocols can be defined as SMIng language extensions. There are several advantages in adopting SMIng as the data definition language for DIAMETER: 1. Using SMIng allows to reuse data definitions from other areas. For example, it is possible to import definitions for common data types such as dates, times, IP addresses, IP filter etc. from common modules. 2. Using common data definitions across several management protocols simplifies the development of applications or network elements that have to interface with equipment supporting multiple protocols. 3. A common data definition language encourages consistency across technology domains which reduces software complexity for products that need to operate on data definitions which may be manipulated with different protocols. 4. Adopting SMIng enables authors to reuse authoring tools to e.g. verify the correctness of their data definitions. 5. SMIng features a versioning mechanism (via status assignments), a naming and import mechanism, and a precise language definition which puts well-defined bounds on syntactic constructs such as identifiers or value notations. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. 2. DIAMETER Base Types The DIAMETER protocol should be modified to support AVPs that encode the following primitive base types: Integer32, Unsigned32, Integer64, Unsigned64, Float32, Float64, Float128, and OctetString as specified in [1]. In addition, the DIAMETER protocol should support a compound type which contains an ordered list of AVPs. The AVPs in the compound type are ordered. Schoenwaelder Expires May 31, 2001 [Page 3] Internet-Draft SMIng Mappings to DIAMETER November 2000 3. SMIng Data Type Mappings The SMIng base types are mapped to the DIAMETER base types according to the following table: SMIng Data Type DIAMETER Base Type --------------- ------------------ OctetString OctetString Integer32 Integer32 Integer64 Integer64 Unsigned32 Unsigned32 Unsigned64 Unsigned64 Float32 Float32 Float64 Float64 Float128 Float128 Enumeration Integer32 Bits OctetString Note that the SMIng base type Pointer is not mapped to any DIAMETER base type. Classes are mapped to the compound DIAMETER base type. Each primitive attribute of a given class is represented according to the mapping table above and is encapsulated in the compound base type. 4. The diameter Extension Statement The `diameter' statement is the main statement of the DIAMETER mapping specification. It gets one arguments: a statement block that contains all details of the DIAMETER mapping. A single SMIng module must not contain more than one 'diameter' statement. 4.1 The vendor Statement The `vendor' statement, which must be present if the definition is not part of an IETF standard, gets one argument which identifies the enterprise responsible for this definition. The value MUST be an IANA assigned enterprise number. 4.2 The avp Statement The `avp' statement is used to define an AVP. The avp statement gets two arguents: an upper-case AVP identifier and a statement block that holds detailed information about the AVP. See the `avpStatement' rule of the SMIng grammar (Section 5) for the formal syntax of the 'avp' statement. Schoenwaelder Expires May 31, 2001 [Page 4] Internet-Draft SMIng Mappings to DIAMETER November 2000 4.2.1 The avp's code Statement The avp's `code' statement, which must be present, gets one argument which specifies the code used to identify the AVP. 4.2.2 The avp's implements Statement The avp's `implements' statement, which must be present exactly once, gets one argument: the identifier of an SMIng class which is implemented by this AVP. 4.3 The msg Statement The `msg' statement is used to define a DIAMETER message. The msg statement gets two arguents: an upper-case message identifier and a statement block that holds detailed information about the message. See the `msgStatement' rule of the SMIng grammar (Section 5) for the formal syntax of the 'msg' statement. 4.3.1 The msg's code Statement The msg's `code' statement, which must be present, gets one argument which specifies the code used to identify the message. 4.3.2 The msg's includes Statement The msg's `includes' statement, which may be present zero, one or multiple times, gets one argument which specifies an AVP which must be included in the message. 4.3.3 The msg's status Statement The msg's `status' statement, which need not be present, gets one argument which is used to specify whether this message definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. If the `status' statement is omitted, the status value `current' is implied. 4.3.4 The msg's description Statement The msg's `description' statement, which must be present, gets one Schoenwaelder Expires May 31, 2001 [Page 5] Internet-Draft SMIng Mappings to DIAMETER November 2000 argument which is used to specify a high-level textual description of this message. It is RECOMMENDED to include all semantics and purposes of this message. 5. TUBS-IBR-SMING-DIAMETER-EXT The grammar of the DIAMETER mapping SMIng extension conforms to the Augmented Backus-Naur Form (ABNF)[4]. It is included in the abnf statement of the `diameter' SMIng extension definition in the TUBS-IBR-SMING-DIAMETER-EXT module below. module TUBS-SMING-DIAMETER-EXT { organization "Technical University of Braunschweig"; contact "Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de"; description "SMIng extension for DIAMETER."; revision { date "2000-11-24"; description "Initial version, published as RFC XXXX."; }; extension snmp { description "The diameter statement maps SMIng definitions to DIAMETER AVPs and messages."; abnf ";; ;; sming-diameter.abnf -- Grammar of DIAMETER mappings in ABNF ;; notation (RFC 2234). ;; ;; @(#) $Id$ ;; ;; Copyright (C) The Internet Society (2000). All Rights Reserved. ;; Schoenwaelder Expires May 31, 2001 [Page 6] Internet-Draft SMIng Mappings to DIAMETER November 2000 ;; ;; Statement rules. ;; diameterStatement = diameterKeyword optsep "{" stmtsep *1(vendorStatement stmtsep) *(avpStatement stmtsep) *(msgStatement stmtsep) "}" optsep ";" vendorStatement = vendorKeyword sep decimalNumber optsep ";" avpStatement = avpKeyword sep ucIdentifier optsep "{" stmtsep codeStatement stmtsep implementsStatement stmtsep *1(statusStatement stmtsep) "}" optsep ";" msgStatement = msgKeyword sep ucIdentifier optsep "{" stmtsep codeStatement stmtsep *(includesStatement stmtsep) *1(statusStatement stmtsep) descriptionStatement stmtsep "}" optsep ";" codeStatement = codeKeyword sep decimalNumber optsep ";" implementsStatement = implementsKeyword sep qucIdentifier optsep ";" includesStatement = includesKeyword sep qucIdentifier optsep ";" ;; ;; Statement keywords. ;; diameterKeyword = %x64 %x69 %x61 %x6D %x65 %x74 %x65 %x72 vendorKeyword = %x76 %x65 %x6E %x64 %x6F %x72 avpKeyword = %x61 %x76 %x70 msgKeyword = %x6D %x73 %x67 codeKeyword = %x63 %x6F %x64 %x65 implementsKeyword = %x69 %x6D %x70 %x6C %x65 %x6D %x65 %x6E %x74 %x73 includesKeyword = %x69 %x6E %x63 %x6C %x75 %x64 %x65 %x73 ;; Schoenwaelder Expires May 31, 2001 [Page 7] Internet-Draft SMIng Mappings to DIAMETER November 2000 ;; EOF ;; "; }; }; 6. Example The following example demonstrates how the DIAMETER AVPs and messages defined in [2] can be defined using the SMIng and the SMIng `diameter' extension presented in this memo. module TUBS-SMING-DIAMETER { import IRTF-NMRG-SMING (Utf8String); import IRTF-NMRG-SMING-INET (InetNetworkEndpoint); import TUBS-DIAMETER-EXT (diameter); organization "Technical University of Braunschweig"; contact "Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de"; description "SMIng core definitions for DIAMETER."; revision { date "2000-11-24"; description "Initial version, published as RFC XXXX."; }; // international domain names (?) typedef NetworkAccessIdentifier { type Utf8String; description "A Network Address Identifier as specified in RFC 2486."; reference "RFC 2486"; }; Schoenwaelder Expires May 31, 2001 [Page 8] Internet-Draft SMIng Mappings to DIAMETER November 2000 // this really belongs into an IANA module typedef DiameterExtension { type Enumeration (none(0), nasreq(1), security(2), resmgmt(3), mobileip(4), accouting(5)); description "This type identifies an extension of the DIAMETER base protocol. Assignments are made by IANA."; }; typedef RandomString { type OctetString (16..65535); description "This type contains a random value of at least 128 bits."; }; typedef SecondsSince2000 { type Unsigned32; description "The number of seconds since 1st January 2000, 00:00 UTC."; }; // this really belongs into an IANA module typedef HashAlgorithm { type Enumeration (none(0), md5(1)); description "Identifies a hash algorithm."; }; typedef KeyId { type Unsigned32; description "This type represents a generic key identifier, which is used to identify the keying information for a security mechanism."; }; typedef MessageAuthenticationCode { type OctetString; description "The message authentication code (MAC) for a given message."; }; // // AVP classes Schoenwaelder Expires May 31, 2001 [Page 9] Internet-Draft SMIng Mappings to DIAMETER November 2000 // class IntegrityCheck { attribute HashAlgorithm alg { description "Identifies the crypto algorithm."; }; attribute KeyId key { description "Identifies the security key."; }; attribute MessageAuthenticationCode mac { description "The fingerprint of the message."; }; description "This class contains the information needed to authenticate a message and to check its integrity on a hop-by-hop basis."; }; class Nonce { attribute RandomString nonce { description "A random byte string used as a nonce."; }; description "The Nonce class MUST be present prior to the IntegrityCheck class within a message and is used to ensure randomness within a message. Some crypto algorithms are known to have weaknesses if a random value is not found early within the plaintext, therefore it is recommended that the Nonce class be added early in a message if possible."; }; class HostName { attribute NetworkAccessIdentifier name { description "A network access identifier which identifies a sender's identity."; }; description "The HostName class is used to inform a DIAMETER peer of the sender's identity. All DIAMETER messages MUST include the HostName class. Note that the HostName class may resolve to more than one address as the DIAMETER peer may support more than one address."; }; }; class VendorName { attribute Utf8String name { description "The name of the vendor."; Schoenwaelder Expires May 31, 2001 [Page 10] Internet-Draft SMIng Mappings to DIAMETER November 2000 }; description "The VendorName class is used to inform a DIAMETER peer of the vendor name of the DIAMETER device. This MAY be used in order to know which vendor specific attributes may be sent to the peer. It is also envisioned that the combination of the VendorName and the FirmwareRevision classes MAY provide very useful debugging information."; }; class FirmwareRevision { attribute Unsigned32 revision { description "A revision number."; }; description "The FirmwareRevision class is used to inform a DIAMETER peer of the firmware revision of the issuing device. For devices that do not have a firmware revision (general purpose computers running DIAMETER software modules, for instance), the revision of the DIAMETER software module may be reported instead."; }; class ExtensionId { attribute DiameterExtension extension { description "Identifies a Diameter extension."; }; description "The ExtensionId AVP identifies a specific DIAMETER extension. This AVP is used in the DeviceRebootInd message in order to inform the peer what extensions are locally supported. Each DIAMETER extension draft MUST have an IANA assigned extension Idenfier. The base protocol does not require an ExtensionId since its support is mandatory. There MAY be more than one ExtensionId AVP within a DIAMETER DeviceRebootInd message."; }; // The description should be more generic. class HostIPAddress { attribute InetNetworkEndpoint endpoint { description "Denotes the sender's IP address."; }; Schoenwaelder Expires May 31, 2001 [Page 11] Internet-Draft SMIng Mappings to DIAMETER November 2000 description "The HostIPAddress class is used to inform a DIAMETER peer of the sender's IP address. All source addresses that a DIAMETER node expects to use with SCTP MUST be advertised in the DeviceRebootInd message by including a HostIPAddress class for each address. This class MUST ONLY be used in the DeviceRebootInd message."; }; // // DIAMETER specific mappings // diameter { avp HostNameAVP { code 264; implements HostName; }; avp VendorNameAVP { code 266; implements VendorName; }; avp FirmwareRevisionAVP { code 267; implements FirmwareRevision; }; avp ExtensionIdAVP { code 258; implements ExtensionId; }; avp HostIPAddressAVP { // really? conflicts with RADIUS assignement code 4; implements HostIPAddress; }; avp NonceAVP { code 261; implements Nonce; }; avp IntegrityCheckAVP { code 259; implements IntegrityCheck; }; msg DeviceRebootInd { code 257; includes NonceAVP; includes HostNameAVP; includes HostIPAddressAVP; Schoenwaelder Expires May 31, 2001 [Page 12] Internet-Draft SMIng Mappings to DIAMETER November 2000 includes VendorNameAVP; includes ExtensionIdAVP; includes FirmwareRevisionAVP; includes IntegrityCheckAVP; description "A DIAMETER device sends the DeviceRebootInd message to inform a peer that a reboot has just occured. Since SCTP allows for connections to span multiple interfaces, the DeviceRebootInd message MUST contain one HostIPAddress AVP for each potential IP address that MAY be locally used when transmitting DIAMETER messages. The DeviceRebootInd message is also used for capabilities negotiation, such as the supported protocol version number, and the locally supported extensions. The receiver uses the extensions advertised in order to determine whether it SHOULD send certain application-specific DIAMETER commands. A DIAMETER node MUST retain the supported extensions in order to ensure that unrecognized commands and/or AVPs are not sent to a peer. Note that in a proxy environment, it is still possible that a downstream proxy has no available peer that have advertised the extension that corresponds to the Command-Code, and therefore the request cannot be forwarded any further. The DIAMETER base protocol provides this error reporting, via the Result-Code AVP. Once the transport layer connection has been established, a DIAMETER entity MUST issue a DeviceRebootInd message, regardless of whether the peer was statically configured, or dynamically discovered. If a peer is no longer reachable, a DIAMETER device SHOULD periodically attempt to establish a transport level connection with the peer and send a DRI message. This message does not require a reply. If a DIAMETER node receives a DeviceRebootInd message that results in an error, a MessageRejectInd message MUST be returned."; }; }; }; Schoenwaelder Expires May 31, 2001 [Page 13] Internet-Draft SMIng Mappings to DIAMETER November 2000 7. Security Considerations This document presents an extension of the SMIng data definition langauge which supports the mapping of SMIng data definitions so that they can be used with the DIAMETER protocol. The language extension and the mapping itself has no security impact on the Internet. 8. Acknowledgements The author would like to thank Frank Strauss for his valuable comments on this document. References [1] Strauss, F., Schoenwaelder, J. and K. McCloghrie, "SMIng - Next Generation Structure of Management Information", draft-irtf-nmrg-sming-04.txt, November 2000. [2] Calhoun, P.R., Rubens, A.C., Akhtar, H. and E. Guttman, "DIAMETER Base Protocol", draft-calhoun-diameter-17.txt, September 2000. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Author's Address Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3266 EMail: schoenw@ibr.cs.tu-bs.de Schoenwaelder Expires May 31, 2001 [Page 14] Internet-Draft SMIng Mappings to DIAMETER November 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Schoenwaelder Expires May 31, 2001 [Page 15]