6lo Privacy Considerations

Slides:



Advertisements
Similar presentations
Transitioning to IPv6 April 15,2005 Presented By: Richard Moore PBS Enterprise Technology.
Advertisements

IPv6 Privacy Hannes Tschofenig, Tara Whalen. Agenda Privacy Threats Layering Addressing Policy Questionnaire.
IETF 651 Issues With Protocols Proposing Multilink Subnets draft-thaler-intarea-multilink-subnet-issues-00.txt Dave Thaler
Health IT RESTful Application Programming Interface (API) Security Considerations Transport & Security Standards Workgroup March 18, 2015.
Network Interop OpenSG 11/2/10 Tom Herbst. Agenda Opening Intro to Interop IETF Draft for Smart Energy Ongoing Work.
CSIS 4823 Data Communications Networking – IPv6
Concerns about designating the MAG as a Default Router James Kempf NETLMM Interim Sept. 27, 2006.
Draft-ietf-v6ops-scanning-implications-00 IPv6 Implications for Network Scanning Tim Chown University of Southampton (UK) IETF 66,
Security Implications of sharing an IPv4 address Gabor Bajko Pierre Levis
03/11/200871st IETF Meeting - 6LoWPAN WG1 Compression Format for IPv6 Datagrams in 6LoWPAN Networks Jonathan Hui 6LoWPAN WG Meeting 71 st IETF Meeting.
07/24/200769th IETF Meeting - 6LoWPAN WG1 IPv6 Header Compression for Global Addresses Jonathan Hui David Culler draft-hui-6lowpan-hc1g-00 – “Stateless.
IPv6 Address Accountability Considerations draft-chown-v6ops-address-accountability-01 IETF81, Quebec Tim Chown, July 28 th, 2011.
(we need your advice!) Jon Peterson MIT– December 2010 IETF & Privacy.
1 RFC Transmission of IPv6 Packets over IEEE Networks Speaker: Li-Wen Chen Date:
Draft-chown-v6ops-port-scanning-implications-02 IPv6 Implications for TCP/UDP Port Scanning Tim Chown IETF 65, March 23rd 2006 Dallas,
Privacy Extensions for Stateless Address Autoconfiguration in IPv6(RFC 3041) 1.
Managing the Use of Privacy Extensions for SLAAC in IPv6 (draft-gont-6man-managing-privacy- extensions-01.txt) Fernando Gont (UTN/FRH) Ron Broersma (DREN)
Guidance for Running Multiple IPv6 Prefixes (draft-liu-v6ops-running-multiple-prefixes-02) Bing Liu, Sheng Jiang (Speaker), Yang Bo IETF91
Network Architecture Protection (draft-vandevelde-v6ops-nap-01.txt) Brian Carpenter, Ralph Droms, Tony Hain, Eric L Klein, Gunter Van de Velde.
6lowpan ND Optimization draft Update Samita Chakrabarti Erik Nordmark IETF 69, 2007 draft-chakrabarti-6lowpan-ipv6-nd-03.txt.
Guidance of Using Unique Local Addresses draft-liu-v6ops-ula-usage-analysis-05 draft-liu-v6ops-ula-usage-analysis-05 Bing Liu(speaker), Sheng Jiang, Cameron.
Analysis and recommendation for the ULA usage draft-liu-v6ops-ula-usage-analysis-00 draft-liu-v6ops-ula-usage-analysis-00 Bing Liu(speaker), Sheng Jiang.
Commissioning in 6LoWPAN Ki-Hyung Kim (picosNet Corp/Ajou University) and S. Daniel Park (SAMSUNG Electronics) 6LoWPAN WG, IETF70, Vancouver.
6LoBAC: A new IPv6 Data Link
1 Framework for IPv4/IPv6 Multicast Translation draft-venaas-behave-v4v6mc- framework-03.txt.
Security Implications of Predictable Fragment Identification Values
Host Scanning in IPv6 Networks (draft-gont-opsec-ipv6-host-scanning) IETF 84 Vancouver, Canada. July 29-August 3, 2012.
1 Computer Networks Chapter 5. Network layer The network layer is concerned with getting packets from the source all the way to the destination. Getting.
Transmission of IP Packets over IEEE 802
Security in Internet of Things Begins with the Data
Outline The basic authentication problem
IPv6 over MS/TP Networks
IoT Integration Patterns, REST, and CoAP
Security&Privacy Considerations for IP over p OCB
Encryption and Network Security
THE NEED FOR DNS DOMAIN NAME SYSTEM
Transmission of IPv6 Packets over IEEE OCB Networks
Carles Gomez, S. M. Darroudi
Instructor Materials Chapter 8: Subnetting IP Networks
Carles Gomez, S. M. Darroudi
Compression Format for IPv6 Datagrams in 6LoWPAN Networks
IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
IPv6 Autoconfiguration Plug & Play Dream or Security Nightmare
Multiple Encapsulation Methods
Hashing - Hash Maps and Hash Functions
Presented by: Jeffrey D. Bombell, American Computer Technologies
Chapter 8: Subnetting IP Networks
What Could Possibly Go Wrong? Jen Linkova,
Stateless Source Address Mapping for ICMPv6 Packets
AP CSP: Bytes, File Sizes, and Text Compression
Dave Thaler A Comparison of Mobility-Related Protocols: MIP6,SHIM6, and HIP draft-thaler-mobility-comparison-01.txt Dave Thaler.
draft-ietf-geopriv-lbyr-requirements-02 status update
draft-gomez-lpwan-ipv6-analysis-00
DHCP Anonymity Profile Update
Chapter 8: Subnetting IP Networks
Internet of Things Vulnerabilities
6LoWPAN Interoperability
Extending IP to Low-Power, Wireless Personal Area Networks
IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
IPv6 Unique Local Addresses Update on IETF Activity
دیواره ی آتش.
Chairs: Samita Chakrabarti, Gabriel Montenegro
Chapter 11: Network Address Translation for IPv4
Mobile IP Outline Homework #4 Solutions Intro to mobile IP Operation
Mobile IP Outline Intro to mobile IP Operation Problems with mobility.
Lecture 4a Mobile IP 1.
Site Report Conceptual Model
Transmission of IPv6 Packets over PLC Networks draft-hou-6lo-plc-04
Lecture-Hashing.
Presentation transcript:

6lo Privacy Considerations draft-thaler-6lo-privacy-addrs-00 Dave Thaler <dthaler@microsoft.com> IETF 93

Privacy Considerations for IPv6 Address Generation Mechanisms draft-ietf-6man-ipv6-address-generation-privacy (in IESG Evaluation) discusses four threats: Correlation of activities over time If stable id used for Internet traffic across long period of time Location tracking If stable id as move between different networks Device-specific vulnerability exploitation If id identifies vendor or version and hence suggests which attacks to try Address scanning Non-random IPv6 interface id narrows search space significantly IETF 93

Let’s look specifically at address scanning Address scans allow off-link attackers to discover a device to track/attack Thus enables all the other threats for off-link attackers Especially dangerous for any link that connects devices to the Internet or any other untrusted network To mitigate address scan, need about ~46 bits of entropy in IPv6 interface id for always-on devices General rule is can address scan 2 addresses every second based on ICMP rate limit Goal is to minimize chance of finding any device during lifetime of connection # bits of entropy to get <50% chance ≈ log2(# devices) + log2(# scan tries) + 1 Example: 2^4 devices on a link lasting 2^5 seconds → need ~10 bits of entropy Ideally without losing efficiency/compression benefits in 6lowpan technologies IETF 93

Let’s look at two potential approaches: Random EUI-48 or EUI-64 addresses “Short Addresses” IETF 93

1. Random EUI-48 or EUI-64 addresses Can use per-network IEEE identifier with 46+ bits of entropy Can use normal LOWPAN_IPHC encoding with stateless compression IPv6 addresses can be fully elided Mitigates privacy threats except for “Correlation over time” Correlation over time can be mitigated if change EUI-48/64 often enough (e.g., each time you connect to a network) See draft-huitema-6man-random-addresses and presentation in 6man Requires that L2 technology allows use of arbitrary EUI-48/EUI-64 IETF 93

Various Link Technologies Technology Reference Bits of Entropy 802.15.4 RFC 4944 16+ or any EUI-64 Bluetooth LE draft-ietf-6lo-btle-15 48 DECT ULE draft-ietf-6lo-dect-ule-02 40 or any EUI-48 MS/TP draft-ietf-6lo-6lobac-02 8 or 64 ITU-T G.9959 RFC 7428 8 NFC draft-ietf-6lo-nfc-01 6 or ??? … This table doesn’t say what the typical link/address lifetime is for each technology though IETF 93

2. Use of “Short Addresses” (e.g., 16-bit) Simple embedding lacks enough entropy to mitigate address scans unless link lifetime is extremely short Padding with 0’s makes address scans easy Could use a different address construction scheme though, e.g. IPv6 IID = Hash64(L2 network key, short address, ABRO version) Still allows full stateless compression/elision IETF 93

Recommendations Security (privacy) sections should say how address scan is mitigated Could be by forcing link to be very short lived Could be by allow large number of bits of entropy Technologies must define a way to include sufficient bits of entropy in the interface id based on the maximum link lifetimes Random EUI-48/EUI-64 is one easy way to do so for some link technologies Do not simply use a short address padded with a well-known prefix unless link lifetime is guaranteed to be extremely short Make sure that an IPv6 address can change over long period of time E.g. each time it connects to the network, or each day, or whatever This mitigates correlation over time If a device can roam between networks AND more than a few bits of entropy exist in the IPv6 iid, then make sure it can vary per network This mitigates location tracking IETF 93