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

[Daryll Swer <[e-mail]>]

>
> There is a fundamentally flawed assumption that all of the DHCP-only based
> schemes depend on.



The assumption is that device IDs are reliable individual person IDs.

I believe I already explained last year, somewhere in the massive email
thread. We don't rely on MACs solely for reliability identification, we
also account for MAC privacy rotation.

It's a combination of MAC<>IP Address Binding/Assignment topped off with
some userID factor, which could be either 802.1x or captive-portal based
user-login.

You can change your MAC address for your iPhone once per 5 hours that is
connected to my network, I don't care. I can still identify you. The /128
ia_na (or /127 ia_pd), that was assigned when you logged in, is logged:
v6 na,pd > MAC Address at the time > userID

The authorities come to my office, gives me a /128 address and a timestamp,
I check my logs, oh here you go:
This /128 at the stated timestamp was assigned to this MAC, who in turned
was tied to userID XYZ.
The /128 can either be ia_na or fall within the /127 ia_pd.

Nobody in their right mind would rely solely on a MAC address in 2024.

You could argue, “Why not dump the MAC address, then?” Well, the MAC
address is more for real-time on-site internal audit/troubleshooting etc,
not all of my client devices rotate MACs 24/7. Some end-hosts misbehave,
have some bug etc, including unmanned systems/IoT devices etc. We still
need MACs to track those.

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


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

>  There is a fundamentally flawed assumption that all of the DHCP-only
> based schemes depend on.
>
> The assumption is that device IDs are reliable individual person IDs.
>
> IP addresses and MAC addresses are assumed to be a person ID, such that
> traffic and actions that can be attributed to an IP address or MAC address
> can be reliably and accurately attributed to a single person.
>
> This is not the case unless there has been some authentication of the
> person that can tightly bind their identity to the IP addresses and MAC
> addresses of the device they're currently using.
>
> A device's IP addresses and MAC addresses can change regularly and
> automatically, and can be easily changed by a malicious actor.
>
> A device's user can change, through being lent, stolen or sold.
>
> Any security system that needs to reliably attribute people's actions to
> IP and MAC addresses can't rely on this assumption.
>
> Regards,
> Mark.
>
>
>
> On Wed, 3 Jan 2024, 09:03 Nick Buraglio, <[e-mail]>
> wrote:
>
>> This thread really went deep over the holiday =)
>>
>> Trying to recap a bit so we can re-focus, remembering that we are all
>> here for roughly the same reasons: to solve problems and because we
>> want to progress IPv6 deployments. I see a couple of topics at play
>> here:
>>
>> device tracking
>> log storage
>>
>> Folks see a need for tracking a device to a user with IPv6. - I get
>> this, I hear the same thing frequently. The commentary slides around
>> from a simple need to associate a hardware address with a layer 3
>> address to a full on mapping of user to device with a strong
>> preference by some to simply mimic what IPv4 does up to and including
>> state synchronization and redundancy of operations.
>> Personally, I don't think it is realistic to assume that we should
>> simply replicate something that exists already. We should aim for
>> whatever it is to be better and to address any shortcomings. I am very
>> excited about draft-ietf-dhc-addr-notification and prefix-per-device
>> as a solution set for most of what is discussed here.
>>
>> Of course, these mappings need to be stored somewhere and in cases
>> where logging may be of concern, I would compare much of this to
>> netflow and normal syslog generation - A reasonable amount of data
>> over a short period of time that is heavily influenced by activity on
>> the network. We have solutions for netflow storage, and we have well
>> traveled production options for log storage, all of which are tunable
>> and user controllable from a retention standpoint. I don't see this as
>> any different even if it means millions of logs. I am sure we have all
>> had to deal with that in the past, and that we all know it's not a
>> set-and-forget operation. Sizing and constant optimization is
>> important for any production system, regardless of size and scale.
>> With anything the logging is going to be wholly dependent on the long
>> term storage requirements. How long things need to be stored will
>> heavily influence how much storage is needed, and with text logs,
>> compression is extremely effective.
>>
>> As I write this, I am also reminded of the old adage I learned in the
>> early ISP days: "Cheap, Fast, Reliable. Pick two". I believe that is
>> still largely applicable here and with most technological solutions,
>> substituting "fast" for "easy", "approachable", "simple" or whatever
>> term applies for a given technology. We can't make the perfect the
>> enemy of the good.
>>
>> So, taking all specific technology out of the picture, what else are
>> we looking for besides device to address tracking and usable logging?
>> What parts of draft-ietf-dhc-addr-notification and prefix-per-device
>> *don't* do what is required? If we can identify the shortcomings then
>> we can work to address them.
>>
>> nb
>>
>>
>>
>>
>> On Tue, Jan 2, 2024 at 12:51 PM Ted Lemon <[e-mail]> wrote:
>> >
>> > Actually I think the expectation is that if the 'a' bit is set in a
>> prefix, you do SLAAC on that prefix regardless of whether or not you're
>> doing DHCPv6 based on the RA.
>> >
>> > On Tue, Jan 2, 2024 at 1:04 PM Owen DeLong <owen=
>> [e-mail]> wrote:
>> >>
>> >>
>> >>
>> >> On Jan 1, 2024, at 11:46, Brian E Carpenter <
>> [e-mail]> wrote:
>> >>
>> >> Simon,
>> >>
>> >> It doesn't matter. All nodes MUST contain a SLAAC implementation
>> because Node Requirements says so. You can't half-implement RFC 4862. The
>> node doesn't know what to do next unless it receives an RA, but it must be
>> ready to do SLAAC.
>> >>
>> >> I agree, we generally use the term "SLAAC" to cover the pre-RA steps,
>> because they don't have a separate name in RFC 4862.
>> >>
>> >> Owen is slightly wrong, though. Section 5.5.2 of RFC 4862 ("Absence of
>> Router Advertisements") clarifies that a node may try DHCPv6 in the absence
>> of any RAs. The M bit is not strictly required.
>> >>
>> >>
>> >> Fair enough, but that’s a “MAY” and not even a should, so it’s pretty
>> shaky ground if you’re counting on it happening that way.
>> >>
>> >>
>> >>
>> >> Regards
>> >>   Brian Carpenter
>> >>
>> >> On 02-Jan-24 08:18, Simon wrote:
>> >>
>> >> Owen DeLong <owen=[e-mail]> wrote:
>> >>
>> >> As conceived, DHCP6 doesn’t even start until you’ve completed most of
>> SLAAC (you need to receive an RA to even tell you to try DHCP6 in theory).
>> >>
>> >> Sorry, but I’m not up on the detail of DHCPv6, but is this actually
>> correct ?
>> >>
>> >> You don’t need to have done SLAAC, or even have any code for it, to
>> generate a LL address and be able to solicit/receive RAs. In fact, SLAAC
>> can’t be done until an RA has been received.
>> >>
>> >> Doesn't the same hold true for DHCP ?
>> >>
>> >>
>> >> Yes and no. As Brian notes, a host MAY try DHCPv6 if it doesn’t get an
>> RA. However, the expected usual case is that an RA is received. If the M
>> bit is set in the RA, then SLAAC is not completed and an IA_NA is requested
>> via DHCPv6. If the M bit is not set, SLAAC is completed (assuming a usable
>> PIO is present) and DHCPv6 will be consulted for other information if the O
>> bit is set.
>> >>
>> >> Well, DHCPv6 kind of requires 70+% of SLAAC to function…
>> >>
>> >>
>> >> Packet
>> >>
>> >>   SLAAC  DHCP
>> >>
>> >> 1 RS->   RS->
>> >>
>> >> 2 RA<-   RA< (+M,?O)
>> >>
>> >> 3 NS (DAD)->  DHCP6 solicit->
>> >>
>> >> You’ve missed out a step - address generation. You can’t do NS (DAD)
>> until you have generated a tentative address. And I’d argue that NS/RA
>> isn’t “part of SLAAC”, it’s “part of the IPv6 stack WHICH IS USED BY
>> ADDRESSING MECHANISMS” (note the plural). Or you could argue that if you
>> use static addressing then you are using 70% of the SLAAC code if the OS
>> does a sanity check before blindly configuring an address.
>> >>
>> >>
>> >> Yes, that step is required, but there’s no packet for it. It happens
>> internal to the host and is (usually) the same algorithm as LLA generation
>> which had to happen before you could send the RS.
>> >>
>> >> OWEN
>> >>
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/v6ops
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>