Re: [arch-d] Treating "private" address ranges specially

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 01 April 2021 01:00 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AAF3A083F for <architecture-discuss@ietfa.amsl.com>; Wed, 31 Mar 2021 18:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QMWEBmQ8A36j for <architecture-discuss@ietfa.amsl.com>; Wed, 31 Mar 2021 18:00:11 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8048E3A083E for <architecture-discuss@ietf.org>; Wed, 31 Mar 2021 18:00:11 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id m11so228708pfc.11 for <architecture-discuss@ietf.org>; Wed, 31 Mar 2021 18:00:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=t/3PWiJkzt8/k4uc/rykF/52m5jH2zyh3D/qBu7iikE=; b=Iy8c5Ofz0vJ4hBZ59KyYoqOjyPvSPD1nLygR+fd822bShZdfrtPazu1jP7Tt0VYvSG YbsuBAwBb6I+i+ao7H/8WRWO95wBpfd9mJjgF50KlnjBcAwx4DmXZM5rqh6YJyqaDDuG qvt3V/hs1YAiq/pd0fFRz3OmuCm6kAqFsHTp8cCz8L9euVeYW8SkGZB0+6ZdQxJ+g3nE FL691EMaq9iZu3ihfQnWZxlz+Qc4drNax1nMevuBnzP6MzBbxIam3BgnrFtK45ufY8Qq tBCxQDsXGi6KkZBO4SbjeR4c6yn6bw32zMC81EJLK3ATvuFunarzGxSrXqMMRxH7lDid z10w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=t/3PWiJkzt8/k4uc/rykF/52m5jH2zyh3D/qBu7iikE=; b=b1Q3Scdwp4wrftZtXvk1tB0SOTFGRl7vEwX+gHpHeEeGa3Yu4RMO8rZP3AUF+nKvVz P3iJJ3+v6KKbnM0lSbUGoTw/fSp97od1TSoYhAqlADKRp5BiFI8TJ1XJ6w1LbE6DehK2 ey1XVyojbIL5DCL0V3VTQhq5+iqeXlXs7/DHvD8dsKfII9c/q96n/7tSggVZCzpDZRw7 QHHbnqQdqHCFYuNxMPLEaGrs7tX/gOysfEsP//pTZzYBVmEN7PE9aDjto9DTG/2K/3Yk YlU0YgU2slAgcLcAUBKgaGot4YZ/aUrymSRT6UBfn0qmGEej+lgNHoFrkk8nmMntErxQ TNxA==
X-Gm-Message-State: AOAM5337h4+eADkyiL8tKFaVefSY1k19SR3x6gA+9q6BnV2XYmwbk1tY 2xATY1E3mDtlvIKvywXCZ7FUzZJlZlML9A==
X-Google-Smtp-Source: ABdhPJxVNazxJbi0MvD1HW2IS5TNpgI6KDSTmKh71rGrKr7qbgzOCc8MAJzYLGPP8rHNGBc6loNjWA==
X-Received: by 2002:a62:7ed2:0:b029:21d:1806:fe30 with SMTP id z201-20020a627ed20000b029021d1806fe30mr5343091pfc.5.1617238808272; Wed, 31 Mar 2021 18:00:08 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.131.14]) by smtp.gmail.com with ESMTPSA id 4sm3305646pjl.51.2021.03.31.18.00.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Mar 2021 18:00:07 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>
Cc: Ted Hardie <ted.ietf@gmail.com>, Erik Kline <ek.ietf@gmail.com>, architecture-discuss@ietf.org
References: <4329d51a-d5ba-45b3-9fb0-6795dc6fccd3@www.fastmail.com> <CAMGpriWA4B8AThNKBOHo-bfAdQ2s5iYv8rBOB7X8UVc5GsqENA@mail.gmail.com> <CAMGpriUJkWYPyw7=oAj_GnGu2J14T3=VZYNWPZtAs870P=x0sg@mail.gmail.com> <a68636c2-5df0-46eb-8147-79ec6a992f8a@www.fastmail.com> <CAMGpriU_L8HbLFX_mMBtBXxy=XOc5BAnYgVR9R8TQO=DPvRD_g@mail.gmail.com> <F59E2FC3-19CE-4D14-9F1C-9F7125D89455@mnot.net> <CAMGpriVJCsird15oBfT=gSDTr59_yf9TkLmOSO7a9DGX0VRjOg@mail.gmail.com> <CA+9kkMB2iOA-QaCidJHVN=qqZ8TtPXV=xyfuKh+i44VzZLWG3w@mail.gmail.com> <0cfae1b5-378d-1b28-9a60-89ef15cd793a@gmail.com> <20210331221054.GG8957@faui48f.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <202e3750-af47-354f-0f95-058a223ca598@gmail.com>
Date: Thu, 01 Apr 2021 14:00:02 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20210331221054.GG8957@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/LA5im7QJcpMn4hkPV7E5qzQnKYk>
Subject: Re: [arch-d] Treating "private" address ranges specially
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2021 01:00:16 -0000

Thanks Toerless.

I should probably have cited the noisy recent discussions more precisely. The threads started at:
https://mailarchive.ietf.org/arch/msg/ipv6/SVEJoron3ICcjaQYjSJSzwsVxRM/
https://mailarchive.ietf.org/arch/msg/ietf/26nb2UjSHEQR9XIvHMQ6ZbeNubE/

(Warning: about 500 messages between them. Summary: simplistic ideas about address scope do not capture reality.)

Also see https://www.cs.auckland.ac.nz/~brian/scope6.pdf which tries to illustrate why certain ideas about address scope are simplistic.

I also forgot to mention another major issue: increasing use of address bits to carry locally defined semantics. Much as traditionalists might dislike this practice, it is increasingly popular and of course greatly complicates the question.

Regards
   Brian Carpenter

On 01-Apr-21 11:10, Toerless Eckert wrote:
> 
> Brian, *:
> 
> a) +1
> 
> b) Maybe the reasons for what Brian is saying are not as obvious to hose working primarily
>    at the app layer, so le me quickly add a bit of explanation: 
> 
>    rfc1918/ULA addresses may be as "global Internet" in reachability as "global scope" IP/IPv6
>    addresses because of NAT (let's assume BEHAVE compatible applications and NATs to avoid getting
>    sucked into a discussion about the "evilness&limitations" of NAT).
> 
>    Whereas in IPv4, rfc1988 addresses are often used this way due to address space limitations,
>    in IPv6, ULA is likely used similarily just to have fixed addresses in all those cases where
>    you do not have PI address space and just don't want to spend the money on renumbering
>    when you change SP or multi-source address selection when you have PD addresses with
>    redundancy.
> 
>    Aka: expect to create a huge amount of blowback of browsers starting to behave differently
>    for those cases in companies or in homes where this happens.
> 
>    Likewise, just because you may use global-scope addresses (especially in IPv6), you
>    as easily may have carved out address semantics for more limited scopes. Likely applicable
>    to any larger organization that has PI address space and is not running out of it.
>    See "firewalls".
> 
> c) There is actually (IMHO) a good discussion that should be had abouut how browser security could
>    better support the needs of limited domains (rfc8799), but i fear the mayority of contributors
>    to w3c / browser security in ietf still think everything required is just what fits the global
>    Internet web-pki and Internet cloud services centric browser security architecture we have today.
> 
> Cheers
>     Toerless
>   
> 
> On Thu, Apr 01, 2021 at 09:27:05AM +1300, Brian E Carpenter wrote:
>> Hi,
>>
>> On 31-Mar-21 22:07, Ted Hardie wrote:
>>
>> <snip>
>>
>>> The document's description of the address space architecture is:
>>>
>>>
>>>       2.1. IP Address Space
>>>
>>> Every IP address belongs to an IP address space, which can be one of three different values:
>>>
>>>  1. local: contains the local host only. In other words, addresses whose target differs for every device.
>>>
>>>  2. private: contains addresses that have meaning only within the current network. In other words, addresses whose target differs based on network position.
>>>
>>>  3. public: contains all other addresses. In other words, addresses whose target is the same for all devices globally on the IP network.
>>
>> The problem is that this classification is worse than heresy; it's nonsense.
>>
>> 1) local. That seems trivially true (assuming that it covers virtual hosts, not just physical ones). Or is it? If a device has multiple interfaces (physical or virtual) which might lie in different administrative domains, each of which has several IP addresses, including but not limited to loopback addresses, are they all equally "local"?
>>
>> 2) private. There is no definition of "private" address in any IETF document. There is no way of looking at the bits in an address and determining that it's private, because there's no definition of private.
>>
>> 3) public. Ditto. Globally reachable != public. "Globally reachable" itself is an over-simplification. See recent very loud discussions in IPv6-land about ULA addresses.
>>
>> The attempt to use the IANA registry to determine things that are undefined is just nonsense. It's an attempt to over-simplify something that is inherently complex. The ground truth about address scope exists only in the entire Internet's routing tables, and simply *cannot* be deduced from the bits in an address.
>>
>> BTW, whoever designed the Python ipaddress module got this wrong too.
>>
>> So IMHO this whole effort is fundamentally misguided and should be scrapped.
>>
>>    Brian
>>
>> _______________________________________________
>> Architecture-discuss mailing list
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>