dhcpcd-discuss

Hi Roy,

On 8 Nov 2017, at 23:43, Roy Marples <roy@xxxxxxxxxxxx> wrote:
> 
> Hi Piers
> 
> On 08/11/2017 17:51, Piers O'Hanlon wrote:
>> I’ve implemented DNA (RFC4436) with some additional privacy enhancements into dhcpcd-6.11.1 - I wasn’t sure where/how I can pass you the code - if you’re interested?
> 
> I'm not a huge fan of that RFC.
> But you can post a patch here from the base of dhcpcd-6.11.1, or the source as a whole if it's easier.
> 
> From there we can work on patching the current git head to use it and then think about merging it post dhcpcd-7.0 release.
> 
Ok - I've attached a patch against dhcpcd-6.11.1. I’ve created some new config options that control the DNA functionality, which I've detailed below. The basic design is to store leases in the existing lease file format as used by dhcpcd and record the corresponding MACs as part of the filename. These are then loaded on startup and checked for validity (deleted if not longer valid) then tested for reachability - if a match is obtained it calls dhcp_reboot(), sending a DHCP REQUEST (like on iOS/OSX) to ensure validity of the requested IP address. I’ve done some simulation based testing of the code and it has been stable but it may need some additional work.

The code was done as part of an EU (5gensure.eu) project for which I wrote some docs - See page 52 onwards:
http://5gensure.eu/sites/default/files/Deliverables/5G-ENSURE_D3.4_5G-PPP_Security_Enablers_Documentation.pdf

There’s a newer deliverable (D3.8) on it’s way but the main info of interest with respect to config and functionality of the final version (R2) is:

•  Enable Detection of Network Attachment (DNA) functionality (opt: dna <no args> )
	- Enables Base DNA (RFC4436) functionality
• Randomised ordering (opt: dna_random <integer> [1: Enable randomised ordering of DNA requests])
	- This mechanism provides for randomised delivery of candidate link layer addresses in the DNA reachability tests, so as to enhance the location privacy with respect to the location and time-based analysis of the device’s movement patterns.
• Dummy addresses (opt: dna_dummy <integer> [0-N: Number of dummy addresses, -1: Automatic choice of number of dummy addresses])	
	- This mechanism allows for the introduction of dummy addresses into the DNA reachability tests to enhance location privacy, with respect to location identification and time-based analysis of the device’s movement patterns.
	- With the R2 release, we introduce a new option that provides for automated the choice of the number of dummy addresses.
* Pre-analysis phase of the address privacy metrics (opt: dna_preanalysis <integer> [1: Enable use of geolocation based pre-filtering of DNA requests]; opt: dna_geourl  <string:URL> [URL to be used for geolocation (Google Geolocate json-based API e.g. https://www.googleapis.com/geolocation/v1/geolocate?key=GOOGLE_API_KEY )
	- This mechanism allows for the set of existing candidate link layer (MAC) addresses for DNA to be analysed once assigned but before use in DNA to ascertain their privacy metrics with release Release v2. Specifically, we provide for the option to check and filter geolocatable candidate MAC address pairs so that a device can’t be easily geolocated from their DNA reachability tests.
	
I imagine you may not be interested in all my additional functionality though it all adds some additional measure of privacy to the protocol - I guess the dna_preanalysis may lead to unwanted additional traffic.

Best,

Piers

Attachment: dhcpcd-6.11.1-DNA.patch
Description: Binary data

> Thanks
> 
> Roy