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, . [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, . Clemm & Pillay-Esnault Expires January 4, 2018 [Page 7] Internet-Draft July 2017 7.2. Informative References [IANA-ENTERPRISE] IANA, "Private Enterprise Numbers", . [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", . [IDEAS-PS] Pillay-Esnault, P., Boucadair, M., Jacquenet, C., Fioccola, G., and A. Nennker, "Problem Statement for Identity Enabled Networks", July 2017, . 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]