[e2e] purpose of pseudo header in TCP checksum

[Joe Touch]

Michael Welzl wrote:
>>>I also searched RFC 2460 for this once, but couldn't find anything.
>>>Still, that doesn't make sense to me. What if you transfer an
>>>IPv6 packet across a link layer that does *NOT* check your data -
>>>why wouldn't this cause harm to the source / destination addresses,
>>>and therefore cause wrong router behavior downstream? 
>>
>>It doesn't cause harm at the destination, since there's supposed to be a 
>>transport checksum (even for ICMP - one was added). I suppose there's no 
>>perceived harm in sending some corrupted traffic through the wrong paths.
>>
>>Note - this is designed to address corruption, not malicious behavior.
> 
> Okay, I agree that end-to-end integrity is preserved, nothing
> wrong about that. It's just that I find it hard to believe
> that there's no perceived harm in having routers make decisions
> based upon an erroneous IP header. Is sending some corrupted
> traffic through the wrong paths really all that can happen?
> Hm, it could affect the hop limit, too, but who cares.
> 
> Okay, so what about the "payload length" field - couldn't
> it lead to errors (a router allocates a buffer that is way
> too large ... hmmm, do we care?) ... 

I don't know if we care much more than we care about misuse of the 
outgoing link.

> I'm unsure, but still, I find it hard to believe.

Anyone on the list more familiar with the history of IPv6 care to comment?

>>And
>>
>>>what about the other fields - say, "next header"; a checksum
>>>error could turn a TCP packet into a UDP packet, change the
>>>payload length field, whatever.
>>
>>Sure - but then that checksum should either match or somebody's 
>>overwriting packets anyway, which they can do even if there are IP 
>>checksums. Onec you overwrite things, all bets are off.
> 
> I don't get that. There's no IPv6 checksum, so these fields
> could be changed by corruption and noone would notice. We
> could say that we don't care about the "next header" field
> too, because that's relevant in the end system, where the
> pseudo header will take effect.

Again, that appears to be the logic.

> So, I wonder: was the reason not to have an IPv6 checksum:
> 
> * because the assumption was that link layers provide
>   strong CRC protection anyway ( = "IP no longer over everything")
> 
> or
> 
> * because end-to-end integrity would be preserved anyway
>   and having routers make decisions based on an erroneous
>   IPv6 header won't really hurt anybody (I still somehow
>   find that hard to believe).

Combination of the two - that link layers that want to check are better 
than what IP provided, and that when they don't it's good enough to 
check at the transport layer.

There's also a notion (AFAIR) that IP checksums don't catch malicious 
behavior or much about link corruption (which is more about bursts than 
random, typically) - they have tended to catch buggy implementations, 
and the effort of putting that check in all routers isn't worth using it 
as a "can you implement a router properly" check (which is more what it 
provided, i.e.).

>>>What if we had a CRC-32 checksum in the IPv4 header, in
>>>the IPv6 header, in UDP Lite's header, in TCP's header,
>>>in the UDP header, well - just all over the place.
>>
>>The argument (far as I recall) was that things would be slower, not better.
> 
> Sure, the checksum was removed to speed things up - but,
> see below...
> 
>>>Then, we could just say "disable your checksums" to
>>>link layers when they notice a UDP Lite packet. It would
>>>even make sense to have a "corruption acceptable" bit
>>>somewhere in the IP header in such a scenario (I know,
>>>no bits to spare).
>>>
>>>Wouldn't that be better design?
>>
>>Define better. Again, the assumption is that not that many packets are 
> 
> Here's a try. Better = "guided by principles (*), not short-sighted
> performance optimizations (**)".
> 
> (*) ... such as "IP over everything"
> (**) ... such as "let's speed things up"

How about "doesn't help for the purpose intended"?

I.e., if the checksum basically helped find buggy router 
implementations, not avoiding link errors as much (typically, as will be 
discussed), then it's more effort than it's worth.

The idea, again, AFAIR, is that buggy links ought to use link error 
detection, not rely on IP layer protection. This may indeed be counter 
to the UDP-Lite assumption, but I never bought that one per se anyway. 
All this work to get arbitrarily corrupted data to the app seems 
misguided, moreso (IMO) than forwarding buggy packets even.

>>corrupted, and that when they are their path doesn't matter so long as 
>>the packets aren't accepted at the alleged destination. How would 
> 
> Assumption #1 is an ugly one because it breaks the "IP over
> everything" principle and now prevents us from cleanly realizing
> stuff like UDP Lite.

Whoa Nelly!

"cleanly realizing stuff like UDP Lite" - poster-child for unclean layer 
violation, in how it wants the _app_ to change how the transport 
interacts with the link layer? I need to clean my keyboard for just 
typing about it ;-)

> Assumption #2 seems strange to me, but okay, if that was it,
> I could live with it (i.e. not call it ugly).

I think it's more like "not worth the effort" than "speeds things up". 
The checksum isn't a particularly slow part; it can force a 
store-and-forward delay, rather than cut-through processing, as well as 
an additional $0.01 of hardware (if that), but it's not slow.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050216/c787ef5e/signature-0001.bin