Subject: Re: Checksum in IPv6 header

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 1 Feb 2008 10:02:52 +0100

On 1 feb 2008, at 1:59, Vishwas Manral wrote:

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

Yes. So if you want to cryptographically protect your header, either  
use AH or put the packet into another packet and protect the original  
packet with ESP.

A header checksum will give you none of this because the checksum  
algorithm used in IP is so simple I can calculate it in my head (just  
16-bit additions over data that's in the packet).

Note also that all the important fields in the IP header are included  
in the transport layer checksum, which also makes it unnecessary to do  
a separate header checksum to protect these fields against bit errors.

Last but not least, if an attacker can toggle bits in your header, it  
really doesn't matter whether you have cryptographically strong means  
to detect this, because what you would be doing is dropping the  
packet, while any of this toggling would also result in dropping the  
packet at some point, all else being equal. (The attacker could also  
toggle bits in the data part of the packet so the receiver would  
accept bad data, but IPsec AH/ESP or even TLS all provide protection  
against that regardless of header checksums.)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Rahim Choudhary <[email-masked]>
Date: Fri, 1 Feb 2008 07:12:39 -0800 (PST)

Yes I meant it in the sense Wishwas explained it. And I also meant it in the sense of someone maliciously toggling bits. Let me say a word about the latter.
   
  Assuming that layer 2 CRC will be kosher after the bits have been maliciously toggled in the mutable fields of the front IPv6 header. This could happen because the bits were toggled leaving the CRC intact or they were toggled and the CRC was also recalculated.
   
  Now if the change is in the muteable fields (DSCP, TTL) then no IPSec measure seems to be able to detect that. This could be a vulnerability that either causes the packets to drop on the way (TTL manipulation) or assigns them to the wrong class (DSCP manipulation).
   
  Moreover as Wishwas pointed out, if only ESP is used without AH (and the support for AH is now not a MUST but a MAY) then we have a bigger problem. Now the front IPv6 header is entirely unprotected including the to and from addresses (Iljitsch please note that no matter how many encapsulations are made, there will always be a first header). The packets can end up at unintended destinations. This is serious from security point of view.
   
  And if IPSec is not used then there is a whole new swing of security issues. 
   
  Admittedly all these are also possible for IPv4. The point is that IPv6 did not use an opportunity to fix any of this. And ironically the popular perception is that IPv6 is more secure than IPv4. 

Iljitsch van Beijnum <[email-masked]> wrote:

       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 1 Feb 2008 16:19:08 +0100

On 1 feb 2008, at 16:12, Rahim Choudhary wrote:

> Now if the change is in the muteable fields (DSCP, TTL) then no  
> IPSec measure seems to be able to detect that. This could be a  
> vulnerability that either causes the packets to drop on the way (TTL  
> manipulation) or assigns them to the wrong class (DSCP manipulation).

Who cares?

If an attacker can flip your bits she can also flip the most  
significant bit in the destination address and you'll never receive  
that packet. The only thing a cryptographic hash over the header would  
give you there is the ability to drop the packet even sooner.

And how exactly are you going to have a HMAC or some such over header  
fields? That requires having secret keying material in EVERY ROUTER  
ALONG THE PATH.

Can we please stop this discussion?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 1 Feb 2008 07:28:22 -0800

Hi Iljitsh,

You have a point when you say that if a malicious router could toggle
some bits, it could as well drop the packet.

However there is one small part you miss. In the above case the router
can only affect traffic going through it. It could be an attack if
toggling bits on the flows through a router, the router could actually
affect flows not going through the router. However if it could bump up
the priority(in the simplest terms) of the packets going through it,
it could affect the flows of packets on other routers, as the packets
needing the highest priority would considerably increase. Its an issue
but a slightly of a lesser priority.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 1 Feb 2008 08:20:13 -0800

Hi Iljitsch,

I agree with you. However if you take note of RFC4301 - the IPsec base
RFC, the AH has been downgraded to a MAY support. So not all machines
will support AH. I agree we can do without checksum, am just trying to
fill in when I feel there is some additional information that
discussion could gain from.

Thanks,
Vishwas

---

From: Rahim Choudhary <[email-masked]>
Date: Fri, 1 Feb 2008 08:49:04 -0800 (PST)

Another point to note is this. In the case that a packet checksum/hash is used, a corrupted packet gets dropped on its way, whereas without such a checksum/hash it is dropped at the destination. Thus additional network resources are consumed. All this is assuming that layer 2 CRC has been circumvented.

Vishwas Manral <[email-masked]> wrote:
  Hi Iljitsch,

Thanks,
Vishwas

       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

---

From: Antonio Querubin <[email-masked]>
Date: Sat, 2 Feb 2008 10:39:40 -1000 (HST)

On Fri, 1 Feb 2008, Rahim Choudhary wrote:

> Another point to note is this. In the case that a packet checksum/hash 
> is used, a corrupted packet gets dropped on its way, whereas without 
> such a checksum/hash it is dropped at the destination. Thus additional 
> network resources are consumed. All this is assuming that layer 2 CRC 
> has been circumvented.

Router CPU is also a network resource and would be consumed if checksum 
was required - adding to overall latency, possibly additional hardware 
costs...

Antonio Querubin
whois:  AQ7-ARIN

---

From: Fred Baker <[email-masked]>
Date: Sun, 3 Feb 2008 01:31:06 +0200

in the big scheme of things, a checksum is peanuts compared to the  
other things a router does. People have decided to not check it and  
cited this as an argument. In our experience tweaks like this makes  
almost no difference whatsoever, and are often an indicator of the  
quality of the rest of the thing you're buying.

On Feb 2, 2008, at 10:39 PM, Antonio Querubin wrote:

>> Another point to note is this. In the case that a packet checksum/ 
>> hash is used, a corrupted packet gets dropped on its way, whereas  
>> without such a checksum/hash it is dropped at the destination.  
>> Thus additional network resources are consumed. All this is  
>> assuming that layer 2 CRC has been circumvented.
>
> Router CPU is also a network resource and would be consumed if  
> checksum was required - adding to overall latency, possibly  
> additional hardware costs...
>
>
> Antonio Querubin
> whois:  AQ7- 
> ARIN------------------------------------------------------------------ 
> --

---

From: Mark Smith <[email-masked]>
Date: Mon, 4 Feb 2008 08:17:16 +1030

On Sat, 2 Feb 2008 10:39:40 -1000 (HST)

> was required - adding to overall latency, possibly additional hardware 

And route aggregation is probably more of a cause of packet
non-delivery than checksums failing.

Regards,
Mark.