draft-dickinson-dprive-bcp-op-00.txt   draft-dickinson-dprive-bcp-op-01.txt 
dprive S. Dickinson dprive S. Dickinson
Internet-Draft Sinodun IT Internet-Draft Sinodun IT
Intended status: Best Current Practice B. Overeinder Intended status: Best Current Practice B. Overeinder
Expires: January 3, 2019 NLnet Labs Expires: January 17, 2019 NLnet Labs
R. van Rijswijk-Deij R. van Rijswijk-Deij
SURFnet bv SURFnet bv
A. Mankin A. Mankin
Salesforce Salesforce
July 2, 2018 July 16, 2018
Recommendations for DNS Privacy Service Operators Recommendations for DNS Privacy Service Operators
draft-dickinson-dprive-bcp-op-00 draft-dickinson-dprive-bcp-op-01
Abstract Abstract
This document presents operational, policy and security This document presents operational, policy and security
considerations for DNS operators who choose to offer DNS Privacy considerations for DNS operators who choose to offer DNS Privacy
services. With the recommendations, the operator can make deliberate services. With the recommendations, the operator can make deliberate
decisions which services to provide, and how the decisions and decisions which services to provide, and how the decisions and
alternatives impact the privacy of users. alternatives impact the privacy of users.
This document also presents a framework to assist writers of DNS This document also presents a framework to assist writers of DNS
skipping to change at page 1, line 37 skipping to change at page 1, line 37
in [RFC6841]). in [RFC6841]).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on January 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 5, line 15 skipping to change at page 5, line 15
provide legal advice or recommendations as to the contents. provide legal advice or recommendations as to the contents.
Community insight [or judgment?] about operational practices can Community insight [or judgment?] about operational practices can
change quickly, and experience shows that a Best Current Practice change quickly, and experience shows that a Best Current Practice
(BCP) document about privacy and security is a point-in-time (BCP) document about privacy and security is a point-in-time
statement. Readers are advised to seek out any errata or updates statement. Readers are advised to seek out any errata or updates
that apply to this document. that apply to this document.
2. Scope 2. Scope
"DNS Privacy Considerations" [RFC7626] describes the general privacy "DNS Privacy Considerations" [I-D.bortzmeyer-dprive-rfc7626-bis]
issues and threats associated with the use of the DNS by Internet describes the general privacy issues and threats associated with the
users and much of the threat analysis here is lifted from that use of the DNS by Internet users and much of the threat analysis here
document and from [RFC6873]. However this document is limited in is lifted from that document and from [RFC6873]. However this
scope to best practice considerations for the provision of DNS document is limited in scope to best practice considerations for the
privacy services by servers (recursive resolvers) to clients (stub provision of DNS privacy services by servers (recursive resolvers) to
resolvers or forwarders). Privacy considerations specifically from clients (stub resolvers or forwarders). Privacy considerations
the perspective of an end user, or those for operators of specifically from the perspective of an end user, or those for
authoritative nameservers are out of scope. operators of authoritative nameservers are out of scope.
This document includes (but is not limited to) considerations in the This document includes (but is not limited to) considerations in the
following areas (taken from [RFC7626]): following areas (taken from [I-D.bortzmeyer-dprive-rfc7626-bis]):
1. Data "on the wire" between a client and a server 1. Data "on the wire" between a client and a server
2. Data "at rest" on a server (e.g. in logs) 2. Data "at rest" on a server (e.g. in logs)
3. Data "sent onwards" from the server (either on the wire or shared 3. Data "sent onwards" from the server (either on the wire or shared
with a third party) with a third party)
Whilst the issues raised here are targeted at those operators who Whilst the issues raised here are targeted at those operators who
choose to offer a DNS privacy service, considerations for areas 2 and choose to offer a DNS privacy service, considerations for areas 2 and
skipping to change at page 14, line 7 skipping to change at page 14, line 7
pseudonymization schema is known, the process can be reversed, so pseudonymization schema is known, the process can be reversed, so
the original identity becomes known again. the original identity becomes known again.
In practice there is a fine line between the two; for example, how to In practice there is a fine line between the two; for example, how to
categorize a deterministic algorithm for data minimization of IP categorize a deterministic algorithm for data minimization of IP
addresses that produces a group of pseudonyms for a single given addresses that produces a group of pseudonyms for a single given
address. address.
5.2.3. IP address pseudonymization and anonymization methods 5.2.3. IP address pseudonymization and anonymization methods
As [RFC7626] makes clear, the big privacy risk in DNS is connecting As [I-D.bortzmeyer-dprive-rfc7626-bis] makes clear, the big privacy
DNS queries to an individual and the major vector for this in DNS risk in DNS is connecting DNS queries to an individual and the major
traffic is the client IP address. vector for this in DNS traffic is the client IP address.
There is active discussion in the space of effective pseudonymization There is active discussion in the space of effective pseudonymization
of IP addresses in DNS traffic logs, however there seems to be no of IP addresses in DNS traffic logs, however there seems to be no
single solution that is widely recognized as suitable for all or most single solution that is widely recognized as suitable for all or most
use cases. There are also as yet no standards for this that are use cases. There are also as yet no standards for this that are
unencumbered by patents. This following table presents a high level unencumbered by patents. This following table presents a high level
comparison of various techniques employed or under development today comparison of various techniques employed or under development today
and classifies then according to categorization of technique and and classifies them according to categorization of technique and
other properties. The list of techniques includes the main other properties. The list of techniques includes the main
techniques in current use, but does not claim to be comprehensive. techniques in current use, but does not claim to be comprehensive.
Appendix B provides a more detailed survey of these techniques and Appendix B provides a more detailed survey of these techniques and
definitions for the categories and properties listed below. definitions for the categories and properties listed below.
Figure showing comparison of IP address techniques (SVG) [5] Figure showing comparison of IP address techniques (SVG) [5]
The choice of which method to use for a particular application will The choice of which method to use for a particular application will
depend on the requirements of that application and consideration of depend on the requirements of that application and consideration of
the threat analysis of the particular situation. the threat analysis of the particular situation.
skipping to change at page 18, line 45 skipping to change at page 18, line 45
practices of the service. practices of the service.
2.1 Specify any temporary or permanent deviations from the policy for 2.1 Specify any temporary or permanent deviations from the policy for
operational reasons operational reasons
2.2 With reference to section Section 5.1 provide specific details of 2.2 With reference to section Section 5.1 provide specific details of
which capabilities are provided on which address and ports which capabilities are provided on which address and ports
2.3 With reference to section Section 5.3 provide specific details of 2.3 With reference to section Section 5.3 provide specific details of
which capabilities are employed for upstream traffic from the server which capabilities are employed for upstream traffic from the server
for
2.4 Specify the authentication name to be used (if any) and if TLSA 2.4 Specify the authentication name to be used (if any) and if TLSA
records are published (including options used in the TLSA records) records are published (including options used in the TLSA records)
2.5 Specify the SPKI pinsets to be used (if any) and policy for 2.5 Specify the SPKI pinsets to be used (if any) and policy for
rolling keys rolling keys
2.6 Provide a contact email address for the service 2.6 Provide a contact email address for the service
6.2. Current policy and privacy statements 6.2. Current policy and privacy statements
skipping to change at page 21, line 42 skipping to change at page 21, line 42
Jim Hague Jim Hague
Sinodun Internet Technologies Sinodun Internet Technologies
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
11. Changelog 11. Changelog
draft-dickinson-dprive-bcp-op-01
o Update reference to RFC7626 to draft-bortzmeyer-rfc7626-bis
o Fix a few typos
draft-dickinson-dprive-bcp-op-00 draft-dickinson-dprive-bcp-op-00
Name change to add dprive. Differences to draft-dickinson-bcp-op-00: Name change to add dprive. Differences to draft-dickinson-bcp-op-00:
o Reworked the Terminology, Introduction and Scope o Reworked the Terminology, Introduction and Scope
o Added Document section o Added Document section
o Reworked the Recommendations section to describe threat o Reworked the Recommendations section to describe threat
mitigations, optimizations and other options. Split the mitigations, optimizations and other options. Split the
recommendations up into 3 subsections: on the wire, at rest and recommendations up into 3 subsections: on the wire, at rest and
upstream upstream
o Added much more information on data handling and IP address o Added much more information on data handling and IP address
pseudonymization and anonymization pseudonymization and anonymization
skipping to change at page 22, line 25 skipping to change at page 22, line 29
draft-dickinson-bcp-op-00 draft-dickinson-bcp-op-00
o Initial commit o Initial commit
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dnsop-terminology-bis] [I-D.ietf-dnsop-terminology-bis]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", draft-ietf-dnsop-terminology-bis-10 (work in Terminology", draft-ietf-dnsop-terminology-bis-11 (work in
progress), April 2018. progress), July 2018.
[I-D.ietf-doh-dns-over-https] [I-D.ietf-doh-dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-12 (work in (DoH)", draft-ietf-doh-dns-over-https-12 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-dprive-padding-policy] [I-D.ietf-dprive-padding-policy]
Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf-
dprive-padding-policy-05 (work in progress), April 2018. dprive-padding-policy-05 (work in progress), April 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6265>. editor.org/info/rfc6265>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6973>. editor.org/info/rfc6973>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<https://www.rfc-editor.org/info/rfc7626>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<https://www.rfc-editor.org/info/rfc7816>. <https://www.rfc-editor.org/info/rfc7816>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016, DOI 10.17487/RFC7830, May 2016, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7830>. editor.org/info/rfc7830>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
<https://www.rfc-editor.org/info/rfc7873>. <https://www.rfc-editor.org/info/rfc7873>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, DOI 10.17487/RFC8310, March 2018, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8310>. editor.org/info/rfc8310>.
12.2. Informative References 12.2. Informative References
[I-D.bortzmeyer-dprive-rfc7626-bis]
Bortzmeyer, S. and S. Dickinson, "DNS Privacy
Considerations", draft-bortzmeyer-dprive-rfc7626-bis-00
(work in progress), July 2018.
[I-D.ietf-dnsop-dns-capture-format] [I-D.ietf-dnsop-dns-capture-format]
Dickinson, J., Hague, J., Dickinson, S., Manderson, T., Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
and J. Bond, "C-DNS: A DNS Packet Capture Format", draft- and J. Bond, "C-DNS: A DNS Packet Capture Format", draft-
ietf-dnsop-dns-capture-format-07 (work in progress), May ietf-dnsop-dns-capture-format-07 (work in progress), May
2018. 2018.
[I-D.ietf-dnsop-dns-tcp-requirements] [I-D.ietf-dnsop-dns-tcp-requirements]
Kristoff, J. and D. Wessels, "DNS Transport over TCP - Kristoff, J. and D. Wessels, "DNS Transport over TCP -
Operational Requirements", draft-ietf-dnsop-dns-tcp- Operational Requirements", draft-ietf-dnsop-dns-tcp-
requirements-02 (work in progress), May 2018. requirements-02 (work in progress), May 2018.
[I-D.ietf-dnsop-session-signal] [I-D.ietf-dnsop-session-signal]
Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations", Lemon, T., and T. Pusateri, "DNS Stateful Operations",
draft-ietf-dnsop-session-signal-10 (work in progress), draft-ietf-dnsop-session-signal-11 (work in progress),
June 2018. July 2018.
[I-D.ietf-tls-dnssec-chain-extension] [I-D.ietf-tls-dnssec-chain-extension]
Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
Record and DNSSEC Authentication Chain Extension for TLS", Record and DNSSEC Authentication Chain Extension for TLS",
draft-ietf-tls-dnssec-chain-extension-07 (work in draft-ietf-tls-dnssec-chain-extension-07 (work in
progress), March 2018. progress), March 2018.
[pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>. [pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>.
[Pitfalls-of-DNS-Encryption] [Pitfalls-of-DNS-Encryption]
skipping to change at page 25, line 7 skipping to change at page 25, line 7
Session Initiation Protocol (SIP) Common Log Format Session Initiation Protocol (SIP) Common Log Format
(CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013, (CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013,
<https://www.rfc-editor.org/info/rfc6873>. <https://www.rfc-editor.org/info/rfc6873>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <https://www.rfc-editor.org/info/rfc7686>. 2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
Servers by Running One on Loopback", RFC 7706, Servers by Running One on Loopback", RFC 7706,
DOI 10.17487/RFC7706, November 2015, DOI 10.17487/RFC7706, November 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7706>. editor.org/info/rfc7706>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <https://www.rfc-editor.org/info/rfc7766>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828, edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016, DOI 10.17487/RFC7828, April 2016, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7828>. editor.org/info/rfc7828>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871, Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016, DOI 10.17487/RFC7871, May 2016, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7871>. editor.org/info/rfc7871>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8094>. editor.org/info/rfc8094>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>. July 2017, <https://www.rfc-editor.org/info/rfc8198>.
12.3. URIs 12.3. URIs
[1] https://nginx.org/ [1] https://nginx.org/
[2] https://www.haproxy.org/ [2] https://www.haproxy.org/
skipping to change at page 28, line 25 skipping to change at page 28, line 25
same form as the original data, to allow the data to be parsed in same form as the original data, to allow the data to be parsed in
the same way as the original. the same way as the original.
o Prefix preservation. Values such as IP addresses and MAC o Prefix preservation. Values such as IP addresses and MAC
addresses contain prefix information that can be valuable in addresses contain prefix information that can be valuable in
analysis, e.g. manufacturer ID in MAC addresses, subnet in IP analysis, e.g. manufacturer ID in MAC addresses, subnet in IP
addresses. Prefix preservation ensures that prefixes are de- addresses. Prefix preservation ensures that prefixes are de-
identified consistently; e.g. if two IP addresses are from the identified consistently; e.g. if two IP addresses are from the
same subnet, a prefix preserving de-identification will ensure same subnet, a prefix preserving de-identification will ensure
that their de-identified counterparts will also share a subnet. that their de-identified counterparts will also share a subnet.
Prefix preservation may be fixed - the extent of the prefix to be Prefix preservation may be fixed (i.e. based on a user selected
preserved must be identified in advance - or general. prefix length identified in advance to be preserved ) or general.
o Replacement. A one-to-one replacement of a field to a new value o Replacement. A one-to-one replacement of a field to a new value
of the same type, for example using a regular expression. of the same type, for example using a regular expression.
Filtering. Removing (and thus truncating) or replacing data in a
o Filtering. Removing (and thus truncating) or replacing data in a
field. Field data can be overwritten, often with zeros, either field. Field data can be overwritten, often with zeros, either
partially (grey marking) or completely (black marking). partially (grey marking) or completely (black marking).
o Generalization. Data is replaced by more general data with o Generalization. Data is replaced by more general data with
reduced specificity. One example would be to replace all TCP/UDP reduced specificity. One example would be to replace all TCP/UDP
port numbers with one of two fixed values indicating whether the port numbers with one of two fixed values indicating whether the
original port was ephemeral (>=1024) or non-ephemeral (>1024). original port was ephemeral (>=1024) or non-ephemeral (>1024).
Another example, precision degradation, reduces the accuracy of Another example, precision degradation, reduces the accuracy of
e.g. a numeric value or a timestamp. e.g. a numeric value or a timestamp.
skipping to change at page 29, line 45 skipping to change at page 29, line 45
Anonymization: Format-preserving, Enumeration. Anonymization: Format-preserving, Enumeration.
B.3. Prefix-preserving map B.3. Prefix-preserving map
Used in TCPdpriv [13], this algorithm stores a set of original and Used in TCPdpriv [13], this algorithm stores a set of original and
anonymised IP address pairs. When a new IP address arrives, it is anonymised IP address pairs. When a new IP address arrives, it is
compared with previous addresses to determine the longest prefix compared with previous addresses to determine the longest prefix
match. The new address is anonymized by using the same prefix, with match. The new address is anonymized by using the same prefix, with
the remainder of the address anonymized with a random value. The use the remainder of the address anonymized with a random value. The use
of a random value means that the TCPdrpiv is not deterministic; of a random value means that TCPdrpiv is not deterministic; different
different anonymized values will be generated on each run. The need anonymized values will be generated on each run. The need to store
to store previous addresses means that TCPdpriv has significant and previous addresses means that TCPdpriv has significant and unbounded
unbounded memory requirements, and because of the need to allocated memory requirements, and because of the need to allocated anonymized
anonymized addresses sequentially cannot be used in parallel addresses sequentially cannot be used in parallel processing.
processing.
Anonymization: Format-preserving, prefix preservation (general). Anonymization: Format-preserving, prefix preservation (general).
B.4. Cryptographic Prefix-Preserving Pseudonymisation B.4. Cryptographic Prefix-Preserving Pseudonymisation
Cryptographic prefix-preserving pseudonymisation was originally Cryptographic prefix-preserving pseudonymisation was originally
proposed as an improvement to the prefix-preserving map implemented proposed as an improvement to the prefix-preserving map implemented
in TCPdpriv, described in Xu et al. [14] and implemented in the in TCPdpriv, described in Xu et al. [14] and implemented in the
Crypto-PAn tool [15]. Crypto-PAn is now frequently used as an Crypto-PAn tool [15]. Crypto-PAn is now frequently used as an
acronym for the algorithm. Initially it was described for IPv4 acronym for the algorithm. Initially it was described for IPv4
 End of changes. 29 change blocks. 
57 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/