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

[Daryll Swer <[e-mail]>]

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

I'll see if I can do something there, I may already know some folks who may
be interested.

But honestly, it's far easier and faster for an operator like me to ask a
vendor XYZ “Hey can you port over Kea state sync to your platform,
please?”, and they go “Oh, we'll look into it” and chances are in a few
months, “Change log line number 5: Added DHCPv6 state sync from Kea”, than
it is to politick in the mailing list for who knows how long before such a
draft gets approved if ever, full stop.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/link/d6348bc12fc364707fff9381511c0a27a1d56aee?url=https%3A%2F%2Fwww.daryllswer.com&userId=2153471&signature=eb649cf546b8fda6>


On Wed, 3 Jan 2024 at 03:21, Mark Smith <[e-mail]> wrote:

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