IETF Logo Mail Archive

Re: [IPv6] Can We Turn the Global Network into a Firewall Protecting All End Users?

Mark Andrews <marka@isc.org> Wed, 24 April 2024 05:46 UTC

Return-Path: <marka@isc.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A274C1519B1; Tue, 23 Apr 2024 22:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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_PASS=-0.001, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=isc.org header.b="GD6xf4VR"; dkim=pass (1024-bit key) header.d=isc.org header.b="V0caNF6t"
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 0MyU7uetvMkA; Tue, 23 Apr 2024 22:46:26 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 58B01C14F6E4; Tue, 23 Apr 2024 22:46:25 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 05ACD3AB1B1; Wed, 24 Apr 2024 05:46:25 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 05ACD3AB1B1
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1713937585; cv=none; b=RMwH56Mk7OwPCIoIW/FJK12g/w9tDyXHwywJMqgBXqP1QkNXHz/bZlcM+6gx6ux92H0lQAHsKS9o/gAsRLAz9je25/AjEsdLid2lxJZoPEu3zZboaaaXti0OXTqgYw6kXvHTVH11p6Wszm36/m+EPb/blovR+d2RjIbC97OmZtw=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1713937585; c=relaxed/relaxed; bh=vfxt9KpGldZN8YjnhbWuFKpQ3VOhUivleOrhdnFjyak=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=nNp/AqhJn25ZRcTsoCnM6wtuD34KM53YBa/nce7/8CKGRAfWcw6ZFGm6uWWeo2JPC2+4RuhL+tpYYvgV1oqUYxswemrIiAHaQ+494qpiP7RaYKkzTOUR1yiMZ51smebjPAW34Im/qH20e9vApB9LpCCeXj8BmT77QC00t9FxoZ0=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 05ACD3AB1B1
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1713937585; bh=Qje8zoM12NnpFw4/gNjXuevPVwGhuEaHsrj95T1oHew=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GD6xf4VRVdqVcWBABrdpioaKxsxYKG0iTxq6jtzUBzyqETjQVIYBHgKVw7PVi262j 9HQ4KJE+b1uDCFnpSBe6yCctx5SaKOeXy2nTBeDenapdslNXjQhzBGai+gqMYpA8LI DnsfIqnwYW7GcjPEhyvJLaSDMgkBENddY/3H4eLg=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id A4CFE9461A3; Wed, 24 Apr 2024 05:46:24 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 7DCDC9463E2; Wed, 24 Apr 2024 05:46:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 7DCDC9463E2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1713937584; bh=vfxt9KpGldZN8YjnhbWuFKpQ3VOhUivleOrhdnFjyak=; h=Mime-Version:From:Date:Message-Id:To; b=V0caNF6tSZVkvSy3YMl7pMivXqGirxQklB/rF7QcxNOgZ5uxCuQolIOD7TNV7fNFF 1DeCMDNwXQi3ZhRnxcfLYuivXSdFyHMTE2kfOHc98ZYAfikbzDBa6WhH5+WpqRw2TD 8MUGN6ZdZZuosHVU20O+jed2oUMc5JQ3x9Z20OxA=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id qgV8jaDKbieK; Wed, 24 Apr 2024 05:46:24 +0000 (UTC)
Received: from smtpclient.apple (n49-187-18-238.bla1.nsw.optusnet.com.au [49.187.18.238]) by zimbrang.isc.org (Postfix) with ESMTPSA id 9E2709461A3; Wed, 24 Apr 2024 05:46:23 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAMkkUf3UqjJbuBQwvaOAsV=4VwPYBCUTBNLfUB2ZF4gAv4CHnQ@mail.gmail.com>
Date: Wed, 24 Apr 2024 15:46:10 +1000
Cc: 6man <ipv6@ietf.org>, 6lo@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4424AFD-CE28-46C8-808E-A41979973DA4@isc.org>
References: <CAMkkUf3UqjJbuBQwvaOAsV=4VwPYBCUTBNLfUB2ZF4gAv4CHnQ@mail.gmail.com>
To: Hubert W <hubert.wisniewski@gmail.com>
X-Mailer: Apple Mail (2.3731.700.6.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/HyBG1XGjr3edbpd7dMNL5BYFvSA>
Subject: Re: [IPv6] Can We Turn the Global Network into a Firewall Protecting All End Users?
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2024 05:46:30 -0000


> On 23 Apr 2024, at 16:51, Hubert W <hubert.wisniewski@gmail.com> wrote:
> 
> Dear WG,
> 
> 
> I woke up with one idea and I would like to challenge it. 
> In IPv6, every device receives a routable address. To protect endpoints effectively, we require firewalls to filter unwanted traffic. 

Apart from packet volume this is a false assertion.  No device should require a firewall.

> But what if we could stop such traffic at the source? Could this approach convince more people toward adopting IPv6?
> 
> According to RFC 7381: “In a /48 assignment, typical for a site, there are then still 65,535 /64 blocks.” and “All user access networks should be a /64.”

/64 is typical not required.

> Can we use then bit 63 to convey a message: “I don’t want any incoming traffic initiated towards me!!!”? Of course a response would be accepted.
> 
> We could divide the /64 allocations into two groups: one for servers, and these accept incoming traffic (bit 63 = 0):
> 
> for example 2001:0db8:0000:0000::/64
> 
> And the second group: endpoints, these never accept incoming traffic (bit 63 = 1):
> 
> for example 2001:0db8:0000:0001::/64
> 
> We only need all systems to understand the message. If a router or firewall sees such a packet, then drops it. 
> Every TCP packet with flag SYN, where destination address (IPv6) has bit 63 equal 1, must be dropped.

All the world is not TCP.  Additionally for TCP the filtering device would need to track state and that implies symmetric routing.

> Would it be theoretically possible?

No.

> Best regards
> 
> Hubert Wisniewski
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.46.0 | Report a Bug | By Email | System Status