Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by September 13, 2023

Alan DeKok <aland@deployingradius.com> Mon, 25 September 2023 14:38 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95969C1524B4 for <dhcwg@ietfa.amsl.com>; Mon, 25 Sep 2023 07:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
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 5dnxr46hGLsx for <dhcwg@ietfa.amsl.com>; Mon, 25 Sep 2023 07:38:40 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (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 B5818C1522CD for <dhcwg@ietf.org>; Mon, 25 Sep 2023 07:38:40 -0700 (PDT)
Received: from smtpclient.apple (unknown [75.98.136.130]) by mail.networkradius.com (Postfix) with ESMTPSA id 27D7F43B; Mon, 25 Sep 2023 14:38:36 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAO42Z2yUT628xbyi9hA_adxtVNm17spgVsb=LRhVK2KXuqP=2g@mail.gmail.com>
Date: Mon, 25 Sep 2023 10:38:35 -0400
Cc: Ole Troan <otroan=40employees.org@dmarc.ietf.org>, dhcwg <dhcwg@ietf.org>, Ted Lemon <mellon@fugue.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0313F33E-7A13-40F5-82DD-89F6DE28A097@deployingradius.com>
References: <CAJgLMKvATJP78ONPc8f6kG2eNWq83XCTSdvRLVGKWB26JGrANQ@mail.gmail.com> <1E185C09-B45E-4B1E-81F8-3CB6141B9881@employees.org> <CAJgLMKtYy2U1vScQoW4eWD3sLipeUTak7BqkELXZ61=6_cKJDQ@mail.gmail.com> <1418C8C0-DBCA-4222-B1C4-604E4B389DEA@employees.org> <CAO42Z2yUT628xbyi9hA_adxtVNm17spgVsb=LRhVK2KXuqP=2g@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/U1Q6fOIE2mN7XjLHU6wWAoRi05A>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by September 13, 2023
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Host Configuration <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Sep 2023 14:38:46 -0000

On Sep 25, 2023, at 10:07 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
> DHCPv6 isn't a solution when you think about what the security requirements are.
> 
> The Stateful DHCPv6 Myth. No, it doesn't record IPv6 addresses in use. Neither does DHCPv4.
> https://ipv6tao.blogspot.com/2021/09/the-stateful-dhcpv6-myth-no-it-doesnt.html?m=1

  I don't buy the arguments in that blog post.  The claim is at best misleading.

  Two systems can always use out-of-band methods to communicate, and the upstream network won't know, because it's not involved.  It's not productive to imply that's a problem.  Because it means that the network is being asked to track information which is unaccessible to it.

  Think of a firewall vendor being asked to filter out packets which aren't sent to the firewall.  This isn't a failure of the firewall.  No amount of tweaking the firewall will fix the problem.  It is simply not appropriate to demand such behaviour from the firewall.

  As Ole points out, SAVI addresses the bulk of the concerns of the network.  Failure of the network to enforce correct IP usage is a policy failure.  That failure can be addressed by implementing the missing policies.

  Maybe my attitude here is different because I've been doing RADIUS for a while.  RADIUS is nothing but policies, so I see this issue not as a failure of DHCP, but as a failure of the network to enforce the correct policies.  And it's a failure to demand that the network enforce policies which are impossible to enforce.

  Alan DeKok.