Re: [v6ops] Thoughts about wider operational input

Joe Maimon <jmaimon@jmaimon.com> Thu, 31 March 2022 00:08 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 CE3683A0112; Wed, 30 Mar 2022 17:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 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, URIBL_BLOCKED=0.001] 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 j9Q8wgG69D_6; Wed, 30 Mar 2022 17:08:29 -0700 (PDT)
Received: from smtp.chl.com (bindzonemaster.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 72A0D3A00E3; Wed, 30 Mar 2022 17:08:27 -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 22V08QKi008263; Wed, 30 Mar 2022 19:08:26 -0500
To: Mark Andrews <marka@isc.org>
Cc: 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> <F04A9339-1C9F-40AA-8FD3-646106F71D5F@isc.org>
From: Joe Maimon <jmaimon@jmaimon.com>
Message-ID: <6244F0FA.4080809@jmaimon.com>
Date: Wed, 30 Mar 2022 20:08:26 -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: <F04A9339-1C9F-40AA-8FD3-646106F71D5F@isc.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mB0lPFoHw0gmDrE0o_VvXLOsuyA>
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: Thu, 31 Mar 2022 00:08:35 -0000


>
>>
>>
>> JORDI PALET MARTINEZ wrote:
>>> To demonstrate how NAT is not security, you just need to enable Teredo or any other UDP tunneling traversing the NAT, so the security guys can see that without any special config in the NAT, you can dig a whole on it (Teredo Navalis = Shipworm).
>>>
On 31 Mar 2022, at 02:56, Joe Maimon <jmaimon@jmaimon.com> wrote:

>> And then you need to demonstrate how the equivalent would not happen on IPv6.

Mark Andrews wrote:
> The fix is the same in both protocols.  Install a FIREWALL and properly configure it to block port 3544.
> NAT is not and never has been a FIREWALL.
>
> A flat screw drive and a flat chisel can both be used to remove screws or dig out wood.  They both work
> well at what they are designed to do and not for which they are not designed to do.
>

There is no actual permanent solution for internal to external 
worm/tunneling protocols, except yanking the plug or equivalent security 
policy.

There is just blocking the method du-jour. When possible.

All this is irrelevant to my point, which seems to have sailed overhead 
that Jordi's little demonstration says nothing about NAT and security 
that it does not also say about a similarly configured IPv6 firewall and 
hence would be dishonest showboating.

Joe