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

[Jen Linkova <[e-mail]>]

On Fri, Dec 29, 2023 at 5:57 PM Michael Richardson
<[e-mail]> 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.

>     > 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.

That's why I'm confused: if you are not OK with oscillating clients,
why are you OK with "listening to the first server is good enough"?
That may (and in many cases will) lead to the oscillation.

>     >> 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)


Oh, my network allows that - it's just 802.1x would take care of
making sure other clients are not affected  ;)

> 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.

IMHO it's a job for DHCP guard/RA guard.

> 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 do not think the primary use case here is "finding rogue DHCP
servers", to be honest.
The use case we have in mind is an additional mechanism to report
addresses in use, not
finding rogue routers/DHCP servers (though actually rogue RAs with
PIOs can be detected using the proposed mechanism).

>     >> 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.

By the simplest you mean "once the client starts sending, it doesn't stop"?
Are you (and the group) OK with 'cons' (such as 'if the administrator
wants to turn it off, it might need to
bounce the client's connection.')?

>     > 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?
I'm not sure I understand the question. The client sent a packet (e.g.
Information request) which includes OPTION REQUEST OPTION containing
OPTION_ADDR_REG_ENABLE code and got a response w/o
OPTION_ADDR_REG_ENABLE option back.
What's now?
Stop? Continue sending?

-- 
Cheers, Jen Linkova