< draft-thomson-tmi-01.txt		draft-thomson-tmi-02.txt >
	Network Working Group M. Thomson		Network Working Group M. Thomson
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Informational 4 January 2021		Intended status: Informational 6 July 2021
	Expires: 8 July 2021		Expires: 7 January 2022
	Principles for the Involvement of Intermediaries in Internet Protocols		Principles for the Involvement of Intermediaries in Internet Protocols
	draft-thomson-tmi-01		draft-thomson-tmi-02
	Abstract		Abstract
	This document proposes a set of principles for designing protocols		This document proposes a set of principles for designing protocols
	with rules for intermediaries. The goal of these principles is to		with rules for intermediaries. The goal of these principles is to
	limit the ways in which intermediaries can produce undesirable		limit the ways in which intermediaries can produce undesirable
	effects and to protect the useful functions that intermediaries		effects and to protect the useful functions that intermediaries
	legitimately provide.		legitimately provide.
	Discussion Venues		Discussion Venues
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 https://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 8 July 2021.		This Internet-Draft will expire on 7 January 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	4. Intermediation Is Useful . . . . . . . . . . . . . . . . . . 5		4. Intermediation Is Useful . . . . . . . . . . . . . . . . . . 5
	5. Intermediation Enables Scaling Of Control . . . . . . . . . . 5		5. Intermediation Enables Scaling Of Control . . . . . . . . . . 5
	6. Incentive Misalignment at Scale . . . . . . . . . . . . . . . 6		6. Incentive Misalignment at Scale . . . . . . . . . . . . . . . 6
	7. Forced and Unwanted Intermediation . . . . . . . . . . . . . 6		7. Forced and Unwanted Intermediation . . . . . . . . . . . . . 6
	8. Contention over Intermediation . . . . . . . . . . . . . . . 7		8. Contention over Intermediation . . . . . . . . . . . . . . . 7
	9. Proposed Principles . . . . . . . . . . . . . . . . . . . . . 8		9. Proposed Principles . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Prefer Services to Intermediaries . . . . . . . . . . . . 8		9.1. Prefer Services to Intermediaries . . . . . . . . . . . . 8
	9.2. Deliberately Select Protocol Participants . . . . . . . . 9		9.2. Deliberately Select Protocol Participants . . . . . . . . 9
	9.3. Limit Capabilities of Intermediaries . . . . . . . . . . 10		9.3. Limit Capabilities of Intermediaries . . . . . . . . . . 10
	9.3.1. Limit Information Exposure . . . . . . . . . . . . . 10		9.3.1. Limit Information Exposure . . . . . . . . . . . . . 10
	9.3.2. Limit Permitted Interactions . . . . . . . . . . . . 10		9.3.2. Limit Permitted Interactions . . . . . . . . . . . . 11
	9.3.3. Costs of Technical Constraints . . . . . . . . . . . 11		9.3.3. Costs of Technical Constraints . . . . . . . . . . . 11
	10. Applying Non-Technical Constraints . . . . . . . . . . . . . 11		10. Applying Non-Technical Constraints . . . . . . . . . . . . . 12
	11. The Effect on Existing Practices . . . . . . . . . . . . . . 12		11. The Effect on Existing Practices . . . . . . . . . . . . . . 12
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 13		12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	14. Informative References . . . . . . . . . . . . . . . . . . . 13		14. Informative References . . . . . . . . . . . . . . . . . . . 13
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	The Internet owes much of its success to its application of the end-		The Internet owes much of its success to its application of the end-
	to-end principle [E2E]. The realization that efficiency is best		to-end principle [E2E]. The realization that efficiency is best
	served by moving higher-level functions to endpoints is a key insight		served by moving higher-level functions to endpoints is a key insight
	in system design, but also a key element of the success of the		in system design, but also a key element of the success of the
	Internet.		Internet.
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	The ability of an intermediary to affect a large number of network		The ability of an intermediary to affect a large number of network
	users can be an advantage or vulnerability, depending on perspective.		users can be an advantage or vulnerability, depending on perspective.
	For instance, network intermediaries have been used to distribute		For instance, network intermediaries have been used to distribute
	warnings of impending natural disasters like fire, flood, or		warnings of impending natural disasters like fire, flood, or
	earthquake, which save lives and property. In contrast, control over		earthquake, which save lives and property. In contrast, control over
	large-scale communications can enable censorship [RFC7754],		large-scale communications can enable censorship [RFC7754],
	misinformation, or pervasive monitoring [RFC7258].		misinformation, or pervasive monitoring [RFC7258].
	Intermediaries that can affect many people can therefore be powerful		Intermediaries that can affect many people can therefore be powerful
	agents for control. Though it is clear that the morality of actions		agents for control. While the morality of actions taken can be
	taken can be subjective, network users have to consider the potential		subjective, network users have to consider the potential for the
	for the power they vest in intermediaries to be abused or subverted.		power they vest in intermediaries to be abused or subverted.
	6. Incentive Misalignment at Scale		6. Incentive Misalignment at Scale
	A dependency on an intermediary can represent a risk to those that		A dependency on an intermediary represents a risk to those that take
	take the dependency. The incentives and motives of intermediaries		the dependency. The incentives and motives of intermediaries can be
	can be important to consider.		important to consider when choosing to use an intermediary.
	For instance, the information necessary for an intermediary to		For instance, the information necessary for an intermediary to
	performs its function can often be used (or abused) for other		performs its function can often be used (or abused) for other
	purposes. Even the simple function of forwarding necessarily		purposes. Even the simple function of forwarding necessarily
	involves information about who was communicating, when, and the size		involves information about who was communicating, when, and the size
	of messages. This can reveal more than is obvious [CLINIC].		of messages. This can reveal more than is obvious [CLINIC].
	As uses of networks become more diverse, the extent that incentives		As uses of networks become more diverse, the extent that incentives
	for intermediaries and network users align reduce. In particular,		for intermediaries and network users align reduce. In particular,
	acceptance of the costs and risks associated with intermediation by a		acceptance of the costs and risks associated with intermediation by a
	majority of network users does not mean that all users have the same		majority of network users does not mean that all users have the same
	expectations and requirements. This can be a significant problem if		expectations and requirements. This can be a significant problem if
	it becomes difficult to avoid or refuse participation by a particular		it becomes difficult to avoid or refuse participation by a particular
	intermediary; see (TODO CHOKEPOINTS=I-D.iab-chokepoints).		intermediary.
			A dependency on an intermediary, particularly a technically or
			operationally challenging dependency, can reduce the number of viable
			choices of intermediary operators. Reduced choice can lead to
			dependence on specific intermediaries, which reduces resilience and
			exposes endpoints to greater potential for abuse.
	7. Forced and Unwanted Intermediation		7. Forced and Unwanted Intermediation
	The ability to act as intermediary can offer more options than a		The ability to act as intermediary can offer more options than a
	service that is called upon to provide information. Sometimes those		service that is called upon to provide information. Sometimes those
	advantages are enough to justify the use of intermediation over		advantages are enough to justify the use of intermediation over
	alternative designs. However, the use of an intermediary also		alternative designs. However, the use of an intermediary also
	introduces costs.		introduces costs.
	The use of transparent or interception proxies in HTTP [HTTP] is an		The use of transparent or interception proxies in HTTP [HTTP] is an
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 37 ¶
	mechanisms; see Section 2.3 of [USE-IT]. For example, measurement of		mechanisms; see Section 2.3 of [USE-IT]. For example, measurement of
	TCP showed that the protocol has poor prospects for extensibility due		TCP showed that the protocol has poor prospects for extensibility due
	to widespread use - and poor implementation - of intermediaries		to widespread use - and poor implementation - of intermediaries
	[TCP-EXTEND].		[TCP-EXTEND].
	8. Contention over Intermediation		8. Contention over Intermediation
	The IETF has a long history of dealing with different forms of		The IETF has a long history of dealing with different forms of
	intermediation poorly.		intermediation poorly.
	Early use of NAT was loudly decried by some in the IETF community.		A debate about the intent and purpose of IPv6 extension headers
	Indeed, the use of NAT was regarded as an unwanted intrusion by		[IPv6] occurred prior to the publication of RFC 8986 [SRv6] and it's
	intermediaries. The eventual recognition - not endorsement - of the		PSP (Penultimate Segment Pop) mode. Here, the use of extension
	existence of NAT ([MIDDLEBOX], [NAT-ARCH]) allowed the community to		headers by entities other than the communication endpoints -- that
	engage in the design protocols that properly handled NAT devices		is, intermediaries -- was contested. As the purpose of this feature
	([UNSAF], [STUN]) and to make recommendations for best practices		is to communicate routing information between intermediaries, this
	[BEHAVE].		could be seen as a form of tunneling between the communicating
			routers that uses the ability of IPv6 intermediaries (or routers) to
			add or remove extension headers.
	Like HTTP, SIP [RFC3261] defines a role for a proxy, which is a form		Like HTTP, SIP [RFC3261] defines a role for a proxy, which is a form
	of intermediary with limited ability to interact with the session		of intermediary with limited ability to interact with the session
	that it facilitates. In practice, many deployments instead choose to		that it facilitates. In practice, many deployments instead choose to
	deploy some form of Back-to-Back UA (B2BUA; [RFC7092]) for reasons		deploy some form of Back-to-Back UA (B2BUA; [RFC7092]) for reasons
	that effectively reduce to greater ability to implement control		that effectively reduce to greater ability to implement control
	functions.		functions.
	There are several ongoing debates in the IETF that are rooted in		There are several ongoing debates in the IETF that are rooted in
	disagreement about the rule of intermediaries. The interests of		disagreement about the rule of intermediaries. The interests of
	network-based devices - which are sometimes intermediaries - is		network-based devices - which are sometimes intermediaries - is
	fiercely debated in the context of TLS 1.3 [TLS], where the design		fiercely debated in the context of TLS 1.3 [TLS], where the design
	renders certain practices obsolete. Proposed uses of IPv6 header		renders certain practices obsolete.
	extensions in [SRv6NP] called into question the extent to which
	header extensions are the exclusive domain of endpoints as opposed to
	being available to intermediaries.
	It could be that the circumstances in each of these debates is		It could be that the circumstances in each of these debates is
	different enough that there is no singular outcome. The		different enough that there is no singular outcome. The
	complications resulting from large-scale deployments of great		complications resulting from large-scale deployments of great
	diversity might render a single clear outcome impossible for an		diversity might render a single clear outcome impossible for an
	established protocol.		established protocol.
	9. Proposed Principles		9. Proposed Principles
	Many problems caused by intermediation are the result of		Many problems caused by intermediation are the result of
	skipping to change at page 13, line 27 ¶		skipping to change at page 13, line 37 ¶
	Lack of proper controls on intermediaries protocols has been the		Lack of proper controls on intermediaries protocols has been the
	source of significant security problems.		source of significant security problems.
	13. IANA Considerations		13. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	14. Informative References		14. Informative References
	[BEHAVE] Audet, F., Ed. and C. Jennings, "Network Address
	Translation (NAT) Behavioral Requirements for Unicast
	UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
	2007, <https://www.rfc-editor.org/info/rfc4787>.
	[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know		[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
	Why You Went to the Clinic: Risks and Realization of HTTPS		Why You Went to the Clinic: Risks and Realization of HTTPS
	Traffic Analysis", Privacy Enhancing Technologies pp.		Traffic Analysis", Privacy Enhancing Technologies pp.
	143-163, DOI 10.1007/978-3-319-08506-7_8, 2014,		143-163, DOI 10.1007/978-3-319-08506-7_8, 2014,
	<https://doi.org/10.1007/978-3-319-08506-7_8>.		<https://doi.org/10.1007/978-3-319-08506-7_8>.
	[E2E] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments		[E2E] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments
	in system design", ACM Transactions on Computer		in system design", ACM Transactions on Computer
	Systems Vol. 2, pp. 277-288, DOI 10.1145/357401.357402,		Systems Vol. 2, pp. 277-288, DOI 10.1145/357401.357402,
	November 1984, <https://doi.org/10.1145/357401.357402>.		November 1984, <https://doi.org/10.1145/357401.357402>.
	[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<https://www.rfc-editor.org/info/rfc3168>.		<https://www.rfc-editor.org/rfc/rfc3168>.
	[EROSION] Hildebrand, J. and P. McManus, "Erosion of the moral		[EROSION] Hildebrand, J. and P. McManus, "Erosion of the moral
	authority of transparent middleboxes", Work in Progress,		authority of transparent middleboxes", Work in Progress,
	Internet-Draft, draft-hildebrand-middlebox-erosion-01, 10		Internet-Draft, draft-hildebrand-middlebox-erosion-01, 10
	November 2014, <http://www.ietf.org/internet-drafts/draft-		November 2014, <https://datatracker.ietf.org/doc/html/
	hildebrand-middlebox-erosion-01.txt>.		draft-hildebrand-middlebox-erosion-01>.
	[HTTP] Fielding, R., Nottingham, M., and J. Reschke, "HTTP		[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Semantics", Work in Progress, Internet-Draft, draft-ietf-		Semantics", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-semantics-13, 14 December 2020,		httpbis-semantics-16, 27 May 2021,
	<http://www.ietf.org/internet-drafts/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	semantics-13.txt>.		semantics-16>.
	[ICMP] Postel, J., "Internet Control Message Protocol", STD 5,		[ICMP] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, DOI 10.17487/RFC0792, September 1981,		RFC 792, DOI 10.17487/RFC0792, September 1981,
	<https://www.rfc-editor.org/info/rfc792>.		<https://www.rfc-editor.org/rfc/rfc792>.
			[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200,
			DOI 10.17487/RFC8200, July 2017,
			<https://www.rfc-editor.org/rfc/rfc8200>.
	[LEAST-PRIVILEGE]		[LEAST-PRIVILEGE]
	Saltzer, J., "Protection and the control of information		Saltzer, J., "Protection and the control of information
	sharing in multics", Communications of the ACM Vol. 17,		sharing in multics", Communications of the ACM Vol. 17,
	pp. 388-402, DOI 10.1145/361011.361067, July 1974,		pp. 388-402, DOI 10.1145/361011.361067, July 1974,
	<https://doi.org/10.1145/361011.361067>.		<https://doi.org/10.1145/361011.361067>.
	[MIDDLEBOX]		[MIDDLEBOX]
	Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and		Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
	Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,		Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
	<https://www.rfc-editor.org/info/rfc3234>.		<https://www.rfc-editor.org/rfc/rfc3234>.
	[NAT-ARCH] Hain, T., "Architectural Implications of NAT", RFC 2993,
	DOI 10.17487/RFC2993, November 2000,
	<https://www.rfc-editor.org/info/rfc2993>.
	[NS-IMPACT]		[NS-IMPACT]
	Cam-Winget, N., Wang, E., Danyliw, R., and R. DuToit,		Cam-Winget, N., Wang, E., Danyliw, R., and R. DuToit,
	"Impact of TLS 1.3 to Operational Network Security		"Impact of TLS 1.3 to Operational Network Security
	Practices", Work in Progress, Internet-Draft, draft-ietf-		Practices", Work in Progress, Internet-Draft, draft-ietf-
	opsec-ns-impact-03, 25 October 2020, <http://www.ietf.org/		opsec-ns-impact-04, 26 January 2021,
	internet-drafts/draft-ietf-opsec-ns-impact-03.txt>.		<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
			ns-impact-04>.
	[PATH-SIGNALS]		[PATH-SIGNALS]
	Hardie, T., Ed., "Transport Protocol Path Signals",		Hardie, T., Ed., "Transport Protocol Path Signals",
	RFC 8558, DOI 10.17487/RFC8558, April 2019,		RFC 8558, DOI 10.17487/RFC8558, April 2019,
	<https://www.rfc-editor.org/info/rfc8558>.		<https://www.rfc-editor.org/rfc/rfc8558>.
	[PATTERNS] Gamma, E., Helm, R., Johnson, R., and J. Vlissides,		[PATTERNS] Gamma, E., Helm, R., Johnson, R., and J. Vlissides,
	"Design Patterns: Elements of Reusable Object-Oriented		"Design Patterns: Elements of Reusable Object-Oriented
	Software", 1994.		Software", 1994.
	[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", Work in Progress, Internet-Draft,		and Secure Transport", Work in Progress, Internet-Draft,
	draft-ietf-quic-transport-33, 13 December 2020,		draft-ietf-quic-transport-34, 14 January 2021,
	<http://www.ietf.org/internet-drafts/draft-ietf-quic-		<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
	transport-33.txt>.		transport-34>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<https://www.rfc-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/rfc/rfc3261>.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003,		DOI 10.17487/RFC3552, July 2003,
	<https://www.rfc-editor.org/info/rfc3552>.		<https://www.rfc-editor.org/rfc/rfc3552>.
	[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of		[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of
	the Middle and the Future of End-to-End: Reflections on		the Middle and the Future of End-to-End: Reflections on
	the Evolution of the Internet Architecture", RFC 3724,		the Evolution of the Internet Architecture", RFC 3724,
	DOI 10.17487/RFC3724, March 2004,		DOI 10.17487/RFC3724, March 2004,
	<https://www.rfc-editor.org/info/rfc3724>.		<https://www.rfc-editor.org/rfc/rfc3724>.
	[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session		[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
	Initiation Protocol (SIP) Back-to-Back User Agents",		Initiation Protocol (SIP) Back-to-Back User Agents",
	RFC 7092, DOI 10.17487/RFC7092, December 2013,		RFC 7092, DOI 10.17487/RFC7092, December 2013,
	<https://www.rfc-editor.org/info/rfc7092>.		<https://www.rfc-editor.org/rfc/rfc7092>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <https://www.rfc-editor.org/info/rfc7258>.		2014, <https://www.rfc-editor.org/rfc/rfc7258>.
	[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.		[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
	Nordmark, "Technical Considerations for Internet Service		Nordmark, "Technical Considerations for Internet Service
	Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,		Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
	March 2016, <https://www.rfc-editor.org/info/rfc7754>.		March 2016, <https://www.rfc-editor.org/rfc/rfc7754>.
	[RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays		[RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays
	around NAT (TURN) Server Auto Discovery", RFC 8155,		around NAT (TURN) Server Auto Discovery", RFC 8155,
	DOI 10.17487/RFC8155, April 2017,		DOI 10.17487/RFC8155, April 2017,
	<https://www.rfc-editor.org/info/rfc8155>.		<https://www.rfc-editor.org/rfc/rfc8155>.
	[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of		[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
	Pervasive Encryption on Operators", RFC 8404,		Pervasive Encryption on Operators", RFC 8404,
	DOI 10.17487/RFC8404, July 2018,		DOI 10.17487/RFC8404, July 2018,
	<https://www.rfc-editor.org/info/rfc8404>.		<https://www.rfc-editor.org/rfc/rfc8404>.
	[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.		[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
	Jacquenet, "An Inventory of Transport-Centric Functions		Jacquenet, "An Inventory of Transport-Centric Functions
	Provided by Middleboxes: An Operator Perspective",		Provided by Middleboxes: An Operator Perspective",
	RFC 8517, DOI 10.17487/RFC8517, February 2019,		RFC 8517, DOI 10.17487/RFC8517, February 2019,
	<https://www.rfc-editor.org/info/rfc8517>.		<https://www.rfc-editor.org/rfc/rfc8517>.
	[SRv6NP] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
	Matsushima, S., and Z. Li, "SRv6 Network Programming",
	Work in Progress, Internet-Draft, draft-ietf-spring-srv6-
	network-programming-28, 29 December 2020,
	<http://www.ietf.org/internet-drafts/draft-ietf-spring-
	srv6-network-programming-28.txt>.
	[STUN] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,		[SRv6] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
	D., Mahy, R., and P. Matthews, "Session Traversal		D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
	Utilities for NAT (STUN)", Work in Progress, Internet-		(SRv6) Network Programming", RFC 8986,
	Draft, draft-ietf-tram-stunbis-21, 22 March 2019,		DOI 10.17487/RFC8986, February 2021,
	<http://www.ietf.org/internet-drafts/draft-ietf-tram-		<https://www.rfc-editor.org/rfc/rfc8986>.
	stunbis-21.txt>.
	[TCP-EXTEND]		[TCP-EXTEND]
	Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,		Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
	Handley, M., and H. Tokuda, "Is it still possible to		Handley, M., and H. Tokuda, "Is it still possible to
	extend TCP?", Proceedings of the 2011 ACM SIGCOMM		extend TCP?", Proceedings of the 2011 ACM SIGCOMM
	conference on Internet measurement conference - IMC '11,		conference on Internet measurement conference - IMC '11,
	DOI 10.1145/2068816.2068834, 2011,		DOI 10.1145/2068816.2068834, 2011,
	<https://doi.org/10.1145/2068816.2068834>.		<https://doi.org/10.1145/2068816.2068834>.
	[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/rfc/rfc8446>.
	[TSV-ENC] Fairhurst, G. and C. Perkins, "Considerations around		[TSV-ENC] Fairhurst, G. and C. Perkins, "Considerations around
	Transport Header Confidentiality, Network Operations, and		Transport Header Confidentiality, Network Operations, and
	the Evolution of Internet Transport Protocols", Work in		the Evolution of Internet Transport Protocols", Work in
	Progress, Internet-Draft, draft-ietf-tsvwg-transport-		Progress, Internet-Draft, draft-ietf-tsvwg-transport-
	encrypt-18, 2 November 2020, <http://www.ietf.org/		encrypt-21, 20 April 2021,
	internet-drafts/draft-ietf-tsvwg-transport-encrypt-		<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
	18.txt>.		transport-encrypt-21>.
	[UNSAF] Daigle, L., Ed. and IAB, "IAB Considerations for
	UNilateral Self-Address Fixing (UNSAF) Across Network
	Address Translation", RFC 3424, DOI 10.17487/RFC3424,
	November 2002, <https://www.rfc-editor.org/info/rfc3424>.
	[USE-IT] Thomson, M., "Long-term Viability of Protocol Extension		[USE-IT] Thomson, M., "Long-term Viability of Protocol Extension
	Mechanisms", Work in Progress, Internet-Draft, draft-iab-		Mechanisms", Work in Progress, Internet-Draft, draft-iab-
	use-it-or-lose-it-00, 7 August 2019, <http://www.ietf.org/		use-it-or-lose-it-00, 7 August 2019,
	internet-drafts/draft-iab-use-it-or-lose-it-00.txt>.		<https://datatracker.ietf.org/doc/html/draft-iab-use-it-
			or-lose-it-00>.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	This document is merely an attempt to codify existing practice.		This document is merely an attempt to codify existing practice.
	Practice that is inspired, at least in part, by prior work, including		Practice that is inspired, at least in part, by prior work, including
	[RFC3552] and [RFC3724] which both advocate for clearer articulation		[RFC3552] and [RFC3724] which both advocate for clearer articulation
	of trust boundaries.		of trust boundaries.
	Jari Arkko, Eric Rescorla, and David Schinazi are acknowledged for		Jari Arkko, Eric Rescorla, and David Schinazi are acknowledged for
	their contributions of thought, review, and text.		their contributions of thought, review, and text.
End of changes. 34 change blocks.
	82 lines changed or deleted		72 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/