Internet DRAFT - draft-bryant-ip-metadata
draft-bryant-ip-metadata
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]
