< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/