Re: Checksum in IPv6 header
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Checksum in IPv6 header



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 <iljitsch at muada.com> wrote:
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.)


Looking for last minute shopping deals? Find them fast with Yahoo! Search.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.