Network Working Group S. Bryant, Ed. Internet-Draft J. Guichard Intended status: Standards Track C. Pignataro Expires: December 14, 2013 S. Spraggs Cisco Systems June 12, 2013 Carrying Metadata in IP Networks draft-bryant-ip-metadata-00 Abstract This document defines the mechanism for carrying and identifying the presence of metadata carried in addition to the payload in IPv4 and IPv6 packets. Requirements Language 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]. 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 December 14, 2013. Copyright Notice Copyright (c) 2013 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 Bryant, et al. Expires December 14, 2013 [Page 1] Internet-Draft IP Metadata June 2013 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 2. Metadata Component Structure . . . . . . . . . . . . . . . . 2 3. Metadata Channel Encapsulation . . . . . . . . . . . . . . . 2 3.1. The Metadata Insertion Process . . . . . . . . . . . . . 3 3.2. The Metadata Receive Process . . . . . . . . . . . . . . 4 3.3. The Metadata removal Process . . . . . . . . . . . . . . 4 4. Load-balancing Considerations . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This document defines the mechanism for carrying and identifying the presence of metadata carried in addition to the payload in IP packets. The metadata header is common across all encapsulations (including IPv4, IPv6, and MPLS) and is defined in [I-D.guichard- metadata-header]. In this document ant reference to IP is to be taken as IPv4 and IPv6 unless otherwise specified. 2. Metadata Component Structure The addition of metadata to packets enables the instrumentation of user packets, and service chaining, although it is anticipated that the ability to allow packets to carry data of use to the infrastructure and specific handling instructions will enable other uses. Metadata carried within an IP packet is carried in UDP and is prefaced by a Metadata Channel Header (MCH) as defined in [I-D .guichard-metadata-header]. The presence of metadata is identified by the UDP port number assigned for this purpose. 3. Metadata Channel Encapsulation Bryant, et al. Expires December 14, 2013 [Page 2] Internet-Draft IP Metadata June 2013 An IP packet carrying metadata consists of the original IP header (except for the IP protocol type), a UDP header, the MCH, the metadata and the original IP payload. This is shown in Figure 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Channel Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Metadata in IP Encapsulation Figure 1 3.1. The Metadata Insertion Process In this section we describe the process of inserting metadata into an existing IP packet. This existing IP packet has been constructed in the normal way including the use of the normal protocol type or final next header type (IPv4 and Ipv6 respectively) to indicate the IP payload type, and the calculation of any transport layer checksums over the normal pseudoheader. The IP header, and in the case of IPv6, the next headers are removed from the packet and stored. The metadata is prepended to the IP payload. The MCH is prepended to the metadata. The IPv4 protocol type or the final IPv6 next header is copied from the stored IP header into the protocol field of the MCH. The UDP header is prepended to the MCH. The UDP destination port is set to the value "MCH-UDP" to indicate that an MCH follows. The UDP source port is used for load balancing as described in Section 4. As in this case UDP is providing an encapsulation for the IP payload, and the IP payload can be assumed to have been adequately protected before the inclusion of the metadata and encapsulation in UDP, the UDP checksum [RFC0768], [RFC6935] MAY therefore be safely set to zero, [RFC6936]. The IP header is restored to the packet by prepending it to the UDP header. The IPv4 protocol field or the IPv6 final next header is overwritten with the value 17 to indicate that a UDP header follows. Bryant, et al. Expires December 14, 2013 [Page 3] Internet-Draft IP Metadata June 2013 The length of the IP packet is increased to compensate for the length of the UDP header, and the length of the metadata plus the metadata itself. The IP checksum is also incrementally corrected to compensate for these modifications. Any process functionally equivalent to the above is considered a compliant implementation. It goes without saying that a packet can be constructed ab initio with the metadata included. Fragmented IP packets are not supported. 3.2. The Metadata Receive Process The receipt of a packet with a UDP port of type "MCH-UDP" indicates the presence of metadata. The MCH is examined and checked for the initial nibble of zero [I-D .guichard-metadata-header] and the MCH type is used to dispatch to the metadata process. The processing of the metadata is MCH type specific and outside the scope of this document. If the MCH does not have an initial nibble of zero the packet is discarded and the configured management recording of the event undertaken (for example the event is counted). 3.3. The Metadata removal Process In this section we describe the removal of the metadata and the reconstruction of the original IP packet. The protocol field in the MCH is stored. The IP header is prepended to the IP payload overwriting the MCH and the metadata. The protocol field in the IP header is overwritten by the protocol field extracted from the MCH. The length of the IP packet is decreased to compensate for the length of the UDP header, and the length of the metadata plus the metadata itself. The IP checksum is also incrementally corrected to compensate for these modifications. Bryant, et al. Expires December 14, 2013 [Page 4] Internet-Draft IP Metadata June 2013 The reconstructed IP packet is processed as normal. Any process functionally equivalent to the above is considered a compliant implementation. It goes without saying that a packet does not need to be de- constructed by an application that is metadata aware. 4. Load-balancing Considerations In an IPv4 packet with included metadata, the only field in the packet available to provide Equal Cost Multi-path (ECMP) Entropy is the UDP source port. The choice of which components of the original packet to extract entropy from and how calculate the entropy value stored in the UDP source port is implementation and protocol specific and is not specified in the document. The following example of a method of calculating the source port is provided by way of example and is not normative. The source port value MAY be calculated by hashing the IP source and destination addresses, the original IP protocol type (or final next header type in the case of IPv6) and, if applicable the source and destination ports of the original transport header and the result taken modulo 2^16. As the MCH is a unidirectional channel a source port value of zero is allowed. Nothing in the above precludes the use of the IPv6 flow label to signal entropy to the routers on the network path, in which case the choice of UDP source port is outside the scope of this document. 5. IANA Considerations This document requests that a UDP port is assigned to indicate the presence of metadata in the packet. This value is referred to as "MCH-UDP" in this document. The IANA specification of this UDP source port is: Service Name = NLmetadata Port Number = Next available from System Port Range. Transport Protocol = UDP (only) Description = Network Layer Metadata Assignee = IESG Contact = IETF Chair Bryant, et al. Expires December 14, 2013 [Page 5] Internet-Draft IP Metadata June 2013 6. Security Considerations The addition of metadata to a packet increases the amount of processing required by the router receiving the packet, and thus may be a used in a denial of service attack vector. Metadata SHOULD be blocked on ingress to the network other than from trusted sources. Metadata SHOULD only be processed when received from a trusted source. The metadata itself may be an attack vector with either the originating router or a man in the middle inserting malicious content, however the trust required from a router in the network is no different from the normal trust needed in this regard. Any management action taken to record the occurrence of a defective MCH or metadata payload SHOULD fall back to a lightweight process in the event of excessive events. This minimises the use of defective metadata packets as an attack vector. If the ingress router is taking instructions from a third party in the specific metadata to insert, there MUST be a sufficient trust relationship between the ingress router and the third party. The security considerations associated with each metadata type MUST be specified as part of its definition. 7. Contributing Authors o Clarence Filsfils (cfilsfil@cisco.com) o Dan Frost (danfrost@cisco.com) 8. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013. Bryant, et al. Expires December 14, 2013 [Page 6] Internet-Draft IP Metadata June 2013 Authors' Addresses Stewart Bryant (editor) Cisco Systems EMail: stbryant@cisco.com Jim Guichard Cisco Systems EMail: jguichar@cisco.com Carlos Pignataro Cisco Systems EMail: cpignata@cisco.com Simon Spraggs Cisco Systems EMail: sspraggs@cisco.com Bryant, et al. Expires December 14, 2013 [Page 7]