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.

Table of Contents

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

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

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.

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

• bit 0: Standard or enterprise-specific type with the following values:
  • 0: standard
  • 1: enterprise-specific

• 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.
• 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] and assign corresponding Information Element IDs. Currently, unassigned Information Element IDs start at 463.

• sourceId4
• destinationId4
• sourceId16
• destinationId16
• sourceIdHash
• destinationIdHash
• sourceIdType
• destinationIdType

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

• 0: Not specified
• 1: Other
• 2: Server
• 3: Mobile Device

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses