IPFIX Working Group C. Inacio Internet-Draft Carnegie Mellon University Intended Status: Standards Track November 9, 2012 Expires May 13, 2013 Private Enterprise Information Elements Registry Exchange <draft-inacio-ipfix-penie-00.txt> Abstract This extension to the IPFIX protocol is intended to provide a mechanism for IPFIX exporters which export private information elements to also transmit information to the collectors. The mechanism is designed to be able to send a URI with information about the private information elements via an options template. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire in May 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Inacio Expires May 13, 2013 [Page 1]
Internet Draft PENIE November 9, 2012 carefully, as they describe your rights and restrictions with respect to this document. Inacio Expires May 13, 2013 [Page 2]
Internet Draft PENIE November 9, 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Options Record Format . . . . . . . . . . . . . . . . . . . . . 4 3. Registry Design . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Registry Introduction . . . . . . . . . . . . . . . . . . . 6 3.2. Registry Informational Elements . . . . . . . . . . . . . . 6 3.3. Registry Formatting . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 99.0. To be removed . . . . . . . . . . . . . . . . . . . . . . 10 99.1. Formatting End of Page . . . . . . . . . . . . . . . . . 12 Inacio Expires May 13, 2013 [Page 3]
Internet Draft PENIE November 9, 2012 1. Introduction The IPFIX protocol [RFC5101] defined a significant information element set for a large number of relevant network activities. The IPFIX protocol was also designed with the ability to extend its information model both via a standards based mechanism, via an IANA registry, to add elements of general interest, but also the ability to add elements via private enterprise numbers to define elements of limited interest. Beyond adding the ability to pass new information elements, the IPFIX protocol is designed to allow collectors the ability to skip information elements which cannot be comprehended. IPFIX was extended in RFC 5610 IPFIX Semantic Type Information to allow IPFIX send type semantic information about information elements. This mechanism allows an IPFIX exporter to send type semantic information along with a common name about an information element to the collector. This allows information elements that the collector would otherwise not be able to comprehend to provide much more information. The mechanism proposed here extends the Semantic Type Information in two ways. First, it allows a more complex definition of information to be presented, capturing the possible relationships contained within the IPFIX Structured Data extension. The IPFIX Structured Data extension, having completed after the Semantic Type Information, is not covered in the Semantic Type Information. Secondly, by moving the information element metadata out from the potentially resource constrained IPFIX data channel, this extension allows a richer and comprehensive set of metadata to be expressed. 2. Options Record Format The mechanism used to transmit the URI information from the exporter to the collector is an options template with a URI. The URI contains a pointer which provides well formatted, as specified in section 3, information about the semantic type information and description of the private information elements. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 257 | Field Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = |0| private ent. number 346 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 4 | PEN Registry URI XXX | Inacio Expires May 13, 2013 [Page 4]
Internet Draft PENIE November 9, 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 65536 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Example PENIE Template Definition 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 257 | Length = 46 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 39 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | "http://tools.netsa.cert.org/yaf_pen.xml" | + + | | + + | | + + | | + + | | + + | | + + | | + + | | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Example PENIE Data Record The options record allows for creating a URI reference for a private enterprise number. It is important to note that more than one URI per a single private enterprise number. The burden of resolving all declared registries falls onto the collector to be able to decode all information elements received from the exporters. 3. Registry Design Inacio Expires May 13, 2013 [Page 5]
Internet Draft PENIE November 9, 2012 3.1. Registry Introduction The registry design goals are to capture all the information that IPFIX Type Information [RFC5610] provides about individual elements, but to also present more metadata about both individual elements as well as have the ability to provide more information about a collection of elements. 3.2. Registry Informational Elements The top level of a registry contains the following additional elements: o Registry ID - This is an ID that can be used by the creator of the registry to be able to track the registry as a unique item. o Version - Indicates the release version of the registry. o Name - A common name that can be used to refer to the registry. o Security Type - This is a new entry type that allows the complete set of elements defined in the registry to be contained within a security type class. By allowing the collector to understand the security type, if present, of the information elements a new class of actions may be taken by a collector implementation. o Policy Type - Similar to the security type, this new entry allows the complete set of elements defined in the registry to be contained within a policy type class. Again, similar to the security type class, the collector may take new actions based upon understanding the policy type of an information element. o Canonical URI - This is the canonical URI to be able to locate the authoritative version of the registry. o Root EID - This defines the Private Enterprise ID for all elements defined in the registry. o Copyright - Optionally the copyright information for the registry o Contact - Contact information to be able to contact the publisher of the registry. o Directory - (I can't remember, but its a URI). Each information element defined in the registry are as follows: Inacio Expires May 13, 2013 [Page 6]
Internet Draft PENIE November 9, 2012 o ID - The information element ID. o PEN - The private enterprise number. o Data type - The data type of the element, as defined in RFC 5610. o Semantics - The semantic of the element, as defined in RFC 5610. o Units - The units of the element, as defined in RFC 5610. o Description - The human readable (and hopefully understandable) description of the element. o MIME Path - An optional MIME path definition of the element. 3.3. Registry Formatting XML or JSON or ???? format to be added here. 5. Security Considerations There are no security considerations relevant to this document, beyond the security considerations necessary in the IPFIX protocol specification [RFC5101] and its successors. 6. IANA Considerations IANA needs to create two registries with expert review: Security types Policy types and create a code point for a new information element. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and Meyer, J., "Information Model for IP Flow Information Export", Inacio Expires May 13, 2013 [Page 7]
Internet Draft PENIE November 9, 2012 RFC 5102, January 2008. [RFC5610] Boschi, E., Trammell, B., Mark, L., and Zseby, T., "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 6.2. Informative References [2223BIS] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", draft-rfc-editor-rfc2223bis- 08.txt, August 2004. Authors' Addresses Christopher Inacio Carnegie Mellon University 4500 5th Avenue Pittsburgh, PA 15213 USA EMail: inacio@sei.cmu.edu Appendix A. Relax-NG based definition of a proposed schema. Can be processed with trang to create a well defined XML XSD file. namespace r = "http://www.ietf.org/ipfix/ipfix-private-element-registry/1.0" # It's unclear what the right way of referencing an info element ought # to be. By PEN/ID pair? By some XML ID? Both has problems. Leave it # text for now. info-elem-ref = text r-data-type = element r:data-type { "octetArray" | "unsigned8" | "unsigned16" | "unsigned32" | "unsigned64" | "signed8" | "signed16" | "signed32" | "signed64" | "float32" | "float64" | Inacio Expires May 13, 2013 [Page 8]
Internet Draft PENIE November 9, 2012 "boolean" | "macAddress" | "string" | "dateTimeSeconds" | "dateTimeMilliseconds" | "dateTimeMicroseconds" | "dateTimeNanoseconds" | "ipv4Address" | "ipv6Address" | "basicList" | "subTemplateList" | "subTemplateMultiList" } r-semantics = element r:semantics { "default" | "quantity" | "totalCounter" | "deltaCounter" | "identifier" | "flags" | "list" } r-units = element r:units { "none" | "bits" | "octets" | "packets" | "flows" | "seconds" | "milliseconds" | "microseconds" | "nanoseconds" | "4-octet words" | "messages" | "hops" | "entries" } #r-value-map = element r:value-map { # attribute type {"integer" | "text" }, # {element value } #} r-element = element r:element { element r:id { xsd:integer {minInclusive="0" maxInclusive="65535"}} & element r:private-enterprise-number { xsd:integer {minInclusive="0" maxInclusive="4294967295"}}? & Inacio Expires May 13, 2013 [Page 9]
Internet Draft PENIE November 9, 2012 r-data-type & r-semantics? & r-units? & element r:range-begin { text }? & element r:range-end { text }? & element r:name { xsd:token } & element r:description { text } & element r:mime-path { text }? # element r:value-map { # attribute type {"integer" | "text"}, # } } r-registry = element r:registry { element r:id { xsd:anyURI } & element r:name { text } & # Should these two be required or optional? element r:security-type { text } & element r:policy-type { text } & element r:url { xsd:anyURI } & element r:root-eid { xsd:integer } & (r-registry | r-element)* } r-enterprise-registry = element r:enterprise-registry { element r:name { text } & element r:copyright { text } & element r:contact { text } & element r:private-enterprise-number { xsd:integer } & element r:directory { xsd:anyURI } & r-registry* } start = r-enterprise-registry 99.0. To be removed The RFC Editor generally uses the simplest nroff features, basically the "-ms" macro package and the following few basic nroff directives: DIRECTIVE FUNCTION .ce Center following line. Inacio Expires May 13, 2013 [Page 10]
Internet Draft PENIE November 9, 2012 .ti # 'temporary indent' -- # is number of spaces. Indents only the line immediately following. .in # Change indentation to # spaces .nf 'No fill': begin block of text to be displayed. .fi Fill (i.e., left-justify, line wrap) .ne # 'need' -- Keep following # lines on same page .bp Break page .br Break line .KS 'Keep Start' -- lines up to .KE on same page .KE 'Keep End' -- end of 'keep' block Nroff also has a '.sp' (space) directive to insert a blank line. However, it is far easier (and more readable) to use the fact that each blank line in the nroff source creates a blank line in the output. Nroff includes many variations on the trivial commands shown above. For example, indentation can be specified relative to the current indentation, using '.in +#' or '.in -#'. Authors are welcome to use such features, but for simplicity this template uses only the simplest set of commands. Some authors who are proficient in nroff will wish to use more advanced features, including perhaps their own macros. This is a private matter for the author, unless and until the document is submitted to the RFC Editor for publication as an RFC. Upon document submission, the RFC Editor will request the nroff source, if any. If the source is sufficiently straightforward, it will be used by the RFC Editor to speed the publication process. If not, the RFC Editor will generate a new nroff source, generally using the simple subset above. The considerations here are as follows: o Defined macros (beyond the -ms package) must be in-line at the front of the source. The RFC Editor is currently prepared to maintain only one source file for each published RFC. o Some of the editors are not nroff experts, and even those who may be do not have the time to figure out some complex/obscure Inacio Expires May 13, 2013 [Page 11]
Internet Draft PENIE November 9, 2012 macro. If any special knowledge about these macros is needed to modify the text for editorial purposes, the RFC Editor will find it more expedient to generate a new .nroff source for the document. o The RFC Editor does not keep a distinct Make file for each RFC, so it is not helpful to send us a tar file or shar script that magically makes a directory and builds an RFC. Our primary input is a .txt file, with a .nroff file as a possible secondary input. When the RFC is published, the RFC Editor will archive a .txt file and a corresponding \&.nroff file. In other words, keep it simple and you can help us a lot; don't show off your programming prowess and waste our time. 99.1. Formatting End of Page The Unix command to create a formatted Internet Draft is: "nroff -ms input-file.nroff > output-file.txt" However, nroff will not follow the RFC standard format for a page: a Form feed (FF or Control-L)) after the last visible line on the page and no extra line feeds before the first visible line of the next page. We want: last visible line on page i ^L first visible line on page i+1 We invented hacks to fix this. The original hack was a "sed" script that called a "C" program called "pg". More recently, we have been using a simple Perl script (see Appendix A). Then the command to process the nroff source file becomes: nroff -ms input-file.nroff | fix.pl > output-file.txt For example: nroff -ms 2-nroff.template | fix.pl > 2-nroff.template.txt Inacio Expires May 13, 2013 [Page 12]