On 2014-01-14, Richard Procter <richard.n.proc...@gmail.com> wrote: > Hi all, > > I'm using OpenBSD 5.3 to provide an Alix-based home firewall. Thank > you all for the commitment to elegant, well-documented software which > isn't pernicious to the mental health of its users. > > I've a question about the new checksum changes[0], being interested > in such things and having listened to Henning's presentation and > poked around in the archives a little. My understanding is that > checksums are now always recalculated when a header is altered, > never updated.[1] > > Is that right and if so has this affected NAT reliability? > > Recalculation here would compromise reliable end-to-end transport > as the payload checksum no longer covers the entire network path, > and so break a basic transport layer design principle.[2][3]
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. > [1] e.g. > 26:45 slide 27, 'use protocol checksum offloading better' > http://quigon.bsws.de/papers/2013/EuroBSDcon/mgp00027.html > 30:51 slide 30, 'consequences in pf' > http://quigon.bsws.de/papers/2013/EuroBSDcon/mgp00030.html > https://www.youtube.com/watch?v=AymV11igbLY > 'The surprising complexity of checksums in TCP/IP' > > [2] V. Cerf, R. Khan, IEEE Trans on Comms, Vol Com-22, No 5 May 1974 > Page 3 in original emphasis. > >> The remainder of the packet consists of text for delivery to the >> destination and a trailing check sum used for end-to-end software >> verification. The GATEWAY does /not/ modify the text and merely >> forwards the check sum along without computing or recomputing it. > > [3] Page 3. http://www.ietf.org/rfc/rfc793.txt > >> The TCP must recover from data that is damaged, lost, duplicated, or >> delivered out of order by the internet communication system. [...] >> Damage is handled by adding a checksum to each segment transmitted, >> checking it at the receiver, and discarding damaged segments.
