RE: TCP Checksum Interoperability
FYI, The 'offending' stacks are PC/TCP (reception) and in Open VMS (transmission). This is an age-old issue; the following dates from 1985(!): http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8502.mm.www/0389.html I think RFC 1624 is missing the UDP case, where +0 means not calculated. Indeed, RFC 768 asserts that the two values (+0 and -0) are equivalent. Part of the problem is that there isn't an RFC standard that deals with the issue of a zero checksum, apart from for UDP. The protocol RFCs don't specify the details and the implementation RFCs (1071, 1141, 1624) state explicitly that they are not standards, It is not a standard, but a set of useful implementation techniques. They are a very good idea but not mandatory. That's why I said I thought the receiver wasn't compliant: it rejects -0 as invalid. Chris -Original Message- From: Lloyd Wood [mailto:[EMAIL PROTECTED]] Sent: 05 April 2002 21:45 To: Michael Smith Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: TCP Checksum Interoperability On Fri, 5 Apr 2002, Michael Smith wrote: The last time this came up for a TCP implementation I used to maintain, our interpretation of Robustness Principle applied to this problem dictated that we shouldn't send segments with checksum fields set to all ones (that is, we shouldn't send ~(+0)), but that we had to accept either ~(+0) or ~(-0) in received segments. Strictly speaking, either zero state is completely legal Not so. Please read RFC1624 sections 3-5. L. [EMAIL PROTECTED]PGPhttp://www.ee.surrey.ac.uk/Personal/L.Wood/ - The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com
TCP Checksum Interoperability
I writing to this list because the TCP workgroup was shutdown a while ago. We have a compatibility problem between two third party implementations of the TCP checksum. The problem concerns the representation of zero, whichhas two 1-s complement representations ( and ). We don't have source to either stack but I managed to deduce the problem from looking at a packet trace. The receiver drops all datagrams containing a TCP with a TCP checksum of . The receiver appears to be following the checksum procedure in the RFC literally - ie zero checksum, recalculate and check that the result is the complement of what the sender sent. The problem is that the sender and receiver don't agree about zero and hence the datagram is dropped silently. My view is that the receiver is in error; it should be checking the special case of 0. All the receiver code I have seen doesn't work this way. The normal approach is to calculate the1-s complement sum withchecksum in place and check that this is zero. The methods Ikonwalways return just one representation for zero, hence there is no special case. Any thoughts? Thanks, Chris - The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.
Re: TCP Checksum Interoperability
The last time this came up for a TCP implementation I used to maintain, our interpretation of Robustness Principle applied to this problem dictated that we shouldn't send segments with checksum fields set to all ones (that is, we shouldn't send ~(+0)), but that we had to accept either ~(+0) or ~(-0) in received segments. Strictly speaking, either zero state is completely legal, but one is (apparently) more surprising to most implementors than the other, due to the implementation techniques that suggest themselves on most modern processors.
Re: TCP Checksum Interoperability
Rob Austein wrote: The last time this came up for a TCP implementation I used to maintain, our interpretation of Robustness Principle applied to this problem dictated that we shouldn't send segments with checksum fields set to all ones (that is, we shouldn't send ~(+0)), but that we had to accept either ~(+0) or ~(-0) in received segments. Strictly speaking, either zero state is completely legal, See my other post on this, as per RFC1624 section 3, only one state (0x) is legal as the complement of the checksum of non-zero data. TCP checksummed data must contain at least one nonzero word (the one with the TCP header length, which must be =20). The receiver is entirely justified in considering 0x as an error. Jeo
RE: TCP Checksum Interoperability
Title: RE: TCP Checksum Interoperability I'm cross-posting this thread to [EMAIL PROTECTED] for archival purposes, we'll see if any further replies to the ietf list get posted at [EMAIL PROTECTED] too (for instructions to join tcp-impl, see below). My rationale here is just to try and keep tcp-impl as a good source of material on tcp/ip implementation issues. It seems you can't post to '[EMAIL PROTECTED]' (see also below for discussion on this group). Sorry, Chris, forgot to copy you on this. Aloha Mike Smith CTO, iReady To: [EMAIL PROTECTED] Subject: Re: TCP Checksum Interoperability From: Rob Austein [EMAIL PROTECTED] Date: Fri, 05 Apr 2002 14:29:44 -0500 In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) The last time this came up for a TCP implementation I used to maintain, our interpretation of Robustness Principle applied to this problem dictated that we shouldn't send segments with checksum fields set to all ones (that is, we shouldn't send ~(+0)), but that we had to accept either ~(+0) or ~(-0) in received segments. Strictly speaking, either zero state is completely legal, but one is (apparently) more surprising to most implementors than the other, due to the implementation techniques that suggest themselves on most modern processors. -Original Message- From: Michael Smith Sent: Friday, April 05, 2002 10:39 AM To: '[EMAIL PROTECTED]' Cc: Michael Smith Subject: RE: TCP Checksum Interoperability Lloyd: your comment is interesting. I know there hasn't been much activity on tcp-impl, but it's still there. Allison sent an email a while back encouraging it's use, but I can't find that just now. To subscribe (or unsubscribe) to the tcp-impl mailing list, send mail to [EMAIL PROTECTED] with one of the following in the body of the message. subscribe tcp-impl unsubscribe tcp-impl There's also http://groups.yahoo.com/group/tcp-impl/ but activity there stopped about July 2001. I never understood how the two mailing lists related, but I posted your mail (below) to both, I hope you don't mind. Aloha Mike Smith CTO, iReady -Original Message- From: Lloyd Wood [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 4:43 AM To: Chris Trobridge Cc: [EMAIL PROTECTED] Subject: Re: TCP Checksum Interoperability See sections 3-5 of RFC1624 for discussion of the one's complement problem for the IP header checksum. I presume similar applies for TCP, although I don't know offhand if it's written down anywhere. L. On Fri, 5 Apr 2002, Chris Trobridge wrote: I writing to this list because the TCP workgroup was shutdown a while ago. We have a compatibility problem between two third party implementations of the TCP checksum. The problem concerns the representation of zero, which has two 1-s complement representations ( and ). We don't have source to either stack but I managed to deduce the problem from looking at a packet trace. The receiver drops all datagrams containing a TCP with a TCP checksum of . The receiver appears to be following the checksum procedure in the RFC literally - ie zero checksum, recalculate and check that the result is the complement of what the sender sent. The problem is that the sender and receiver don't agree about zero and hence the datagram is dropped silently. My view is that the receiver is in error; it should be checking the special case of 0. All the receiver code I have seen doesn't work this way. The normal approach is to calculate the1-s complement sum with checksum in place and check that this is zero. The methods I konw always return just one representation for zero, hence there is no special case. Any thoughts? Thanks, Chris stupid autoappended signatures below. - The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content
Re: TCP Checksum Interoperability
From: Joe Touch [EMAIL PROTECTED] our interpretation of Robustness Principle applied to this problem dictated that we .. had to accept either ~(+0) or ~(-0) in received segments. Strictly speaking, either zero state is completely legal, as per RFC1624 section 3, only one state (0x) is legal as the complement of the checksum of non-zero data. ... .. The receiver is entirely justified in considering 0x as an error. I would tend to disagree strongly with this last line, and agree with the original statement above. The TCP (and IP) checksum is defined as the one's complement of the one's-complement sum of the packet contents precisely to allow the following behaviour: one adds up the incoming packet, *including the checksum as it sits* (i.e. without having to zero out that field), and then checks to see that the result is all 1's - which is, as you point out, the only valid zero value that a one's-complement summation process *of a packet* can compute. (The only way to get all 0's as a sum of a one's-complement addition process is to to sum a series of zero's - which a real packet will never contain.) Note that if the packet's check sum (i.e. the sum with the checksum field set to zero) happens to come out to zero (i.e. all one's, before the complement), then *either* value of zero in the checksum field of the packet will result in an all-1's sum when the packet is checksummed. I honestly don't understand why anyone's code even bothers to look at the actual value in the checksum field of the incoming packet; just do the checksum of the whole packet, and look at the result. Noel PS: One does have to look at the incoming value for UDP, but that's different.
Re: TCP Checksum Interoperability
* From [EMAIL PROTECTED] Fri Apr 5 11:50:30 2002 * X-Authentication-Warning: ietf.org: majordom set sender to [EMAIL PROTECTED] using -f * Date: Fri, 05 Apr 2002 14:29:44 -0500 * From: Rob Austein [EMAIL PROTECTED] * To: [EMAIL PROTECTED] * Subject: Re: TCP Checksum Interoperability * User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) * MIME-Version: 1.0 (generated by SEMI 1.13.7 - Awazu) * X-Loop: [EMAIL PROTECTED] * X-AntiVirus: scanned by AMaViS 0.2.1 * * The last time this came up for a TCP implementation I used to * maintain, our interpretation of Robustness Principle applied to this * problem dictated that we shouldn't send segments with checksum fields * set to all ones (that is, we shouldn't send ~(+0)), but that we had to * accept either ~(+0) or ~(-0) in received segments. * * Strictly speaking, either zero state is completely legal, but one is * (apparently) more surprising to most implementors than the other, due * to the implementation techniques that suggest themselves on most * modern processors. * We thought we had laid these issues to rest in 1988, in RFC 1071. Bob Braden
Re: TCP Checksum Interoperability
and RFC791 claims ttl is in seconds, ergo I don't have to decrement ttl because I know my traffic is on paths less than a second long. Cool reasoning. You lose -- 791 says you have to subtract at least 1 from TTL even if. However, I think that (A) most or all extant IPv4 routers violate 791 if they happen hold a packet more than a second, and (B) IPv6 invalidated TCP's correctness by defining the Hop Limit field to be a hop limit and have no connection to time. A TCP riding on IPv6 may receive old segments an unbounded time later without any other network element breaking a spec. I said so at the time, but nobody cared. No doubt Vint will take care of multi-second hops for us.
Re: TCP Checksum Interoperability
At 03:13 PM 4/5/2002, Matt Crawford wrote: I think that (A) most or all extant IPv4 routers violate 791 if they happen hold a packet more than a second, and (B) IPv6 invalidated TCP's correctness by defining the Hop Limit field to be a hop limit and have no connection to time. A TCP riding on IPv6 may receive old segments an unbounded time later without any other network element breaking a spec. for the record, while IPv4 TTL remains theoretically a time in seconds, it effectively became a hop count a long time ago. Thus sayeth RFC 1812: 5.3.1 Time to Live (TTL) The Time-to-Live (TTL) field of the IP header is defined to be a timer limiting the lifetime of a datagram. It is an 8-bit field and the units are seconds. Each router (or other module) that handles a packet MUST decrement the TTL by at least one, even if the elapsed time was much less than a second. Since this is very often the case, the TTL is effectively a hop count limit on how far a datagram can propagate through the Internet. When a router forwards a packet, it MUST reduce the TTL by at least one. If it holds a packet for more than one second, it MAY decrement the TTL by one for each second. In that it MAY decrement the value, it also may choose not to...
Re: TCP Checksum Interoperability
At Fri, 5 Apr 2002 22:37:24 GMT, Bob Braden wrote: We thought we had laid these issues to rest in 1988, in RFC 1071. I think you came close. I disagree with one minor point in RFC 1071, but code based on RFC 1071 would have the behavior that I think is correct: it wouldn't generate TCP segments with 0x in the checksum field, but it would accept such segments if it received them.
