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

[Mark Smith <[e-mail]>]

On Mon, 25 Sept 2023, 23:55 Ole Troan, <otroan=
[e-mail]> wrote:

> > We have had some operators' interests in this solution over scrapping
> switches and routers.   I think it would be helpful to hear from network
> operators or DHCPv6 server solutions about how viable and deployable this
> solution is.
>
> I hope we are not suggesting scrapping all switches and routers.
> Wouldn’t be much of a network then! :-D
>
> It would be useful to hear from enterprise network operators indeed.
> We need to make it clear to them that this mechanism depends on hosts
> (voluntarily) notifying the DHCP server about it’s addresses. And unless
> that’s also enforced through the network in other ways, the information
> given is “just another datapoint with some probability of being correct”).
>
> “Scraping” of routers and switches isn’t the direct alternative to DHCP
> address notification. Although some level of first hop security functions
> is likely required. I would think DHCPv6 address assignment is the obvious
> solution instead of this.
>

DHCPv6 isn't a solution when you think about what the security requirements
are.

The Stateful DHCPv6 Myth. No, it doesn't record IPv6 addresses in use.
Neither does DHCPv4.
https://ipv6tao.blogspot.com/2021/09/the-stateful-dhcpv6-myth-no-it-doesnt.html?m=1


> O.
>
>
> >
> > ~Tim
> >
> > On Sat, Sep 23, 2023 at 4:08 AM Ole Trøan <[e-mail]> wrote:
> > Thanks Tim,
> >
> > I do wonder if it’s not worth doing a complete retake of this proposal.
> >
> > If the operator requirement is to know which address has been in use in
> the network by which device at any point in time, then that cannot be
> guaranteed with this mechanism. Existing first-hop security mechanisms in
> switches and routers would be much more robust.
> >
> > O.
> >
> >> On 22 Sep 2023, at 22:22, Timothy Winters <[e-mail]> wrote:
> >>
> >> Hi Everyone,
> >>
> >> The working group had some great discussion about this document during
> the WGLC.    Based on the discussion it didn't pass WGLC at this time.  It
> will mostly need another round of discussion and potentially a revision
> based on those discussions.
> >>
> >> Additionally, Bernie and I discussed and think it's a good idea to wait
> to ask IANA for a early code points until we have passed WGLC.
> >>
> >> Regards,
> >> Tim
> >>
> >> On Thu, Sep 14, 2023 at 3:16 PM Bernie Volz <[e-mail]> wrote:
> >> An interesting question may be do we need new messages at all? Using
> Information Request / Reply with new option is perhaps cleanest?
> >> - existing clients can do what they do today
> >> - existing servers (and relays or other snoopers) will not know option
> so ignore (hopefully silently)
> >> - existing servers only see “more” Information-Request for clients not
> supporting this new work when enabling O-bit to request address
> registrations
> >> - “new” clients that do SLAAC when O-bit set and did support
> Information-Request can do initial registration in first message (or send
> when address assigned) and do periodic updates (perhaps even ask for other
> options via ORO to refresh information) … they may actually have no more
> messages than today (well, except if they have multiple SLAAC addresses as
> need to use a separate Information-Request for each) … they could also
> decouple previous and new behavior at increase in traffic.
> >> - registration only clients that did not use Information-Request
> previously add new traffic … which is exactly what we want
> >>
> >> The only downside is it kind of overloads Information-Request as it is
> now also a client to server communication. Though the client already can
> send information to server in Information-Request (user class, vendor
> class, vendor information, …). And, we could say the client is asking
> whether the server supports registration (by getting new option in Reply).
> >>
> >> Note: It may be worth thinking about making use of the new
> “registration address” option’s encapsulated options field if client wants
> to send other information (such as fqdn). This isn’t really bad as this is
> likely address specific and any server that wanted to do something with
> this data needs updating anyway. This keeps all of the registration
> information hidden from those devices that don’t that registration option.
> >>
> >> Anyway, this is now a very good reason to hold off on early assignment
> for message types (and likely say WGLC failed).
> >>
> >> - Bernie (from iPad)
> >>
> >>> On Sep 14, 2023, at 2:32 PM, Bernie Volz <[e-mail]> wrote:
> >>>
> >>> Hi:
> >>>
> >>> (Just catching up and responding to this as was asked
> specifically…there could have been more I haven’t yet read.)
> >>>
> >>> 8415bis only prohibits IA options in Information-Request
> >>>
> >>> 16.12. Information-request Message
> >>>
> >>> Clients MUST discard any received Information-request messages.
> >>>
> >>> Servers MUST discard any received Information-request message that
> >>> meets any of the following conditions:
> >>>
> >>> * the message includes a Server Identifier option (see
> >>> Section 21.3), and the DUID in the option does not match the
> >>> server's DUID.
> >>>
> >>> * the message includes an IA option.
> >>>
> >>> I wonder however if having an Address Registration option specifically
> would be better (the Information-Request and new registration request could
> use this instead of IA_Addr option). This might avoid an overly aggressive
> server or relay that checks the Information-Request or its Reply for
> options from doing odd things if it sees the IAAddr. If we’re trying to
> make things safe, this may be best. Note also that it may help other
> devices in the path that may want to snoop for this data. (But it could
> have downside if any “options” are developed as then those specifications
> would need to determine if they are also allowed in this new address
> option).
> >>>
> >>>
> >>> On a separate note, one issue the current draft may need to document
> and is a consideration is that when O-bit (RA) and A-bit (PIO) is set, a
> registration only server should really support Information-Request as it
> will also get lots of those from clients that support DHCPv6 - it may just
> send back a pretty empty Reply.
> >>>
> >>> By using Ted’s suggestion of using Information-Request, it would be
> natural for registration only to be implemented at least sufficiently to
> send a well formed Reply even when not address registration request.
> >>>
> >>> It seems like a clever idea to use Information-Request at least for
> initial determination of support.
> >>> - it avoids extra packets.
> >>> - client could honor server’s INF_MAX_RT to reduce frequency of
> probing (likely periodic probing is not a bad idea).
> >>>
> >>>
> >>> - Bernie (from iPad)
> >>>
> >>>> On Sep 14, 2023, at 11:29 AM, Lorenzo Colitti <[e-mail]>
> wrote:
> >>>>
> >>>> On Fri, Sep 15, 2023 at 12:22 AM Ted Lemon <[e-mail]> wrote:
> >>>> What I think would be most expedient (if we must use DHCP to probe
> for support of address registration) would be to do the first address
> registration as an information request with the additional information in
> the information request, using the source address being registered. If the
> reply that comes back confirms the address registration, then all
> subsequent address registrations on this link would be sent as address
> registrations.
> >>>>
> >>>> Well, but if we can come up with a reasonable way to represent an
> address registration using an information-request packet, then why not make
> all registrations be information-request packets?
> >>>>
> >>>> +Bernie Volz any thoughts on using information-request and reply
> messages, instead of the new addr-reg-inform and addr-reg-reply messages
> currently defined in the draft?
> >> _______________________________________________
> >> dhcwg mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dhcwg
> >> _______________________________________________
> >> dhcwg mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>