Re: [v6ops] Thoughts about wider operational input

Joe Maimon <jmaimon@jmaimon.com> Wed, 30 March 2022 22:07 UTC

Return-Path: <jmaimon@jmaimon.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B39A3A1091; Wed, 30 Mar 2022 15:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE2GPmRpjI5p; Wed, 30 Mar 2022 15:07:23 -0700 (PDT)
Received: from smtp.chl.com (smtp.ttec.chl.com [216.222.148.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC9A3A0F00; Wed, 30 Mar 2022 15:07:22 -0700 (PDT)
Received: from [216.222.150.100] (joe.ttec.chl.com [216.222.150.100]) by smtp.chl.com (8.13.6/8.13.6) with ESMTP id 22UM7LRl028100; Wed, 30 Mar 2022 17:07:21 -0500
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, v6ops list <v6ops@ietf.org>
References: <52661a3d-75dc-111a-3f23-09b10d7cb8d4@gmail.com> <A72CDDDB-CDCE-4EAF-B95E-997C764DB2C4@gmail.com> <9175dc32-45c1-e948-c20a-3bcc958b77b9@gmail.com> <YjmJQMNgnJoSInUw@Space.Net> <D75EF08F-6A41-41B2-AFB2-649CBCC1D83E@consulintel.es> <CAPt1N1nRnYUFA=yyJHx6t52yqWbmcd2Tf1H8gQuCZBd3Q3VqJw@mail.gmail.com> <7F4AEB43-4B24-4A21-AE9D-3EB512B98C46@consulintel.es> <8fac4314b8244ba6b33eea68694296d0@huawei.com> <9A13E47B-75D0-443F-9EE9-D2917ACB2D0F@consulintel.es> <CAO42Z2xUG+BXj+VQpajed9aGjH+q-HR7RX7C-T4DsTbouz7xWQ@mail.gmail.com> <F6A90BBF-7F44-403E-960A-8F756353B562@chinatelecom.cn> <B49417F7-3EFB-4A4D-9D1A-0D21574EA4F2@consulintel.es> <44B01ACA-3D5C-4618-B608-3B3479D29875@consulintel.es> <62447DCB.1010206@jmaimon.com> <7228D9A7-54A8-4BAE-9299-204C049F600B@consulintel.es> <6244BA91.3060306@jmaimon.com> <41f99f66-5a15-add5-5679-8860ec962e7c@gmail.com>
From: Joe Maimon <jmaimon@jmaimon.com>
Message-ID: <6244D497.7060604@jmaimon.com>
Date: Wed, 30 Mar 2022 18:07:19 -0400
User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40
MIME-Version: 1.0
In-Reply-To: <41f99f66-5a15-add5-5679-8860ec962e7c@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jGh7-JIZkzQIZi0bOlAudqQgTSw>
Subject: Re: [v6ops] Thoughts about wider operational input
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2022 22:07:27 -0000


Brian E Carpenter wrote:
> On 31-Mar-22 09:16, Joe Maimon wrote:
> ...
>
>> At least with the existence of NAT there also exists some level of state
>> management and unsolicited incoming traffic constraints from reaching
>> the internal network nodes. By default, by dint of them being
>> operationally on the internet.
>
> As I just noted, the same is true with IPv6-capable domestic CEs in the
> complete absence of NAT66 or NPTv6. By default. Why can that not be true
> for enterprise CEs?
>
>     Brian
>

I thought you were expressing some sarcasm. The same is completely 
untrue of IPv6 CPE.

Of course we fully expect (and hope for) CPE to incorporate a properly 
functioning firewall, IPv4 and IPv6, whether for end users or 
enterprises. And we want it to have secure defaults.

The problem is that in IPv6, any and all security functionality is 
orthogonal to the primary purpose of the CPE, which is to pass packets 
so the user gets to use the internet.

Enterprises are with near complete certainty going to need extensive 
management and featuresets on that firewall. Their requirements from a 
firewall go far far beyond network translation features, of which there 
are many and they make use of them, but thats beside the point.

The point I have been trying to make is that with NAPT44 in IPv4 as it 
is commonly deployed today, when the "firewall" is off, so is the 
internet. That is an inherent level of security absent in IPv6 as 
commonly deployed.

NAT fails securely. IPv6 firewalls do not.

In the absence of this basic level of security by default, ever greater 
rigorous and vigorous attention needs to be given to the security 
features and functionality as shipped to consumers, who are unlikely to 
do anything beyond plug it in and turn it on.

I question whether such efforts are enough to bridge that gap. History 
suggests that is unlikely. And the fact that they are now required is a 
step backwards in time.

These are the same devices that oops, ship with backdoor passwords and 
otherwise glaring security defects. All the time.

I further note that with such a setup, communication issues 
troubleshooting will likely start with "turn off the firewall", as it 
does today on most desktops. Users are unlikely to turn it back on after 
that at any point. So your CPE must also come with a turn back on timer 
feature. Standardize that. Worse, this is a moving target, and as 
before, its orthogonal, tangential, a cost center.

Typical IPv6 users are not likely to be any more security aware and 
conscious than IPv4 users are now. They are the same users.

The same is true for the vendors whose customers are those users.

Joe