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

Mark Townsley <townsley@cisco.com> Mon, 22 March 2010 08:00 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF60028C0E5 for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 22 Mar 2010 01:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.594
X-Spam-Level:
X-Spam-Status: No, score=-7.594 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsP39PIxzq2q for <ietfarch-v6ops-archive@core3.amsl.com>; Mon, 22 Mar 2010 01:00:19 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A064328C0CE for <v6ops-archive@lists.ietf.org>; Mon, 22 Mar 2010 01:00:19 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1NtcWf-0001ni-5H for v6ops-data0@psg.com; Mon, 22 Mar 2010 07:58:17 +0000
Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from <townsley@cisco.com>) id 1NtcWZ-0001mv-MW for v6ops@ops.ietf.org; Mon, 22 Mar 2010 07:58:11 +0000
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKq/pkurR7Hu/2dsb2JhbACDCZgic6ECiDGPPYEsgmdqBA
X-IronPort-AV: E=Sophos;i="4.51,286,1267401600"; d="scan'208";a="170113483"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2010 07:58:11 +0000
Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2M7wBt0029158; Mon, 22 Mar 2010 07:58:11 GMT
Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2M7w9Y27441; Mon, 22 Mar 2010 00:58:09 -0700 (PDT)
Message-ID: <4BA7230E.6020505@cisco.com>
Date: Mon, 22 Mar 2010 08:58:06 +0100
From: Mark Townsley <townsley@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: james woodyatt <jhw@apple.com>, Gert Doering <gert@space.net>, IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09
References: <D6F5ACD2-EB43-477E-9F48-AC3EDB3F7EB4@apple.com> <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com> <4BA40DD1.7080306@gmail.com> <6C168711-6A34-4487-9911-92766513183C@apple.com> <4BA522E8.7050504@cisco.com> <4BA56626.20606@gmail.com> <20100321133831.GL69383@Space.Net> <4BA6575D.7070300@gmail.com> <4BA670ED.1020302@cisco.com> <D69F1DE6-D24D-45AA-95D0-99B63E62A1EE@apple.com> <4BA68F61.7020005@cisco.com> <4BA69A3D.7@gmail.com>
In-Reply-To: <4BA69A3D.7@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 3/21/10 11:14 PM, Brian E Carpenter wrote:
>
> 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.
>    
Right, NAPTs were invented primarily for address amplification, but also 
brought simple security and address independence.

Address amplification is something that IPv6 currently does not need, 
and address independence is something that would be quite useful but we 
haven't been able to design and deploy it without breaking end-to-end.

The firewall function in simple-security explicitly damages end-to-end. 
If we go this route, we might as well toss in NAT too as we will have 
already paid the price in terms of end-to-end transparency; We might as 
well get the address independence benefit along with it.

I suspect this will be used as an argument in the future if stateful 
firewall operations become ubiquitous in CPEs: How is NAT *that much* 
worse than the firewall you already have?

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

>      Brian
>
>