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

[Jen Linkova <[e-mail]>]

On Fri, Dec 22, 2023 at 3:36 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.  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?
Because it's impossible to predict in which order the replies would arrive.

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

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

>     > So the problematic part is about stopping those messages.  I see the
>     > following options: 1. The client does not stop at all as long as it's
>     > connected to the given link (Lorenzo's suggestion).  2. The client
>     > sends an Information-request periodically, wait for....how long?...(the
>     > shorter of RT and MAX_WAIT_TIME as per section 7.6 of RFC8415?) and
>     > continue retransmission as long as at least one reply allows that. my
>     > understanding that this is a grey area in RFC8415 anyway, so might not
>     > be the best option.  3. (introduced in -07 and it looks like the group
>     > doesn't like it): described above Any other suggestions?
>
> So this is only relevant if the client gets no answer, right?
> If it gets an answer then it stops.
>
> 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).

>     > Maybe the client shall stop transmitting if it doesn't receive an
>     > explicit signal of registration support for 3 X
>     > information-refresh-time?
>
> I don't object to this, but I'm not routing for it.

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.
2. The client SHOULD start sending the registration message when it
receives the signal.
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?

>     >> > The only message for which RFC8415 acknowledges that there can be
>     > I believe all traffic sent by the client is multicast (RFC8415 allowed
>     > the unicast option but it's being deprecated in the -bis;
>     > https://www.ietf.org/archive/id/draft-ietf-dhc-rfc8415bis-03.html#name-reception-of-unicast-messag
>
> 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.

-- 
Cheers, Jen Linkova