Re: [v6ops] Thoughts about wider operational input

Simon <linux@thehobsons.co.uk> Fri, 01 April 2022 20:53 UTC

Return-Path: <linux@thehobsons.co.uk>
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 2C79F3A006A for <v6ops@ietfa.amsl.com>; Fri, 1 Apr 2022 13:53:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 xJcjvpB0-aFh for <v6ops@ietfa.amsl.com>; Fri, 1 Apr 2022 13:53:31 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3F83A094A for <v6ops@ietf.org>; Fri, 1 Apr 2022 13:52:50 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from smtpclient.apple (MacBook-Pro.thehobsons.co.uk [192.168.137.121]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id AA101110001 for <v6ops@ietf.org>; Fri, 1 Apr 2022 20:52:44 +0000 (UTC)
From: Simon <linux@thehobsons.co.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 01 Apr 2022 21:52:43 +0100
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> <67762447-43D4-4393-851C-99370D3BF623@thehobsons.co.uk> <6246126C.1030609@jmaimon.com> <259B108A-C3DD-4460-B41A-A0028ACA9594@thehobsons.co.uk> <624759B1.8060700@jmaimon.com>
To: v6ops list <v6ops@ietf.org>
In-Reply-To: <624759B1.8060700@jmaimon.com>
Message-Id: <89D652EB-8920-4992-99EC-CC3C3A856D57@thehobsons.co.uk>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7s6d_G13Tht5jEq3job5uCucEOQ>
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: Fri, 01 Apr 2022 20:53:36 -0000

> On 1 Apr 2022, at 20:59, Joe Maimon <jmaimon@jmaimon.com> wrote:
> 
> 
> 
> Simon wrote:
>> On 31 Mar 2022, at 21:43, Joe Maimon <jmaimon@jmaimon.com> wrote:
>> 
>>> https://www.rfc-editor.org/rfc/rfc3724.html
>>> 
>>> Since the upper level protocol incorporates lower level properties into its functionality, it is now dependent on them.
>> Hmm, that is not what that document says. I have to assume you are referring to section 4.2 since everything else is in favour of end-end connectivity.
>>>    Two key points in designing application
>>>    protocols are to ensure they don't have any dependencies that would
>>>    break the end-to-end principle and to ensure that they can identify
>>>    end points in a consistent fashion.
> 
> In a network where devices are free to translate packets addressing between them for whatever reasons they want (and this was always true, its just that it became prevalent for various reasons and ingrained and widespread due to shortage), how are they to ensure that end points are identified in consistent fashion?
> 
> In other words, applications compliant with this rfc must be secured with AH

Identifying endpoints in a consistent fashion is trivially easy - you use its IP address*. It is only if the network starts mangling the address that it becomes non-trivial. “The internet” has never been "free to translate packets addressing between them for whatever reasons they want” for the simple reason that doing so breaks stuff.
OK, any bit of the network can do things internal to itself (e.g. wrap a packet in another header for transit through a carrier’s network) - but then it would need to undo it at the other end.

As far as I can see, you're taking a starting point that it’s OK for “the network” to mangle packets (specifically addresses), and then using that to justify everything else. You’ve cited an RFC to support your viewpoint, but my reading of that RFC says “don’t mangle packets because it breaks things”.


* Yes, the IP address you use needs to remain stable for the duration of the session.


So, serious question. How do you read the RFC you cited and come to the conclusion that “the internet” has always been free to mangle addresses in any way it likes” ?

Simon