Re: I-D.ietf-v6ops-cpe-simple-security-09

[james woodyatt <[e-mail]>]

On Mar 21, 2010, at 15:14, Brian E Carpenter wrote:
> On 2010-03-22 10:28, Mark Townsley wrote:
>> 
>> Why not, if that is the current consensus? We've reversed the text of
>> IETF standards track documents before, much less Informational documents
>> that are not a standard of any kind.

The design team was directed by the chair to write a draft that detailed the recommendation in Section 4.2 of RFC 4864 for a stateful filter in residential IPv6 CPE routers, and we were not instructed that revisiting the recommendation with an eye toward reversing it was explicitly within our ambit.

> As a co-author of 4864, let me agree violently. It's not a BCP.
> Even if it was, consensus could reverse it.
> 
> What 4864 says is: NATs weren't designed as security devices but they
> provide simple security by blocking everything incoming by default.
> To implement simple security for v6 you should do it with a stateful
> firewall.

I would have expected an author of RFC 4864 to quote the following excerpt from Section 4.2 instead:

   To implement simple security for IPv6 in, for example, a DSL or cable
   modem-connected home network, the broadband gateway/router should be
   equipped with stateful firewall capabilities.  These should provide a
   default configuration where incoming traffic is limited to return
   traffic resulting from outgoing packets (sometimes known as
   reflective session state).  There should also be an easy interface
   that allows users to create inbound 'pinholes' for specific purposes
   such as online gaming.

That paragraph is the whole reason that I-D.ietf-v6ops-cpe-simple-security exists today.  Note the use of the word "should" in the verb phrase of the second sentence.  It sure looks to me like it makes a value judgment that IPv6 Simple Security in unmanaged home routers is considered helpful.

When I first read Section 4.2 of the Internet Draft that would become RFC 4864, just a little over three years ago, I sent <http://ops.ietf.org/lists/v6ops/v6ops.2007/msg00055.html> to the V6OPS list to surface what I thought, at the time, was an oversight.  Note that I was objecting to the use of the word "should" in that paragraph.  I thought RFC 4864 should not be making such a recommendation, and I believed that the authors must have been mistaken to include it in an Informational category document.

Alas, I later learned that this recommendation was quite deliberate and *NOT* open for discussion anymore.  I withdrew my objection soon thereafter, after one of the authors expressed "violent" disagreement with me, because I came to believe my personal misgivings about this recommendation weren't shared by the majority of IETF participants.  I still think only a small minority of participants agrees with me.

> It doesn't say that CPEs MUST do this. It leaves that choice open, as an informational document.

No, it doesn't say that CPE routers MUST do this, but it does go out of its way to say that CPE routers "should" do this.

More importantly, other specifications which reference RFC 4864 as if it's morally equivalent to a proposed standard *do* say that CPE routers MUST do this.  While categorized as Informational, the language in I-D.ietf-v6ops-cpe-simple-security is deliberately crafted to be easily cited by other SDO's in requirement specifications, which are expecting to describe not just the CPE routers MUST do this, but HOW they will do this.  I am aware of at least two other SDO's that are preparing exactly that.

So, while it's true that neither RFC 4864 nor I-D.ietf-v6ops-cpe-simple-security say that CPE routers MUST implement a "default deny" stateful filtering regime, the common law is congealing around this as a requirement as we speak.  So, despite the fact that this draft is Informational and not BCP or Proposed Standard, what we say in this document should it be published in the RFC series is very likely to become the Law of the Internet pretty much overnight, and I think that pretending otherwise would be awfully naïve.


--
james woodyatt <[e-mail]>
member of technical staff, communications engineering