This is very interesting insight into what actually guided the decision to
exclude the checksum field from the IPv6 header.
However there were alternatives possible. For example it could be retained
and its usage made optional. Further the usage could be allowed to employ a
cryptographic hash of the header bits. That would have guaranteed integrity for
the entire IPv6 header, though everyone would not be forced to use it.
Such a guaranteed integrity for the packet header is currently not available,
even with the use of IPSec because of the matter of the mutable fields. From
this angle it could be argued that not including the "checksum" field amounts
to a lost opportunity. Perhaps security did not have such an overarching
posture in those days :-)
Rahim
Alex Conta <[EMAIL PROTECTED]> wrote:
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:[EMAIL PROTECTED]
> Sent: Tuesday, January 29, 2008 11:10 AM
> To: Rahim Choudhary; Fred Baker
> Cc: ipv6@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
> [EMAIL PROTECTED]
>
> ________________________________
>
> From: Rahim Choudhary [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 29, 2008 7:43 AM
> To: Fred Baker
> Cc: ipv6@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 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.
> om/newsear
ch/category.php?category=shopping>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
---------------------------------
Never miss a thing. Make Yahoo your homepage.--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
