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

Versions: 00

Network Working Group                                           A. Clemm
Internet-Draft                                         P. Pillay-Esnault
Intended status: Informational                                    Huawei
Expires: January 4, 2018                                    July 3, 2017


           Information Elements for Identity-Enabled Networks
                       draft-clemm-ideas-ipfix-00

Abstract

   This document defines a set of new Information Elements related to
   Identity-Enabled Netwoks.  The Information Elements are used by the
   IP Flow Information Export (IPFIX) protocol to export flow data
   containing identity-related information.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 4, 2018.

Copyright Notice

   Copyright (c) 2017 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
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Clemm & Pillay-Esnault   Expires January 4, 2018                [Page 1]


Internet-Draft                                                 July 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   3
   3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
   4.  Information Elements  . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Identifiers . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.1.  sourceId16  . . . . . . . . . . . . . . . . . . . . .   4
       4.1.2.  sourceId4 . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.3.  destinationId16 . . . . . . . . . . . . . . . . . . .   4
       4.1.4.  destinationId4  . . . . . . . . . . . . . . . . . . .   4
     4.2.  Identifier Hashes . . . . . . . . . . . . . . . . . . . .   5
       4.2.1.  sourceIdHash  . . . . . . . . . . . . . . . . . . . .   5
       4.2.2.  destinationIdHash . . . . . . . . . . . . . . . . . .   5
     4.3.  Metadata  . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.3.1.  sourceIdType  . . . . . . . . . . . . . . . . . . . .   6
       4.3.2.  destinationIdType . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   This document defines a set of new Information Elements to be used in
   conjunction with the IP Flow Information Export (IPFIX) protocol
   [RFC7011].  The new Information Elements are intended to be used in
   Identity-Enabled Networks [IDEAS-PS], in which communication flows
   between Entities contain identifiers that reference the Identities of
   Entities that participate in the flow, in addition to or in lieu of
   addresses that tie Entities to a specific location.

   To use IPFIX in the context of Identity-Enabled Networks, extensions
   are needed to denote the identifiers of sources and destinations in a
   flow.  Those identifiers are generally distinct from e.g. an IP
   addresses, which are commonly included in flow records today.

   In addition to Information Elements to capture Identifiers of
   communicating Entities, this document also defines a Information
   Elements that contain metadata about communicating Entities.  An
   example of such metadata is an Entity's type, for example, whether
   the Entity represents a mobile phone, a connected vehicle, an IoT
   lightbulb, or an Automated Teller Machine.  It is anticipated that
   metadata will play an important role in Identity-Enabled Networks.
   However, in principle, Information Elements that capture metadata




Clemm & Pillay-Esnault   Expires January 4, 2018                [Page 2]


Internet-Draft                                                 July 2017


   could be applied in other contexts and other types of networks as
   well.

2.  Specification of Requirements

   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 [RFC2119].

3.  Definition of Terms

      Entity: An entity is a communication endpoint.  It can be a
      device, a node, or a (software) process, that needs to be
      identified.  An entity may have one or multiple Identifiers
      simultaneously.  An entity is reached by the resolution of one or
      more of its Identifiers to one or more Locators.

      Identifier (IDf): An IDf denotes information to unambiguously
      identify an entity within a given scope.  There is no constraint
      on the format, obfuscation or routability of an IDf.  The IDf may
      or may not be present in the packet whose format is defined by
      Identifier-based protocols.

      Identity: the essence of "being" of a specific entity.  An
      Identity is not to be confused with an Identifier: while an
      Identifier may be used to refer to an entity, an Identifier's
      lifecycle is not necessarily tied to the lifecycle of the Identity
      it is referencing.  On the other hand, the Identity's lifecycle is
      inherently tied to the lifecycle of the entity itself.

      IDentity Enabled Networks (IDEAS): IDEAS are networks that support
      the Identifier/Locator decoupling.  Reaching an entity is achieved
      by the resolution of Identifier(s) to Locator(s).

      Information Element (IE): An Information Element is a protocol-
      and encoding-independent description of an attribute that may
      appear in an IPFIX Record.  Information Elements are defined in
      the IANA "IPFIX Information Elements" registry [IANA-IPFIX].  The
      type associated with an Information Element indicates constraints
      on what it may contain and also determines the valid encoding
      mechanisms for use in IPFIX.

      IP Flow Information Export (IFFIX): A technology used to export
      data about flow records, specified in a series of standards that
      are anchored by [RFC7011].

      IPFIX Collector: A device that hosts a process which receives
      IPFIX Messages from one or more IPFIX Devices.



Clemm & Pillay-Esnault   Expires January 4, 2018                [Page 3]


Internet-Draft                                                 July 2017


      IPFIX Device: An IPFIX Device is a device that hosts at least one
      process that exports IPFIX records.

      Metadata: Metadata is data about an Identity.  The metadata may
      contain information such as the nature of the entity for example.

4.  Information Elements

4.1.  Identifiers

   In this section, Information Elements are defined for Identifiers of
   16 or 4 octets length.  It is TBD whether additional Information
   Elements need to be defined for variable length Identifiers or for
   Identifiers of different length.  It should be noted that variable
   and long length Identifiers can also be accommodated by Identifier
   Hashes, as defined in Section 4.2.

4.1.1.  sourceId16

   This Information Element specifies the Source IDf, i.e. the
   identifier of the source of the flow, in cases where the source's IDf
   uses 16 octets.  The Information Element uses 16 octets and is of
   type octetArray.

4.1.2.  sourceId4

   This Information Element specifies the Source IDf, i.e. the
   identifier of the source of the flow, in cases where the source's ID
   uses 4 octets.  The Information Element uses 4 octets and is of type
   octetArray.

4.1.3.  destinationId16

   This Information Element specifies the Destination IDf, i.e. the
   identifier of the destination of the flow, in cases where the
   destination's IDf uses 16 octets.  The Information Element uses 16
   octets and is of type octetArray.

4.1.4.  destinationId4

   This Information Element specifies the Source IDf, i.e. the
   identifier of the source of the flow, in cases where the source's IDf
   uses 4 octets.  The Information Element uses 4 octets and is of type
   octetArray.







Clemm & Pillay-Esnault   Expires January 4, 2018                [Page 4]


Internet-Draft                                                 July 2017


4.2.  Identifier Hashes

   Carrying a hash of an Identifier, instead of an Identifier itself,
   provides an additional measure of privacy and information security.
   It also allows for more compact identification of sources and
   destinations in the case of Identifiers of long length and/or
   variable length.

   Which hash function an IPFIX Exporter should apply is subject to
   configuration and not specified further in this document.

   For an IPFIX Collector to associate a hash with an actual Identifier,
   it needs to be able to resolve which hash is associated with which
   Identifier.  There are different ways in which such resolution can be
   performed.  One possibility is for the IPFIX Device to export a table
   containing Identifiers and Hashes, containing entries for Identifiers
   who have had associated flow records recently exported.

   It is TBD whether additional hash lengths should be supported.

4.2.1.  sourceIdHash

   This Information Element specifies a hash of the identifier of the
   source of the flow.  The Information Element uses 4 octets and is of
   type octetArray.

4.2.2.  destinationIdHash

   This Information Element specifies a hash of the identifier of the
   destination of the flow.  The Information Element uses 4 octets and
   is of type octetArray.

4.3.  Metadata

   Metadata contains information about Entities that are involved in a
   communications flow.  There are different ways in which metadata
   could be inferred.  In some cases, metadata may be evident by the
   structure of the Entity's identifier.  In other cases, there may be
   additional functions that allow to look up an Entity's metadata.

   At this point, the only metadata that is deemed interesting to
   include in flow records concerns the type of the entity, although it
   is conceivable that additional types of metadata might be added in
   the future.  It should also be noted that it is conceivable to have a
   hierarchy of types, in which specialized types are subtypes of a more
   general type.  In such a case, type information SHOULD be populated
   with the most specific type.




Clemm & Pillay-Esnault   Expires January 4, 2018                [Page 5]


Internet-Draft                                                 July 2017


   The type of the entity is encoded using 4 octets as follows:

   o  bit 0: Standard or enterprise-specific type with the following
      values:

      *  0: standard

      *  1: enterprise-specific

   o  bits 1 through 19: In case of enterprise-specific type, enterprise
      number per IANA's Enterprise Numbers registry, binary encoded,
      with leading 0's.  In case of standard type, ignored.  Note: it is
      anticipated that 19 bits will suffice to encode enterprise numbers
      for the foreseeable future.

   o  bits 20 through 31: Type number, binary encoded, with leading 0's,
      per newly introduced IANA registry for Type Numbers.  Please refer
      to section "IANA Considerations".

   A value of "0" indicates that the type is not specified.

4.3.1.  sourceIdType

   This Information Element specifies the type of the source of the
   flow.  This Information element uses 4 octets and is of type
   octetArray, encoded as described.

4.3.2.  destinationIdType

   This Information Element specifies the type of the destination of the
   flow.  This Information Element uses 4 octets and is of type
   octetArray, encoded as described.

5.  Security Considerations

   The recommendations in this document do not introduce additional
   security issues beyond those already specified in [RFC7011].  That
   said, it should be noted that flow records that carry Identifiers do
   contain sensitive information that allows to identify Entities that
   are engaged in communication flows and their communication patterns.
   By opting to use Identifier hashes, instead of Identifiers
   themselves, an additional measure of data protection can be provided.

6.  IANA Considerations

   IANA is requested to add the Information Elements described above
   (Section 4) to IANA's registry of Information Elements [IANA-IPFIX]




Clemm & Pillay-Esnault   Expires January 4, 2018                [Page 6]


Internet-Draft                                                 July 2017


   and assign corresponding Information Element IDs.  Currently,
   unassigned Information Element IDs start at 463.

   o  sourceId4

   o  destinationId4

   o  sourceId16

   o  destinationId16

   o  sourceIdHash

   o  destinationIdHash

   o  sourceIdType

   o  destinationIdType

   IANA is requested to create a new registry for Identity Types and
   register the following initial values:

   o  0: Not specified

   o  1: Other

   o  2: Server

   o  3: Mobile Device

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,
              <http://www.rfc-editor.org/info/rfc7011>.







Clemm & Pillay-Esnault   Expires January 4, 2018                [Page 7]


Internet-Draft                                                 July 2017


7.2.  Informative References

   [IANA-ENTERPRISE]
              IANA, "Private Enterprise Numbers",
              <http://www.iana.org/assignments/enterprise-numbers>.

   [IANA-IPFIX]
              IANA, "IP Flow Information Export (IPFIX) Entities",
              <http://www.iana.org/assignments/ipfix>.

   [IDEAS-PS]
              Pillay-Esnault, P., Boucadair, M., Jacquenet, C.,
              Fioccola, G., and A. Nennker, "Problem Statement for
              Identity Enabled Networks", July 2017,
              <https://datatracker.ietf.org/doc/draft-padma-ideas-
              problem-statement/>.

Authors' Addresses

   Alexander Clemm
   Huawei
   2330 Central Expressway
   Santa Clara,  CA 95050
   USA

   Email: ludwig@clemm.org


   Padma Pillay-Esnault
   Huawei
   2330 Central Expressway
   Santa Clara,  CA 95050
   USA

   Email: padma.ietf@gmail.com
















Clemm & Pillay-Esnault   Expires January 4, 2018                [Page 8]


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