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

[Mark Townsley <[e-mail]>]

James, if anyone who suggested to you that RFC 4864 or any Informational 
document represented the consensus of the IETF, you were sadly misled. 
However, if it is true what you say that, "this document should it be 
published in the RFC series is very likely to become the Law of the 
Internet pretty much overnight" then we better be sure we have consensus 
on what it says.

I do not want to see the IETF recommending a default-deny rule on IPv6 
residential gateways, and I regret that RFC 4864 has been interpreted as 
recommending this with any authority in the past. I've offered one 
admittedly imperfect compromise, but I find it better than wishing for a 
pin-hole protocol that doesn't exist and may never in a ubiquitous and 
interoperable manner. Even if such a protocol did exist, there are very 
legitimate security concerns about the effectiveness of operating what 
is essentially a distributed IP-stack between the host and RG vs. using 
a local firewall on the host. These have been brought up, but not fully 
discussed in this document or on the list.

Bottom line: I think that the IETF should not publish any documents 
implying a default-deny rule as a recommended practice and default 
setting for IPv6 residential gateways. I think it is fine to describe 
how this should work should it be turned on, and that a configuration 
knob MUST exist, but the default should be set in a way that ensures it 
is "beneficial" and "not harmful to the Internet as a whole" (RFC 3935, 
BCP 95).

The market always makes the final decision, and if it decides that 
customers want, or vendors want to sell, equipment with a default 
setting that breaks end-to-end transparency, there is no stopping this 
from happening. But, the IETF doesn't have to help it happen. I think 
the simple-security document, as a whole, doesn't risk being ignored if 
it leans a bit toward favoring IPv6 end-to-end transparency vs. IPv4 
status quo in this one case.

- Mark


On 3/22/10 6:19 AM, james woodyatt wrote:
> 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
>
>
>
>
>