Fred, All, On Wed, Jun 17, 2015 at 07:41:33AM +0000, Fred Baker (fred) wrote: > I'm of course missing the preceding email. No problem with the cross-posting, > but let's get the question on the table? Is this section 4.1's statement that > "it is recommended that those headers appear in the following order"? > > I have a hunch that an internet draft requiring headers to be in the listed > order would be looked at with approbation. The issue, if any, would likely > have regard to repeated Destination Option headers. However > > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). > > seems to me fairly definitive.
I'm not so sure about this. First probably a capital "SHOULD" would have been more appropriate. Second - and this is our main point/observation - there's too much space of interpretation for actual implementation. To underline this I will just cite two somewhat random sections from the study we performed on evading security controls (IDPS systems) by means of extension headers, combined with fragmentation (https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf). One of the devices (all of them latest code incl. some high-end gear) could be evaded by the following: "Case 1: - An IPv6 Routing Header Type 0 in the unfragmentable part is used. - AND a IPv6 Destination Option header is part of the fragmentable piece of the IPv6 datatagram. - AND The IPv6 Destinations Option header is padded with six (6) octets of bytes (at least). - AND The IPv6 datagram is fragmented in 2 fragments. Case 2: - An IPv6 Hop-by-Hop Option Header and Routing Header Type 0 in the unfragmentable part is used - AND a IPv6 Destination Option header is part of the fragmentable piece of the IPv6 datatagram. - AND The IPv6 datagram is fragmented in 2 fragments. Case 3: - An IPv6 Destination Option Header and Routing Header Type 0 in the unfragmentable part is used. - AND a IPv6 Destination Option header is part of the fragmentable piece of the IPv6 datatagram. - AND The IPv6 datagram is fragmented in 2 fragments. Case 4: - An IPv6 Hop-by-Hop, Destination Option Header and Routing Header Type 0 in the unfragmentable part is used - AND a IPv6 Destination Option header is part of the fragmentable piece of the IPv6 datatagram. - AND The IPv6 datagram is fragmented in 2 fragments." Another one by the following: "a. The unfragmentable part consists of three (3) Destination Option headers b. The fragmentable part consists of two (2) Destination Option headers plus the layer 4 header. c. The aforementioned datagram is split in two fragments." It should be noted that most operating systems happily accept and process (incl., ofc, reassembly) packets crafted in such ways. [see results section in https://www.ernw.de/download/Advanced%20Attack%20Techniques%20against%20IPv6%20Networks-final.pdf]. It should further be noted that some of the techniques we used would even have worked in settings where RFC 7112 would have been strictly applied. > > Fernando would like to see a specification of how long the entire list of > extension headers may be, in terms of "how large of a hardware buffer has to > be implemented in a switch?" That has a couple of issues related to "why does > one have to ask the question?" The hardware should definitely be large enough > to read in the IPv6 header, the HBH Header, and the Routing Header. After > that, the only host that SHOULD need to read it all in is the host itself, > and the host can do its processing from RAM. There is one "gotcha" case, > which is when someone uses an ACL (disallowing Fragmentation Headers, > perhaps, or looking for the TCP port, meaning one has to ask whether a given > packet is TCP and what its port number is). The firewall is going to have to > chase down the chain of extension headers. Which might be a quite difficult task (not least performance-wise) once this chain, by definition, is abitrarily long. best Enno > > How big is a HBH header? How big is a routing option such as the Segment > Routing option? If that's a list of 27 services, each with a 16 byte IPv6 > address... > > > On May 17, 2015, at 12:18 PM, Enno Rey <[email protected]> wrote: > > > > Hi Silvia, > > > > On Sun, May 17, 2015 at 06:43:11PM +0000, Silvia Hagen wrote: > >> Hi > >> > >> I keep stumbling about that "recommendational wording" in RFC 2460 > >> everytime I teach it. > >> > >> Couldn't we update RFC2460 and make this list a strict order? > > > > good luck bringing this suggestion to IETF 6man... ;-) > > > > > > > >> > >> I would want my firewall to notify me if the EHs in a packet do not follow > >> the list. > > > > actually when we tested a number of commercial firewalls in late 2013 > > (results here: > > https://www.ernw.de/download/TR14_IPv6SecSummit_AAtlasis-RISC-project_results.pdf) > > it turned out that pretty much all of them follow a (from our perspective > > "reasonable approach", that is dropping "unusal combinations or number of > > ext_hdrs" by default. (which, of course, violates RFC 2460. but apparently > > all major vendors follow a line of reasoning similar to ours). > > so, in short, firewalls "are not affected". > > > > > >> And limiting the number of possible EHs per packet might be a good idea. > > > > yes, that _would actually be_ a good idea. > > > > > > I'm cross-posting this to v6ops as there's a related discussion going on > > right now. pls forgive this potential Usenet etiquette violation. > > > > best > > > > Enno > > > > > > > > > >> > >> Silvia > >> > >> -----Urspr?ngliche Nachricht----- > >> Von: ipv6-wg [mailto:[email protected]] Im Auftrag von Benedikt > >> Stockebrand > >> Gesendet: Sonntag, 17. Mai 2015 18:39 > >> An: [email protected] > >> Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices > >> > >> Hi Enno and list, > >> > >> Enno Rey <[email protected]> writes: > >> > >>> hope everybody had a great #RIPE70 meeting. We did! > >>> Many thanks to the organizers and chairs! > >> > >> and thanks to the actual speakers as well the speakers we had to turn down > >> due to time constraints, too:-) > >> > >>> If the chairs consider this appropriate we will happily give a > >>> presentation on this stuff in Bucharest or at another occasion. > >> > >> Sounds good to me! > >> > >>> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to > >>> their number, order[...] > >> > >> Actually, as far as I'm concerned that's the real core of the problem. > >> Or more specifically, the first two lines of RFC 2460, section 4.1: > >> > >> When more than one extension header is used in the same packet, it is > >> recommended that those headers appear in the following order: > >> > >> followed on the next page by > >> > >> Each extension header should occur at most once, except for the > >> Destination Options header which should occur at most twice (once > >> before a Routing header and once before the upper-layer header). > >> > >> Note in particular that these are not even RFC 2119 "SHOULD" or > >> "RECOMMENDED" and such. > >> > >> The impact here is actually at least twofold: > >> > >> - It is impossible to implement this as a simple pipeline architecture > >> in hardware; at least for cases deviating from the "recommendations" > >> above this effectively becomes either excessively complex to implement > >> in hardware or an invitation to DoS when implemented in software on an > >> otherwise hardware router. > >> > >> - As I understand it, at least some of the issues you have found are > >> effectively based on violating the second paragraph quoted, making it > >> impossible to come up with a lower bound on how long the header chain > >> can actually get and therefore leading to the fragmentation related > >> attacks and similar you have discovered. > >> > >> The original idea was that the extension headers are processed strictly in > >> the order they occur, so one question to ask is if there is any valid > >> reason to violate these "recommendations" for other than malicious > >> purposes. > >> > >> > >> Cheers, > >> > >> Benedikt > >> > >> -- > >> Benedikt Stockebrand, Stepladder IT Training+Consulting > >> Dipl.-Inform. http://www.stepladder-it.com/ > >> > >> Business Grade IPv6 --- Consulting, Training, Projects > >> > >> BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/ > >> > >> > > > > -- > > Enno Rey > > > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > > > Handelsregister Mannheim: HRB 337135 > > Geschaeftsfuehrer: Enno Rey > > > > ======================================================= > > Blog: www.insinuator.net || Conference: www.troopers.de > > Twitter: @Enno_Insinuator > > ======================================================= > > > > _______________________________________________ > > v6ops mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/v6ops > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
