Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt

Tom Herbert <tom@herbertland.com> Fri, 22 March 2024 16:39 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F848C18DBB7 for <int-area@ietfa.amsl.com>; Fri, 22 Mar 2024 09:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWnamZ_FBQiQ for <int-area@ietfa.amsl.com>; Fri, 22 Mar 2024 09:39:38 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689A0C180B6E for <int-area@ietf.org>; Fri, 22 Mar 2024 09:39:38 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-56a2bb1d84eso4205387a12.1 for <int-area@ietf.org>; Fri, 22 Mar 2024 09:39:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1711125576; x=1711730376; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fijVXDMt1OB3uh1ifLvpV8abNFSJM6xBbTXug5vUS90=; b=A1B+tQiLjnGMDaIazHe3a0+fnL4saex1ixrKLSqJ0KLodzqM8RAnGtNatN4lk2uY/X F3bNUKSBLosBwYtExaXCIt3p6d3L34cSvyqXwxW1kGLjotL8YRrZpbBpyc+05rn6eFPo Dw/Rc1LQu/qD3paffEN5udi6opFi6hz370M7plAwlgLmhu4oeg7KVz1JAydTxV7w3yay 2PJuBUZZ8ccxP3PoN7/tAvGfIe5xGp/Dqd1t9dFs4WaaASWahDixt2f1t8JD6JVJ7dD5 UTWVPg2BZU35BWJxc7hDBowBx8fdG6xeLBnSYECOIfiI8Re3uWjGDIqWvfiSXOgOamHr bXkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711125576; x=1711730376; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fijVXDMt1OB3uh1ifLvpV8abNFSJM6xBbTXug5vUS90=; b=kmx8YmjQdPYYF49TmoHa6iS54zxekdNABhlSHGK7NbAo/vAvTDV91NJbxb0znrqpi5 J2962H2+MeYu3MECN+3hx0gbsg3LHvU6fJHR8ubCNfpDzBxa6SEsOoAaopg/MQx8vKTo 9S9yorRRddnNOFg27vDXg1xVvi2sx8nADyCzfbSEsPIoUq3bm6onc/TgqnwTBdW36QoT 6Lgiza7nTW8JPqeLXzmqmlIzzH/WNhn7Y088gtMddRppt943Us8xBXYLN+VkZAZhMc4j 3dMep0GCLoWMWUSnVJ9A7sZOcRjNL/vRviNvyQOgRUsBOdu6GapkQFgZuYr01Wecln8Y CTtA==
X-Gm-Message-State: AOJu0YzwaTy4O/3f2UyCPJYlY0dbxLrf1nPeDcVdCKvvjLOml0eBDxKs wgucdt/KUFBh3kZ/zqGXb/NryQ+UmASYMHeU+YvtQfE2MIH7jw4R6kbikVGHB/C8/V+rtIzfH++ /a/sQV6VgILq7KVHRdO+imwD8J01P4cwvPOgONt6lUu4Anpx7BQ==
X-Google-Smtp-Source: AGHT+IGFCDrnd35ONmAb3B1KNaVcBAG0aBCFvr8Jh/tEIeOq0r5XXpqyc1+PklOKm03pzE9RmZtpH2fNTSRIR8sr2kI=
X-Received: by 2002:a50:935b:0:b0:567:efec:6d81 with SMTP id n27-20020a50935b000000b00567efec6d81mr2288020eda.11.1711125575860; Fri, 22 Mar 2024 09:39:35 -0700 (PDT)
MIME-Version: 1.0
References: <170865175505.14082.3856617737779580933@ietfa.amsl.com> <CALx6S363oh+7rNMaMa0s+9A-xeyLBy+ct-Q_Bx0xQm_di1PPJA@mail.gmail.com> <ZeZjGyxmuapXz5tb@faui48e.informatik.uni-erlangen.de> <CALx6S34OFL7tzabL+RMvB3nkad5k9esCD_dFpMi6DUtUEG-Dmg@mail.gmail.com> <ZedO1u7aheBhZ26N@faui48e.informatik.uni-erlangen.de> <ZfurRK_oNVES2hVz@faui48e.informatik.uni-erlangen.de> <CALx6S36L57vPa5YkiV3khYbFpPPgPUVynWaRVno0BufvXcALeA@mail.gmail.com> <Zfu5GQ7101lMnHGs@faui48e.informatik.uni-erlangen.de> <DCE2D4E2-9C5D-40B7-952F-7424E7FCBAFE@strayalpha.com> <CALx6S37XnjWcpeGZUQWXFyE0jP=XyodmUBBh+69SonLw3ndvaQ@mail.gmail.com> <57C622DE-2C8E-4415-805D-7053309B0D01@strayalpha.com> <CALx6S36Dpn0qC9e0ZGaK-ckbT58hRkeLHDKkNqmmJn0vQ5ONUw@mail.gmail.com> <B1CC8B09-A701-4401-8BEA-C31DE0FD0FD3@strayalpha.com> <CALx6S354xQHqk4y+0dTkTQ524n5vrN01gJe57FBjbV1UuToWLA@mail.gmail.com> <FF84650B-6739-4D12-B390-977627A1296E@strayalpha.com> <CALx6S34ePRxNNqx1TOSon9=QgKvq0wJh7mMFRH7gr2OUjZ_zmw@mail.gmail.com> <E89DABED-3612-4B18-93FF-4FB31A072508@strayalpha.com> <CALx6S34F0FTyUhf8ew0tAuyaLJquRPdiOHVnT0OE7pFAQY+c_Q@mail.gmail.com> <0087c4475ce244848354c2755cb8e3f3@huawei.com> <SN6PR08MB392050BC6FEA009B4BDBDF16E6312@SN6PR08MB3920.namprd08.prod.outlook.com> <CALx6S354H_bExgjeRiqbB7KoBZoHqnRHOHPNR1Th70-ZLzCJOA@mail.gmail.com> <SN6PR08MB392035D0E90221C36681D032E6312@SN6PR08MB3920.namprd08.prod.outlook.com>
In-Reply-To: <SN6PR08MB392035D0E90221C36681D032E6312@SN6PR08MB3920.namprd08.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 22 Mar 2024 09:39:24 -0700
Message-ID: <CALx6S37uii3uZvm+DAC2ugwnYL0wEae51WM-BLpZyoW6n=4xeg@mail.gmail.com>
To: "Robinson, Herbie" <Herbie.Robinson=40stratus.com@dmarc.ietf.org>
Cc: int-area <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/nfRAcOO2J1d_b8i5ZXy2RxnDATs>
Subject: Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 16:39:42 -0000

On Fri, Mar 22, 2024 at 9:12 AM Robinson, Herbie
<Herbie.Robinson=40stratus.com@dmarc.ietf.org> wrote:
>
> > Whether something is "legitimate" is a matter of opinion, protocol
> > conformance typically is not.
>
> In the real world, protocol conformance involves how people interpret the specs (which have historically been quite loose) and what developers of things like firewalls have to do to keep real world threats from  making the Internet totally useless.  What seems to be happening is things that are necessary get done while adhering to the developers best efforts to adhere to the specs and real world utilization.  Eventually, what really happens is things which are necessary enough to be widely used (like firewalls) dictate what the specs didn't say when the firewalls were designed.
>
> > For applications and hosts firewalls are not all necessary to do their job and
> > have created way more problems for developers than they solve.
>
> Umm, are you really trying to claim that firewalls are not necessary?

Herbie,

Yes, I'm saying that. I know this is true because whenever I connect
to WIFI at the local coffee shop or the airport I get no indication
that the network is even running a firewall, much less any guarantee
that their running a firewall that's well maintained, that the devices
are up to date with latest vendor patches, or that they have a
reasonable and sufficient security policy. I rely solely on my
application and host OS which I can control for security, malware
detection, virus scanning, etc. So some anonymous firewall that thinks
they can protect me better is more likely to cause problems or reduce
my security (like if they don't forward my IPsec or QUIC packets
because the firewall thinks that hiding data from them is insecure).
If there was some real standard for firewalls that had broad
conformance, ubiquitous deployment, and consistent policies then I
might think differently-- but until that happens I believe firewalls
are more part of the problem than the solution.

Tom

>  If it wasn't for firewalls, the Internet would be pretty much useless.  I wish that were not so, but...
>
> > In fact, in the 6man meeting the other day someone pointed out that the
> > effect of NAT has been to move the problems and complexity out of the
> > network into the host and application-- as a host developer I  can say that this
> > statement is spot on.
>
> NAT is a red herring -- it's not the only reason firewalls need to look at ports to do their job.  Then again, NAT It is a really good argument for not enhancing IPv4 (so that NAT will go away).
>
> BTW, I am a host developer and protocol stack maintainer.  I see this as a huge amount of work to implement something no-one will be able to use for 2-3 decades.  Especially when it's all available via IPv6, now.
>
> > Right, and this is exactly what drives use to limit packets on the Internet to
> > perpetually use the least common denominator of support in the network.
> > The result is an ossified Internet that we can no longer
> > evolve-- IMO that's not a good thing!
>
> And how does defining something no-one will be able to use for two or three decades solve that problem -- better than IPv6 which already has a 2 decade head start?