Subject: [v6ops] Document Action: 'Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service' to Informational RFC

From: The IESG <[email-masked]>
Date: Fri, 22 Oct 2010 06:54:09 -0700 (PDT)

The IESG has approved the following document:

- 'Recommended Simple Security Capabilities in Customer Premises 
   Equipment for Providing Residential IPv6 Internet Service '
   <draft-ietf-v6ops-cpe-simple-security-16.txt> as an Informational RFC

This document is the product of the IPv6 Operations Working Group. 

The IESG contact persons are Ron Bonica and Dan Romascanu.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security-16.txt

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.

Personel

Fred Baker is shepherd.

RFC Editor Note

OLD TEXT:

REC-13: 

By DEFAULT, Internet gateways SHOULD, automatically download
and install software updates for extending IPv6 simple security for
support of future standard upper layer transports and extension
headers.

NEW TEXT:

REC-13:
Residential Internet Gateways SHOULD provide a convenient means to 
securely update their firmware, for the installation of security 
patches and other manufacturer-recommended changes.
 
Vendors can expect users and operators to have differing viewpoints 
on the maintenance of patches, with some preferring automated update 
and some preferring manual initiation, and those preferring automated 
update wanting to download from a vendor site or one managed by the 
network operator. To handle the disparity, vendors are well advised 
if they provide manual and automated options. In the automated case, 
they would do well to facilitate pre-configuration of the download 
URL and a means of validating the software image such as a certificate.

---

From: Mark Smith <[email-masked]>
Date: Sat, 23 Oct 2010 03:41:07 +1030

On Fri, 22 Oct 2010 06:54:09 -0700 (PDT)

>    <draft-ietf-v6ops-cpe-simple-security-16.txt> as an Informational RFC

Well done everybody, especially James. I think I've read somewhere that
the DHCPv6 spec had set a record at 15 revisions ... it's just been
beaten :-)

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Oct 2010 15:28:13 -0400

With a little research - regrettably, we didn't record the actual rev number in RFC 3315 - the highest numbered rev of the DHCPv6 spec I could find was draft-ietf-dhc-dhcpv6-28.

From the Acknowledgments in RFC 3315:

   And, thanks to Steve Deering for pointing out at IETF 51 in London
   that the DHCPv6 specification has the highest revision number of any
   Internet Draft.

In any event, that record has been significantly exceeded by more recent drafts: draft-hixie-thewebsocketprotocol-77.txt 

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 22 Oct 2010 14:38:23 -0500

Just so the record is correct, technically they only got to 76:

http://www.ietf.org/id/draft-hixie-thewebsocketprotocol-77.txt:

---
This Internet-Draft, draft-hixie-thewebsocketprotocol-76.txt, has been
replaced by another
document, draft-ietf-hybi-thewebsocketprotocol-01.txt, and has been
deleted from the 
Internet-Drafts directory.

Internet-Drafts are not archival documents, and copies of
Internet-Drafts
that have been deleted from the directory are not available.  The
Secretariat does not have any information regarding the future plans of
the author(s) or working group, if applicable, with respect to this
deleted Internet-Draft.  For more information, or to request a copy of
the document, please contact the author(s) directly. 

Draft Author(s):

 I. Hickson <[email-masked]>
---

Kind of sad they didn't keep going, but 76 is a going to be a tough
record to beat -- I would have long given up?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms (rdroms)
Sent: Friday, October 22, 2010 3:28 PM
To: Mark Smith
Cc: v6ops mailing list
Subject: Re: [v6ops] Document Action: 'Recommended Simple
SecurityCapabilities in Customer Premises Equipment for
ProvidingResidential IPv6 Internet Service' to Informational RFC

With a little research - regrettably, we didn't record the actual rev
number in RFC 3315 - the highest numbered rev of the DHCPv6 spec I could
find was draft-ietf-dhc-dhcpv6-28.

In any event, that record has been significantly exceeded by more recent
drafts: draft-hixie-thewebsocketprotocol-77.txt 

- Ralph

>> A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-cpe-simple-security
-16.txt

---

From: Mark Smith <[email-masked]>
Date: Sun, 24 Oct 2010 01:55:52 +1030

On Fri, 22 Oct 2010 14:38:23 -0500

> record to beat -- I would have long given up?

I've read in Radia Perlman's book that one of the ATM AAL standards was
published unimplementable, just so that they could cross off the
"published standard" check box. The IETF is obviously far more
pragmatic than that, however it'd be possibly useful to have a status
of "unRFC", to capture a historical representation of the effort people
put into it even if it didn't eventuate as an RFC :-) I think there is
quite commonly just as much value in knowing about what doesn't
work as there is in knowing what does.

Regards,
Mark.