* Richard Procter <richard.n.proc...@gmail.com> [2014-01-22 06:44]: > > That is exactly what slides 30-33 talk about. PF now checks > > the incoming packets before it rewrites the checksum, so it can > > reject them if they are broken. > Right -- so NAT now replaces the existing transport checksum > with one newly computed from the payload [0].
correct - IF the original cksum was right. > This fundamentally weakens its usefulness, though: a correct > checksum now implies only that the payload likely matches > what the last NAT router happened to have in its memory, > whereas the receiver wants to know whether what it got is > what was originally transmitted. In the worst case of NAT on > every intermediate node the transport checksum is > effectively reduced to an adjunct of the link layer > checksum. huh? we receive a packet with correct cksum -> NAT -> packet goes out with correct cksum. we receive a packet with broken cksum -> NAT -> we leave the cksum alone, i. e. leave it broken. > I think it's great to see someone working hard to simplify > crucial code but in light of the above I believe pf should > always update the checksum, as it did in versions prior to > 5.4, as the alternative fundamentally undermines TCP by > making the undetected error rate of its streams unknown and > unbounded. One might argue networks these days are reliable; > I think it better to avoid the need to make the argument. > In any case the work I've found on that question is not > reassuring [1]. It doesn't seem you know what you are talking about. the cksum is dead simple, if we had bugs in claculating or verifying it, we really had a LOT of other problems. There is no "undetected error rate", nothing really changes there. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
