> > we have discussed that with bluhm in berlin and initially i had the same > > opinion: leave the check in the stack, but he has convinced me that it's > > rather pf's job to do it. i'm not against bringing it back and his diff > > looks fine to me, esp. since it avoids double check that was there before. > > Personally, I wasn't aware that variations of RH0 attacks are > possible, and that PF is the only > way to mitigate the attacks completely, until alexender blumh mentioned.
pf was NOT the only way to mitigate the attacks. Until a month ago, there was automatic filtering, which worked against a subset of the attack scenarios, including the most common and most damaging cases. At least, that is my recollection from the time when the ORIGINAL change went in during the itojun era. The idea was that if the filtering is known to be super cheap, do it. Our source tree has many similar filters, for example, libc/rpc has code to handle FTP bounce attacks. When handling something damaging was possible at a specific layer, historically we have done such filtering, even if something else "might" be doing it. > To me, that is an important piece of information for end-users > running v6 networks. By that token, everything is an important piece of information for everyone running everything? > Do you guys think that it might be worth mentioning this in pfctl man page ? No way. Mentioning low-level effects in high-level places is an unsuitable documentation practice. Documentation is supposed to be terse. If you mention that specific issue, you will soon end up wanting to mention 40 other similar issues, and soon you are not documenting -d anymore, and the pfctl manual page is an unreadable book. Lacking a terse starting point, soon we have users who don't know where to start. The result is far greater knowledge gaps that what you just pointed out.
