The words you are searching are inside this book. To get more targeted content, please make full-text search by clicking here.

DHCP Anonymity Profile Update h"ps://datatracker.ie0.org/doc/dra4ie04dhc4 anonymity4profile/: IETF:93,:Prague,:July:2015: 7/23/2015 DHCP:Anonymity:Profile:44:IETF:93: 1

Discover the best professional documents and content resources in AnyFlip Document Base.
Search
Published by , 2016-04-10 20:09:03

DHCP Anonymity Profile Update

DHCP Anonymity Profile Update h"ps://datatracker.ie0.org/doc/dra4ie04dhc4 anonymity4profile/: IETF:93,:Prague,:July:2015: 7/23/2015 DHCP:Anonymity:Profile:44:IETF:93: 1

DHCP Anonymity
Profile Update

h"ps://datatracker.ie0.org/doc/dra3-­‐ie0-­‐dhc-­‐
anonymity-­‐profile/
 

IETF
 93,
 Prague,
 July
 2015
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  1
 

Prototype Implementation

•  Developed
 by
 Nick
 GriRa
 on
 test
 version
 of
 
Windows
 10
 (not
 in
 the
 product
 yet)
 

•  Implemented
 both
 DHCPv4
 and
 DHCPv6
 versions
 

•  Straigh0orward
 
•  Implementa[on
 choice:
 do
 not
 send
 Host
 Name,
 FQDN
 
•  Needed
 variance
 on
 DHCPv6
 CONFIRM
 –
 performance
 

issue
 

•  Alternate
 behavior
 triggered
 by
 use
 of
 Random
 
MAC
 Address
 

•  Addi[onal
 complexity
 is
 modest
 


 7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  2
 

Trials in the wild

•  Tested
 on
 9
 different
 Wi-­‐Fi
 hot
 spots
 in
 Bellevue
 /
 
Sea"le
 area
 

•  Ranged
 from
 big
 brands
 (ATT
 Wi-­‐Fi,
 Google)
 to
 cafes
 and
 
public
 library
 

•  Connec[on
 (almost)
 always
 succeeded
 

•  One
 excep[on:
 Wi-­‐Fi
 network
 did
 not
 allow
 connec[on
 using
 
randomized
 MAC
 Address.
 
 

•  DHCP
 profile
 itself
 did
 not
 cause
 any
 failure
 

•  Confirms
 validity
 of
 “No
 Name”
 op[on
 

•  DHCP
 servers
 do
 not
 actually
 need
 the
 name
 of
 your
 device
 
•  Changed
 dra3
 to
 “SHOULD
 avoid
 sending
 the
 host
 name
 

op[on.”
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  3
 

Summary of changes

•  Sec[on
 2.6.
 Using
 the
 anonymity
 profiles,
 sta[c
 vs.
 mobile.
 
•  Sec[on
 3.4.
 Client
 Iden[fier
 Op[on,
 for
 PPP
 links
 
•  Sec[on
 3.5.
 Default
 to
 not
 sending
 Host
 Name
 
•  Sec[on
 3.5.
 If
 sending
 Host
 Name,
 obfuscate,
 don’t
 leak
 

MAC
 Address
 
•  Sec[on
 4.
 Prefer
 Stateless
 IPV6
 address
 configura[on
 when
 

possible
 
•  Sec[on
 4.1.
 Allow
 DHCPv6
 CONFIRM
 when
 roaming
 

between
 Access
 Points
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  4
 

Next step?

•  Do
 we
 need
 anything
 more
 before
 last
 call?
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  5
 

Background slides

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  6
 

History

•  Presented
 dra3-­‐huitema-­‐dhc-­‐anonymity-­‐profile
 at
 
IETF
 92,
 Dallas.
 

•  Revised
 with
 Tomek
 Mrugalski,
 Suresh
 Krishnan
 
•  Adopted
 by
 WG.
 
•  Version
 01
 published
 June
 30,
 2015
 
•  Feedback
 from
 mailing
 list,
 implementa[on,
 trials
 
•  Version
 01
 published
 June
 30,
 2015
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  7
 

Feedback on DHCPv6 Confirm

•  Found
 one
 issue
 with
 DHCPv6
 CONFIRM
 

•  Used
 when
 roaming
 between
 access
 points
 
•  Code
 has
 logic
 to
 recognize
 “same
 network”
 using
 Wi-­‐Fi
 

authen[ca[on
 
•  DHCPv6
 CONFIRM
 allows
 for
 con[nuous
 connec[vity,
 

instead
 of
 full
 DISCOVER/REQUEST
 cycle.
 

•  Updated
 dra3
 to
 allow
 CONFIRM
 when
 roaming
 
between
 wireless
 AP
 in
 same
 network.
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  8
 

Feedback: different networks,
use cases

•  Some
 networks
 do
 not
 use
 “link
 layer
 addresses,”
 
users
 s[ll
 need
 privacy:
 

•  Added
 text
 in
 sec[on
 3.4.
 Client
 Iden[fier
 Op[on
 
•  Sugges[on:
 Pick
 random
 iden[fier,
 unique
 to
 current
 

link.
 

•  Case
 of
 “shared
 alloca[on”
 (dra3-­‐ie0-­‐dhc-­‐dynamic-­‐
shared-­‐v4alloca[on):
 

•  Added
 text
 in
 sec[on
 2.6.
 Using
 the
 anonymity
 profiles
 
•  Dis[nguish
 between
 “stability
 for
 sta[c
 clients”
 and
 

“privacy
 for
 mobile
 clients”
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  9
 

Feedback: don’t leak the
random MAC

•  Previous
 version
 suggested
 construc[ng
 an
 
“anonymized
 host
 name”
 as
 HEX
 rendering
 of
 
Random
 MAC
 Address.
 

•  Problem:
 names
 leak
 outside
 the
 scope
 of
 the
 link,
 
and
 leaking
 MAC
 Addresses
 outside
 of
 their
 scope
 
increases
 the
 a"ack
 surface.
 

•  Changed
 the
 suggested
 construc[on
 to
 “HEX
 of
 
Hash(secret,
 MAC)”
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  10
 

Feedback: for DHCPv6, prefer
stateless

•  Feedback
 expressed
 during
 IETF
 92,
 incorporated
 in
 
dra3
 00:
 

•  …
 When
 these
 op[ons
 enable
 stateless
 address
 
configura[on
 hosts
 using
 the
 anonymity
 profile
 SHOULD
 
choose
 it
 over
 stateful
 address
 configura[on…
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  11
 

Feedback on DHCPv6 Confirm

•  Found
 one
 issue
 with
 DHCPv6
 CONFIRM
 

•  Used
 when
 roaming
 between
 access
 points
 
•  Code
 has
 logic
 to
 recognize
 “same
 network”
 using
 Wi-­‐Fi
 

authen[ca[on
 
•  DHCPv6
 CONFIRM
 allows
 for
 con[nuous
 connec[vity,
 

instead
 of
 full
 DISCOVER/REQUEST
 cycle.
 

•  Updated
 dra3
 to
 allow
 CONFIRM
 when
 roaming
 
between
 wireless
 AP
 in
 same
 network.
 

7/23/2015
  DHCP
 Anonymity
 Profile
 -­‐-­‐
 IETF
 93
  12
 


Click to View FlipBook Version