Hi Rahim, My answer is more related to the security part of the question you asked. Though it may be a bit off what you are asking about, I thought it would be helpful.
With the various attacks on MD5(and SHA-1) that have been documented, in my view having the checksum as part of the packet which is MD5 hashed, in my view helps make the known attacks on MD5 even harder (if you want details I can get to you in another mail). Thanks, Vishwas On Jan 29, 2008 8:09 AM, Templin, Fred L <[EMAIL PROTECTED]> wrote: > 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:zSzzSzsigcomm.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 > [EMAIL PROTECTED] > > ________________________________ > > From: Rahim Choudhary [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 29, 2008 7:43 AM > To: Fred Baker > Cc: [email protected] > 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 <[EMAIL PROTECTED]> 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.com/newsear > ch/category.php?category=shopping> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
