[4553] in linux-net channel archive
Re: IP Masquerading (checksums)
daemon@ATHENA.MIT.EDU (Nigel Metheringham)
Sat Sep 28 01:24:23 1996
To: Juan Jose Ciarlante <jjciarla@raiz.uncu.edu.ar>
cc: Remco van de Meent <remco@cal052012.student.utwente.nl>,
Charles Brian Hill <hill@unr.net>, linux-net@vger.rutgers.edu
From: Nigel Metheringham <Nigel.Metheringham@theplanet.net>
In-reply-to: Your message of "Thu, 26 Sep 1996 17:15:50 -0300."
<Pine.LNX.3.95.960926151834.679B-100000@kosa>
Date: Fri, 27 Sep 1996 15:47:11 +0100
} On Tue, 24 Sep 1996, Remco van de Meent wrote:
}
} > If you wanna loose them, why don't you just simply comment out the code
} > that log's such things in the source code for ip_masq. (though I dunno
} > where to find it, never looked after it).
Its obvious and easy to find... that message only appears in 2 places
in the code (incoming and outgoing masquerade). Rather than
commenting out a better solution may be to reduce the priority of the
message so that it is ignored by default - take it down to debug
level.
} Here we come to the ``semantic'' question of masquerading, not being
} a router nor an application-level proxy ... (something in between ;).
} So, should we toss corrupted pkts or leave detection to linkends like a
} router? Maybe we should only spend CPU cycles checking packets that go
} through ip_masq application modules.
OK, here is my justification for the current behaviour.
Masquerading depends on rewriting the IP and higher protocol
(TCP/UDP) headers to readdress packets to/from the new ports.
This rewriting obviously changes the packet checksums - both IP and
TCP/UDP.
The code *used* to rewrite the packets then calculate and insert the
checksums for the new packet. This has the *very* bad side effect
that corrupt data was (incorrectly) validated (by which I mean made
to appear valid) by the masquerade. This could have "interesting"
side effects and was obviously a no-no.
I added code to check the packets before tampering, so that we did
not tamper with corrupt packets, but instead dropped them.
This is correct but inefficient in that each packet is checksumed
twice on the Linux masquerade box (to check and to force the new
checksum).
So thats what happens now....
You could use checksum modification - there is some info on that
somewhere (not to hand) - you know how you change the packet, you
change the checksum similarly. This gives a single change which is
more CPU efficient - only one op which doesn't require reading the
whole packet. That is the right way to go on - and will stop these
messages since you will never know if the data is corrupt (but the
end point should detect it).
However if there is an application helper this might radically change
the data - change the packet length, tamper with all sorts of things,
in which case checksum fudging becomes infeasible.
So I suggest that the following is done for 2.1 (Keith - can you add
this into your scheme).
+ An application helper can register itself as checksum friendly
meaning it doesn't change data (or fudges the checksum itself
for data changes it makes). Call this parameter needs_checksum
which is true if full checkumming is needed, and false if the
helper is checksum friendly.
+ If a masq tunnel has no application helper then checksum
modification
is performed.
+ If a masq tunnel has a helper with needs_checksum unset (false),
then
checksum modification is performed (prior to calling the helper).
+ If a masq tunnel has a help with needs_checksum set (true), then
the incoming packet is checkummed (checked) and dropped if this
fails.
The packet is then rewritten and passed to the helper.
The packet from the helper has a new checkum forced on it.
This adds complexity, but in most cases is more efficient than right
now. The disadvantage is that bad data passes through, but the
checksums will be wrong and the other end will reject it (well, it
should!) Unchecksummed UDP will still be dangerous!
Comments please...
Nigel.
--
[ Nigel.Metheringham@theplanet.net - Unix Applications Engineer ]
[ *Views expressed here are personal and not supported by PLAnet* ]
[ PLAnet Online : The White House Tel : +44 113 251 6012 ]
[ Melbourne Street, Leeds LS2 7PS UK. Fax : +44 113 2345656 ]
[[[ Welcome to Grace, arrived 01:37 BST, 18 Sept 1996, 5lb 15oz ]]]
