Internet DRAFT - draft-clemm-ideas-ipfix
draft-clemm-ideas-ipfix
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]
