Re: TCP/IP CRC question

[Miles Stevenson <miles () mstevenson org>]

> 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 () mstevenson org
PGP FP: 035F 7D40 44A9 28FA 7453 BDF4 329F 889D 767D 2F63

Attachment: _bin
Description: