Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-Privacy] February 4 - Teleconference details

Summary: It's a tool that might be valuable for some.

On Wednesday, February 4, 2015, Christian Huitema <huitema@xxxxxxxxxxxxx> wrote:

Why do you assume that the lease time has to be shortened, and how much?

I'm not assuming it has to be. It certainly depends on the client implementation and usage, as well as the server config to start with. Many DHCP servers are configured to give 24 hour leases, so I'll use that number here. Different conclusions may be reached with different values.

Also, different installations will have different ratios of clients to IPv4 pool size, and different numbers of clients seen over the lease period vs. the total possible clients. So some installations are more aggressive about reclaiming IPv4 addresses, and may desire a different lease time for clients using local MAC addresses.

Installations with DHCP servers run on processor or I/O limited boxes may be more concerned about the load on the server, possibly leading to a different conclusion.

It is possible that folks using random MAC addresses will consume more IPv4 addresses from a given DHCP pool over a given time period. I'm going to use 24 hours here.

When implementing random MAC addresses, there are many reasons to keep them “somewhat stable.” Changing the MAC address on an interface very much implies getting new IP address, and that means resetting all the TCP connections bound to that interface. If behind a NAT, that means doing NAT traversal again to reestablish the VoIP and other P2P connections. If on a hot spot, that means another round of “web portal capture.”

 

The sweet spot for MAC address randomization is probably to pick a new MAC address just before connecting to a new Wi-Fi network. In practice, that means the MAC address should remain in use for the duration of the connection to the Wi-Fi network, which is pretty much the “natural” duration of the DHCP lease.

This is certainly one possible use case. And one that still suggests shorter lease times might be desired. An issue is that the frequency of or trigger for a MAC address change is determined by the client, while the duration of the DHCP lease is determined by the server. 

A typical work day may include multiple connections to a network broken up by natural breaks like lunch. This break might result in a change of MAC address on a particular client.

A client that doesn't want to be tracked from home to coffee shop to work to lunch to work to dinner to home may change their MAC address several times a day, with different MACs seen by the same network in the course of a day.

This leads me to believe we need the capability of varying the DHCP lease time based on the setting of the local bit, just as typical DHCP servers typically vary the lease time on different pools. Guest networks often have shorter lease times for example.

The impact of shorter lease times is predictable on both the client and server, and, for "reasonable" numbers, the impact is low on both.

I understand that nothing prevents a system from resetting their MAC address every few seconds. But this is not normal behavior. In fact, a misbehaving system could also resets it MAC address to a fake “globally assigned” value. I am not sure that your protection against this type of attacks has to be conditioned to the use of the local bit.

I'm not trying to address this concern.

In my particular use case, expanding the MAC privacy experiment across all IETF networks, we will be able to evaluate the frequency of MAC changes and experiment with adjusting lease times. And I expect the frequency of MAC changes during this experiment to be higher than what might be expected in the real world, so I'll be setting the lease times for local MACs lower than our typical setting.

Chris.

From: Chris Elliott [mailto:chelliot@xxxxxxxxx]
Sent: Tuesday, February 3, 2015 9:45 PM
To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-Privacy] February 4 - Teleconference details

 

On Tue, Feb 3, 2015 at 11:13 PM, Robert Moskowitz <rgm@xxxxxxxxxxxxxxxxxxxx> wrote:

What about devices that 'legitimately' use local MACs?  Like my armv7 Cubie boards?  I now have a Fedora Rawhide build that has the video working...

 

Good question--I would have guessed this would have come up earlier, and I'm certainly not an expert here. All I'm doing is decreasing the IPv4 lease time. So, for the "innocent" devices you mention, I'll suggest there's two possible impacts, one with minimal consequence, and the other with a very remote chance of occuring:

 

1. Shortened lease time for the "innocent" will require them to request leases more frequently. The impact of this is minimal, as long as you have a reliable DHCP server, and a reliable connection to it. I'll suggest that, if you don't have both of those you have bigger problems that should be resolved.

 

2. A collision of the "innocent" with a random MAC address. I think there's plenty of documentation on this list and elsewhere how unlikely a collision is if you have 2^46 bits to play with. And there have been suggestions on how to handle such collisions, including listening or probing for devices on the network with your selected random address to your own (Bob) proposal for a MAC address mediator.

 

Chris.

 

On 02/04/2015 12:03 AM, Chris Elliott wrote:

JC, et. al.,

 

So I've now tested a config stanza extensively for ISC-DHCPD that works well, and tests just for the local bit. For those that just want to implement it, here's the stanza to put in your subnet definitions to modify the lease time for leases with the local bit on in the client's MAC address:


if (substring(reverse(1,binary-to-ascii(2, 8, ":", substring(hardware,1,1))), 1, 1) = "1") {
           default-lease-time 1800;
}
else {
           default-lease-time 14400;
}

 

This works well, and is minimally invasive.

 

Here's the debug version I used to get it right, with comments explaining all the pieces:


# Grab the first byte of the MAC address
set bytemac = substring(hardware,1,1);

# Strictly for logging (printing)
set byteprt = binary-to-ascii(16,8,":", bytemac);

# Make it binary so we can select the bit in question
set binmac = binary-to-ascii(2, 8, ":", bytemac);

# isc-dhcp-server truncates leading zeros, so we need to reverse the string, then the local bit is the second
set localbit = substring(reverse(1,binmac), 1, 1);

# Log it to see if it's right...
if localbit = "1" {
          log (error, concat("dhcpd local bit, bytemac: .",byteprt,". binmac: .", binmac, "., localbit: .", localbit, "."));
}

 

I'm comfortable using this on all the subnets, so I'm recommending we modify the experiment at the next IETF meeting in Dallas to allow MAC address randomization on all user subnets.

 

I'm not planning on being at the IEEE meeting coming up, so I'll leave it up to those that will whether you want to give this a go.

 

I may be able to join the call tomorrow, if things here continue to go well.

 

Enjoy!

Chris.

 

 

On Tue, Feb 3, 2015 at 10:24 AM, Warren Kumari <warren@xxxxxxxxxx> wrote:

On Mon, Feb 2, 2015 at 5:15 PM, Carlos Jesús Bernardos Cano
<cjbc@xxxxxxxxxx> wrote:
> Hi Juan Carlos, all,
>
> We continue working on the update of the scripts & tools to perform MAC
> address randomization automatically in the upcoming experiments.
> Unfortunately, this time I will not be able to join the teleconference
> this time.

Neither will I, but while Chris Elliot and I were helping build the
NANOG network we took some time out to build and test configs for ISC
DHCPd for MAC randomization.

We tested 2 configs, the first matches a first octet of '0x06'
(leaving 40 bits to be randomized)  and the second attempts to match
just the local bit. The first is much simpler, got more testing, and
(IMO) gives more than enough space
(http://mac-collision-probability.appspot.com/calculate ), the second
is a bit sexier, but we didn't get as much testing time and is a bit
back magic.

First examplet:
class "Random_MAC" {
      # Locally assigned, restricting the MAC space to 06 (2^40bits)
      match if (substring(hardware, 1, 1)) = 06;
      }

# test
subnet 192.168.1.128 netmask 255.255.255.128 {
        pool {
          authoritative;
          range 192.168.1.160 192.168.1.200;
          allow members of "Random_MAC";
          option routers 192.168.1.129;
          option domain-name              "meeting.example.com";
          option domain-name-servers      192.168.1.12, 192.168.1.13;
          # 30 minutes.
          default-lease-time 1800;
          }

        pool {
          authoritative;
          range 192.168.1.130 192.168.1.159;
          option routers 192.168.1.129;
          default-lease-time              14400;
          option domain-name              "meetings.example.com";
          option domain-name-servers      192.168.1.12, 192.168.1.13;
        }
}

Second example:

      # Locally assigned bit matching...
      set bytemac = substring(hardware,1,1);
      set byteprt = binary-to-ascii(16,8,":", bytemac);
      set binmac = binary-to-ascii(2, 8, ":", bytemac);
      set localbit = substring(reverse(1,binmac), 1, 1);
      if localbit = "1" {
        log (error, concat("dhcpd local bit, bytemac: .",byteprt,".
binmac: .", binmac, "., localbit: .", localbit, "."));
      }

class "Random_MAC" {
      # Locally assigned, restricting the MAC space to 06 (2^40bits)
      match if localbit = "1";
      }

# test
subnet 192.168.1.128 netmask 255.255.255.128 {
        pool {
          authoritative;
          range 192.168.1.160 192.168.1.200;
          allow members of "Random_MAC";
          option routers 192.168.1.129;
          option domain-name              "meeting.example.com";
          option domain-name-servers      192.168.1.12, 192.168.1.13;
          # 30 minutes.
          default-lease-time 1800;
          }

        pool {
          authoritative;
          range 192.168.1.130 192.168.1.159;
          option routers 192.168.1.129;
          default-lease-time              14400;
          option domain-name              "meetings.example.com";
          option domain-name-servers      192.168.1.12, 192.168.1.13;

        }
}




>  I'll check the minutes after and keep the list posted on our
> progress.
>
> Thanks,
>
> Carlos
>
> On Mon, 2015-02-02 at 19:40 +0000, Zuniga, Juan Carlos wrote:
>> Dear all,
>>
>>
>>
>> Below are the details of our next teleconference on Wednesday.
>>
>>
>>
>> This time the main topic will be the discussion and pre-circulation of
>> the group’s PAR/CSD (i.e. Charter) for consideration at the March 2015
>> meeting.
>>
>>
>>
>> We will also discuss the plans to do the MAC address randomization
>> experiment at the upcoming IEEE 802 Berlin plenary and IETF 92 Dallas
>> meetings.
>>
>>
>>
>> As a friendly reminder, you should plan to spend 2-3 minutes
>> connecting to WebEx, just in case.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Juan Carlos
>>
>>
>>
>> ---------------
>>
>> Agenda
>>
>> ---------------
>>
>> •         Welcome
>>
>> •         Chair's slides
>>
>> –       IEEE Slides
>>
>> –       Call meeting to order
>>
>> •         Group’s updates
>>
>> –       Privacy EC SG PAR/CSD
>>
>> –       IETF MAC address randomization trial – next steps
>>
>> •         Technical Topics
>>
>> –       Threat Model for Privacy at Link Layer
>>
>> –       Privacy Issues at Link Layer
>>
>> –       Proposals regarding functionalities in IEEE 802 protocols to
>> improve Privacy
>>
>> –       Proposals regarding measuring levels of Privacy on Internet
>> protocols
>>
>> –       Implications of MAC address changes
>>
>> –       Other
>>
>> •         Next Steps
>>
>>
>>
>> ---------------
>>
>> Chair’s slides
>>
>> ---------------
>>
>> https://mentor.ieee.org/privecsg/dcn/15/privecsg-15-0005-00-ecsg-feb-4-conf-call-slides.pptx
>>
>>
>>
>> ---------------
>>
>> Meeting information
>>
>> ---------------
>>
>> Topic: EC Priv Recomm SG #5
>>
>> Date: Wednesday, February 4, 2015
>>
>> Time: 10:00 am, Eastern Standard Time (New York, GMT-05:00)
>>
>> Meeting Number: 746 673 385
>>
>> Meeting Password: privecsg
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>>
>> To join the online meeting (also from mobile devices)
>>
>> -------------------------------------------------------
>>
>> 1. Go to
>> https://premconf.webex.com/premconf/j.php?MTID=m8a4786c5b454adf48f45b879102e172e
>>
>> 2. If requested, enter your name and email address.
>>
>> 3. If a password is required, enter the meeting password: privecsg
>>
>> 4. Click "Join".
>>
>>
>>
>> To view in other time zones or languages, please click the link:
>>
>> https://premconf.webex.com/premconf/j.php?MTID=meac83add1b23800f65b22f624b011066
>>
>>
>>
>> -------------------------------------------------------
>> To join the teleconference only
>> -------------------------------------------------------
>> Provide your phone number when you join the meeting to receive a call
>> back. Alternatively, you can call:
>> Call-in number (Premiere): 1-719-867-1571  (US/Canada)
>> Show global numbers:
>> https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=542167&num=1&num2=1719-867-1571
>> Attendee access code: 542167
>>
>>
>>
>>
>>
>>


--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf



 

--

Chris Elliott
chelliot@xxxxxxxxx

"What the f*ck is a sesame? It's a street...it's a way to open sh*t!" --Mitch Hedberg

 

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      rgm@xxxxxxxxxxxxxxxxxxxx

There's no limit to what can be accomplished if it doesn't matter who gets the credit



 

--

Chris Elliott
chelliot@xxxxxxxxx

"What the f*ck is a sesame? It's a street...it's a way to open sh*t!" --Mitch Hedberg



--
Chris Elliott
CCIE # 2013

“You and I are mirages that perceive themselves”
--Douglas Hofstadter