Early Review of draft-ietf-v6ops-balanced-ipv6-security-00
review-ietf-v6ops-balanced-ipv6-security-00-secdir-early-hoffman-2013-11-28-00

Greetings. The v6ops chairs apparently asked for an early (pre-IETF-LC) review
of draft-ietf-v6ops-balanced-ipv6-security, "Balanced Security for IPv6
Residential CPE" which is in WG LC. In short: from a security standpoint, the
document seems fine if you are of the same point of view as the authors, and
terrible if you are not. Neither point of view is better than the other, so
this review will probably not make anyone happy.

The topic of the document is what the initial firewall configuration for an
IPv6 residential gateway should be. It is based on actual deployment
experiences from an ISP. The view of the authors of the document is,
approximately, "IPv6 lets us re-enable the end-to-end principle, so make that
the default for home gateways, modulo closing a couple of long-standing
vulnerabilities". The opposing camp is "end hosts in the home often have
terrible security, so you need to prevent initial contact from the Internet",
with a subset of that group saying "but let those hosts do PCP to open holes".
The IPv6 aspect of the argument seems to be mostly lost in the noise of the WG
LC comments, even though it is the lead for the draft itself.

Calling this draft "Balanced" is kind of like titling a security protocol with
"Simple" (something that I am guilty of...). Please consider changing the title
to something more representative of the discussion, such as "Permissive" or
"Open".

From a security standpoint, the document seems self-consistent in its stance
(and certainly more than RFC 6092 was). The list of threats in section 2 has a
few problems, however:

- Most of the bullet points are about incoming threats, but then the last
bullet talks about an outgoing threat, and not very well at that. Either the
list should be broken into two and my more outgoing threats listed, or the last
bullet should be removed.

- The list doesn't include denial of service from the outside that exhausts
stateful tables in the CPE itself. Give that what is being described is
small-footprint firewalls, this seems like a great attack that could cause some
interesting failure modes.

- The example of vulnerable hosts being "old versions of Windows" is out of
place. New versions of all operating systems that live in the home, and even
the CPE itself, are often vulnerable.

Given the large amount of discussion from the "closed, open it with PCP" folks,
it is odd that PCP isn't mentioned at all in Section 3, even for the services
that are initially blocked such as HTTP. Given the number of HTTP-based devices
out there that someone might want to control from outside the home, this seems
like a major oversight.

The AllowManagement rule in Section 3.1 mentions Broadband Forum TR-69 as if it
is done either at layer 2 or using some non-IP protocol at layer 3. This should
be described in a bit more detail, and that should be an informative reference.

The paragraph after Table 2 makes it seem like doing firmware updates and
policy updates to a CPE are equivalent. From a security standpoint, that's a
terrible comparison. Updating firmware can introduce many more security issues
than updating a policy table. Please consider removing the firmware option.

The last paragraph of Section 3.2 has sexist bullshit in it. I guess I should
give you points for not making it racist too, but still.

--Paul Hoffman