Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023
Michael Richardson <mcr+ietf@sandelman.ca> Fri, 29 December 2023 16:57 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 E22BDC157914 for <dhcwg@ietfa.amsl.com>; Fri, 29 Dec 2023 08:57:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (2048-bit key) header.d=sandelman.ca
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 PQuh6pXErCqx for <dhcwg@ietfa.amsl.com>; Fri, 29 Dec 2023 08:57:48 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3653C14CF18 for <dhcwg@ietf.org>; Fri, 29 Dec 2023 08:57:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2EA431800D; Fri, 29 Dec 2023 11:57:46 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9fRndwfTi4PN; Fri, 29 Dec 2023 11:57:44 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A9D931800C; Fri, 29 Dec 2023 11:57:44 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1703869064; bh=N3ANEbDbhSWDVCo9yBMvHuyPuGp7RQkAH+duFiEPbD8=; h=From:To:Subject:In-Reply-To:References:Date:From; b=xRhnc05YFBooTxdQ0AFO9LXVlQz4x0ly5FTOLxoBwXqniP3/1Ax7tZLc7zGBpUdB/ 8Og+A5XhmYHbcLtk0umemCx1sxcZ80f+J1cPvFa/drNEsu5CvXf8sZyfJffKTaVb40 zwF5gjbTqFYFqzuuN4g0zwL8LoUNX/v8rg4vwSsMRjR/b532ujkqoP5ptwyO9Cazwt vbx1nOmqZYxFpj6FXFK/yb9TqN8BmqpHDZJK09s+UicnPPyCwYbMGiYWN35hm04thD fI2JXRS5d/gzQ1uN30HjWOfkSqEOpG6OUVqoCmobswpfw3zH0684dtdsWd3bmnkoM8 PhJcIGWp60XZg==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A52971BF; Fri, 29 Dec 2023 11:57:44 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jen Linkova <furry13@gmail.com>, dhcwg <dhcwg@ietf.org>
In-Reply-To: <CAFU7BAQ6fJjhjtvmwJd8otwPG3A0=4x87oFnMRPyyn9uWoCB6Q@mail.gmail.com>
References: <CAJgLMKuUkm1bxhT379QxrdOLzbA0zuGPQY4UbvzOYJD-ykWBwg@mail.gmail.com> <CAFU7BAQzwW4yFXH6vF2stZT5G7OmyZj248zGxeZbJ06JDJ_ieg@mail.gmail.com> <7598.1701799723@localhost> <CAFU7BAQ1Ge3yKjdSXEX80ukbw-OYMReC8+Tvh6UNAB2UKEOz5w@mail.gmail.com> <9253.1703255775@localhost> <CAFU7BAQ6fJjhjtvmwJd8otwPG3A0=4x87oFnMRPyyn9uWoCB6Q@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 29 Dec 2023 11:57:44 -0500
Message-ID: <21509.1703869064@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/GjgxmLLlEnyDqPiDSOvh4NLa6qI>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 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: Fri, 29 Dec 2023 16:57:53 -0000
Jen Linkova <furry13@gmail.com> wrote: > On Fri, Dec 22, 2023 at 3:36 PM Michael Richardson > <mcr+ietf@sandelman.ca> wrote: >> EXEC SUM: I think it's really complex for a client to know when "all" of the >> servers have turned on this option. While clients are supposed to listen >> for all the servers, I think in practice, they listen for the first >> server that is "Good Enough" for them. I suspect that there are >> probably bugs here when the servers are not equally capable. > So are we OK with the client oscillating between starting and and > stopping the registration process if some servers on the network do > not support it? I'll repeat once more :-) I'm not okay with this. I think it should be wire-or. >> I am primarily concerned with desired behaviour in the absence of >> RAguard/DHCPguard. While many enterprise APs have those kinds of filters >> since a long time, they are less common on commodity wired switches, and it's >> less common to see them enabled. > It's a shared fate. If RAGuard/DHCPguard are not enabled on the > network, the whole IPv6 connectivity is in danger and unreliable. > No new risk here. I'm not claiming a new risk :-) >> While I think that the incidence of DHCPv6 being turned on randomly by >> desktop operating systems is far lower than for DHCPv4, the occurance of >> people plugging in "home routers" at their desk thinking they are ethernet >> switches is just going to rise. (using the "LAN" ports exclusively) > The threat exists even w/o the proposed mechanism, right? > Or am I missing anything and you do see a new thread being introduced? When you consider the case where someone at an Enterprise sticks a "switch" on their desk in order to hook up a few more things they are supposed to be configuring. (someone junior in IT at a non-IT company. So Jen, not your network) Only, as I suggest, it's not a switch, it's a home router, and they have plugged the LAN side in. Sure, RAguard/DHCPguard on the Enterprise switch port keeps that junk away from the rest of the network, but the devices on junior-IT guy's desk all see two RAs, and two DHCP Advertises. Only the only from the "switch" does not have ADDR-REG-ENABLE on. I think that it is *PRECISELY* in a case like that IT would really really like reports from all those devices to show up in their logs. I'm not claiming a new security issue, I'm claiming that finding these kinds of things is exactly the problem we are trying to diagnose. >> I think that (1) is simplest, but it seems that all of the server option >> announcements can timeout, and then there would be no announcements and maybe >> the client should stop. > I might be wrong but I do not think it's what Bernie and Lorenzo are > suggesting. I read it as 'the client starts the registration process > as soon as it gets the very first support signal, and then it doesn't > stop even if subsequent Replies do not have the option". Because if it > does take subsequent Replies into account, then it either has to > a)track which server sends it (-07 text, which we all agree is > complicated) or b) treat the first reply w/o the option as a signal to > stop (the original text, which would lead to the oscillation). I guess I assumed it would track which server sends the signal. And there aren't any timeouts involved, since no addresses were allocated, which I forgot. I was thinking that there were some things allocated (v6-PD!), so there would be a timeout associated with that lease. But, I see your point, one could just observe the latest announcement. Well, I don't know then, the simpler solution is appealing. > To be honest I'm still confused about what behaviour we shall prescribe. > 1. The client MUST NOT send the registration messages until it gets an > explicit signal. Sure. > 2. The client SHOULD start sending the registration message when it > receives the signal. Agreed. > What shall the client do after that? > What shall the client do if it sends an information request and gets a > reply w/o an option? Is this the ADDR-REG-INFORM message, or another information request? >> Oh, maybe I did not understand this debate correctly. >> (I admit that I was mostly, "meh", because my implementation lives on a PPP link) >> {I thought it was about the server multicasting message 4.} >> >> Are we introducing a privacy concern by using multicast? >> If any server can effective turn on this reporting, and get all the hosts to >> multicast this info, have we just created a new passive discovery attack? > First of all, the vast majority of switches out there do not have MLD > snooping enabled. So your passive discovery attack is possible already > because of DAD (we discussed exactly that in the Security > Consideration section of RFC9131). > If the network has MLD snooping enabled - then an attacker can join > 'all routers' group and still see GRAND (RFC9131) packets as well. If > the attacker joins 'all DHCP servers' group and sees all DHCP traffic > from the client, in which case all DHCP addresses are revealed anyway. > IMHO if the network administrator wishes to hide addresses used by > other clients, the network shall provide complete p2p isolation. > Thanks for pointing this out, it's worth adding to the Security > consideration section, will be included in -08. Fair enough. Not a new attack, just extension of what you can already get. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [dhcwg] WGLC for draft-ietf-dhc-addr-notification… Timothy Winters
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Lorenzo Colitti
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Li HUANG
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Lorenzo Colitti
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ivan A Pena
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Daryll Swer
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Daryll Swer
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ole Trøan
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Bernie Volz
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Daryll Swer
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Lorenzo Colitti
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Jen Linkova
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Daryll Swer
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Li HUANG
- Re: [dhcwg] WGLC for draft-ietf-dhc-addr-notifica… Michael Richardson