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

[Brian E Carpenter <[e-mail]>]

We seem to have changed the subject, so I've changed the Subject.

On 03-Jan-24 12:59, Nick Buraglio wrote:
> 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.

I don't think that's the assumption at all. It's more so the site security person can go to a specific desk, point at a specific device, and say "Who was using this at 10:38 a.m. last Tuesday?" (Or, of course, analyse logs to answer that question.) For a lot of obvious reasons, this question may be unanswerable or the answer will be untrue, but that is what identifying a device is for.

Now if we want to argue that MAC addresses are no longer reliable device IDs, I agree. I run this laptop on the MAC address originally assigned to the laptop I bought in 2012. I expect you can work out why.

If we want reliable device IDs, we really need to use IDevIDs with all the necessary cryptographic support.

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

How are enterprise networks going to deal with mutating MAC addresses?
If they rely on them for admission control to a LAN, VLAN or BSS,
things just won't work. A system like Eduroam, that depends on end-user
credentials rather than mutable numbers, seems much more robust.

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

Exactly.

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

Right. But using user credentials to validate users seems a lot more
to the point. At the moment, I think there must be a lot of enterprises
trying to forbid MAC address rotation and IPv6 temporary addresses,
but as King Cnut demonstrated about 1000 years ago, this approach
has its limits.
  
>>
>> 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.

Especially when that thinking (audit by MAC address and/or IP address)
is in the process of being overtaken by events.

     Brian

> 
> 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
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops