]> Independent

2386 Panoramic Circle Apopka Florida 32703 USA +1-508-333-2270 d3e3e3@gmail.com

Cisco Systems

3550 Cisco Way San Jose CA 95134 USA ncamwing@cisco.com

IPinfusion

India mohammed.umair2@gmail.com

tbd Network Working Group Tenant ID Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet.

Introduction Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain as shown in . Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it was simply forwarded in a traditional manner. There are many such fields that have been specified. A few examples from IETF RFCs are given below in . This document provides Security Considerations for the inclusion of such supplemental information with a packet.

Example Network Domain Ingress>---------->Transit>-----------> Egress >---------> (Header +-------+ (Header +------+ (Header +--------+ (Header +Data) | +Field +Field | +Data) +Data) +Data | | +- -- -- -- -- -- -- -- -- -- -+ ]]>

shows a simplified diagram. In a specific case, there may be zero or many transit nodes and, in the case of a multi-destination packet, there might be multiple paths from the ingress to multiple egress nodes. There might be multiple fields added which are considered one logical field for the purposes of this document or an added information "field" might be encoded into an existing field or subpart of that field. The primary security concern with the addition of such supplemental information is harm to the privacy of the packet source by distinguishing the packet's source and the packet's intended handling in detail. The granularity with which packet sources are distinguished can vary greatly. At their most specific, fields could distinguish one or combination of a single host computer, individual user, or specific process, application, or protocol instance within a host. At the least specific end of the granularity spectrum, only the identity of an adjacent Internet Service Provider might be revealed. For example, if VXLAN is in use, the outer IP header source and destination IP addresses, which identify VXLAN Tunnel End Points (VTEPs), combined with the inner original header IP addresses normally enable one to precisely identify a host/VM/Tenant. In addition to distinguishing packet sources with a finer granularity, supplemental information may enable multiple apparently different sources to be grouped as related and allow some information about the structure of complex sources to be deduced. The supplemental information fields added or set by the ingress node may be derived from fields present in the packet which are normally forwarded, such as the "5-tuple" of IP Source and Destination Address, IP Source and Destination Port, and IP Protocol and/or additional header fields that would be transmitted with the packet. Reasons for adding a derived field include that the information it is derived from will not be available to transit nodes because it will be encrypted or it is too deep in the packet, that is, too far from the beginning of the packet for convenient access. In other cases, the field may be derived in whole or in part from information such as ingress port identity or a VLAN tag on the packet arriving via Ethernet and which would not normally be forwarded with the packet.

Meta-Data The supplemental added information referred to above is an example of meta-data, which is additional data distinct form the content of messages. Meta-data is usually less sensitive than the content of messages. For example, consider messages between an individual and a doctor with a narrow medical specialty where there was no prior relationship between them. The existence and timing of such an exchange of messages could be quite revealing but clearly less so than the content of the messages which could reveal specific diagnosis and prognosis as well as the actual patient's name which might be different from the messaging participant. While there are exceptions, in mandatory label systems, such the USA government classification system for national security information with categories Unclassified < Confidential < Secret < Top Secret, a default rule of thumb is that the meta-data for a messages stream is one level less sensitive that the messages contents. For example, if there is a stream of messages whose content is classified as Secret, the message meta-data such as source and destination addresses, message timing and size, etc., would tend to be classified as Confidential. A counter-example would be the less common case where the content of a message was only moderately important but the mere existence and address of the source and/or destination is very sensitive. A former head of the USA NSA and CIA has said, "We kill people based on meta-data".

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The acronyms and terms below are used in this document. For further security term definitions, see .

AEAD

-  Authenticated Encryption with Additional Data.

ASCII

-  American Standard Code for Information Interchange .

ciphertext

-  Data that has been transformed by encryption so that its semantic information content is no longer intelligible or directly available (see ) .

CPU

-  Central Processing Unit.

DSCP

-  Differentiated Services Code Point .

LAN

-  Local Area Network.

MAC

-  Media Access Control .

plaintext

-  Data that is input to an encryption process (see ) .

QoS

-  Quality of Service.

TLV

-  Type, Length, Value.

VLAN

-  Virtual LAN .

VTEP

-  VXLAN Tunnel End Point.

VXLAN

-  Virtual eXtensible Local Area Network .

Threat Model The primary threats considered in this document due to the inclusion of meta data in packets are from the surveillance of and/or modification of such fields. Such surveillance or modification could be accomplished either on links within the network domain or by the subversion of one or more nodes through which the traffic passes. Surveillance threatens loss of privacy to the users whose traffic is transiting the network domain because it permits packets to be associated with such users and their host or service provider with greater specificity. The additional information with packets may also reveal associations between users or aspects of the network domain structure and capabilities. And, to the extent that the additional information affects the treatment of the packet, unauthorized modification may disrupt network operation and interfere with the modified traffic or other traffic. Note that, without suitable countermeasures, radio links are particularly subject to surveillance and to traffic modification which can be accomplished by blocking the original version of a packet and injection of a modified copy. Subversion of a transit or egress node enables surveillance and modification of all the traffic through that node. Subversion of an ingress node is a threat but not closely related to adding information to the packet. All the information that might be in or associated with the packet is available at the ingress node regardless of whether any of this is added to the packet being ingressed.

Security Considerations This section provides Security Considerations for the inclusion in a packet of additional fields/information as discussed in this document. These considerations are equally applicable to IPv4 and IPv6 . They are grouped into the following topics:

• Surveillance Oriented Considerations o  Minimization o  Encryption o  Obfuscation
• Other Security Considerations o  Integrity and Authentication Considerations o  Covert Channel Considerations

The first three items above have a dominance relationship as follows: Minimization > Encryption > Obfuscation As further discussed below, where reasonably possible, the types of additional information discussed in this document SHOULD NOT be included with a packet. Where it is necessary to include the information, it SHOULD be encrypted where practical. Where encryption of the entire packet is prohibitive, the cleartext data that is not mutable in transit MUST be authenticated, for example through authenticated encryption with associated data (AEAD) mechanisms. In cases where it can be neither excluded nor encrypted, consideration should be given to obfuscating the information, even though that provides only weak protection.

Minimization The simplest method to minimize the harm that can be caused by the threats described in is to minimize the amount of additional information added to packets transiting the network domain. If some information will not be necessary for controlling the treatment of a packet or other network management functions, it SHOULD NOT be included. The exceptional cases where inclusion is reasonable are

1. transition scenarios, where information remains included for a brief time while mechanisms using the information are being removed or disabled, or included starting a brief time before mechanisms using the information are being installed or enabled, and
2. some debugging cases where the additional information would be temporarily helpful (but note that the mere addition of this information may change behavior and mask or cause erroneous behavior).

Minimization is the strongest method to defeat the security threats outlined in and MUST always be considered so a determination can be made as to whether the benefits of including the information exceed the risks. Any data that does not appear with the packets cannot, due to its transit of or egress from the network domain, compromise the privacy/security of the packet source.

Encryption Encryption is a powerful technique. With the use of appropriate cryptographic algorithms and key management, encryption coverts easily understandable plaintext into cyphertext from which the original plaintext cannot be derived. Use of encryption provides clear benefits but there also some costs. The computational burden of encryption/decryption at line speed may increase the cost of CPU or port hardware and may increase latency. Requirements for key management and pseudorandom number generation will impose some burden. Even with strong encryption, surveillance can yield information such as outer addressing and control information and the size and number of packets transmitted. The analysis of such indications is commonly known as "traffic analysis". Padding and dummy packets can obscure some of this meta information about encrypted traffic but only at a significant expense in bandwidth consumed. The subsections below discuss the scope of encryption, such as what part of a packet it can be applied to and whether it is at the link level or edge-to-edge. It is RECOMMENDED that both link level and edge-to-edge encryption be used unless careful consideration shows the costs to exceed the benefits in a particular case. If both are not being used, then it RECOMMENDED that one or the other be used with default preference for edge-to-edge encryption in wired networks and link encryption for radio networks. Some reasons for this default preference are that wired networks are typically higher speed and hardware security assist in a port is unusual and relatively expensive while the ease of access to traffic in radio networks has led to the almost universal inclusion of hardware security in wireless chip sets such that the use of link level encryption and authentication on a radio link can be considered low or zero cost.

Scope of Encryption Encryption can be applied to various parts of a packet; enough addressing and service information must be present outside the encryption to get the packet through the one or more hops it needs to transit with the desired QoS to the point where it will be decrypted. There is usually some encryption control information, such as a Key ID, which must be exposed to facilitate key rollover and the like. Also, depending on the mode of operation, a packet sequence number or the like may be needed. When part of a packet is encrypted, authentication of unencrypted fields in the packet SHOULD be considered (see ).

Link Encryption Link encryption encrypts a packet as it is output from the ingress node or a transit node and decrypts it on input to the next node in the path, which will be a transit node or the egress node. This protects the information content of the packet from surveillance of the link. However, it is usual that some link layer addressing information, such as a MAC address, and control information is needed by the destination node and in some cases needed by devices within the link. For example, if routers are connected by a bridged LAN proper handling of the packets between them may require that the packet be sent with a VLAN/priority tag. However, link layer encryption can normally encrypt network or higher layer addressing and control information including IP addresses. With link encryption, the packet will be decrypted inside each hop-by-hop node so additional information within the packet will be exposed there and privacy can still be harmed or service selectively denied by a subverted transit or egress node. Link encryption is common by default on radio links which are easily surveilled. For example, almost all Wi-Fi chip sets have built in cryptographic hardware so standardized link encryption for Wi-Fi is usually thought of as "free" in that its use does not impose significant speed or latency limitations although there is some key set-up and management overhead. A method more commonly used on wired networks, is the IEEE MACSEC standard.

Edge-to-Edge Encryption Encryption between the ingress node and the egress node provides protection from surveillance of all the links along that path as well as surveillance by the transit nodes used. However, such encryption cannot cover any fields that are needed to control the treatment of the packet along its path in the network domain or that cause it to be routed to and decrypted at its egress node (or possibly nodes in the case of multicast or broadcast). Thus edge-to-edge encryption does not cover network layer addresses and control information or link layer addressing and control information. While Link Encryption involves key setup only between adjacent nodes on the link, usually two nodes, strong Edge-to-Edge Encryption would require key setup for every pair of edge (ingress or egress) nodes that will be communicating traffic. This is potentially up to N*(N-1)/2 pairs if there are N edge nodes. And additional key set up and management may be required for multicast groups or the like.

Obfuscation Obfuscation refers to weak methods of hiding the content of a field or packet or reducing the predictability of some sequence identifier field. The strongest obfuscation would be to use a random, possibly even time-varying, one-to-one mapping of the values in such fields but this imposes a burden of generating and storing such a mapping at nodes that set or access such a mapped filed. It is more common to use weaker obfuscation as suggested below.

Field/Content Obfuscation The first type of obfuscation of can be thought of as weak encryption that is unkeyed or uses a fixed key or a key sent with the message. There is, nevertheless, some benefit to its use. Roughly speaking, it protects against inadvertent disclosure but provides almost no protection against deliberate attack. An interesting example of obfuscation is "masking" in The WebSocket Protocol . For client to server data transfer the protocol requires that the payload be "masked" by taking a 4-byte mask value, repeating it as many times as necessary, and XORing it with the payload. Furthermore, the mask value is required to be a random number different for each message derived from a strong source of entropy. However, this mask value is included as plain text with the payload so an entity that understands this masking can easily unmask the payload. In this case the obfuscation serves a particular security purpose as explained in which provides further information. As another example, someone debugging a network problem might do a capture of the packets on a link with a program that will display the packet data in hexadecimal and ASCII. This data might include personally identifying information or other sensitive information that could be immediately read if interpreted as ASCII. Such inadvertent disclosure could be avoided by an obfuscation as simple as XORing a fixed non-zero byte value with each data field byte.

Sequence Obfuscation A second type of obfuscation involves, to the extent practical, avoiding easily predictable numbers for identifiers such as Tenant IDs, sequence numbers, interface (port) identifiers, IP addresses, source socket numbers, and the like. If successively allocated identifiers of this sort are easily predictable, it is, for example, much easier to forge packets that may be accepted as genuine. Instead of simply counting to determine a next value to use, something like the output of a linear feedback shift register could be used. For further discussion, see , "Security Considerations for Transient Numeric Identifiers Employed in Network Protocols", which, among other things, states the following: "Protocol specifications SHOULD NOT employ predictable transient numeric identifiers, except when such predictability is the result of their interoperability requirements." and may also be of interest.

Integrity and Authentication Considerations Providing for the integrity and authentication of packets in the network domain is generally a good idea for reasons including the following:

1. To the extent that additional information with a packet affects network handling of that packet, it is important that the information is not corrupted or forged. Not only can the treatment of the packet be affected but if, for example, arbitrary numbers of high priority packets can be forged, overall performance of the network domain can be disrupted. Thus, integrity and authentication SHOULD be used.
2. Some modes of encryption (see ) are sensitive to modified, dropped, or extra packets which may result in garbling the decryption of following genuine packets. Appropriate integrity and authentication SHOULD be used with flows that are so encrypted.

Where part of a packet is encrypted and authenticated, unencrypted parts may be authenticated using AEAD.

Covert Channel Considerations The presence of additional information in a packet provides a place into which a node originating or forwarding a packet can potentially hide information and from which a subsequent node in the packet's path can retrieve information. The encryption of such additional information, which is desirable for reasons given above, can make detection of such tunneling, which can be used to exfiltrate information, hard to detect. Many of the headers discussed in which provide for the sort of additional information fields which are the primary focus of this document also have reserved fields. Most commonly the specification for these fields, which are reserved for later definition, state they must be sent as zero and ignored on receipt. Since their value is ignored by standards compliant nodes, such fields could also be used as a communications channel.

Examples of Applicable Fields The subsections below give some examples of fields to which the Security Considerations material in apply.

Example Fields from Standards Track RFCs The following are examples of fields specified in Standards Track RFCs to which these Security Considerations would apply.

Service Function Chaining Network Service Header The Service Function Header (SFC) Network Service Header (NSH) provides for the inclusion of metadata with packets inside an SFC enabled domain as shown in .

SFC NSH (from )

The MD Type field in the NSH header indicates the type of metadata field or fields in the "Context Headers" section of the NSH header. Such fields are appropriate for including additional information with a packet that would otherwise only be available at the ingress node. See, for example, the context headers specified in . The NSH is used to encapsulate the traffic and requires an outer transport header as shown in . This encapsulation is applied on ingress to the SFC enabled domain and removed on egress from that domain. If the transport encapsulation is, for example, IP, then transport encapsulation fields may also be available to add information to the packet within the network domain (see ).

NSH Encapsulation (from )

Geneve The Geneve (General Network Virtualization Encapsulation) header provides for a Virtual Network Identifier which is equivalent to a Tenant ID, as shown in . It also has a flexible provision for header options encoded at TLVs.

Geneve Header (from )

Geneve is used to encapsulate the traffic transiting the network domain with an IP transport encapsulation in a manner similar to the NSH Header as shown in and similar considerations apply.

IP Header Fields There are a number of IPv4 and IPv6 header fields that can be used to encode supplemental information. Some of these fields are, in general, mutable, so they could change as a packet is propagated through a network; however, this document is restricted to considerations within a single network domain with coordinated management which can, in some cases, avoid changing such fields. There is particular freedom to use IP fields where the traffic transiting the network domain is encapsulated in a manner that provides for a new outer IP header. For example, IP-in-IP or where the traffic is encapsulated in a tunnel header, such as VXLAN, NVGRE, SFC NSH, or Geneve, which is in turn encapsulated in an outer IP header.

DSCP/ToS

- There is an 8-bit field in the IPv6 and IPv4 header. Two of these bits are commonly used for Explicit Congestion Notification (ECN, ) and the other six are commonly used to encode hop-by-hop behaviors . In an outer IP header within a network domain with common management those six bits could be used as desired as could the ECN bits unless those bit are used to accumulate congestion information to be combined into an inner IP or similar header on domain egress.

Options

- Both IPv4 and IPv6 provide for header options with IPv6 having provisions for more flexible and extensive options but these have proven hard to use in practice.

IPv6 Flow Label

- In the IPv6 header, a 20-bit Flow Label field is available.

Addresses

- Where an outer IP header is used within a network domain, not all of the IPv4 or generously sized IPv6 address fields are needed to direct transit traffic from ingress to egress. Thus, other additional information could be encoded into the address field, perhaps in low order bits.

Sockets, Etc.

- There are additional fields available in the commonly used UDP and TCP headers that could, in an outer IP encapsulation inside a network domain, be interpreted as holding other information.

Example Fields from Other RFCs The following are examples of fields specified in RFCs that are not Standards Track to which the Security Considerations material in apply.

VXLAN VXLAN (Virtual eXtensible Local Area Network) is specified in and the VXLAN header is shown in .

VXLAN Header (from )

The Virtual Network Identifier (VNI) is a tenant identifier in multi-tenant domains. It is intended to identify traffic that uses an overlay network for that tenant. In addition, the use of VXLAN involves encapsulation of the traffic being forwarded so there is an outer IP and UDP header with various fields that could be used for additional information (see ).

NVGRE NVGRE (Network Virtualization Using Generic Routing Encapsulation) is specified in and the NVGRE header is shown in .

NVGRE Header (from )

The Virtual Subnet ID (VSID) is a tenant identifier in multi-tenant domains. It is intended to identify traffic that uses an overlay network for that tenant. In addition, the use of NVGRE involves encapsulation of the traffic being forwarded so there is an outer IP and UDP header with various fields that could be used for additional information (see ).

IANA Considerations This document requires no IANA actions.

Normative References Informative References Institute for Electrical and Electronic Engineers Institute for Electrical and Electronic Engineers Institute for Electrical and Electronic Engineers Wikipedia

Acknowledgements The suggestions and comments on this document from the following persons are gratefully acknowledged:    TBD