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

Michael Richardson <[email protected]> Fri, 29 Dec 2023 11:57:44 -0500
Newsgroups	gmane.ietf.dhc
Message-ID	<21509.1703869064@localhost>
Jen Linkova <[email protected]> wrote:
    > On Fri, Dec 22, 2023 at 3:36 PM Michael Richardson
    > <[email protected]> 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 <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg
signature.asc (application/pgp-signature, 515 B)