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

[Nick Buraglio <[e-mail]>]

On Tue, Jan 2, 2024 at 4:54 PM 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.

Thanks, Mark.

I think this is where the disconnect really is. Historically this was
achieved with IPv4 DHCP, but even that is less and less common due to
rotating MACs for privacy enforcement. Without things like a NAC or
another form of access authentication, this data is not terribly
useful in a large section of off the shelf scenarios.

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

This is fairly straightforward on a cellular handset, but at that
point it's not even the MAC it's an ICCID, right?  For ethernet the
closest is the MAC, which on many platforms rotates unless that
feature is disabled, which it won't be unless dictated by policy and
probably central control.

>
> A device's IP addresses and MAC addresses can change regularly and automatically, and can be easily changed by a malicious actor.

Yes, I think this is the elephant in the room. With dynamic MAC
addresses as a default on many (most?) modern devices, what does the
mac/ip binding really buy? In some cases this gets manufacturer and a
rough approximation of location based on the switchport / mac table.
This is, of course, less of an issue for things like a broadband
network where a CPE is likely the demarc and access to the network is
controlled and tracked via that, which does *not* indicate user, but
instead only provides the responsible party, which may be very
different.

>
> A device's user can change, through being lent, stolen or sold.

In many cases this is probably ok to ignore, in my experience the case
of LE the investigating body uses their discretion to determine things
like that and often it's more about responsible party identification,
at least on a first order approximation. My data is a few years old,
and solely based on experience with federal entities in the US. But
like someone said way above, we can't really expect to solve every
problem for everyone.

>
> Any security system that needs to reliably attribute people's actions to IP and MAC addresses can't rely on this assumption.

I agree and I think that's really the point we have to come to terms
with. Unless we can implement something closer to an ICCID, and agree
that a responsible party is enough, the rest is at worst a security
theater operation or at best a compass that may point north.

This is precisely why I suggested we talk through what we need from a
requirements standpoint rather than a technology point of view. It's
easy to throw around technologies and say "I want this to do what that
does" when in reality that may not actually provide what is actually
required, or maybe even the wrong question being asked all together.
Tracking users in today's day and age is harder than most folks think,
and it almost certainly relies on correlating data unless there is
total control from endpoint to access egress, and even then it is only
going to lead to a responsible party, not necessarily the offending
person. I don't think we can actually trust a MAC to L3 binding as
correct or authentic, unless there is resource control at the end
point. The least common denominator we can do *today* is try to
correlate what existed at a given time on the network with the traffic
it generated. A prefix makes that at least a bit easier.
And realistically every time I have had to run down something
questionable or nefarious that's exactly what it came down to: when
was it on the network? where was it, approximately, and what traffic
did it generate? Anything else is investigated but can rarely be
corroborated without an actual hardware device or user login tied to
the access.

Enterprises operate differently. In many cases they can do things like
control the software load on the hosts and push policy, enforcing
behaviors. What I believe would solve more problems is better IPv6
support in existing tooling and products that are in use in
enterprises. This doesn't mean "make it like IPv4" it means "meet the
protocol where it is". and not trying to shoehorn a behavior into a
specific, existing way of thinking.

nb


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