Subject: [v6ops] SecDir and WG LC review of draft-ietf-v6ops-balanced-ipv6-security

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Nov 2013 18:09:51 -0800

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