Last Call Review of draft-ietf-behave-v6v4-xlate-
review-ietf-behave-v6v4-xlate-secdir-lc-kivinen-2010-06-11-00

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document describes the translation algorithm between ipv6 and
ipv4. The security considerations section say:

   The use of stateless IP/ICMP translators does not introduce any new
   security issues beyond the security issues that are already present
   in the IPv4 and IPv6 protocols and in the routing protocols that are
   used to make the packets reach the translator.

   There are potential issues that might arise by deriving an IPv4
   address from an IPv6 address - particularly addresses like broadcast
   or loopback addresses and the non IPv4-translatable IPv6 addresses,
   etc.  The [I-D.ietf-behave-address-format] addresses these issues.

This text is fine but the next paragraph describing the AH is bit
misleading:

   As the Authentication Header [RFC4302] is specified to include the
   IPv4 Identification field and the translating function is not able to
   always preserve the Identification field, it is not possible for an
   IPv6 endpoint to verify the AH on received packets that have been
   translated from IPv4 packets.  Thus AH does not work through a
   translator.

The Authentication Header includes also the addresses etc in the ICV
thus it is not only the IPv4 Identification field that causes problems
also the changing the IPv4 address to IPv6 addresses and vice versa,
changing the IP version field, payload length etc makes AH
incompatible with this translation.

If the text was supposed to say that some implementation which knows
both AH and this translation could be made to know that this packet
has gone through this translation and could then check the ICV by
reversing the translation before checking the ICV, then this text
should more clearly say that.

I.e instead of saying that endpoing cannot verify AH and that AH does
not work (standard AH as defined in RFC4302 will always fail the
verification), it should be said that it is not possible to make
specification which specifies how AH should be modified to understand
this translation and even then it would be impossible to completely
reverse translation as some information (like parts of the
Identification field) is not available. I also think that in addition
to the Identification field the translation is loosing information
about the IP extensions.

The last paragraph of security considerations section talks about ESP:

   Packets with ESP can be translated since ESP does not depend on
   header fields prior to the ESP header.  Note that ESP transport mode
   is easier to handle than ESP tunnel mode; in order to use ESP tunnel
   mode, the IPv6 node MUST be able to generate an inner IPv4 header
   when transmitting packets and remove such an IPv4 header when
   receiving packets.

Even with ESP there is complications, as in transport mode the
transport layer protocols inside the ESP do contain checksums which
cannot be modified by the translator, thus they will keep the original
IP addresses in there, and if the translation is not checksum neutral
then end node will throw away the packet after ESP processing as the
transport layer checksums are incorrect.

For tunnel mode the transport layer protocol checksums contains the
inner IP header thus they are ok.

Actually for ESP the situation is even more different, as the IPsec
will detect this kind of translation as NAT along the path, and will
enable NAT-Traversal, meaning ESP packets will get UDP encapsulated,
and the IPsec itself will do the checksum fixup as specified in the
RFC3847.

On the other hand I do not know how many existing implementations know
how to handle checksum fixup when changing from IPv4 address to IPv6
address or other way around, altough some of them do full checksum
recalculation (or simply skip the transport layer checksum checking)
anyways so they might work.
-- 
kivinen at iki.fi