On 2015/09/25 13:05, Richard Procter wrote: > > Well we've been thru it more than once; the argument presented here > > was that modifying the cksum instead of verify + recalc is better as > > it wouldn't hide cksum mismatches if the cksum engines on the NICs we > > offload to misbehave. After many years with the verify + recalc > > approach I think it is pretty safe to say that this is of no > > concern... > > I'm sorry, that's not what I'm saying. Even supposing perfection of every > offload engine, offload engines have no monopoly on faults; regenerated > checksums also mask bus, stack and memory faults in pf-altered packets.
This is definitely not just a theoretical problem. It's one thing having corrupted packets delivered to the router's own TCP/UDP stack (or to another host but in a state where the corruption can be detected), but it's something totally different to do this for forwarded packets without providing the endpoint a way to detect it before they reach the application layer. SSH/TLS typical response is to terminate the whole session. As more and more traffic moves to secure connections (I'm seeing 40% of requests at my web proxies using CONNECT vs GET/HEAD, and the true count will be higher because it doesn't count keepalives as separate hits), errors that previously weren't really noticeable (some minor corruption in a web page or glitch in an image) now cause sessions to fail. > Another (home) router I administer was seeing IIRC five a day on average over > 42 days, something we expect of a globe-spanning internetwork. Passing one of > these damaged segments to the user sufficies to break MACs and drop secure > connections. While I do generally support this diff as long as it doesn't have a big negative impact on performance, the implication of mentioning this is that these are packets which PF would pass on to other hosts with a re-calculated checksum if the packets were modified (nat, scrub etc). But that's not the case because they would be checked on input to PF so wouldn't make it that far.
