Privacy and Security for IPv6-based Deployments

1. Privacy and Security for IPv6-based Deployments Hannes Tschofenig Hannes.tschofenig@nsn.com

2. Deploying IPv6 Networks • The IETF v6OPS group has developed different strategies for IPv6 deployment in different environments. • Examples: • Enterprise Networks: http://datatracker.ietf.org/doc/rfc4057/ • Broadband Networks: • http://datatracker.ietf.org/doc/rfc4779/ • Additional specifications for transition mechanisms. • For example: 3GPP Networks (RFC 3574, RFC 3314, RFC 4215)

3. Deploying IPv6 Networks, cont. • The incentives and approaches for IPv6 deployment clearly vary between the different environments. • My example: Smart meter standardization effort by the German Federal Ministry of Economics and Technology. • With many of the smart object deployment being new the focus is not only on IPv6 and/or IPv4 but to develop a complete architecture.

4. BSI TR‐03109 Architecture

5. Architectural Choices Server Infrastructure Internet Sensor Gateway Sensor

6. Architectural Choices Server Infrastructure Internet Sensor Sensor

7. Protocols Re-Use • Lots of IETF building blocks to re-use! • Examples with special focus on smart objects: • CoAP from CORE WG, http://datatracker.ietf.org/wg/core/) • RPL from ROLL WG, http://datatracker.ietf.org/wg/roll/) • Various specifications from 6LoWPAN WG http://datatracker.ietf.org/wg/6lowpan/ on IPv6 over Low-Power Wireless Personal Area Networks • RFC 6272 “Internet Protocols for the Smart Grid” provides a more extensive list of protocols.

8. From Protocols to Systems • Do we expect others to take these individual building blocks and put a complete system together? • Do we have preferences and suggestions what they should come up with? • Result from my Smart Meter example: • Application layer only. • Security solution specification (with TLS) – without threat model • Pseudonymity mechanism (without a description of the privacy threats) • Gateway internals (communication with a security module) • Gateway to server communication

9. Guidance for Engineers available? • Typically IETF documents do not make a difference between engineers from the IETF and from other organizations. • For protocol engineers in the IETF we provide lots of guidance, such as • Protocol specific recommendations, such as RADIUS design guidelines (RFC 6158) or Diameter design guidelines (draft-ietf-dime-app-design-guide) • “Design Considerations for Protocol Extensions“ (draft-iab-extension-recs) • “Guidance for AAA Key Management” (RFC 4962)

10. Guidance for Implementers/ Deployment Community • Examples: • Recommendations for Transport-Protocol Port Randomization (RFC 6056) • Recommendations for Filtering ICMPv6 Messages in Firewalls (RFC 4890) • Network Ingress Filtering (RFC 2827); RFC 3704 (for multi-homed networks) • Many others… • Relevant work from groups: • IPv6 Operations (v6ops): http://datatracker.ietf.org/wg/v6ops/charter/ • Source Address Validation Improvements (savi): http://datatracker.ietf.org/wg/savi/charter/ • Light-Weight Implementation Guidance (lwig): http://datatracker.ietf.org/wg/lwig/charter/

11. More Generic IAB Recommendations? • Security: RFC 3552 on “Guidelines for Writing RFC Text on Security Considerations” and RFC 4101 on “Writing Protocol Models” • RFC 4732 on “Internet Denial-of-Service Considerations“ relates to the above document. • Privacy: draft-iab-privacy-considerations on “Privacy Considerations for Internet Protocols” • RFC 3914 on “Open Pluggable Edge Services (OPES) Treatment of IAB Considerations” is a small part of it. • Generic: RFC 5218 “What Makes for a Successful Protocol?” RFC 3439 and RFC 1958 on Internet architectural principles.

12. Can we do better? • Let us assume: • Various organizations will be developing IP-based protocol stacks (from IPv6 to application layer protocols). • They are interested in standardizing complete protocol stacks. • What recommendations can be provided that • consider the specifics of smart objects, and • are generic enough? • Focus only on privacy and security. • Other areas are also useful to look at, such as energy efficiency, manageability, innovation friendliness, etc.

13. Privacy • Many standardization organizations had to deal with privacy requirements in various forms already. • See paper submission to “W3C Workshop on Privacy for Advanced Web APIs“ http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-32.pdf • Many documents don’t use a common vocabulary. • draft-hansen-privacy-terminology introduces a common vocabulary to talk about anonymity, unlinkability, unobservability, and pseudonymity. • draft-iab-privacy-considerations additionally introduces a threat model and offers a few guiding questions.

14. Privacy Considerations • A couple of privacy reviews have been conducted by the IAB: • http://www.iab.org/activities/programs/privacy-program/privacy-reviews/ • Among these reviews is one on IPv6. • The purpose of these reviews was to determine what had lead to certain design decisions (with regard to privacy). • Recent draft changes lead to • Shorter document (examples removed; background and scope description shortened). • Document not only applicable to a protocol but also to a protocol suite.

15. Privacy Considerations, cont. • Guidelines • 4.1. General • a. Trade-offs. • 4.2. Data Minimization • a. Identifiers. • b. User information. • c. Fingerprinting. • d. Persistence of identifiers • e. Leakage. • f. Recipients. • g. Intermediaries. • h. Retention. • 4.3. User Participation • a. Control over initial sharing. • b. Control over sharing with recipients. • c. Control over sharing with intermediaries. • d. Preference expression. • 4.4. Security • a. Communication security. • 4.5. Accountability • a. User verification.

16. IPv6 Privacy • Many remember the ability to use the MAC address as the interface identifier of an IPv6 address. • This problem was later fixed by the publication of RFC 3041/RFC 4941. • So, is everything fine if we use RFC 4941 for IPv6-based smart object deployments?

17. IPv6 Privacy Threats • Re-identification over time by the other communication partner. • Ability to infer geographical location information using • third party location services, or • routing infrastructure services (utilizing address prefix information) • Associating the network layer identifier to subscriber information by the access network provider. • Analysis of communication patterns by entities along the communication path • Secondary usage without consent.

18. Layering & Addressing Policy • There are multiple protocols within a single layer and tunneling & translation is very common. • Requires many more protocols to be considered than just IPv6! • Application protocols often need to establish media communication (e.g., SIP, XMPP, and RTCWeb) • Reachability-checking protocols may compromise address privacy • Example: IPv6 REAchability Protocol (REAP, RFC 5534), STUN/ICE • For practical purposes the capabilities of application layer protocols have to be considered. • Each address configuration mechanism describes the procedures for initially allocating, using, renewing, expiring and releasing addresses. • The policy for choosing the lifetime of a specific address may depend on the context and usage.

19. IPv6 Privacy Questionnaire • Useful to know what the current implementation and deployment status is. • Suggest running a short survey to gather feedback about IP stacks used in • Desktop operating systems • Mobile devices • Sensor networks and industrial appliances • Current survey snapshot: • https://raw.github.com/hannestschofenig/tschofenig-ids/master/IPv6-Privacy/IPv6_privacy_survey.txt • Not yet released; soliciting feedback.

20. Example Questions • 5) What mechanisms for IPv6 interface identifier configuration do you support? • __ Manual configuration • __ Link layer identifier, such as MAC address (RFC 1972/RFC 2464) • __ Randomly generated temporary addresses (RFC 3041/RFC 4941) • __ Cryptographically generated addresses (RFC 3972) • __ Network provided interface identifier (e.g., 3GPP networks or PPP provide IID to the end host - RFC 5072) • __ DHCPv6 (RFC 3315) / IKEv2 (RFC 5739) • 6) Which interface identifier configuration mechanism(s) is(are) set by *default*? • _______________

21. Example questions, cont. • 8) Which IPv4/IPv6 transition mechanism that embed IPv4 addresses in IPv6 addresses do you implement? • __ Teredo based on RFC 4380 • __ Teredo based on RFC 5991 • __ 6to4 (RFC 3056) • __ 6RD (RFC 5569) • __ ISATAP (RFC 5214) • __ RFC 6052 addresses (as, for example, used by NAT64) • __ others, namely ______ • 9) Do you have documentation on how an end user can change the interface identifier configuration mechanism, and the default settings? • __ yes • __ no

22. Example questions, cont. • 10) Address Selection Procedure • RFC 3484 specifies that public addresses be used for outbound connections unless an application explicitly prefers temporary addresses. The default preference for public addresses was established to avoid applications potentially failing due to the short lifetime of temporary addresses or the possibility of a reverse look-up failure or error. However, RFC 3484 allowed that "implementations for which privacy considerations outweigh these application compatibility concerns MAY reverse the sense of this rule and by default prefer temporary addresses over public addresses.” • What is the default policy in your IP stack? • __ Prefer temporary addresses over public addresses. • __ Prefer public addresses over temporary addresses. • 11) Can the default address selection policy be changed by the user? • __ yes • __ no

23. Security • RFC 3552 introduces security terminology, a threat model, and guidance. • Is there additional guidance that can be provided? • Should protocols/protocol suite be designed for multiple credentials, and flexible authentication protocol support? (rather than for a single credential only) • What recommendations can be given regarding security functionality at different layers in smart objects? What security primitives can be recommended? • Do we demand “software update” capability to deal with broken crypto-primitives, algorithms, and other flaws? • What can be said about weak authentication mechanisms designed for usage in special environments? • Example: Engineers will possible want to let the following criteria influence their selection process: • Number of roundtrips • Bandwidth • Energy consumption • Code size • Main memory size • Computational requirements

24. Security, cont. • NIST SP 800-130 “A Framework for Designing Cryptographic Key Management Systems” and a generalized version of RFC 4962 could provide a good starting point? • A number of IETF security mechanisms provide useful guidance for those deploying IPv6 technology, such as . • RFC 4942 “IPv6 Transition/Coexistence Security Considerations” • RFC 5157 “IPv6 Implications for Network Scanning” • RFC 4890 “Recommendations for Filtering ICMPv6 Messages in Firewalls” • RFC 4864 “Local Network Protection for IPv6” • RFC 6169 “Security Concerns with IP Tunneling”

25. Conclusion • Presentation aims to raise some meta-questions about the design of network architectures. • What guidance should we provided to those using IETF building blocks? • To what degree should protocol profiles be specified in the IETF? • Examples from security & privacy provided with a focus on the smart object space.