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 Ole Troan wrote: > 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
