Transcript Privacy Strategy

Privacy and Security for IPv6-based
Deployments
Hannes Tschofenig
[email protected]
For internal use
1
© Nokia Siemens Networks
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)
For internal use
2
© Nokia Siemens Networks
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.
For internal use
3
© Nokia Siemens Networks
BSI TR‐03109 Architecture
For internal use
4
© Nokia Siemens Networks
Architectural Choices
Server
Infrastructure
Internet
Sensor
For internal use
5
© Nokia Siemens Networks
Gateway
Sensor
Architectural Choices
Server
Infrastructure
Internet
Sensor
For internal use
6
© Nokia Siemens Networks
Sensor
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 LowPower Wireless Personal Area Networks
• RFC 6272 “Internet Protocols for the Smart Grid”
provides a more extensive list of protocols.
For internal use
7
© Nokia Siemens Networks
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
For internal use
8
© Nokia Siemens Networks
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-iabextension-recs)
– “Guidance for AAA Key Management” (RFC 4962)
For internal use
9
© Nokia Siemens Networks
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/
For internal use
10
© Nokia Siemens Networks
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.
For internal use
11
© Nokia Siemens Networks
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.
For internal use
12
© Nokia Siemens Networks
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-privacyws/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.
For internal use
13
© Nokia Siemens Networks
Privacy Considerations
• A couple of privacy reviews have been conducted by
the IAB:
– http://www.iab.org/activities/programs/privacyprogram/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.
For internal use
14
© Nokia Siemens Networks
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.
For internal use
15
© Nokia Siemens Networks
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 IPv6based smart object deployments?
For internal use
16
© Nokia Siemens Networks
IPv6 Privacy Threats
1. Re-identification over time by the other communication
2.
3.
4.
5.
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.
For internal use
17
© Nokia Siemens Networks
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.
For internal use
18
© Nokia Siemens Networks
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/tschofenigids/master/IPv6-Privacy/IPv6_privacy_survey.txt
– Not yet released; soliciting feedback.
For internal use
19
© Nokia Siemens Networks
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*?
_______________
For internal use
20
© Nokia Siemens Networks
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
For internal use
21
© Nokia Siemens Networks
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
For internal use
22
© Nokia Siemens Networks
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
For internal use
23
© Nokia Siemens Networks
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”
For internal use
24
© Nokia Siemens Networks
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.
For internal use
25
© Nokia Siemens Networks