Subject: Checksum in IPv6 header

From: Rahim Choudhary <[email-masked]>
Date: Mon, 28 Jan 2008 14:03:44 -0800 (PST)

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?
       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Jan 2008 14:38:28 -0800

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.

---

From: Rahim Choudhary <[email-masked]>
Date: Tue, 29 Jan 2008 07:43:11 -0800 (PST)

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-masked]> wrote:

  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.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Jan 2008 08:09:44 -0800

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-masked]    

________________________________

	From: Rahim Choudhary [mailto:[email-masked]] 
	Sent: Tuesday, January 29, 2008 7:43 AM
	To: Fred Baker
	Cc: [email-masked]
	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.

			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>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 29 Jan 2008 08:55:07 -0800

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 29 Jan 2008 10:01:09 -0800

On Jan 29, 2008, at 7:43 AM, Rahim Choudhary wrote:

> Thanks. I also heard from Brian McGehee. It is basically the same  
> reason: efficiency by removing processing that is deemed unneeded.  

IIRC this is a place where the consensus was "rough". The argument  
made, however, followed the effect of an error. If there was a  
checksum and an error occurred, the checksum would cause the packet  
to be discarded and a higher layer would have to recover. If there  
was no checksum, either the errored packet would get a different  
service quality in some way, be delivered to the wrong place,  
delivered correctly with the wrong putative sender, or (imagine a  
high-order bit in the TTL being flipped) would get dropped for some  
other reason. In any event, a higher layer protocol or application  
would have to recover. So with or without the checksum, a higher  
layer protocol would have to recover, and some other system in the  
network would have to recognize that something about the packet was  
screwy.

If IPsec is in fact used, the MD5 or SHA checksum is certainly  
stronger than IPv4's checksum ever was.

So the feeling was "what's the point?"

> 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.

if someone is intentionally manipulating the header, you need to  
assume they are smart enough to recalculate the checksum. The header  
checksum was never intended for security and never offered much.

> doesn't result in packet discard in real networks, and so was  
> deemed unjustified.
>
>
>

---

From: "TJ" <[email-masked]>
Date: Tue, 29 Jan 2008 10:48:18 -0500

The checksum is not a keyed hash - it's a standard, so any malicious node
that modified the header would just recalculate the hash and no one would be
the wiser. 

It was not meant to stop malicious activity - just random bit errors.

As for "Why drop it?" - why not.  J

L2 already does it, L4 already does it . back in the day, presumably this
was a performance benefit.  Now it is one less ASIC (or fewer lines of code
burned into an ASIC) needed J.

Thanks!

/TJ <http://facebook.tjevans.net/> 

From: Rahim Choudhary [mailto:[email-masked]] 
Sent: Monday, January 28, 2008 5:04 PM
To: [email-masked]
Subject: Checksum in IPv6 header

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?

  _____  

Looking for last minute shopping deals? Find
<http://us.rd.yahoo.com/evt=51734/*http:/tools.search.yahoo.com/newsearch/ca
tegory.php?category=shopping>  them fast with Yahoo! Search.

---

From: "TJ" <[email-masked]>
Date: Tue, 29 Jan 2008 09:06:23 -0500

Thanks!

  _____

---

From: "TJ" <[email-masked]>
Date: Tue, 29 Jan 2008 10:48:18 -0500

Thanks!

  _____

---

From: "TJ" <[email-masked]>
Date: Tue, 29 Jan 2008 09:06:23 -0500

Thanks!

  _____

---

From: Alex Conta <[email-masked]>
Date: Wed, 30 Jan 2008 13:01:02 -0500

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-masked]] 
> Sent: Tuesday, January 29, 2008 11:10 AM
> To: Rahim Choudhary; Fred Baker
> Cc: [email-masked]
> Subject: RE: Checksum in IPv6 header
> 
> 
> Rahim,
> 
> 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.
> 
> 	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.
> 	 
> 	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 
> 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.
> 
> 
>

---

From: Rahim Choudhary <[email-masked]>
Date: Thu, 31 Jan 2008 08:49:16 -0800 (PST)

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-masked]> wrote:
  Fred,

Regards,
Alex

> Fred Baker wrote:
> om/newsear

       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

---

From: Alex Conta <[email-masked]>
Date: Thu, 31 Jan 2008 12:50:27 -0500

There were additional secondary considerations. The IPv6 headers were
carefully crafter and compartmented, in terms of functionality. The main
header was carefully crafted not only to carry the very essential
information for delivering the packet to the next hop, but also in terms
of its size, and alignment of its fields. The alignment was a criterion
for faster processing - for instance, the IPv6 addresses, have 8 byte
alignment. Furthermore, the entire main header yields 8 byte alignment
to the next header.
 
Header integrity, which you refer to, seems to me of going beyond just
uncovering some hardware or software errors between the transmitting and
receiving of the IP header, which is the (only) object of the IPv4
checksum. In that regard, as its function is really one IP hop, it still
stands that an IPv6 checksum, if it existed, it would have only
duplicated the functions of the L2 checksum as far as the header is
concerned even in cases when the IP one hop corresponds to multiple L2
hops, Integrity, in terms of security, was considered part of the
functionality and job which was assigned to the IPsec headers.
 
Regards,
Alex

-----Original Message-----
From: Rahim Choudhary [mailto:[email-masked]] 
Sent: Thursday, January 31, 2008 11:49 AM
To: Alex Conta; 'Templin, Fred L'; 'Fred Baker'
Cc: [email-masked]
Subject: RE: Checksum in IPv6 header

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

Fred,

Regards,
Alex

om/newsear

  _____  

Never miss a thing. Make Yahoo
<http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs> your
homepage.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 31 Jan 2008 15:08:43 -0500

From: Alex Conta [mailto:[email-masked]] 
	Sent: Thursday, January 31, 2008 12:50 PM
	To: 'Rahim Choudhary'; Templin, Fred L; 'Fred Baker'
	Cc: [email-masked]
	Subject: RE: Checksum in IPv6 header

	There were additional secondary considerations. The IPv6 headers
were carefully crafter and compartmented, in terms of functionality. The
main header was carefully crafted not only to carry the very essential
information for delivering the packet to the next hop, but also in terms
of its size, and alignment of its fields. The alignment was a criterion
for faster processing - for instance, the IPv6 addresses, have 8 byte
alignment. Furthermore, the entire main header yields 8 byte alignment
to the next header.
	 
	Header integrity, which you refer to, seems to me of going
beyond just uncovering some hardware or software errors between the
transmitting and receiving of the IP header, which is the (only) object
of the IPv4 checksum. In that regard, as its function is really one IP
hop, it still stands that an IPv6 checksum, if it existed, it would have
only duplicated the functions of the L2 checksum as far as the header is
concerned even in cases when the IP one hop corresponds to multiple L2
hops, Integrity, in terms of security, was considered part of the
functionality and job which was assigned to the IPsec headers. 

I'm seeing a lot of good reason why the header checksum was dropped in
IPv6, but I'm not seeing the one perfectly valid reason why it would
have been good to retain it. I thought this was discussed on here very
recently.
 
The reason is IPsec tunnels, where encrypted packets are tunneled
through a non-secure IPv6 link. In such cases, you can't count on L2
checksums when going across the tunnel boundaries. Or did I miss part of
that recent thread?
 
Bert
 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 31 Jan 2008 16:59:52 -0800

Hi Fred,

For ESP (RFC4303) the ICV does not cover the outer IP header at all
the mutable field or not. For AH (RFC4302) however the outer IP header
is covered for the ICV calculation.

May be that is what Rahim meant. We can have the IP header fields that
are not covered by the ICV calculation and there may be no way of
verifying integrity of the header. I however do not think it is
required, because as mentioned earlier the probability of the error is
very less(the issues may still be caught at a higher layer), and it
does not justify the trade off to have a checksum.

Thanks,
Vishwas

On Jan 31, 2008 1:35 PM, Fred Baker <[email-masked]> wrote:
>
>
>
> On Jan 31, 2008, at 8:49 AM, Rahim Choudhary wrote:
> available, even with the use of IPSec because of the matter of the mutable
> fields.
> Mutable fields are mutable for a reason. We don't seem to be on the same
> page in that regard.