>My diff was on tech@ for one day during a hackathon before I commited it. >Not enough people discussed it back then. Fine. Let's discuss it now. > >The reasons why I removed the check in the stack are: >- Scanning headers in the forwarding path is against the spirit of IPv6.
One day someone should find the people who pushed RH0 into IPv6 and punish them. >- pf deals much better with fragments and headers now. True. >- When the check was added, there was no RFC. Now I am following RFC5095. I don't think RFC5095 goes far enough. Itojun also wanted a more penalizing solution. The idea behind the RH0 scanning is that it would dampen the pressure of RH0 attacks. If there are fewer participants, it is less feasible to use it to attack small pipes here or there. >- It is pf's job to add more security. It is. However, you will note that in IPv4 land we have sysctl net.inet.ip.sourceroute. It defaults to 0 (off). RH is like IPv4 source routing, except on steriods. Would any of us at this time recommend net.inet.ip.sourceroute=1, or to go further, remove the code disabling code from the kernel and assume that pf is doing the filtering? I doubt it. And yet, the IPv4 sourcerouting RFCs are just as toothless... >- The scanning was done twice with pf enabled. This latter point is very valid. I am very happy with your new approach that does the extra scanning only if pf is disabled. >Now I am tempted to put it back because: >- Theo says there a lot of OpenBSD boxes without pf attached to the internet. There are scenarios where pf is run disabled, or pf is not watching the up-stream/down-stream traffic. When pf is run, it only protects the local machine. >- Fernando Gont says there are plenty of legacy implementations supporting RH0. >- Fernando Gont says it is not the most secure approach to remove the check. If Fernando sees them, then the case is solid. All you need is a few hosts honouring RH0 on the opposite of a thin pipe, and you can cause blistering damage. The idea behind the RH0 scanning was to dampen the effects of a dead option. I believe this idea will be reasonable until RH0 is extinct. I only believe in this approach when the header is already cache-hot, and there is little performance. Untimately if many feel "pf is always on", then there is no argument for resisting code for the "pf is disabled" case... >- I have removed the double scan when pf is enabled. Beautiful.
