Subject: 6MAN WG Last Call: <draft-ietf-6man-oversized-header-chain-02>

From: Ole Troan <[email-masked]>
Date: Mon, 11 Feb 2013 21:07:53 +0100

All,

This message starts a two week 6MAN Working Group on advancing:

	Title           : Security and Interoperability Implications of Oversized IPv6 Header Chains
	Author(s)    : F Gont, V. Manral
	Filename    : draft-ietf-6man-oversized-header-chain-02
	Pages        : 13
	Date           : 2012-11-05

      https://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/

as a Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list.  Editorial suggestions can be sent to the author.  This last call will end on 2013-02-25.

The chairs would also like to solicit a few people to do a detailed review of this document.  Please contact the chairs directly.

Regards,

Bob Hinden & Ole Trøan

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Feb 2013 07:58:36 +0000

I believe the draft needs one more spin in order to be precise
about the number of bytes included in the upper layer header.

Consider that in addition to the common transport headers,
and ICMPv6, any protocol number defined in the IANA registry
that is not an extension header might in theory occur as the
final "next header". The phrasing in the draft at present does
not tell a programmer what to do in the general case:

         Note: If there is an upper layer header, only the header (and
         not its payload) are considered part of the "entire IPv6 header
         chain".

Regards
   Brian Carpenter

---

From: Ray Hunter <[email-masked]>
Date: Tue, 12 Feb 2013 12:29:19 +0100

I have read this draft and support the work. The intention is good. The
detail is thorny.

Substantive Comment:

I think you're going to be asked lots of questions about what
constitutes an "IPv6 header chain," and to provide a tighter
specification of where it ends.

I'm sure there are people who wouldn't necessarily regard the contents
of the TCP header as being an integral part of an IPv6 header chain.

If I read RFC2460 "upper layer - a protocol layer immediately above
IPv6.  Examples are transport protocols such as TCP and UDP, control
protocols such as ICMP, routing protocols such as OSPF,  and internet or
lower-layer protocols being "tunneled" over (i.e., encapsulated in) IPv6
such as IPX, AppleTalk, or IPv6 itself."

So to me, a first-fragment that contained a complete IPv6 header with a
next-header value of 6 (an upper layer protocol) , but without
containing the TCP header itself, could also be considered a valid IPv6
header chain. However I'm sure we'd agree that'd be pretty useless for
stateless firewall filtering based solely on the first-fragment.

On the other hand, I know plenty of people who will certainly want to
apply a very granular filter on ICMPv6 Type and Code fields. Some ICMPv6
messages are required for normal operations, but others are useful in
network reconnaissance. Yet officially ICMPv6 is not called a header
AFAIK: it's a "message" with a "psuedo-header."

So I think we'll probably have to end up with an explicit specification
for the next-header values that constitute the first "upper-layer
protocol" together with the number of octets of that next header that
are mandatory to include, plus a default "last IPv6 header + X bytes"
for any unknown/new headers.

An alternative would be to make this an Informational RFC, and let
developers use "common sense" on "ensuring  that sufficient information
is included in the first fragment for a packet classifier located on the
forwarding path to be able to classify a packet as matching a filter
with a low probability of either false positives or false negatives"

Editorial

> A lot of the switches and Routers in the internet do hardware based
>    forwarding.  To be able to achieve a level of throughput, there is a
>    fixed maximum number of clock cycles dedicated to each packet.
>    However with the use of unlimited options and header interleaving,
>    larger packets with a lot of interleaving might have to be forwarded
>    to the software.  This is one reason why the maximum size of valid
>    packets with interleaved headers needs to be limited.

It ain't just firewalls: there's all sorts of middleware boxes and
packet classifiers.

Suggest:

Various devices on the internet forward or process packets via a number
of alternative internal paths, each of which may be optimised to handle
specific packet types in different ways. Packets are generally sent for
processing by the various paths based on the complexity of the packet,
with the most optimised path being the fastest (low latency and/or high
throughput) but also the most limited, whilst other paths may be able to
handle more complex packet formats, albeit slower (higher latency and/or
lower throughput). Some of these paths may be implemented in hardware,
with a fixed number of clock cycles dedicated to processing each packet.
Larger packets with a lot of headers may have to be processed by the
more generic, slower paths, leading to lower overall network
performance.  This is one reason why the maximum size of header chains
needs to be limited.

Additionally, stateless processing of packets (where each packet can be
processed independently) can be far more efficient and require less
resources than stateful processing (where a device has to maintain state
between related packets, and match newly arriving packets to previously
observed flows). Fragmentation of the IPv6 header chain across multiple
fragments may force a device into stateful processing, again reducing
overall network or device performance. Or perhaps more likely, the
packet will simply be dropped, or not correctly processed by this device.

Add to the list under 5:?
 o  Specific transport-layer information e.g. ICMPv6 message Type and
Code fields.

s/When presented with fragmented traffic, many of such firewalls
typically enforce their policy only on the first fragment of a packet,/
When presented with fragmented traffic, many such firewalls typically
enforce their policy based only on the information contained in the
first fragment of a packet,/

Small clarification:
s/On the other hand, first-fragments that fail
   to include the entire IPv6 header chain have never been formally
   deprecated and thus, in theory, might be legitimately generated./
On the other hand, first-fragments that fail
   to include the entire IPv6 header chain have never been formally
   deprecated and thus, in theory, might be legitimately generated by
end nodes, but incorrectly dropped by firewalls./

Suggest lower case NOT as there's no special meaning here, just emphasis.
s/packets that do NOT contain/packets that do not contain/

regards,
RayH