Re: [v6ops] Why should IP networks be different? [DHCP Option 108 Issue with Mac and iOS devices]

[Mark Smith <[e-mail]>]

On Wed, 3 Jan 2024 at 03:41, Daryll Swer <contact=
[e-mail]> wrote:

> I've given much thought to this DHCPv6/SLAAC debate over the week, and my
> final opinion is.
>
> 1. The “address notification” mechanism likely just adds more complexity
> (and the time required for devices to support it) vs just fixing ia_na
> specific issues
> 2. The “state sync” problem is fixed in ISC Kea, which means there's no
> technical reason for the IETF to not adopt the open source protocol into a
> standard
>

If you wish Kea's state sync mechanism to be documented and possibly
standardised in an RFC, it is up to you to write or get written the
Internet Drafts and submitted to the appropriate IETF working group, as the
start of the process to gain consensus, which then may or may not result in
an RFC (which are also fundamentally voluntary to comply with).

Don't expect the IETF to do that work just because you ask for it. That's
not how the IETF works. You have to invest your own time and resources in
the work if you want that work to occur. Other IETF participants may help
you if they're interested in what you're proposing.


> 3. I will recommend enterprises do “Do IPv6 for everything but Android”
> (already the reality as is)
> 4. ia_na does help with traceroutes/troubleshooting vs link-local for
> PD-only
>
> I'm not sure if the time/energy required for “address notification” top to
> bottom, is significantly less than what would be required to patch ia_na
> specific issues.
>
> *--*
> Best Regards
> Daryll Swer
> Website: daryllswer.com
> <https://mailtrack.io/link/b8fbb9af84a504e9046468dc0a0438e543cb4486?url=https%3A%2F%2Fwww.daryllswer.com&userId=2153471&signature=dd709ee618d93ac2>
>
>
> On Tue, 2 Jan 2024 at 21:28, Ted Lemon <[e-mail]> wrote:
>
>> It's rather unkind of you to respond to a thoughtful answer that I took
>> some time to compose with an accusation that it came from ChatGPT. I have a
>> lot going on today, and participating in this conversation isn't free for
>> me. I would encourage the chairs to weigh in on whether they think this is
>> appropriate.
>>
>> That said, I agree with (what I think is) your point: if the DHCP address
>> registration is not enforced with e.g. 802.1x, it's actually harmful. But
>> the same criticism is also valid for the DHCPv6 IA_NA use case, so I don't
>> think you've said anything new. This is precisely why there isn't consensus
>> to require these mechanisms: by default they don't do what people want them
>> to do. But it's easy to pretend that they do, and that leads to bad
>> outcomes for end users. As the service provider, unless you can be held
>> liable for false accusations (and they can be proven) you can freely accuse
>> your users of bad behavior and back it up with your DHCPv6 logs, and it's
>> likely that you won't be held accountable for any accidental false
>> accusations that you make in good faith.
>>
>> In case it's not obvious, I'm not actually advocating for this. I think
>> it's a bad idea. It's not an accident that I used the term "surveillance"
>> in my previous message.
>>
>> On Tue, Jan 2, 2024 at 10:44 AM Ole Troan <[e-mail]> wrote:
>>
>>> Ted,
>>>
>>> ChatGPT?
>>>
>>> For an idea of what the network does already:
>>>
>>> https://www.cisco.com/c/en/us/td/docs/routers/7600/ios/15S/configuration/guide/7600_15_0s_book/IPv6_Security.pdf
>>>
>>>
>>> Again, I can’t quite see how the DHCPv6 registration mechanism would
>>> help the network in tracking endpoints.
>>> Given that the network cannot trust the hosts that support the mechanism
>>> to provide a truthful answer, then you have the other set of endpoints that
>>> do not support the mechanism at all, which the network also has to handle.
>>>
>>> I may have missed it, but I have not seen this question answered in the
>>> draft, nor in your reply.
>>>
>>> O.
>>>
>>>
>>> > On 2 Jan 2024, at 16:31, Ted Lemon <[e-mail]> wrote:
>>> >
>>> > If the problem is attributing flows to particular users, then you need
>>> a way to associate a particular flow with a particular user. The easiest
>>> way to do this is with the IP address of the non-server endpoint of the
>>> flow (that is, the IP address the surveilled device is using to
>>> communicate). So you have two things you need to do to be able to
>>> successfully do this attribution:
>>> >
>>> > 1. Establish an association between a device/user and every IP address
>>> that device will use to communicate with other devices where surveillance
>>> is required.
>>> > 2. Make sure only the owner of the device is able to successfully use
>>> each such IP address to communicate.
>>> > 3. Maintain a record of what IP addresses were in use by what devices
>>> during what time periods.
>>> >
>>> > So, DHCPv6 IA_NA and DHCPv6 address registration provide a way for a
>>> host to communicate the IP addresses it is using to a DHCPv6 server. The
>>> DHCPv6 server can log these addresses. It can also reach out and enable
>>> those addresses on the per-port filter for ethernet, or per 802.1x identity
>>> for WiFi. This is all stuff we've talked about many times before.
>>> >
>>> > One slight issue we'd need to be sure of is that the DHCPv6 address
>>> registration packet comes from a link-local address, so that it's not
>>> filtered. I think that's contrary to what the document currently says.
>>> >
>>> >
>>> > On Tue, Jan 2, 2024 at 9:54 AM Ole Troan <[e-mail]> wrote:
>>> > Since the network has to do enforcement anyway, then it can do so with
>>> existing mechanisms.
>>> > Are you suggesting that network enforcement of devices somehow become
>>> easier with the proposed mechanism?
>>> > If so, how exactly?
>>> >
>>> > O.
>>> >
>>> > > On 2 Jan 2024, at 15:49, Ted Lemon <[e-mail]> wrote:
>>> > >
>>> > > Presumably if the user disables tracking on their host, the network
>>> won't allow them transit, so problem solved. Without that enforcement
>>> mechanism, there's no point in implementing DHCPv6-based tracking: the
>>> notion that you can just assume based on the source address that the packet
>>> originated from a particular host is actively harmful, because it creates
>>> an opportunity for malware to spoof a host and engage in bad actions, which
>>> will then be blamed on the legitimate owner of that host.
>>> > >
>>> > > Indeed, in order to be able to reliably attribute traffic from a
>>> particular IP address to a particular host or user, the filtering would
>>> need to be done in a way that can't be spoofed—at Tim says, using 802.1x
>>> might prevent this since the packets are all signed with a per-host key (if
>>> I understand it correctly—not claiming to be an expert).
>>> > >
>>> > > On Tue, Jan 2, 2024 at 9:33 AM Ole Troan <[e-mail]>
>>> wrote:
>>> > > > In order to disable it, you have to be on a network that allows
>>> arbitrary devices to be DHCPv6 servers. So I think it's still useful, since
>>> blocking DHCP from unauthorized servers isn't that hard. Even if you aren't
>>> actively blocking it, finding a DHCPv6 server that's poisoning the well
>>> isn't that hard.
>>> > >
>>> > > The user of a host that doesn’t want tracking can disable it for
>>> that host.
>>> > > Rendering the mechanism less than useful for the problem of tracking
>>> hosts on a network.
>>> > >
>>> > > O.
>>> >
>>> >
>>>
>>>
>>> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>