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

[Nick Buraglio <[e-mail]>]

On Mon, Sep 25, 2023 at 9:27 AM Ole Troan <otroan=
[e-mail]> wrote:

> Mark,
>
> > 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.
>
> It’s a significant building block.
>
> > 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
>
> That was a dreadfully opinionated blogpost…
>
> DHCPv6 would give the network enough information to enforce which
> addresses a host is permitted to use. Using mechanisms like FHS (first-hop
> security) / SAVI.
>

Agreed. With the inclusion of tools like RA Guard and DHCP Snooping, one
can get pretty far down the path.  Pie in the sky desirable would be a
device manufacturer adding a DHCP snooping mechanism that requires the
inform to be reported before access is granted much like the DHCPv4
transaction function.

>
> With SLAAC there isn’t an equally robust mechanism available. And I’m not
> sure this helps.
>

It's certainly more than what is available now, and it fits within the
current use practices that many LANs currently use, which greases the
wheels of adoption of a technology that is already eliciting a notable
amount of apprehension for lots of LANs.


> As an DHCPv6 address assignment alternative the ARO option might have been
> better.
>
> To emphasise, this is for the use case of a network operator requires
> control of addresses in use by which device. Allowing IPv6 to support that
> use case does not mean there are many other use cases where SLAAC is
> perfectly fine.
>

I don't see it as control, per se, it's more about information for future
triage or forensics.  In concert with RA-guard, one could minimize the
rogue RAs, further reducing the blast radius. That's what this really reads
as to me is a blast radius container providing visibility when the
inevitability of a system with SLAAC address does something unsavory.  As a
data point, my looking at a very large scale network telescope / tarpit /
honeypot has shown 90%+ of IPv6 devices (which admittedly is not a lot of
IPv6 hosts comparatively speaking) that are caught by the honeypot / tarpit
are SLAAC addresses.
Being able to run those down to at the very least a device manufacturer and
the last known L2 location would go pretty far in the threat hunting
process.


>
> O.
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>