template W. Kumari
Internet-Draft Google
Intended status: Informational J. Jaeggli
Expires: August 8, 2013 Zynga
R. Bonica
Juniper Networks
February 4, 2013
Operational Issues Associated With Long IPv6 Extension Header Chains
draft-wkumari-long-headers-00
Abstract
This document outlines a set of issues with the use of long IPv6
extension header chains. It considers their use in the context of
today's IPv6 Internet and potential interaction with forwarding
devices that require upper-layer headers.
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 August 8, 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
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
Kumari, et al. Expires August 8, 2013 [Page 1]
Internet-Draft long-v6-headers February 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Understanding the scale. . . . . . . . . . . . . . . . . . 4
2.2. Different types of networks. . . . . . . . . . . . . . . . 5
2.3. Large Edge Site Operators. . . . . . . . . . . . . . . . . 5
3. Need to see upper-layer to filter . . . . . . . . . . . . . . . 6
4. Recomendations . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Kumari, et al. Expires August 8, 2013 [Page 2]
Internet-Draft long-v6-headers February 2013
1. Introduction
Many forwarding devices make forwarding decisions based upon
information that is drawn from both the IPv6 and transport
headers.When a software-based forwarding device encounters an IPv6
datagram that includes a long extension header chain, it parses the
header chain, acquires 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
processing budget.
By contrast, ASIC-based forwarders are typically required to forward
many more packets per second. In order to fulfill this requirement,
the forwarder copies an arbitrarily chosen number of bytes for 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 the beginning of the packet to
on-chip memory, the forwarder can make its forwarding decision very
quickly, because subsequent packet processing can all be achieved on-
chip.
The act of copying 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. If it copies too few
bytes, it cannot parse the extension header chain and make the
correct forwarding decision.
This memo describes problems that are caused by IPv6 packets
containing large extension header chains. Specifically, it describes
how ASIC-based forwarding devices may fail when both of the following
conditions are true:
o The forwarder is required to make a forwarding decision based upon
information that is drawn from both the IPv6 and transport layer
headers
o The forwarder encounters a packet in which the length of the IPv6
header plus the length of the extension header chain is greater
than the number of bytes that the ASIC copies to on-chip memory
This memo also presents recommendations, and is intended to spark
discussions.
Kumari, et al. Expires August 8, 2013 [Page 3]
Internet-Draft long-v6-headers February 2013
2. Background
Router architectures have evolved over time, and routers have become
more specialized devices. Initially (and 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 the packet, make forwarding decisions, perform additional
packet processing (decrement TTL, recalculate checksum, perhaps
process source route options) and then send the packet towards the
destination. This approach began to run into scaling / performance
issues for "core" type routers. More and more of the forwarding
logic has moved to Application Specific Integrated Circuits (ASICs)
and Network Processors. Networks that need to shift a large amount
of traffic (for example, large ISPs, enterprises, and content
providers generally purchase these "core" style devices.
As the amount of traffic (and correspondingly interface speeds
increased), the buses between linecards and to the forwarding ASICs
have become a bottleneck. In order to scale to the required speeds,
router manufacturers began segmenting the incoming packet into a
number of "cells" and only sending the first cell to the forwarding
logic.. Once this decision is made, the forwarding ASIC notifies the
output interface, which then sucks all of the other cells across the
switch fabric, assembles them into the correct order and ships the
packet. While this is more complex than simply shipping the entire
packet to the forwarding logic, it dramatically decreases the amount
of very fast memory associated with the forwarding logic, it works in
general quite well with IPv4 packets and it was needed to allow
routers to scale to the current demands.
In IPv4 this first cell contains all of the information required to
make forwarding (and filtering!) decisions, but this is not
necessarily the case in IPv6.
Readers of this document are expected to be familiar with [RFC2460]
Section 4.
2.1. Understanding the scale.
In order to understand why designs like this have evolved, it is
useful 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, and so has
approximerik ately 6.7 nanoseconds to forward the packet in order to
keep up with the input rate (for comparison, this is 26 clock cycles
on a 3.8Ghz CPU core).
Kumari, et al. Expires August 8, 2013 [Page 4]
Internet-Draft long-v6-headers February 2013
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 of the Internet is that there are a large number of
"edge" networks that connect to a "core" network, comprised of large
ISPs. The edge networks create (and consume) the data, the core
simply transits the traffic between the edge networks. Because the
core aggregates all of traffic from the edge networks it is made up
of huge, fast routers. Because the edge networks shift much less
traffic they use much smaller routers. While this makes a pretty
(and easily understood) picture, the reality is much more complex --
and messier.
There exist a number of "edge" networks whose scale of traffic make
them look much more like, and employ technology associated, with
"core" networks - these are entities like video distribution
networks, "cloud providers", social networks, large enterprises and
similar. For the purpose of this document we will call these Large
Edge Sites. This is relevant to this document because 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 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
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 to expectations.
This is as much an availability/performance/protocol requirement
(as we will see) as it is a security posture.
o The operator is not an Internet Service Provider in the
traditional sense; the customer is an application which in turn is
leveraged over the Internet.
Operator goals (in this order):
Kumari, et al. Expires August 8, 2013 [Page 5]
Internet-Draft long-v6-headers February 2013
1. Keeping their (and their users) data secure.
2. Keeping the networks up and running.
3. Keeping the network performing well.
4. Architect the network to be scalable.
5. Costs
6. Standards compliance.
This should in no way be considered to mean that operators throw away
packets capriciously, but in a decision between security and
availability, and standards compliance, the former considerations may
trump the later.
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 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).
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.
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
Kumari, et al. Expires August 8, 2013 [Page 6]
Internet-Draft long-v6-headers February 2013
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 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 and probably
deliberately malicious case of initial fragments which do not contain
an upper layer header.
In one widely deployed router architecture, if there are any
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 many operators choose to simply drop
all packets with any extension headers.
Network operators may filter traffic with extention header, because
of the lack of fixed extention header size, the complexity of
following header chains, and the inability of deployed routers to
look sufficently deep into packets to see the upper-layer header.
For this reason, appplications and 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
This document discourages the use of IPv6 Extension headers, and
advises the community that some operators currently filter ingress
packets that contain more than one extension header (and / or headers
that exceed a small number of bytes).
5. IANA Considerations
This document makes no requests of the IANA
Kumari, et al. Expires August 8, 2013 [Page 7]
Internet-Draft long-v6-headers February 2013
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
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ]
o Initial submission.
Authors' Addresses
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: warren@kumari.net
Kumari, et al. Expires August 8, 2013 [Page 8]
Internet-Draft long-v6-headers February 2013
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
Kumari, et al. Expires August 8, 2013 [Page 9]