rfc9335v3.txt		rfc9335.txt
	Internet Engineering Task Force (IETF) J. Uberti		Internet Engineering Task Force (IETF) J. Uberti
	Request for Comments: 9335 Clubhouse		Request for Comments: 9335
	Updates: 3711 C. Jennings		Updates: 3711 C. Jennings
	Category: Standards Track Cisco		Category: Standards Track Cisco
	ISSN: 2070-1721 S. Garcia Murillo		ISSN: 2070-1721 S. Garcia Murillo
	Millicast		Millicast
	January 2023		January 2023
	Completely Encrypting RTP Header Extensions and Contributing Sources		Completely Encrypting RTP Header Extensions and Contributing Sources
	Abstract		Abstract
	skipping to change at line 192 ¶		skipping to change at line 192 ¶
	* Protection of CSRCs when present		* Protection of CSRCs when present
	* Simple signaling		* Simple signaling
	* Simple crypto transform and SRTP interactions		* Simple crypto transform and SRTP interactions
	* Backward compatibility with unencrypted endpoints, if desired		* Backward compatibility with unencrypted endpoints, if desired
	* Backward compatibility with existing RTP tooling		* Backward compatibility with existing RTP tooling
	The last point deserves further discussion. While considering		The last point deserves further discussion. While other possible
	possible solutions that would have encrypted more of the RTP header		solutions that would have encrypted more of the RTP header (e.g., the
	(e.g., the number of CSRCs), lack of support on current tools was		number of CSRCs) were considered, the inability to parse the
	inevitable, and the additional complexity outweighed the slight		resultant packets with current tools and a generally higher level of
	improvement in confidentiality by fixing previous solutions. Hence,		complexity outweighed the slight improvement in confidentiality in
	a new approach was needed to solve the problem described in		these solutions. Hence, a more pragmatic approach was taken to solve
	Section 1.1.		the problem described in Section 1.1.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Design		3. Design
	skipping to change at line 306 ¶		skipping to change at line 306 ¶
	5.1. Sending		5.1. Sending
	When the mechanism defined by this specification has been negotiated,		When the mechanism defined by this specification has been negotiated,
	sending an RTP packet that has any CSRCs or contains any header		sending an RTP packet that has any CSRCs or contains any header
	extensions [RFC8285] follows the steps below. This mechanism MUST		extensions [RFC8285] follows the steps below. This mechanism MUST
	NOT be used with header extensions other than the variety described		NOT be used with header extensions other than the variety described
	in [RFC8285].		in [RFC8285].
	If the RTP packet contains one-byte headers, the 16-bit RTP header		If the RTP packet contains one-byte headers, the 16-bit RTP header
	extension tag MUST be set to 0xC0DE to indicate that the encryption		extension tag MUST be set to 0xC0DE to indicate that the encryption
	has been applied and the one-byte framing is being used. Otherwise,		has been applied and the one-byte framing is being used. If the RTP
	the header extension tag MUST be set to 0xC2DE to indicate encryption		packet contains two-byte headers, the header extension tag MUST be
	has been applied and the two-byte framing is being used.		set to 0xC2DE to indicate encryption has been applied and the two-
			byte framing is being used.
	If the packet contains CSRCs but no header extensions, an empty		If the packet contains CSRCs but no header extensions, an empty
	extension block consisting of the 0xC0DE tag and a 16-bit length		extension block consisting of the 0xC0DE tag and a 16-bit length
	field set to zero (explicitly permitted by [RFC3550]) MUST be		field set to zero (explicitly permitted by [RFC3550]) MUST be
	appended, and the X bit MUST be set to 1 to indicate an extension		appended, and the X bit MUST be set to 1 to indicate an extension
	block is present. This is necessary to provide the receiver an		block is present. This is necessary to provide the receiver an
	indication that the CSRCs in the packet are encrypted.		indication that the CSRCs in the packet are encrypted.
	The RTP packet MUST then be encrypted as described in Section 6.2		The RTP packet MUST then be encrypted as described in Section 6.2
	("Encryption Procedure").		("Encryption Procedure").
	skipping to change at line 1051 ¶		skipping to change at line 1052 ¶
	Acknowledgements		Acknowledgements
	The authors wish to thank Lennart Grahl for pointing out many of the		The authors wish to thank Lennart Grahl for pointing out many of the
	issues with the existing header encryption mechanism, as well as		issues with the existing header encryption mechanism, as well as
	suggestions for this proposal. Thanks also to Jonathan Lennox, Inaki		suggestions for this proposal. Thanks also to Jonathan Lennox, Inaki
	Castillo, and Bernard Aboba for their reviews and suggestions.		Castillo, and Bernard Aboba for their reviews and suggestions.
	Authors' Addresses		Authors' Addresses
	Justin Uberti		Justin Uberti
	Clubhouse
	Email: justin@uberti.name		Email: justin@uberti.name
	Cullen Jennings		Cullen Jennings
	Cisco		Cisco
	Email: fluffy@iii.ca		Email: fluffy@iii.ca
	Sergio Garcia Murillo		Sergio Garcia Murillo
	Millicast		Millicast
	Email: sergio.garcia.murillo@cosmosoftware.io		Email: sergio.garcia.murillo@cosmosoftware.io
End of changes. 4 change blocks.
	12 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.48.