[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/