On Mon, Jul 14, 2003 at 12:37:26PM -0700, Aaron Suen wrote: > I'm sure there are things I haven't thought through clearly enough when > considering this topic, but it sounds like it will work to me. And, though the > payoff for a "typical" computer network is not spectacular, there are potential > benefits for this kind of approach. It could, effectively, render all current > fragment handling methods obsolete (am I being too ambitious?).
One point has already been mentioned: you might want the firewall to do complete reassembly if your server is dealing poorly with fragmentation attacks (if it keeps incomplete packets/fragments too long and runs out of memory). So I wouldn't replace full reassembly with your scheme, but add it as an additional reassembly mode. I'm not sure yet whether this is a common problem. What kind of services produce this kind of traffic? Obviously NFS over UDP, but how many people allow untrusted peers to talk NFS through a firewall? The added latency of full reassembly matters most with slow uplinks (not local networks), so I wonder how many people do NFS over UDP through slow uplinks to the internet :) Anything else must have failed PMTU discovery, if it sends large IP packets fragmented. We need a common, legitimate case that produces this traffic. If the traffic is nearly always produced by an attack, additional latency doesn't really matter... Daniel
