wdiff draft-wkumari-long-headers-01.txt draft-wkumari-long-headers-02.txt

6MAN W. Kumari
Internet-Draft Google
Intended status: Best Current Practice J. Jaeggli
Expires: January 05, April 24, 2014 Zynga
R. Bonica
Juniper Networks
July 04,
October 21, 2013

Operational Issues Associated With Long IPv6 Extension Header Chains
draft-wkumari-long-headers-01
draft-wkumari-long-headers-02

Abstract

This document explains why memo specifies requirements for IPv6 forwarders as they process
packets with long header chain length affects the cost
of ASIC-based packet forwarding. chains. It also provides guidance for
application developers whose applications might rely on long headers
chains.

As background, this memo explains how many ASIC-based IPv6 forwarders
process packets and why some network
service providers discard processing of packets with exceptionally long header
chains. Finally, it identifies a reasonable header chain length.
While a network service provider can enforce any filtering policy
that supports its security model, a network service provider should
not discard IPv6 packets based solely upon header chain length if the
header chain is not longer than the value specified herein. chains
might be problematic.

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 RFC 2119 [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 January 05, April 24, 2014.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Termnology Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background Forwarder Information Requirements . . . . . . . . . . . . . 4
3. Requirements For IPv6 Forwarders . . . . . . . . . . . . 4
3. Need to see upper-layer to filter . . 5
4. Recommendations For Application Developers . . . . . . . . . 7
5. IANA Considerations . . . 5
4. Recommendations . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . 7
8. References . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . 7 . . . . . . . . . . . . . . . 8
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 9

1. Introduction

In order to make a forwarding decision,

IPv6 [RFC2460] forwarders can acquire information from the forwarding device may
require following
sources:

o The IPv6 header

o One or more IPv6 extension headers

o An upper-layer header

Section 2 of this document explains how IPv6 forwarders use
information from both the IPv6 header and an upper layer
header. IPv6 extension headers to
provide traditional forwarding services. It also explains how IPv6
forwarders use information from the upper-layer header to provide
enhanced forwarding services.

When a software-based forwarder encounters processes an IPv6 datagram
that includes a long header chain, datagram, it parses
the header chain, regardless of its length, acquires the required
information and makes its a forwarding decision. Typically, software-based software-
based forwarders are not required to process a
large relatively small number of packets per
second. Therefore, they can perform the above mentioned procedure
within the constraints of their processing budget.

By contrast, ASIC-based forwarders are engineered to forward process many more packets per
second. In order to fulfill this requirement, the
forwarder copies ASIC-based forwarders
copy a fixed number of bytes from the beginning of the packet to on-chip on-
chip memory. The ASIC does Forwarders do this because it they can access on-chip
memory much more quickly than it they can access off-chip memory. Once
the beginning of the packet has been transferred to on-chip memory,
subsequent processing and forwarding decisions can be made proceed very quickly.

The act of copying bytes from the beginning of a packet to on-chip
memory consumes both wall-time and processor cycles. consumes:

o Processor cycles

o On-chip memory

o Wall-time

Therefore, the number of bytes copied to on-chip memory must be
chosen wisely. If a forwarder copies more bytes than it needs, it
wastes resources,
significantly increasing cost resources and decreasing maximum adversely impacts performance. If it copies too
few bytes, it cannot parse the header chain and may not have sufficient information to make a correct
forwarding decision.

As currently specified in [RFC2460], the

The IPv6 header chain is a variable-length data structure, whose size
can exceed 64 kilobytes. However, packets with header chains
exceeding 128 256 bytes are rarely observed on the Internet. Therefore,
most ASIC-
based ASIC-based forwarders copy a relatively small number of bytes
from the beginning of the a packet into on-chip memory.

This document explains why While this small
number varies from platform to platform, it is generally much closer
to 256 bytes than it is to 64 kilobytes.

IPv6 forwarders MUST behave in a predictable manner when they process
a packet whose header chain length affects exceeds the cost number of bytes copied
to on-chip memory. Section 3 of this memo defines required
behaviors.

Application developers should be aware of how ASIC-based packet forwarding. It also explains why some network
service providers discard forwarders
process packets with exceptionally long extension header chains. Finally, it identifies a reasonable header chain length.
While a network service provider can enforce any filtering policy
that supports its security model, a network service provider SHOULD
NOT discard IPv6 packets based upon header chain length if the header
chain is not longer than the value specified herein. Therefore,
Section 4 of this document provides guidance to application
developers.

1.1. Termnology Terminology
For the purposes of this document, the terms Extension Header, Header
Chain "header chain" and Upper-layer Header
"upper-layer" header are used as follows:

Extension Header :

Extension Headers are defined in Section 4 of [RFC2460].
Currently, six extension header types are defined. [RFC2460]
defines
[I-D.ietf-6man-oversized-header-chain].

This document also introduces the hop-by-hop, routing, fragment following terms:

o forwarding service - a service that accepts a packet from one
interface and destination options
extension header types. [RFC4302] defines forwards it through another

o traditional forwarding service - a forwarding service in which all
parameters to the authentication
header (AH) type forwarding algorithm are drawn from the IPv6
header, the hop-by-hop extension header, and [RFC4303] defines the encapsulating security
payload (ESP) routing extension
header type.

Header Chain :

The initial

o enhanced forwarding service - a forwarding service in which
parameters to the forwarding algorithm can be drawn from any
portion of an IPv6 datagram containing headers. The
first member of the IPv6 header chain is always

2. Forwarder Information Requirements

When an IPv6 header. For a
subsequent header to qualify as a member of the header chain, forwarder provides traditional forwarding services, it
must be referenced
extracts all information required by the "Next Header" field of the previous
member of forwarding algorithm from
the header chain. The header chain can include IPv6
headers, IPv6 header, the hop-by-hop extension headers header (if present), and an upper-layer header. If
the routing extension header chain includes two IPv6 headers, as is (if present). In the case when IPv6
is tunneled over IPv6, nominal case, the second
IPv6 header terminates contains all information required by the
header chain. Any headers following forwarding
algorithm. However, the second IPv6 hop-by-hop and routing extension headers are
not members can
also impact forwarding behavior.

Section 4.2 of [RFC2460] explains how the hop-by-hop extension header chain. Likewise, if
impacts forwarding behavior. When the header chain
includes an ESP forwarder processes a hop-by-
hop extension header, it examines each option contained by the ESP header terminates the header
chain. Only
header. If forwarder encounters an unrecognized hop-by-hop option,
and the first 8 bytes high-order bits of the ESP header contribute option type are "00", the forwarder
skips over the option and continues to process subsequent options.
However, if an forwarder encounters an unrecognized option, and the
header chain length. Any headers following ESP header are not
members
high-order bits of the header chain.

Upper-layer Header :

In the general case, option type are "01", "10" or "11", the upper-layer header is
forwarder discards the first member packet.

Section 4.4 of [RFC2460] explains how the header chain that is neither an IPv6 header nor an IPv6 routing extension header. Typically, the upper-layer header represents a
transport protocol (e.g., TCP, UDP, SCTP). However, it can
represent
impacts forwarding behavior. When the forwarder processes a non-transport layer protocol. For example, when IPv4 packet
whose destination address is tunneled over IPv6, local to itself, it scans the upper-layer header is an IPv4
chain, searching for a routing extension header. If the packet
contains a routing extension header chain includes two IPv6 headers, as is and the case when
IPv6 is tunneled over IPv6, forwarder recognizes the second IPv6
routing header is considered
to be type, it processes the upper-layer header and terminates header. If the forwarder does
not recognize the routing header chain.

For type, the purposes of this document, when required behavior depends
upon the upper-layer protocol Segments Left field. If the Segments Left field is ICMPv6, equal to
zero, the first 32 bits of forwarder ignores the ICMPv6 message (i.e., routing extension header. Otherwise,
the
type, code fields forwarder discards the packet. [RFC6275] and checksum fields) are considered [RFC6554] describe
currently defined routing extension header types.

Some IPv6 forwarders provide enhanced forwarding services, such as
firewall filtering, rate limiting and load balancing. In order to be
provide these services, the
ICMPv6 forwarder requires access to an upper
layer header. The upper-layer payload is not part of the upper-layer header and
therefore, is not part following are examples of enhanced services that
require the IPv6 header chain. For example, if
the upper-layer protocol is TCP, forwarder to examine the upper layer header:

o Discard all packets directed to TCP port 25

o Rate limit packets destined for a particular address whose payload
is not part of TCP and have the TCP header or SYN bit set

o Load balance packets across parallel links so that all packet
belonging to particular TCP session traverse the same link

3. Requirements For IPv6 header chain.

2. Background

When IPv6 was first conceived, forwarding was largely performed in
software running on general-purpose processors. Due Forwarders

The following requirements apply to all IPv6 forwarders:

o REQ-1: An IPv6 forwarder SHOULD NOT discard a valid packet because
of its header chain length. However, the required
performance, parsing forwarder MAY support a long
configuration option that causes it to discard packets whose
header chain was not length exceeds a specified value.

o REQ-2: When processing packet that contains a hop-by-hop extension
header, an issue.

In the years between the conception of IPv6 and publication of this
documentation, the Internet evolved as follows:

o Throughput requirements increased dramatically, requiring forwarder MUST process the
deployment entire hop-by-hop
extension header, regardless of ASIC-based forwarders its length. The forwarder MUST
process each option as specified in both core and edge networks Section 4.2 of [RFC2460].

o New network types emerged, including very large enterprises,
social networks, data centers and "clouds". Like core networks,
these network require very high throughput. Like edge networks,
these networks require "high-touch" edge services, which require
the forwarder REQ-3: When processing a packet whose destination address is local
to access itself, an IPv6 forwarder MUST scan the entire header chain

o Requirements for "high-touch" service, which require the forwarder chain,
regardless of its length, in order to access determine whether the entire packet
contains a routing extension header. If the packet contains a
routing extension header, the forwarder MUST process routing
extension header chain, increased as specified in networks Section 4.4 of [RFC2460].

The length of all
kinds

During those years, IPv4 [RFC0791] was the most commonly deployed
protocol on IPv6 header plus the Internet. length of the hop-by-hop
extension header can exceed the number of bytes that an ASIC-based
forwarder copies into on-chip memory. Therefore, in order to support
REQ-2, ASIC-based forwarders could meet typically support a special processing
mechanism for packets containing hop-by-hop extensions.

Also, the
requirements combined length of all headers preceding the evolving Internet because ASICs could predict routing
extension header may exceed the number of bytes that needed to be copied an ASIC-based
forwarder copies into on-chip memory memory. Therefore, in order to make support
REQ-3, ASIC-based forwarders typically support a forwarding decision.

Today, as special processing
mechanism for packets whose IPv6 destination address is being deployed, ASIC-forwarders cannot safely
predict local to the size
forwarder. This forwarding mechanism is capable of processing the header chain. This leads to complexity and
vulnerability in handling
routing extension headers. For this reason, many
network operators filter all IPv6 packets containing extension
headers.

3. Need header, even if it begins beyond of the portion of
the packet that was copied to see upper-layer on-chip memory.

The following requirements apply to filter

There is IPv6 forwarders that provide
enhanced forwarding services:

o REQ-4: If a school of thought forwarder's ability to deliver enhanced services is
limited in any way by extension header length, that ISPs, content-providers and
enterprises should not limitation
MUST be performing any sort of filtering reflected in the
network user documentation. For example, assume that
a forwarder provides a load balancing service, and that it
acquires information required by the filtering is more appropriately performed at service from the
end hosts. Unfortunately this solution, while clean and elegant,
simply doesn't work in IPv6 header
and the real world. Filtering unknown traffic at upper-layer header. If the edge (and / or service behaves in one manner
when all required information is contained by the core) first N bytes of
the network header chain and in another manner when all required
information is needed for a number not contained by the first N bytes of reasons, some the header
chain, user documentation MUST reflect both behaviors as well as
the value of which are discussed below. N.

o ISPs (and cloud providers) are routinely called upon REQ-5: If a forwarder's ability to filter DoS
traffic aimed at their customers (for example to block multi-Gbps
DNS reflection attacks aimed at web servers, etc). At Large Edge
Sites this deliver an enhanced service is often a large part of the "service" provided
limited by extension header length, the
network team.

o IPv6 stacks are still relatively immature and operators still have
concerns that stack or kernel vulnerabilities may still surface.
If this turns out policy specification
language used to configure the enhanced service MUST be
sufficiently robust to address the case, limitation. For example,
assume that the forwarder provides a means firewall service. The
firewall service is capable of filtering packets directed to protect a
particular TCP port, but only if the end nodes TCP header is needed.

o In many enterprises contained by
the end systems are not sufficiently hardened
to be exposed on first N bytes of the public Internet. Even if there were no
remotely exploitable operating system vulnerabilities there is
significant risk that an employee may install vulnerable software,
accidentally share confidential files or folders publicly or start
offering (unauthorized) services.

o Content providers (and similar) need to header chain. In this case, it MUST be able
possible to filter traffic
and only allow "expected" traffic into their networks. This is
needed both configure one policy for DoS protection, but also packets directed to ensure that
development systems, databases, test systems, etc are the
specified port, another policy for packet not
accidentally exposed.

o While it would be nice if all employees, system and database
administrators could be trusted directed to always ensure that only the
"correct" services were listening on ports, that all software was
always fully patches (and contained no vulnerabilities), that
confidential data was only shared with internal addressed
specified port, and a third policy for packets whose TCP
destination port is unknown.

4. Recommendations For Application Developers

Applications developers should be aware that
all credentials were strong many ISPs and regularly changed,
enterprises filter or severely rate limit packets containing long
header chains. They do this simply
does not reflect reality.

All because of these lead to limitations imposed by the requirement that operators be able to filter
ASIC-based forwarders deployed at Layer 3 their edges. ISPs and Layer 4, at line rate, enterprises
accept these limitations as part of an engineering trade off, in the network. Obviously, to
be able to filter
which high-speed forwarding is achieved at layers 3 and 4, the router needs to be able to
see the layer 3 and 4 information. Unfortunately, if the size cost of limiting
enhanced services for packets with long extension header chain varies between 0 and 64 kilobytes, extension
headers cannot be processed efficiently in ASICs.

Because many implementation do not process IPv6 extension headers
well, many operators filter headers.

For example, assume that an enterprise deploys the following firewall
filtering policy at its edge:

o Permit all IPv6 packets that include them.

4. Recommendations

An ISP SHOULD NOT discard IPv6 whose destination is TCP port 80

o Discard all packets based solely upon whose destination is not TCP port 80

o Discard all packets whose header chain
length if is so long that TCP port
information is not accessible to the filtering function

In this case, the enterprise discards all packets whose destination
cannot be determined by the filtering function.

Aside from the issue of header chain contains 128 bytes or fewer. However, it
is common practice ISPs to length, operators may filter IPv6
packets with long containing extension
header chains. This document offers no recommendation regarding headers that may either compromise the
network's security posture or require inordinate processing
resources.

This memo does not specify a maximum extension header chain length length. However,
this memo does note that an ISP should forward.

See Section 1.1 for a formal definition at the time of its publication, the number
of bytes that ASIC-based forwarders copy from the beginning of a
packet to on-chip memory varies from platform to platform. Typical
platforms copy between 128 and 384 bytes. Therefore, application
developers should avoid sending packets who header chain. chain length is in
that range, unless they have some assurance that their packets will
not be discarded.

5. IANA Considerations

This document makes no requests of the IANA

6. Security Considerations

There are potential implications to the filtering or acceptances of
packets which cannot be processed according to the configuration of
the network operator. It is clear from the vantage point of the
authors that implementors and operators should be aware of
implications of relying on extension header chains or apply policies
that must necessarily discard packets which contain them.

TBD

7. Acknowledgements
The authors wish to thank Paul Hoffman, KK and Fernando Gont. The
authors also express their gratitude to an anonymous donor, without
whom this document would not have been written.

8. References

8.1. Normative References

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.

[I-D.ietf-6man-oversized-header-chain]
Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", draft-ietf-6man-oversized-
header-chain-08 (work in progress), October 2013.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.

[RFC4302] Kent,

[RFC2474] Nichols, K., Blake, S., "IP Authentication Header", Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 4302, 2474, December
2005.

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
1998.

8.2. Informative References

[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC
4303, December 2005. 6275, July 2011.

[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, March
2012.

Appendix A. Changes / Author Notes.

[RFC Editor: Please remove this section before publication ]

Template to -00

o Initial submission.

-00 to -01

o Added maximum header chain recommendation.

o Rewrite the forwarding description.

Authors' Addresses

Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US

Email: warren@kumari.net

Joel Jaeggli
Zynga
675 East Middlefield
Mountain View, CA
USA

Email: jjaeggli@zynga.com

Ronald P Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA
USA

Email: rbonica@juniper.net