[4554] in linux-net channel archive
Re: IP Masquerading (checksums)
daemon@ATHENA.MIT.EDU (Matthias Urlichs)
Sat Sep 28 03:13:36 1996
From: Matthias Urlichs <smurf@smurf.noris.de>
To: linux-net@vger.rutgers.edu
Date: Sat, 28 Sep 1996 08:46:48 +0100
In linux.dev.net, article <m0v6eC8-000BFeC@dingo.theplanet.co.uk>,
Nigel Metheringham <Nigel.Metheringham@theplanet.net> writes:
>=20
> That is the right way to go on - and will stop these=20
> messages since you will never know if the data is corrupt (but the=20
> end point should detect it).
>=20
This requires passivity, i.e. you don't depend on the correctness of th=
e
packet itself. For instance, this works when decrementing a packet's TT=
L
because you don't actually do anything with the packet and your local s=
tate
does not change.
On the other hand, I'd recommend to _always_ check the checksum of inco=
ming
packets whenever you need to work with a packet's data, even if you onl=
y
look at them.
Whether to recalculate or to fudge the checksum of modified packets sho=
uld
depend only on the extent of modifications made to the data.
IMHO, an application helper will usually do something more than just lo=
ok
at and modify packets. It's probably easier for an application to just =
pass
the data to another socket. I don't think we need a "look at that packe=
t,
possibly modify it, and tell the kernel what to do with it, all in one
or two rather complex system calls" interface.
Again IMHO, helper applications should be done with the masquerading co=
de
in the incoming firewall which we have now, and kernel helpers should b=
e
done with the masquerading code which we also have now. The only proble=
m is
that the kernel code has access to internals, such as being able to
correctly set up a reverse connection for FTP. We currently can't do th=
at
with a helper application, and piping gigabyte data streams through a
helper application is just plain stupid.=20
However, adding an appropriate interface should not be too difficult.
--=20
I'll speak to it though hell itself should gape, and bid me hold my
peace.
-- Shakespeare
--=20
Matthias Urlichs \ noris network GmbH / Xlink-POP N=FCrnberg=
=20
Schleiermacherstra=DFe 12 \ Linux+Internet / EMail: urlichs@nor=
is.de
90491 N=FCrnberg (Germany) \ Consulting+Programming+Networking+etc=
'ing
PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 D=
E
Click <A HREF=3D"http://info.noris.de/~smurf/finger">here</A>. =
42
