[ipv6-wg] Extension Headers / Impact on Security Devices

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" <silvia.hagen at sunny.ch> 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:ipv6-wg-bounces at ripe.net] Im Auftrag von Benedikt
>Stockebrand
>Gesendet: Sonntag, 17. Mai 2015 18:39
>An: ipv6-wg at ripe.net
>Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices
>
>Hi Enno and list,
>
>Enno Rey <erey at ernw.de> 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/
>
>