idnits 2.17.1 draft-bryant-ip-metadata-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 12, 2013) is 3970 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant, Ed. 3 Internet-Draft J. Guichard 4 Intended status: Standards Track C. Pignataro 5 Expires: December 14, 2013 S. Spraggs 6 Cisco Systems 7 June 12, 2013 9 Carrying Metadata in IP Networks 10 draft-bryant-ip-metadata-00 12 Abstract 14 This document defines the mechanism for carrying and identifying the 15 presence of metadata carried in addition to the payload in IPv4 and 16 IPv6 packets. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 14, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Metadata Component Structure . . . . . . . . . . . . . . . . 2 60 3. Metadata Channel Encapsulation . . . . . . . . . . . . . . . 2 61 3.1. The Metadata Insertion Process . . . . . . . . . . . . . 3 62 3.2. The Metadata Receive Process . . . . . . . . . . . . . . 4 63 3.3. The Metadata removal Process . . . . . . . . . . . . . . 4 64 4. Load-balancing Considerations . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 6 68 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 This document defines the mechanism for carrying and identifying the 73 presence of metadata carried in addition to the payload in IP 74 packets. The metadata header is common across all encapsulations 75 (including IPv4, IPv6, and MPLS) and is defined in [I-D.guichard- 76 metadata-header]. In this document ant reference to IP is to be 77 taken as IPv4 and IPv6 unless otherwise specified. 79 2. Metadata Component Structure 81 The addition of metadata to packets enables the instrumentation of 82 user packets, and service chaining, although it is anticipated that 83 the ability to allow packets to carry data of use to the 84 infrastructure and specific handling instructions will enable other 85 uses. 87 Metadata carried within an IP packet is carried in UDP and is 88 prefaced by a Metadata Channel Header (MCH) as defined in [I-D 89 .guichard-metadata-header]. 91 The presence of metadata is identified by the UDP port number 92 assigned for this purpose. 94 3. Metadata Channel Encapsulation 95 An IP packet carrying metadata consists of the original IP header 96 (except for the IP protocol type), a UDP header, the MCH, the 97 metadata and the original IP payload. This is shown in Figure 1 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | IP Header | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | UDP Header | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Metadata Channel Header | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Metadata | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | IP Payload | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 Metadata in IP Encapsulation 113 Figure 1 115 3.1. The Metadata Insertion Process 117 In this section we describe the process of inserting metadata into an 118 existing IP packet. This existing IP packet has been constructed in 119 the normal way including the use of the normal protocol type or final 120 next header type (IPv4 and Ipv6 respectively) to indicate the IP 121 payload type, and the calculation of any transport layer checksums 122 over the normal pseudoheader. 124 The IP header, and in the case of IPv6, the next headers are removed 125 from the packet and stored. The metadata is prepended to the IP 126 payload. The MCH is prepended to the metadata. The IPv4 protocol 127 type or the final IPv6 next header is copied from the stored IP 128 header into the protocol field of the MCH. 130 The UDP header is prepended to the MCH. The UDP destination port is 131 set to the value "MCH-UDP" to indicate that an MCH follows. The UDP 132 source port is used for load balancing as described in Section 4. As 133 in this case UDP is providing an encapsulation for the IP payload, 134 and the IP payload can be assumed to have been adequately protected 135 before the inclusion of the metadata and encapsulation in UDP, the 136 UDP checksum [RFC0768], [RFC6935] MAY therefore be safely set to 137 zero, [RFC6936]. 139 The IP header is restored to the packet by prepending it to the UDP 140 header. The IPv4 protocol field or the IPv6 final next header is 141 overwritten with the value 17 to indicate that a UDP header follows. 143 The length of the IP packet is increased to compensate for the length 144 of the UDP header, and the length of the metadata plus the metadata 145 itself. 147 The IP checksum is also incrementally corrected to compensate for 148 these modifications. 150 Any process functionally equivalent to the above is considered a 151 compliant implementation. 153 It goes without saying that a packet can be constructed ab initio 154 with the metadata included. 156 Fragmented IP packets are not supported. 158 3.2. The Metadata Receive Process 160 The receipt of a packet with a UDP port of type "MCH-UDP" indicates 161 the presence of metadata. 163 The MCH is examined and checked for the initial nibble of zero [I-D 164 .guichard-metadata-header] and the MCH type is used to dispatch to 165 the metadata process. The processing of the metadata is MCH type 166 specific and outside the scope of this document. 168 If the MCH does not have an initial nibble of zero the packet is 169 discarded and the configured management recording of the event 170 undertaken (for example the event is counted). 172 3.3. The Metadata removal Process 174 In this section we describe the removal of the metadata and the 175 reconstruction of the original IP packet. 177 The protocol field in the MCH is stored. 179 The IP header is prepended to the IP payload overwriting the MCH and 180 the metadata. 182 The protocol field in the IP header is overwritten by the protocol 183 field extracted from the MCH. 185 The length of the IP packet is decreased to compensate for the length 186 of the UDP header, and the length of the metadata plus the metadata 187 itself. 189 The IP checksum is also incrementally corrected to compensate for 190 these modifications. 192 The reconstructed IP packet is processed as normal. 194 Any process functionally equivalent to the above is considered a 195 compliant implementation. 197 It goes without saying that a packet does not need to be de- 198 constructed by an application that is metadata aware. 200 4. Load-balancing Considerations 202 In an IPv4 packet with included metadata, the only field in the 203 packet available to provide Equal Cost Multi-path (ECMP) Entropy is 204 the UDP source port. 206 The choice of which components of the original packet to extract 207 entropy from and how calculate the entropy value stored in the UDP 208 source port is implementation and protocol specific and is not 209 specified in the document. The following example of a method of 210 calculating the source port is provided by way of example and is not 211 normative. The source port value MAY be calculated by hashing the IP 212 source and destination addresses, the original IP protocol type (or 213 final next header type in the case of IPv6) and, if applicable the 214 source and destination ports of the original transport header and the 215 result taken modulo 2^16. As the MCH is a unidirectional channel a 216 source port value of zero is allowed. 218 Nothing in the above precludes the use of the IPv6 flow label to 219 signal entropy to the routers on the network path, in which case the 220 choice of UDP source port is outside the scope of this document. 222 5. IANA Considerations 224 This document requests that a UDP port is assigned to indicate the 225 presence of metadata in the packet. This value is referred to as 226 "MCH-UDP" in this document. The IANA specification of this UDP 227 source port is: 229 Service Name = NLmetadata 231 Port Number = Next available from System Port Range. 233 Transport Protocol = UDP (only) 235 Description = Network Layer Metadata 237 Assignee = IESG 239 Contact = IETF Chair 241 6. Security Considerations 243 The addition of metadata to a packet increases the amount of 244 processing required by the router receiving the packet, and thus may 245 be a used in a denial of service attack vector. Metadata SHOULD be 246 blocked on ingress to the network other than from trusted sources. 247 Metadata SHOULD only be processed when received from a trusted 248 source. 250 The metadata itself may be an attack vector with either the 251 originating router or a man in the middle inserting malicious 252 content, however the trust required from a router in the network is 253 no different from the normal trust needed in this regard. 255 Any management action taken to record the occurrence of a defective 256 MCH or metadata payload SHOULD fall back to a lightweight process in 257 the event of excessive events. This minimises the use of defective 258 metadata packets as an attack vector. 260 If the ingress router is taking instructions from a third party in 261 the specific metadata to insert, there MUST be a sufficient trust 262 relationship between the ingress router and the third party. 264 The security considerations associated with each metadata type MUST 265 be specified as part of its definition. 267 7. Contributing Authors 269 o Clarence Filsfils (cfilsfil@cisco.com) 271 o Dan Frost (danfrost@cisco.com) 273 8. Normative References 275 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 276 August 1980. 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 282 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 284 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 285 for the Use of IPv6 UDP Datagrams with Zero Checksums", 286 RFC 6936, April 2013. 288 Authors' Addresses 290 Stewart Bryant (editor) 291 Cisco Systems 293 EMail: stbryant@cisco.com 295 Jim Guichard 296 Cisco Systems 298 EMail: jguichar@cisco.com 300 Carlos Pignataro 301 Cisco Systems 303 EMail: cpignata@cisco.com 305 Simon Spraggs 306 Cisco Systems 308 EMail: sspraggs@cisco.com