Re: TCP/IP CRC question

> So, while you are right that it IS redundant to perform  checksums on each
> layer of the stack instead of just doing it on one layer that encapsulates
> the whole packet (such as Ethernet), the protocols had to take this
> approach to remain independant of the other protocols.

Self correction here. I don't mean to imply that performing a checksum on
layer 2 (in this case Ethernet) alone would actually work, since the original
Ethernet frame header is removed by a gateway device once it passes outside
the local network.

A few other interesting things to note about checksums:

Ethernet uses a CRC-32 algorithm for the checksum, which is different from the
other layers. CRC checksums are based on long-division, but can actually be
kind of tricky mathematically when you try to implement them. The CRC-32
algorithm is pretty effective  at avoiding "collisions", which happens when
the data is in fact corrupted, but the checksum happens to match this
particular corrupttion, as well as the non-corrupted version. Avoiding these
collisions is one of the most important aspects of a good checksum algorithm.

The checksum algorithm employed by IP is NOT a CRC checksum, but is addition
based, and comparitively a lot simpler, and a lot weaker than the CRC used by
Ethernet. This is also the same algorithm used by TCP/ICMP/UDP/IGMP (although
TCP uses some of the IP headers to calculate its checksum in addition to TCP
headers). I'm haven't found a good resource analyzing the rate of collisions
with the algorithm employed by IP,  but its not nearly as effective as CRC.  
Christopher Abad has written a very interesting paper demonstrating some of
the weaknessess of this algorithm, and how it can be used for a very slick
covert channel to store data in this checksum field, which would be extremely
difficult if not impossible to detect, because the checksums are still valid!

<link to Abad's paper> http://downloads.securityfocus.com/library/ipccc.pdf
</link>

In a previous reponse to this thread, Fernando Gont pointed out:
<snip>
>Finally, CRCs and checksums catch different type of errors. Checksums catch
>single bit errors (which usually happen at routers' memories), while CRCs
>protect data against burst error (continuous bits in the data stream are
>corrupted).
</snip>

I haven't found any resources to support this information. Of all the
resources that I have looked at explaining CRC algorithms and the addition
algorithm used by IP, "single bit errors" never comes up, and doesn't make
sense to me mathematically why CRC's only catch "burst errors". This isn't
meant to be negative toward Mr. Gonts' claims though. If he wouldn't mind
sharing some more detailed examples to support this, I'd go along with it.

Another interesting thing to note about IP checksums is the need for them to
be recalculated. For example, the IP header has 2 fields which are not
static, and can change when the packet gets routed from hop to hop: the TTL
field (which gets decremented by each router along its route), and the IP
Options field (which routers may append information to if requested, such as
record-route, timestamp, etc). When a router along this path changes these
fields, a new checksum has to be generated.

In the case of the TTL, its as simple as decrementing the checksum value (the
entire algorithm doesn't need to be applied to fix the checksum). But in the
case of IP Options being added, the entire checksum algorithm must be
applied, using slightly more processing power.

In a brief conversation with Johannes Ullrich of the ISC
(http://www.incidents.org/), Johannes pointed out that adding IP Options to
the headers could be an effective way of making DoS attacks more deadly,
because they require a bit more processing per-packet to recalculate the IP
checksums.

Have fun!

-- 
Miles Stevenson
miles_at_mstevenson.org
PGP FP: 035F 7D40 44A9 28FA 7453 BDF4 329F 889D 767D 2F63