Let me chime in ;-) On this topic, I am suffering of schizophrenia with a double personality...
- security person: I hate when there are too many options and sub-options and my usual recommendation is to use white list approach at the destination (being plain layer-4 ACL or more content filtering) and at the source (let's try to cut down covert channels): block unused ports, block unused protocols (remember IP protocol 41), block unused extension headers and drop everything which is not a normal IP packet (from address spoofing to invalid EH chain). If your firewall cannot implement this policy, then it is time to change or to use a combination of FW & IPS or whatever. - network person: as I will live with IPv6 for the rest of my life, then I want a way to extend it and I need any packet to travel to my source to my destination. Any IPv6 packet should be able to traverse the Internet/private network as long as its layer-3 header is valid (filtering/dropping can be done exceptionally for good operational reason). Did we remember the IPv4 teardrop attack? It is blocked by default by most routers for years ;-) Bugs will plague us for ever... And make our life more complex than the above description of course ;-) -éric On 17/05/15 20:43, "Silvia Hagen" <[email protected]> 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? > >I would want my firewall to notify me if the EHs in a packet do not >follow the list. >And limiting the number of possible EHs per packet might be a good idea. > >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/ > >
