Re: [dhcwg] draft-wkumari-dhc-addr-notification and the secops problem

[Bernie Volz <[e-mail]>]

These are great points Michael.

For the earlier (circa 2014) draft that was similar, draft-ietf-dhc-addr-registration, the reason a client would have implemented it was to get its information in DNS (as there would presumably be a reason it needed this, such as to allow other devices to communicate with it). With this new draft, there is really zero benefit to the client. I’m not promoting a shift to this DNS registration as that had its own issues.

If you want “notification”, why not just require DHCPv6 for address assignments? If you don’t care or are using other tools, use SLAAC. Do we really need something in between?

- Bernie Volz

> On Aug 12, 2022, at 9:03 PM, Michael Richardson <[e-mail]> wrote:
> 
> This document seems to require many changes to many systems.
> Do I hear that Google is willing to do this for Android?
> I am very enthusiastic about having better information.
> 
> It works only if all the devices implement it, it's not that useful until all
> the devices do it.  Until that happens, then it's completely useless to the
> helpdesk.
> It requires updates to DHCPv6 server, assuming that there is one, which if
> you are using SLAAC... you probably don't even have one.
> It does not require updates to the core routers, which is the only
> interesting part.  {But, in homes and small offices, and remotely supported
> small offices with a b2b ISP..., that's all the same openwrt box.}
> 
> It seems that if one already had an SNMP or YANG/NETCONF feed from the
> routers for the Neighbor Entry Cache, that feeding that into the "database"
> would be good.
> 
> Warren eventually says that he thinks this would be *more* complicated, and I
> read his slide 10.... and come-on.   You hacked up something that needs to be
> clearly coded correctly in the router.  Yes, it's chatty, but it doesn't need
> to tell about every state transition.
> BUT, even if it did, who cares if you can't read it scrolling on your screen.
> That's what the networking monitoring system is for.  Actually, I think you
> just proved how easily this could be done even without code changes to the routers.
> 
> So, I don't think that I agree at all.  The best part about linking it to the NCE
> is that if the NCE is bad, overwhelmed or has been forged, then the client
> machine probably doesn't get connectivity anyway.  There is some fate sharing here.
> 
> Another way would be to send the proposed DHCPv6 message along the DHCPv6-relay
> path.  This is very much akin to the Accounting records that radius sends.
> Doing it this way links the v6 address more directly to the MAC address,
> while not requiring the host to actually know what it is doing.
> 
> As Lorenzo says in the chat, it needs to be tied in "whatever" L2 security
> mechanisms they already have, but I'm not really sure how this should involve
> the client system.
> 
> And...if I was going to upload all the source code, the first thing I'd do is send
> one of these messages saying that I'm either the CEO, or the new hire, and then do it.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg