Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
draft-ietf-v6ops-cpe-simple-security-16

[Ballot discuss]
Section 3.3.4 is not entirely correct on claiming that Shim6 is not
applicable. Of course, it is true that a single-homed home network does
not need Shim6 for itself. However, it is possible that the other end
does. Hence, I believe it would be proper to allow Shim6 headers.

Also, the only mention of new protocols and unrecognized protocols and what to do with them is here:

  Conversely, simple Internet gateways are not expected to prohibit the
  development of new applications.  In particular, packets with end-to-
  end network security and routing extension headers for mobility are
  expected to pass Internet gateways freely.

In other words, if you package your traffic in IPsec (or Mobile IPv6) it will work, otherwise not. I think the document should be more explicit about this limitation, and that new extension headers, new transport protocols, etc. would not work through the simple gateway. I would suggest that the document say something about recommending automatic software updates for any device that supports this type of a functionality so that newly allocated protocol numbers could become supported in an easy manner.

[Ballot discuss]
Section 3.3.4 is not entirely correct on claiming that Shim6 is not
applicable. Of course, it is true that a single-homed home network does
not need Shim6 for itself. However, it is possible that the other end
does. Hence, I believe it would be proper to allow Shim6 headers.

Jari

[Ballot comment]
Two comments:

(1) REC-25 seems out of place.  REC-25 specifies default mode for  handling Host Identity Protocol (hip) packets,
but is in section 3.2.4 "IPsec and Internet Key Exchange (IKE)".

(2) Shouldn't REC-21 cover WESP packets as well as ESP packets?  It would seem the same rules would apply.

[Ballot comment]
Section 3.1:

  REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
  exterior interfaces MUST NOT be processed by any integrated DHCPv6
  server.

Did you consider processing by an integrated DHCPv6 relay agent?  I would
suggest "server and/or relay agent".

[Ballot comment]
Section 3.1:

  REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
  exterior interfaces MUST NOT be processed by any integrated DHCPv6
  server.

Did you consider processing by an integrated DHCPv6 relay agent?  I would suggest "server and/or relay agent".

> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

The document shepherd is Fred Baker. Yes, I believe that it is ready for IESG consideration.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

This document has experienced extensive review and discussion.

> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?

I could imagine a review from the Security Directorate...

The one recommendation that is unusual among IPv4 stateful firewalls is that be default sessions secured by IPsec are passed without notice. This appears benign on the surface, as IPsec provides its own security. That said, in view of port-agile attacks and applications, this seems to me to be a potential attack vector, as consenting applications could use it to bypass the firewall. This was discussed in the working group and the working group considered it an acceptable risk.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document, or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.

I don't have any areas of discomfort on a procedural basis.

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

The working group has been very divided on the document - not because of its specific recommendations, but because of its general concept. It describes a stateful firewall, and some in the IPv6 community are very much opposed to anything resembling a firewall (or a NAT), believing it to be an impediment to the deployment of an end to end IPv6 network. I note that the document came into existence primarily because the author's company discovered the hard way that the existence of firewalls as a product if not a deployment fact is an absolute business requirement, regardless of the political opinions the author or anyone else might have.

As such, the document represents the intersection of the opinions of those who support definition and deployment of firewalls and those who do not, after those who would filibuster the concept have been ruled out of order.

> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No. However, an alternative draft has been proposed, draft-vyncke-advanced-ipv6-security. The authors of that draft have been invited to progress the draft in the working group as they fill out the concept.

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See the
> Internet-Drafts Checklist
>
> and
> http://tools.ietf.org/tools/idnits/
> ). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?

Yes.

> (1.h) Has the document split its references into normative and
> informative?

Yes

> Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

This draft is informational, and its normative references are all RFCs.

> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document?

The document correctly states that it makes no request of IANA.

> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

No such sections exist.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up? Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:
>
> Technical Summary

This document identifies a set of recommendations for the makers of
devices describing how to provide for "simple security" capabilities
at the perimeter of local-area IPv6 networks in Internet-enabled
homes and small offices.

> Working Group Summary

The working group was divided on the concept of defining or recommending the use of firewalls; as a result, this document is very explicitly a set of recommendations for those that would choose to build or deploy a firewall without making any recommendation on whether anyone should do either. It describes a simple stateful firewall, permeable to traffic that is secured using IPsec.

> Document Quality

There is at least one deployed implementation of this firewall, and expected to be others. The document clearly specifies a consensus set of recommendations for such firewalls.