Why do you assume that the lease time has to be shortened, and how much?
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.
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.
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.
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.
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
--
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
|