Last Call Review of draft-ietf-behave-address-format-
review-ietf-behave-address-format-secdir-lc-kaufman-2010-06-20-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 discusses formats and algorithms around dealing with the
translation of IPv4 addresses to IPv6 addresses and vice versa. Such
translation is necessary when two endpoints and the network between them do not
all support a single version of IP.

I found the document quite comprehensible, its decisions well considered, and I
have only minor comments.

Security Related:

Section 5 discusses two threats related to routers that handle IPv6 addresses
that embed IPv4 addresses. I believe an important third attack in the same
category is where firewalls filter traffic based on IPv4 addresses. In all such
scenarios, admins should assure that packets that embed those IPv4 addresses
inside IPv6 addresses perform the same filtering on the IPv6 addresses.
Otherwise, lots of traffic that was previously blocked might be able to pass
through the firewalls disguised as IPv6 packets.

Section 3.1 says that the Well-Known Prefix MUST NOT be used to represent non
global IPv4 addresses, such as those defined in [RFC1918]. First, especially
given that this is a MUST, there should be an explicit list of forbidden IPv4
addresses rather than a vague reference to RFC1918. Second, the text should
probably explicitly say that any translator that extracts an IPv4 address from
an IPv6 address MUST check the IPv4 address against the forbidden list and drop
the packet if it has such a forbidden address. Otherwise, the text could be
interpreted as only forbidding encapsulation. In most attacks, the attacker
does the encapsulation and the good guy does the decapsulation, so forbidding
encapsulation doesn't help.

The last sentence of section 2.2 says "These bits are reserved for future
extensions and SHOULD be set to zero." In any spec where it says that some bits
SHOULD or MUST be set to zero, there should be corresponding text saying what
an implementation SHOULD or MUST do if it receives data containing non-zero
values. In this case, I couldn't tell whether the intended action was to ignore
the non-zero bits or to drop the packet. The bits will be much more useful for
future uses if we have confidence about how existing implementations handle
them.

Typos:

P5 middle: "prefic" -> "prefix"
P9 middle: "return them message in" -> "return them in"