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

[Daryll Swer <[e-mail]>]

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

Didn't see this thread, but yes +1 to Brian.

Like I said in the original “thread”, nobody in their right mind in 2024
would rely on MACs *alone*.

I'm not aware of any modern day enterprise that says “Oh, I need *static*
MACs”. This whole discussion was never about static MACs, at all, was it?

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


On Wed, 3 Jan 2024 at 07:17, Brian E Carpenter <[e-mail]>
wrote:

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