RE: Checksum in IPv6 header

[Alex Conta <aconta at optonline.net>]

Fred,

I could add, that at the time, it was known that more and more, some
newer IPv4 forwarding machines circumvent TRUE checksum validation on
input/ingress, and/or recalculation on output/egress. This was
facilitated by things already mentioned: the stability of the IPv4
implementations - the "debug" factor mentioned by Fred B. lost its
importance - and by the fact that statistically, packet errors caused by
faulty links between two routers would be uncovered a lot more often, if
not exclusively, at L2. 

Performance wise, clever implementations already existed, which would
reduce the number of memory accesses involved for checksum calculations
- a few to begin with, since it is only a header checksum - by combining
the checksum calculation with regular operations on the header fields
involved in checksum.

Regards,
Alex

> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin at boeing.com] 
> Sent: Tuesday, January 29, 2008 11:10 AM
> To: Rahim Choudhary; Fred Baker
> Cc: ipv6 at ietf.org
> Subject: RE: Checksum in IPv6 header
> 
> 
> Rahim,
> 
> About the layer 2 and layer 4 checksums, from what I have
> been told and AFAICT the IPv6 Extension Headers are only 
> covered by L2 checksums; not L4. The question comes to
> 1) how likely is it that an error could occur in the
> extension headers that was not caught by the L2 checks,
> and 2) how bad would it be if that happened.
> 
> About 1), as Fred said this should only be problematic
> when there are implementation errors. That assertion I
> believe is supported by the work of Stone et al:
> 
> "When the CRC and TCP Checksum Disagree" 
> http://citeseer.ist.psu.edu/cache/papers/cs/21401/http:zSzzSzs
> igcomm.it.
> uu.sezSzconfzSzpaperzSzsigcomm2000-9-1.pdf/stone00when.pdf
> 
> "Performance of Checksums and CRCs Over Real Data" 
> http://citeseer.ist.psu.edu/cache/papers/cs/1909/ftp:zSzzSzftp
> .dsg.stanf
> ord.eduzSzpubzSzpaperszSzsplice-paper.pdf/stone98performance.pdf  
> 
> especially in the first of these two where it was observed
> that only a small number of "bad apple" machines were 
> responsible for contributing the largest portion of packets 
> with incorrect header checksums. (But, that work also asserts 
> that the L4 checksums in the Internet today are inadequate.)
> 
> About 2), there are a number of considerations as to what
> would happened if an error occurred in the IPv6 extension 
> headers that was not caught by the L2 checksums. For example, 
> if an error occurred in the ID field of a fragment header 
> there would be possiblity for the fragment of a first packet 
> to be combined with a fragment of a second packet. But, such 
> an unlikely combination should be caught by the L4 checksums. 
> As another example, if an error occurred in an address field 
> in a routing header, the packet could be mis-delivered. But, 
> this would appear as simply a lost packet from the 
> perspective of the intended target and a spurious packet from 
> the perspective of a target to which the packet may have been 
> mis-directed.
> 
> I haven't tried to track down all of the IPv6 extension
> headers and make analysis of what could happen if an error 
> occurred, but I think the correct questions in each instance
> are: 1) how likely is an error not caught by L2 CRCSs to
> occur, and 2) how bad would it be if that happened?
> 
> Thanks - Fred
> fred.l.templin at boeing.com    
> 
> ________________________________
> 
> 	From: Rahim Choudhary [mailto:rahimchoudhary at yahoo.com] 
> 	Sent: Tuesday, January 29, 2008 7:43 AM
> 	To: Fred Baker
> 	Cc: ipv6 at ietf.org
> 	Subject: Re: Checksum in IPv6 header
> 	
> 	
> 	Thanks. I also heard from Brian McGehee. It is 
> basically the same reason: efficiency by removing processing 
> that is deemed unneeded. In this case the layer 2 and 4 
> checksums are relied upon and simplification and thereby 
> performance is achieved at layer 3.
> 	 
> 	These are obvious reasons and I have seen them 
> documented. Wonder on two things: 
> 	 
> 	1. one if there were other reasons for not including 
> checksum in IPv6 header, historically speaking if there was a 
> contrary view?
> 	 
> 	2. second, concerns the security implication if any. 
> Yes the checksum was intended for guarding against 
> transmission errors, not as a security technique. The 
> question is if there are some unintended security impact 
> possible? Eventually the presence or absence of a checksum at 
> layer 3 may be not too important because the checksum can be 
> recomputed if some malicious change is inserted.
> 	 
> 	Thanks for the input.
> 	 
> 
> 
> 	Fred Baker <fred at cisco.com> wrote:
> 
> 
> 		On Jan 28, 2008, at 2:03 PM, Rahim Choudhary wrote:
> 
> 
> 			This may be a matter that is common knowledge to
> this list. But please forgive me for asking. What were the 
> reasons that the IPv6 working group decided not to include a 
> checksum field for the IPv6 packet Header? Does it have no 
> security impact to omit the checksum?
> 
> 
> 		The short version is that in general the 
> checksum found implementation errors, but given a working 
> system rarely found true operational errors. It's not stupid 
> as a debug technique, but it doesn't result in packet discard 
> in real networks, and so was deemed unjustified.
> 
> 
> 
> 	________________________________
> 
> 	Looking for last minute shopping deals? Find them fast 
> with Yahoo! Search. 
> <http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.c
om/newsear
ch/category.php?category=shopping> 


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------