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 PROTECTED]> 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@ietf.org
Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
