Le 2012-04-11 à 15:44, Maoke a écrit : > > postpone other parts, but focus on the checksum issue. > 2012/4/11 Rémi Després [email protected] > > 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4 > message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But this > integrity can be ensured at tunnel exit by checking that CNPs do preserve > checksum neutrality. This can be clarified by a complement in the 4rd-u > security section. > > > 1. this introduces another new semantics/logic of protocol stack processing > at exit CE. it is really hard to call it either IPv4 or IPv6.
How it is called is IMHO secondary, what is a fact is that it ensures address security. > 2. even though this CNP works for the address integrity, (which was the listed point) > unfortunately, however, the checksum still provides integrity protection for > packet length and payload protocol type in both IPv4/ICMPv4 pair and > IPv6/ICMPv6 pair. they are involved either in IPv4 header checksum or in > ICMPv6 checksum, which covers the pseudo-header of IPv6. > how could CNP protect these? No way, of course. (Are we now in the technical discussion, or still in deliberate controversy?). > thanks for mentioning CNP here. > i need to modify the concern for "address integrity" to the concern for > "integrity of addresses, packet length and payload protocol type". - Addresses have been covered AFAIAC. - No test scenario I can imagine can reveal an ICMPv4 security problem concerning protocol type or packet length. (A simulated hardware failure would AFAIK be needed, and with that, many other security problems can be considered to exist.) => Unless you come up with new facts, end of this subject for me. RD > > - maoke
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
