IETF Logo Mail Archive

Re: rfc791 coming up to 40 years ... what to do (remember, celebrate, ...?)

Joseph Touch <touch@strayalpha.com> Thu, 25 March 2021 00:07 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175EB3A12E5 for <ietf@ietfa.amsl.com>; Wed, 24 Mar 2021 17:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.199
X-Spam-Level: *
X-Spam-Status: No, score=1.199 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, HAS_X_OUTGOING_SPAM_STAT=2.517, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 myTO9BN5NxNr for <ietf@ietfa.amsl.com>; Wed, 24 Mar 2021 17:06:56 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967DD3A1415 for <ietf@ietf.org>; Wed, 24 Mar 2021 17:06:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e7vha+8c2EtpXkdGHtihOpxIAt95gmPCrxI+p2CHNwg=; b=TmcupCQtYFV8AAQW/1Hrn18e2 9zxoAHKPBgeE6egPCXQo0PNf5exGCqNr+nvn7sFFX4YPfr4undmvXbLKjpnK6BZm6gTbEk0xbIS5Y nDv4DV7/KgFT7FkMrhe+IFn209YifIt3hhBVH9mPm/cWHw92NejxFl7rjrg1eYuz7tH1WCZAyWi29 dpL4eWf/IBM4WgOI53Bv9O6xl/myPjVapRrgUl9KOUZF4Dude4XXS2z5iggu39xV2I5Wcos4hYhb9 kxg8uUUzSI4YVi1IikKzkyzG7HAnwU4LQyWjcC3f7rSjVk9Wu6x2BZE4KD5mLw5QHkw4Ez8VJ1nfB Uj85Qh0wA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:51748 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <touch@strayalpha.com>) id 1lPDWF-0047Gk-Co; Wed, 24 Mar 2021 20:06:39 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_67ACFF99-4FC9-4A6B-8E5A-2F4C5EE5F18A"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Subject: Re: rfc791 coming up to 40 years ... what to do (remember, celebrate, ...?)
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <c25db9b8-b000-599e-35ca-f073062efd90@mtcc.com>
Date: Wed, 24 Mar 2021 17:06:35 -0700
Cc: ietf@ietf.org
Message-Id: <58BB00BB-1E43-4D4A-AF64-65BDDACE2805@strayalpha.com>
References: <4c4460b9-5074-a320-6ebb-8b537f4c22a2@network-heretics.com> <A5F380FA-FB87-46CB-9D77-1FDB4453E8BD@strayalpha.com> <CAC8QAcfLqmf8Hq22fr6SQQxGj7i9p4n0i=WG1fUBX9hnHwT55Q@mail.gmail.com> <CAMm+LwjunKat1rp9QgkmZEKrp0zUAzPDL8Mp35f6saX5dyzu7g@mail.gmail.com> <35816c08-3375-94a4-33d3-f0b2e3eca895@mtcc.com> <2119081b-c04e-2ff8-0530-11c96cc1c74f@network-heretics.com> <baa0a47f-d7b1-85f9-30a5-5eebf9becb4e@mtcc.com> <F1A84553-90BA-4E7F-9B89-7FBA9762C30F@strayalpha.com> <c25db9b8-b000-599e-35ca-f073062efd90@mtcc.com>
To: Michael Thomas <mike@mtcc.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/cF4HQDA6biZZB5KqIayu3Rxbunc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 00:07:00 -0000


> On Mar 24, 2021, at 5:05 PM, Michael Thomas <mike@mtcc.com> wrote:
> 
> 
> On 3/24/21 4:57 PM, Joseph Touch wrote:
>> 
>>> On Mar 24, 2021, at 4:10 PM, Michael Thomas <mike@mtcc.com> wrote:
>>> 
>>> 
>>> On 3/24/21 3:23 PM, Keith Moore wrote:
>>>> On 3/24/21 5:36 PM, Michael Thomas wrote:
>>>> 
>>>>> IPsec certainly suffered this fate, though with filtering I'm not sure if it would have the right security properties for tunnel mode. Certainly had we used transport mode IPsec instead of SSL we wouldn't be coming back 25 years later worried about the TCP checksum.
>>>> IMO IPsec was DOA because it didn't actually consider the needs of applications.
>>>> 
>>> Well there's no actual reason why IPsec needs to be run in the kernel except for maybe some issues with IP protocol numbers (can't remember if they could be exposed up at that time).
>>> Beyond that IPsec in transport mode doesn't seem to be much different than TLS other than covering the transport headers too.
>> Turns out that can be important for things like BGP (that’s why we had TCP-MD5 and now TCP-AO).
>> 
>> IMO, what IPsec got wrong was tunnel mode; it should have just been transport mode and IP-IP tunneling (RFC 3884 explains why).
>> 
> Ah, interesting point. On the other hand for most VPN applications I've often wondered why they need to advertise/configure specific tunnel endpoints. Why can't you just follow normal routing to the destination and send back an ICMP to say they need to be authenticated/encrypted if need be. It seems it would solve a lot of weird problems that tunnels cause.

See the recent discussions on int-area.

ICMPs are largely blocked.

Joe

v2.23.0 | Report a Bug | By Email