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

Michael Richardson <[email protected]> Fri, 22 Dec 2023 09:36:15 -0500
Newsgroups	gmane.ietf.dhc
Message-ID	<9253.1703255775@localhost>
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.

Jen Linkova <[email protected]> wrote:
    >> The broken servers are... broken, and perhaps an automatic
    >> configuration process will update them in a few minutes or hours. (Why
    >> break all your servers at the same time!)

    > Yes, so maybe we shall not introduce additional complexity to the
    > client implementations to save some multicast traffic during the
    > transition period or if the server is misconfigured.

Yes.

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.

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)
If this feature is was the missing thing for an Enterprise to turn on IPv6,
then I think it should work reasonably.

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

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

    >> > The only message for which RFC8415 acknowledges that there can be
    >> multiple > replies is a Solicit, but in fact an Information-Request
    >> could just as > easily return multiple replies. I don't know if the WG
    >> is thinking about > this, but this seems like a fairly serious gap.
    >>
    >> I guess I don't have enough experience with Information-Request
    >> messages to understand this situation.  I thought they were all
    >> unicast.

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

    >> okay, I generally agree.  While it might be rare for an enterprise to
    >> deploy DHCP servers from different vendors (and therefore different
    >> feature sets), I'll bet it's not rare for them to incrementally
    >> upgrade the servers, with significant gaps between the
    >> upgrades... because critical infrastructure.  Particularly if it's
    >> integrated into some AD server.

    > The question is how much complexity we'd like to introduce to cover
    > that case (especially as it's not really harmful, just some servers
    > receive messages they do not support).

I am not concerned about servers logging things they don't understand.
They either should do this, or shouldn't, but it should never be a DoS on
that server.   If it is, then that server should get fixed.


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