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

template
6MAN W. Kumari
Internet-Draft Google
Intended status: Informational Best Current Practice J. Jaeggli
Expires: August 8, 2013 January 05, 2014 Zynga
R. Bonica
Juniper Networks
February 4,
July 04, 2013

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

Abstract

This document outlines a set of issues with explains why IPv6 header chain length affects the use cost
of ASIC-based packet forwarding. It also explains why some network
service providers discard packets with exceptionally long IPv6
extension header
chains. It considers their use in the context of
today's 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 Internet packets based solely upon header chain length if the
header chain is not longer than the value specified herein.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and potential interaction with forwarding
devices that require upper-layer headers. "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this 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 August 8, 2013. January 05, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . 2
1.1. Termnology . . . . . . . . . . . . . . . . . . . 4
2.1. Understanding the scale. . . . . . . . . . . . . . . . . . 4
2.2. Different types of networks. . . . . . . 3
2. Background . . . . . . . . . 5
2.3. Large Edge Site Operators. . . . . . . . . . . . . . . . . 5 4
3. Need to see upper-layer to filter . . . . . . . . . . . . . . . 6 5
4. Recomendations . Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 7
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 8 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 7

1. Introduction

Many forwarding devices

In order to make a forwarding decisions based upon decision, the forwarding device may
require information that is drawn from both the IPv6 header and transport
headers.When an upper layer
header. When a software-based forwarding device forwarder encounters an IPv6 datagram
that includes a long extension header chain, it parses the header chain,
acquires the required information and makes its forwarding decision.
Typically, software-based forwarders are not required to process a
large number of packets per second. Therefore, they can perform the
above mentioned procedure within a specified time and their processing budget.

By contrast, ASIC-based forwarders are typically required engineered to forward many
more packets per second. In order to fulfill this requirement, the
forwarder copies an arbitrarily chosen a fixed number of bytes for from the beginning of the
packet to on-chip memory. The ASIC does this because it can access
on-chip memory much more quickly than it can access off-chip memory. Having copied
Once the beginning of the packet has been transferred to on-chip
memory, the forwarder can make its forwarding decision very
quickly, because subsequent packet processing and forwarding decisions can all be achieved on-
chip. made
very quickly.

The act of copying bytes from the beginning of a packet to on-chip
memory consumes both wall-time and processor cycles. The number of bytes
copied is directly proportional to the amount of wall-time and
processing cycles consumed. 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. resources,
significantly increasing cost and decreasing maximum performance. If
it copies too few bytes, it cannot parse the extension header chain and make the a
correct forwarding decision.

This memo describes problems that are caused by

As currently specified in [RFC2460], the IPv6 header chain can exceed
64 kilobytes. However, packets
containing large extension with header chains. Specifically, it describes
how ASIC-based forwarding devices may fail when both of the following
conditions chains exceeding 128
bytes are true:

o The forwarder is required to make a forwarding decision based upon
information that is drawn from both rarely observed on the IPv6 and transport layer
headers
o The forwarder encounters Internet. Therefore, most ASIC-
based forwarders copy a packet in which relatively small number of bytes from the length
beginning of the packet into on-chip memory.

This document explains why IPv6 header plus the chain length affects the cost
of ASIC-based packet forwarding. It also explains why some network
service providers discard 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 upon header chain length if the extension header
chain is greater not longer than the number value specified herein.

1.1. Termnology

For the purposes of bytes that this document, the ASIC copies to on-chip memory
This memo also presents recommendations, and is intended to spark
discussions.

2. Background

Router architectures have evolved over time, terms Extension Header, Header
Chain and routers have become
more specialized devices. Initially (and Upper-layer Header are used as follows:

Extension Header :

Extension Headers are defined in some cases still),
routers were "software switched" - a packet would arrive at the
router and software running on a general purpose microprocessor would
look at Section 4 of [RFC2460].
Currently, six extension header types are defined. [RFC2460]
defines the packet, make forwarding decisions, perform additional
packet processing (decrement TTL, recalculate checksum, perhaps
process source route options) hop-by-hop, routing, fragment and then send the packet towards destination options
extension header types. [RFC4302] defines the
destination. This approach began to run into scaling / performance
issues for "core" authentication
header (AH) type routers. More and more of [RFC4303] defines the forwarding
logic has moved to Application Specific Integrated Circuits (ASICs)
and Network Processors. Networks that need to shift a large amount encapsulating security
payload (ESP) header type.

Header Chain :

The initial portion of traffic (for example, large ISPs, enterprises, and content
providers generally purchase these "core" style devices.

As the amount an IPv6 datagram containing headers. The
first member of traffic (and correspondingly interface speeds
increased), the buses between linecards and to the forwarding ASICs
have become header chain is always an IPv6 header. For a bottleneck. In order to scale
subsequent header to qualify as a member of the required speeds,
router manufacturers began segmenting header chain, it
must be referenced by the incoming packet into a
number "Next Header" field of the previous
member of "cells" the header chain. The header chain can include IPv6
headers, IPv6 extension headers and only sending an upper-layer header. If the first cell to
header chain includes two IPv6 headers, as is the forwarding
logic.. Once this decision case when IPv6
is made, tunneled over IPv6, the forwarding ASIC notifies second IPv6 header terminates the
output interface, which then sucks all
header chain. Any headers following the second IPv6 headers are
not members of the other cells across header chain. Likewise, if the
switch fabric, assembles them into header chain
includes an ESP header, the correct order and ships ESP header terminates the
packet. While this is more complex than simply shipping header
chain. Only the entire
packet first 8 bytes of the ESP header contribute to the forwarding logic, it dramatically decreases
header chain length. Any headers following ESP header are not
members of the header chain.

Upper-layer Header :

In the amount general case, the upper-layer header is the first member of very fast memory associated with
the forwarding logic, header chain that is neither an IPv6 header nor an IPv6
extension header. Typically, the upper-layer header represents a
transport protocol (e.g., TCP, UDP, SCTP). However, it works in
general quite well with can
represent a non-transport layer protocol. For example, when IPv4 packets and it was needed to allow
routers to scale to
is tunneled over IPv6, the current demands.

In upper-layer header is an IPv4 this first cell contains all of header.
If the information required to
make forwarding (and filtering!) decisions, but this header chain includes two IPv6 headers, as is not
necessarily the case in IPv6.

Readers of this document are expected to be familiar with [RFC2460]
Section 4.

2.1. Understanding when
IPv6 is tunneled over IPv6, the scale.

In order to understand why designs like this have evolved, it second IPv6 header is
useful considered
to be able to get a rough idea of the sorts of scale we are
discussing.

A single 100Gbps Ethernet interface, filled with 64byte packets
receives approximately 148.8 million packets per second, upper-layer header and so has
approximerik ately 6.7 nanoseconds to forward terminates the packet in order to
keep up with header chain.

For the input rate (for comparison, purposes of this document, when the upper-layer protocol
is 26 clock cycles
on a 3.8Ghz CPU core).

A (current) large router contains multiple distributed packet
processing engines, and a single chassis might have an aggregate
switching capacity of around 4.5Tbps.

2.2. Different types of networks.

The classic view ICMPv6, the first 32 bits of the Internet is that there ICMPv6 message (i.e., the
type, code fields and checksum fields) are a large number of
"edge" networks that connect considered to a "core" network, comprised of large
ISPs. The edge networks create (and consume) the data, be the core
simply transits
ICMPv6 header.

The upper-layer payload is not part of the traffic between upper-layer header and
therefore, is not part of the edge networks. Because IPv6 header chain. For example, if
the
core aggregates all of traffic from upper-layer protocol is TCP, the edge networks it TCP payload is made up not part of huge, fast routers. Because
the edge networks shift much less
traffic they use much smaller routers. While this makes TCP header or the IPv6 header chain.

2. Background

When IPv6 was first conceived, forwarding was largely performed in
software running on general-purpose processors. Due to the required
performance, parsing a pretty
(and easily understood) picture, long header chain was not an issue.

In the reality is much more complex -- years between the conception of IPv6 and messier.

There exist a number publication of "edge" networks whose scale this
documentation, the Internet evolved as follows:

o Throughput requirements increased dramatically, requiring the
deployment of traffic make
them look much more like, ASIC-based forwarders in both core and employ technology associated, with
"core" edge networks - these are entities like video distribution
networks, "cloud providers",

o New network types emerged, including very large enterprises,
social networks, large enterprises data centers and
similar. For the purpose of this document we will call these Large
Edge Sites. This is relevant to this document because "clouds". Like core networks,
these large
edge sites often have network requirements that differ from
traditional ISPs, and often wish to perform more filtering of
traffic.

2.3. Large Edge Site Operators.

Some properties common to large require very high throughput. Like edge site operators.

o Run their own "backbone".
o Push or Sink significant amounts of traffic from peers or
providers.
o They lack customer routes, e.g. they are their own customer, not a
transit ISP in the traditional sense.
o Peer with a large number of ISPs and other LES / edges.
o Look sort of like an enterprise. Apply ingress policy on upsteam networks,
these networks require "high-touch" edge or locations other than end systems. The principle is to
only allow in traffic that is expected (incoming connections are
by nature unsolicited)
o Filter out any traffic that does not conform services, which require
the forwarder to expectations.
This is as much an availability/performance/protocol requirement
(as we will see) as it is a security posture. access the entire header chain

o The operator is not an Internet Service Provider in Requirements for "high-touch" service, which require the
traditional sense; forwarder
to access the customer is an application which entire header chain, increased in turn is
leveraged over networks of all
kinds

During those years, IPv4 [RFC0791] was the most commonly deployed
protocol on the Internet.

Operator goals (in this order):

1. Keeping their (and their users) data secure.
2. Keeping ASIC-based forwarders could meet the networks up and running.
3. Keeping
requirements of the network performing well.
4. Architect evolving Internet because ASICs could predict the network
number of bytes that needed to be scalable.
5. Costs
6. Standards compliance.

This should copied into on-chip memory in no way be considered order
to mean that operators throw away
packets capriciously, but in make a decision between security and
availability, and standards compliance, forwarding decision.

Today, as IPv6 is being deployed, ASIC-forwarders cannot safely
predict the former considerations may
trump size of the later. header chain. This leads to complexity and
vulnerability in handling extension headers. For this reason, many
network operators filter all IPv6 packets containing extension
headers.

3. Need to see upper-layer to filter

There is a school of thought that ISPs, content-providers and
enterprises should not be performing any sort of filtering in the
network and that the filtering is more appropriately performed at the
end hosts. Unfortinalty Unfortunately this solution, while clean and elegant,
simply doesn't work in the real world. Filtering unknown traffic at
the edge (and / or in the core) of the network is needed for a number
of reasons, some of which are discussed below (these are not really
germane to the draft, but discussing them here may help head off many
discussions). below.

o ISPs (and cloud providers) are routinely called upon 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 is often a large part of the "service" provided by 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 to be the case, a means to protect the end nodes
is needed.

o In many enterprises the end systems are not sufficiently hardened
to be exposed on 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 be able to filter traffic
and only allow "expected" traffic into their networks. This is
needed both for DoS protection, but also to ensure that
development systems, databases, test systems, etc are not
accidentally exposed.

o While it would be nice if all employees, system and database
administrators could be trusted 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 and that
all credentials were strong and regularly changed, this simply
does not reflect reality.

All of these lead to the requirement that operators be able to filter
at Layer 3 and Layer 4, at line rate, in the network. Obviously, to
be able to filter at layers 3 and 4, the router needs to be able to
see the layer 3 and 4 information. Unfortunately, if the upper layer
header is not available in the first cell / segment size of the larger
packet we may not be able to see it. This applies to cases where
extension headers pad the variable length portion of the header,
beyond the cell size or, the presumably rarer header chain varies between 0 and probably
deliberately malicious case of initial fragments which 64 kilobytes, extension
headers cannot be processed efficiently in ASICs.

Because many implementation do not contain
an upper layer header.

In one widely deployed router architecture, if there are any process IPv6 extension headers between the IPv6 header and the upper-layer header,
the forwarding logic never sees the upper-layer header, and so is not
able to filter on it. This means that the operator has no visibility
into the packet contents, and so
well, many operators choose to simply drop filter all IPv6 packets with any extension headers.

Network operators may filter traffic with extention header, because
of the lack of fixed extention that include them.

4. Recommendations

An ISP SHOULD NOT discard IPv6 packets based solely upon header size, chain
length if the complexity of
following header chains, and the inability of deployed routers to
look sufficently deep into packets chain contains 128 bytes or fewer. However, it
is common practice ISPs to see the upper-layer header.

For this reason, appplications and filter IPv6 stacks should avoid the use
of extention headers whenever possaible, and applications should be
designed to deal with the posibility that packets containing
extention headers may not be delivered.

4. Recomendations with long extension
header chains. This document discourages the use of IPv6 Extension headers, and
advises offers no recommendation regarding the community that some operators currently filter ingress
packets that contain more than one
maximum extension header (and / or headers chain length that exceed an ISP should forward.

See Section 1.1 for a small number formal definition of bytes). the header chain.

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.

7. Acknowledgements

The authors wish to thank Paul Hoffman, KK and Fernando Gont.

They also wish to thank folk for not getting all up in arms :-P

8. Normative References

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

[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, S., "IP Authentication Header", RFC 4302, December
2005.

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.

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: internet-drafts@bonica.org rbonica@juniper.net