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

james woodyatt <jhw@apple.com> Sun, 21 March 2010 06:03 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 D7E263A6838 for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 20 Mar 2010 23:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.134
X-Spam-Level:
X-Spam-Status: No, score=-103.134 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 hqGYuy426ib1 for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 20 Mar 2010 23:03:09 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AFFA3A68B8 for <v6ops-archive@lists.ietf.org>; Sat, 20 Mar 2010 23:03:08 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1NtEDW-000AZu-8I for v6ops-data0@psg.com; Sun, 21 Mar 2010 06:00:54 +0000
Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <jhw@apple.com>) id 1NtEDK-000AYN-PL for v6ops@ops.ietf.org; Sun, 21 Mar 2010 06:00:43 +0000
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 12DE591697DA for <v6ops@ops.ietf.org>; Sat, 20 Mar 2010 23:00:42 -0700 (PDT)
X-AuditID: 11807137-b7c50ae0000001dd-18-4ba5b60907d7
Received: from [17.151.110.46] (Unknown_Domain [17.151.110.46]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id C4.B9.00477.906B5AB4; Sat, 20 Mar 2010 23:00:42 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09
From: james woodyatt <jhw@apple.com>
In-Reply-To: <20100321113037.13756c12@opy.nosense.org>
Date: Sat, 20 Mar 2010 23:00:40 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E8126B81-8893-4BE4-85AF-AA51EC7A4101@apple.com>
References: <D6F5ACD2-EB43-477E-9F48-AC3EDB3F7EB4@apple.com> <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <D6BE2A3C-57BD-486D-B9C6-382B42FA4A67@cisco.com> <4BA55147.601@cisco.com> <F0FDFF3D-F703-422A-9443-D6F723FB034C@cisco.com> <20100321113037.13756c12@opy.nosense.org>
To: IPv6 Operations <v6ops@ops.ietf.org>
X-Mailer: Apple Mail (2.1078)
X-Brightmail-Tracker: AAAAAQAAAZE=
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Mar 20, 2010, at 18:00, Mark Smith wrote:
> 
> One thing that does seem to be missing from the draft is a specific list of threats it is attempting to mitigate i.e. a threat model.

RFC 4864 doesn't offer one, and its authors haven't offered much in the way of specifics to the discussion here or on the design team list.  Perhaps, you'd like to offer a contribution?

The Overview contains my best attempt at explaining what considerations I think are really in play behind the CPE Simple Security recommendation.  Here's what I think is the most relevant excerpt:

>> The stateful packet filtering behavior of NAT set user expectations that persist today with residential IPv6 service.  "Local Network Protection for IPv6" [RFC4864] recommends applying stateful packet filtering at residential IPv6 gateways that conforms to the user expectations already in place.

In other words, we recommend filtering at the middlebox-- making IPv6 routers do filtering like IPv4/NAT gateways do-- because "defense in depth" is a virtue in and of itself, and that Internet users have come to expect it.  Apparently, there's a consensus in IETF that this is enough reason to do it, and I strongly suspect that an explicit threat model might be inviting more controversy than anyone wants to endure.


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering