rfc9768v7.txt		rfc9768.txt
	skipping to change at line 1514 ¶		skipping to change at line 1514 ¶
	RFC 3168 says that a router that changes ECT to Not-ECT is invalid		RFC 3168 says that a router that changes ECT to Not-ECT is invalid
	but safe. However, from a host's viewpoint, this transition is		but safe. However, from a host's viewpoint, this transition is
	unsafe because it could be the result of two transitions at different		unsafe because it could be the result of two transitions at different
	routers on the path: ECT to CE (safe) then CE to Not-ECT (unsafe).		routers on the path: ECT to CE (safe) then CE to Not-ECT (unsafe).
	This scenario could well happen where an ECN-enabled home router		This scenario could well happen where an ECN-enabled home router
	congests its upstream mobile broadband bottleneck link, then the		congests its upstream mobile broadband bottleneck link, then the
	ingress to the mobile network clears the ECN field [Mandalari18].		ingress to the mobile network clears the ECN field [Mandalari18].
	3.2.2.4. Testing for Zeroing of the ACE Field		3.2.2.4. Testing for Zeroing of the ACE Field
			NOTE: This section does not concern the case where the ACE field is
			zero when the handshake encoding has been used on the ACK of the SYN/
			ACK under the carefully worded conditions in Section 3.2.2.1
	Section 3.2.2 required the Data Receiver to initialize the r.cep		Section 3.2.2 required the Data Receiver to initialize the r.cep
	counter to a non-zero value. Therefore, in either direction the		counter to a non-zero value. Therefore, in either direction the
	initial value of the ACE counter ought to be non-zero.		initial value of the ACE counter ought to be non-zero. However, if
			reordering occurs, the first feedback packet that arrives will not
	This section does not concern the case where the ACE field is zero
	when the handshake encoding has been used on the ACK of the SYN/ACK
	under the carefully worded conditions in Section 3.2.2.1.
	If AccECN has been successfully negotiated, the Data Sender MAY check
	the value of the ACE counter in the first feedback packet (with or
	without data) that arrives after the three-way handshake. If the
	value of this ACE field is found to be zero (0b000), for the
	remainder of the half-connection the Data Sender ought to send non-
	ECN-capable packets and it is advised not to respond to any feedback
	of CE markings.
	Reason: the symptoms imply any or all of the following:
	* the remote peer has somehow entered Not ECN feedback mode;
	* a broken remote TCP implementation;
	* potential mangling of the ECN fields in the TCP headers (although
	unlikely given they clearly survived during the handshake).
	This advice is not stated normatively (in capitals), because the best
	strategy might depend on the likelihood to experience these
	scenarios, which can only be known at the time of deployment.
	| Note that a host in AccECN mode MUST continue to provide
	| Accurate ECN feedback to its peer, even if it is no longer
	| sending ECT itself over the other half-connection.
	If reordering occurs, the first feedback packet that arrives will not
	necessarily be the same as the first packet in sequence order. The		necessarily be the same as the first packet in sequence order. The
	test has been specified loosely like this to simplify implementation,		possibility of reordering means that there is a chance that the ACE
	and because it would not have been any more precise to have specified		field on the first packet to arrive is genuinely zero (without
	the first packet in sequence order, which would not necessarily be		middlebox interference). This would cause a host to unnecessarily
	the first ACE counter that the Data Receiver fed back anyway, given		disable ECN for a half-connection. Therefore, it is NOT RECOMMENDED
	it might have been a retransmission.		to explicitly test for zeroing/bleaching of the ACE as reordering or
			ACK loss can still cause the initially observed value to be zero and
	The possibility of reordering means that there is a small chance that		would disable AccECN randomly and unnecessarily.
	the ACE field on the first packet to arrive is genuinely zero
	(without middlebox interference). This would cause a host to
	unnecessarily disable ECN for a half-connection. Therefore, in
	environments where there is no evidence of the ACE field being
	zeroed, implementations MAY skip this test.
	| Note that the Data Sender MUST NOT test whether the arriving		Further, the Data Sender MUST NOT test whether the arriving counter
	| counter in the initial ACE field has been initialized to a		in the initial ACE field has been initialized to a specific valid
	| specific valid value -- the above check solely tests whether		value. This allows hosts to use different initial values as an
	| the ACE fields have been incorrectly zeroed. This allows hosts		additional signalling channel in the future.
	| to use different initial values as an additional signalling
	| channel in the future.
	3.2.2.5. Safety Against Ambiguity of the ACE Field		3.2.2.5. Safety Against Ambiguity of the ACE Field
	If too many CE-marked segments are acknowledged at once, or if a long		If too many CE-marked segments are acknowledged at once, or if a long
	run of ACKs is lost or thinned out, the 3-bit counter in the ACE		run of ACKs is lost or thinned out, the 3-bit counter in the ACE
	field might have cycled between two ACKs arriving at the Data Sender.		field might have cycled between two ACKs arriving at the Data Sender.
	The following safety procedures minimize this ambiguity.		The following safety procedures minimize this ambiguity.
	3.2.2.5.1. Packet Receiver Safety Procedures		3.2.2.5.1. Packet Receiver Safety Procedures
	skipping to change at line 2679 ¶		skipping to change at line 2646 ¶
	A generic privacy concern of any new protocol is that for a while it		A generic privacy concern of any new protocol is that for a while it
	will be used by a small population of hosts, and thus those hosts		will be used by a small population of hosts, and thus those hosts
	could be more easily identified. However, it is expected that AccECN		could be more easily identified. However, it is expected that AccECN
	will become available in more operating systems over time and that it		will become available in more operating systems over time and that it
	will eventually be turned on by default. Thus, an individual		will eventually be turned on by default. Thus, an individual
	identification of a particular user is less of a concern than the		identification of a particular user is less of a concern than the
	fingerprinting of specific versions of operation systems. However,		fingerprinting of specific versions of operation systems. However,
	the latter can be done using different means independent of Accurate		the latter can be done using different means independent of Accurate
	ECN.		ECN.
	As Accurate ECN exposes more bits in the TCP header that could be
	tampered with without interfering with the transport excessively, it
	may allow an additional way to identify specific data streams across
	a virtual private network (VPN) to an attacker that has access to the
	datastream before and after the VPN tunnel endpoints. This may be
	achieved by injecting or modifying the ACE field in specific patterns
	that can be recognized.
	Overall, Accurate ECN does not change the risk profile on privacy to
	a user dramatically beyond what is already possible using classic
	ECN. However, in order to prevent such attacks and means of easier
	identification of flows, it is advisable for privacy-conscious users
	behind VPNs to not enable Accurate ECN, or Classic ECN for that
	matter.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP		[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
	Selective Acknowledgment Options", RFC 2018,		Selective Acknowledgment Options", RFC 2018,
	DOI 10.17487/RFC2018, October 1996,		DOI 10.17487/RFC2018, October 1996,
	<https://www.rfc-editor.org/info/rfc2018>.		<https://www.rfc-editor.org/info/rfc2018>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
End of changes. 5 change blocks.
	65 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.48.