draft-ietf-sframe-encv4.txt		rfc9605.txt
	sframe E. Omara		Internet Engineering Task Force (IETF) E. Omara
	Internet-Draft Apple		Request for Comments: 9605 Apple
	Intended status: Standards Track J. Uberti		Category: Standards Track J. Uberti
	Expires: 18 January 2025 Fixie.ai		ISSN: 2070-1721 Fixie.ai
	S. G. Murillo		S. G. Murillo
	CoSMo Software		CoSMo Software
	R. Barnes, Ed.		R. Barnes, Ed.
	Cisco		Cisco
	Y. Fablet		Y. Fablet
	Apple		Apple
	17 July 2024		July 2024
	Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-		Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-
	Time Media		Time Media
	draft-ietf-sframe-enc-latest
	Abstract		Abstract
	This document describes the Secure Frame (SFrame) end-to-end		This document describes the Secure Frame (SFrame) end-to-end
	encryption and authentication mechanism for media frames in a		encryption and authentication mechanism for media frames in a
	multiparty conference call, in which central media servers (Selective		multiparty conference call, in which central media servers (Selective
	Forwarding Units or SFUs) can access the media metadata needed to		Forwarding Units or SFUs) can access the media metadata needed to
	make forwarding decisions without having access to the actual media.		make forwarding decisions without having access to the actual media.
	This mechanism differs from the Secure Real-Time Protocol (SRTP) in		This mechanism differs from the Secure Real-Time Protocol (SRTP) in
	that it is independent of RTP (thus compatible with non-RTP media		that it is independent of RTP (thus compatible with non-RTP media
	transport) and can be applied to whole media frames in order to be		transport) and can be applied to whole media frames in order to be
	more bandwidth efficient.		more bandwidth efficient.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 18 January 2025.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9605.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology
	3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Goals
	4. SFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. SFrame
	4.1. Application Context . . . . . . . . . . . . . . . . . . . 5		4.1. Application Context
	4.2. SFrame Ciphertext . . . . . . . . . . . . . . . . . . . . 7		4.2. SFrame Ciphertext
	4.3. SFrame Header . . . . . . . . . . . . . . . . . . . . . . 8		4.3. SFrame Header
	4.4. Encryption Schema . . . . . . . . . . . . . . . . . . . . 9		4.4. Encryption Schema
	4.4.1. Key Selection . . . . . . . . . . . . . . . . . . . . 10		4.4.1. Key Selection
	4.4.2. Key Derivation . . . . . . . . . . . . . . . . . . . 11		4.4.2. Key Derivation
	4.4.3. Encryption . . . . . . . . . . . . . . . . . . . . . 11		4.4.3. Encryption
	4.4.4. Decryption . . . . . . . . . . . . . . . . . . . . . 13		4.4.4. Decryption
	4.5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 15		4.5. Cipher Suites
	4.5.1. AES-CTR with SHA2 . . . . . . . . . . . . . . . . . . 16		4.5.1. AES-CTR with SHA2
	5. Key Management . . . . . . . . . . . . . . . . . . . . . . . 18		5. Key Management
	5.1. Sender Keys . . . . . . . . . . . . . . . . . . . . . . . 19		5.1. Sender Keys
	5.2. MLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		5.2. MLS
	6. Media Considerations . . . . . . . . . . . . . . . . . . . . 22		6. Media Considerations
	6.1. Selective Forwarding Units . . . . . . . . . . . . . . . 22		6.1. Selective Forwarding Units
	6.1.1. RTP Stream Reuse . . . . . . . . . . . . . . . . . . 23		6.1.1. RTP Stream Reuse
	6.1.2. Simulcast . . . . . . . . . . . . . . . . . . . . . . 23		6.1.2. Simulcast
	6.1.3. Scalable Video Coding (SVC) . . . . . . . . . . . . . 23		6.1.3. Scalable Video Coding (SVC)
	6.2. Video Key Frames . . . . . . . . . . . . . . . . . . . . 23		6.2. Video Key Frames
	6.3. Partial Decoding . . . . . . . . . . . . . . . . . . . . 24		6.3. Partial Decoding
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 24		7. Security Considerations
	7.1. No Header Confidentiality . . . . . . . . . . . . . . . . 24		7.1. No Header Confidentiality
	7.2. No Per-Sender Authentication . . . . . . . . . . . . . . 24		7.2. No Per-Sender Authentication
	7.3. Key Management . . . . . . . . . . . . . . . . . . . . . 25		7.3. Key Management
	7.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 25		7.4. Replay
	7.5. Risks Due to Short Tags . . . . . . . . . . . . . . . . . 25		7.5. Risks Due to Short Tags
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		8. IANA Considerations
	8.1. SFrame Cipher Suites . . . . . . . . . . . . . . . . . . 26		8.1. SFrame Cipher Suites
			9. Application Responsibilities
	9. Application Responsibilities . . . . . . . . . . . . . . . . 27		9.1. Header Value Uniqueness
	9.1. Header Value Uniqueness . . . . . . . . . . . . . . . . . 28		9.2. Key Management Framework
	9.2. Key Management Framework . . . . . . . . . . . . . . . . 28		9.3. Anti-Replay
	9.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 29		9.4. Metadata
	9.4. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 29		10. References
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		10.1. Normative References
	10.1. Normative References . . . . . . . . . . . . . . . . . . 30		10.2. Informative References
	10.2. Informative References . . . . . . . . . . . . . . . . . 30		Appendix A. Example API
	Appendix A. Example API . . . . . . . . . . . . . . . . . . . . 32		Appendix B. Overhead Analysis
	Appendix B. Overhead Analysis . . . . . . . . . . . . . . . . . 33		B.1. Assumptions
	B.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 34		B.2. Audio
	B.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 35		B.3. Video
	B.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 35		B.4. Conferences
	B.4. Conferences . . . . . . . . . . . . . . . . . . . . . . . 37		B.5. SFrame over RTP
	B.5. SFrame over RTP . . . . . . . . . . . . . . . . . . . . . 37		Appendix C. Test Vectors
	Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 40		C.1. Header Encoding/Decoding
	C.1. Header Encoding/Decoding . . . . . . . . . . . . . . . . 40		C.2. AEAD Encryption/Decryption Using AES-CTR and HMAC
	C.2. AEAD Encryption/Decryption Using AES-CTR and HMAC . . . . 65		C.3. SFrame Encryption/Decryption
	C.3. SFrame Encryption/Decryption . . . . . . . . . . . . . . 66		Acknowledgements
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71		Contributors
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 71		Authors' Addresses
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
	1. Introduction		1. Introduction
	Modern multiparty video call systems use Selective Forwarding Unit		Modern multiparty video call systems use Selective Forwarding Unit
	(SFU) servers to efficiently route media streams to call endpoints		(SFU) servers to efficiently route media streams to call endpoints
	based on factors such as available bandwidth, desired video size,		based on factors such as available bandwidth, desired video size,
	codec support, and other factors. An SFU typically does not need		codec support, and other factors. An SFU typically does not need
	access to the media content of the conference, which allows the media		access to the media content of the conference, which allows the media
	to be encrypted "end to end" so that it cannot be decrypted by the		to be encrypted "end to end" so that it cannot be decrypted by the
	SFU. In order for the SFU to work properly, though, it usually needs		SFU. In order for the SFU to work properly, though, it usually needs
	skipping to change at page 4, line 47 ¶		skipping to change at line 183 ¶
	calls that can be used with arbitrary SFU servers.		calls that can be used with arbitrary SFU servers.
	2. Decouple media encryption from key management to allow SFrame to		2. Decouple media encryption from key management to allow SFrame to
	be used with an arbitrary key management system.		be used with an arbitrary key management system.
	3. Minimize packet expansion to allow successful conferencing in as		3. Minimize packet expansion to allow successful conferencing in as
	many network conditions as possible.		many network conditions as possible.
	4. Decouple the media encryption framework from the underlying		4. Decouple the media encryption framework from the underlying
	transport, allowing use in non-RTP scenarios, e.g., WebTransport		transport, allowing use in non-RTP scenarios, e.g., WebTransport
	[I-D.ietf-webtrans-overview].		[WEBTRANSPORT].
	5. When used with RTP and its associated error-resilience		5. When used with RTP and its associated error-resilience
	mechanisms, i.e., RTX and Forward Error Correction (FEC), require		mechanisms, i.e., RTX and Forward Error Correction (FEC), require
	no special handling for RTX and FEC packets.		no special handling for RTX and FEC packets.
	6. Minimize the changes needed in SFU servers.		6. Minimize the changes needed in SFU servers.
	7. Minimize the changes needed in endpoints.		7. Minimize the changes needed in endpoints.
	8. Work with the most popular audio and video codecs used in		8. Work with the most popular audio and video codecs used in
	skipping to change at page 5, line 25 ¶		skipping to change at line 209 ¶
	E2EE, is simple to implement, has no dependencies on RTP, and		E2EE, is simple to implement, has no dependencies on RTP, and
	minimizes encryption bandwidth overhead. This section describes how		minimizes encryption bandwidth overhead. This section describes how
	the mechanism works and includes details of how applications utilize		the mechanism works and includes details of how applications utilize
	SFrame for media protection as well as the actual mechanics of E2EE		SFrame for media protection as well as the actual mechanics of E2EE
	for protecting media.		for protecting media.
	4.1. Application Context		4.1. Application Context
	SFrame is a general encryption framing, intended to be used as an		SFrame is a general encryption framing, intended to be used as an
	E2EE layer over an underlying HBH-encrypted transport such as SRTP or		E2EE layer over an underlying HBH-encrypted transport such as SRTP or
	QUIC [RFC3711][I-D.ietf-moq-transport].		QUIC [RFC3711][MOQ-TRANSPORT].
	The scale at which SFrame encryption is applied to media determines		The scale at which SFrame encryption is applied to media determines
	the overall amount of overhead that SFrame adds to the media stream		the overall amount of overhead that SFrame adds to the media stream
	as well as the engineering complexity involved in integrating SFrame		as well as the engineering complexity involved in integrating SFrame
	into a particular environment. Two patterns are common: using SFrame		into a particular environment. Two patterns are common: using SFrame
	to encrypt either whole media frames (per frame) or individual		to encrypt either whole media frames (per frame) or individual
	transport-level media payloads (per packet).		transport-level media payloads (per packet).
	For example, Figure 1 shows a typical media sender stack that takes		For example, Figure 1 shows a typical media sender stack that takes
	media from some source, encodes it into frames, divides those frames		media from some source, encodes it into frames, divides those frames
	skipping to change at page 30, line 19 ¶		skipping to change at line 1273 ¶
	data.		data.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[MLS-PROTO]		[MLS-PROTO]
	Barnes, R., Beurdouche, B., Robert, R., Millican, J.,		Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
	Omara, E., and K. Cohn-Gordon, "The Messaging Layer		Omara, E., and K. Cohn-Gordon, "The Messaging Layer
	Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,		Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
	July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.		July 2023, <https://www.rfc-editor.org/info/rfc9420>.
	[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-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated		[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
	Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,		Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
	<https://www.rfc-editor.org/rfc/rfc5116>.		<https://www.rfc-editor.org/info/rfc5116>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,		Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,		DOI 10.17487/RFC5869, May 2010,
	<https://www.rfc-editor.org/rfc/rfc5869>.		<https://www.rfc-editor.org/info/rfc5869>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/rfc/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[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/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	10.2. Informative References		10.2. Informative References
	[I-D.gouaillard-avtcore-codec-agn-rtp-payload]
	Murillo, S. G., Fablet, Y., and A. Gouaillard, "Codec
	agnostic RTP payload format for video", Work in Progress,
	Internet-Draft, draft-gouaillard-avtcore-codec-agn-rtp-
	payload-01, 9 March 2021,
	<https://datatracker.ietf.org/doc/html/draft-gouaillard-
	avtcore-codec-agn-rtp-payload-01>.
	[I-D.ietf-moq-transport]
	Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and
	I. Swett, "Media over QUIC Transport", Work in Progress,
	Internet-Draft, draft-ietf-moq-transport-05, 8 July 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
	transport-05>.
	[I-D.ietf-webtrans-overview]
	Vasiliev, V., "The WebTransport Protocol Framework", Work
	in Progress, Internet-Draft, draft-ietf-webtrans-overview-
	07, 4 March 2024, <https://datatracker.ietf.org/doc/html/
	draft-ietf-webtrans-overview-07>.
	[MLS-ARCH] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and		[MLS-ARCH] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and
	A. Duric, "The Messaging Layer Security (MLS)		A. Duric, "The Messaging Layer Security (MLS)
	Architecture", Work in Progress, Internet-Draft, draft-		Architecture", Work in Progress, Internet-Draft, draft-
	ietf-mls-architecture-14, 8 July 2024,		ietf-mls-architecture-14, 8 July 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-mls-		<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
	architecture-14>.		architecture-14>.
			[MOQ-TRANSPORT]
			Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and
			I. Swett, Ed., "Media over QUIC Transport", Work in
			Progress, Internet-Draft, draft-ietf-moq-transport-05, 8
			July 2024, <https://datatracker.ietf.org/doc/html/draft-
			ietf-moq-transport-05>.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, DOI 10.17487/RFC3711, March 2004,		RFC 3711, DOI 10.17487/RFC3711, March 2004,
	<https://www.rfc-editor.org/rfc/rfc3711>.		<https://www.rfc-editor.org/info/rfc3711>.
	[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the		[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
	Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,		Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
	September 2012, <https://www.rfc-editor.org/rfc/rfc6716>.		September 2012, <https://www.rfc-editor.org/info/rfc6716>.
	[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and		[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
	B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms		B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
	for Real-Time Transport Protocol (RTP) Sources", RFC 7656,		for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
	DOI 10.17487/RFC7656, November 2015,		DOI 10.17487/RFC7656, November 2015,
	<https://www.rfc-editor.org/rfc/rfc7656>.		<https://www.rfc-editor.org/info/rfc7656>.
	[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,		[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
	DOI 10.17487/RFC7667, November 2015,		DOI 10.17487/RFC7667, November 2015,
	<https://www.rfc-editor.org/rfc/rfc7667>.		<https://www.rfc-editor.org/info/rfc7667>.
	[RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach,		[RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach,
	"Double Encryption Procedures for the Secure Real-Time		"Double Encryption Procedures for the Secure Real-Time
	Transport Protocol (SRTP)", RFC 8723,		Transport Protocol (SRTP)", RFC 8723,
	DOI 10.17487/RFC8723, April 2020,		DOI 10.17487/RFC8723, April 2020,
	<https://www.rfc-editor.org/rfc/rfc8723>.		<https://www.rfc-editor.org/info/rfc8723>.
	[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:		[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
	Session Description Protocol", RFC 8866,		Session Description Protocol", RFC 8866,
	DOI 10.17487/RFC8866, January 2021,		DOI 10.17487/RFC8866, January 2021,
	<https://www.rfc-editor.org/rfc/rfc8866>.		<https://www.rfc-editor.org/info/rfc8866>.
			[RTP-PAYLOAD]
			Murillo, S. G., Fablet, Y., and A. Gouaillard, "Codec
			agnostic RTP payload format for video", Work in Progress,
			Internet-Draft, draft-gouaillard-avtcore-codec-agn-rtp-
			payload-01, 9 March 2021,
			<https://datatracker.ietf.org/doc/html/draft-gouaillard-
			avtcore-codec-agn-rtp-payload-01>.
	[TestVectors]		[TestVectors]
	"SFrame Test Vectors", commit 025d568, September 2023,		"SFrame Test Vectors", commit 025d568, September 2023,
	<https://github.com/sframe-wg/sframe/blob/025d568/test-		<https://github.com/sframe-wg/sframe/blob/025d568/test-
	vectors/test-vectors.json>.		vectors/test-vectors.json>.
			[WEBTRANSPORT]
			Vasiliev, V., "The WebTransport Protocol Framework", Work
			in Progress, Internet-Draft, draft-ietf-webtrans-overview-
			07, 4 March 2024, <https://datatracker.ietf.org/doc/html/
			draft-ietf-webtrans-overview-07>.
	Appendix A. Example API		Appendix A. Example API
	*This section is not normative.*		*This section is not normative.*
	This section describes a notional API that an SFrame implementation		This section describes a notional API that an SFrame implementation
	might expose. The core concept is an "SFrame context", within which		might expose. The core concept is an "SFrame context", within which
	KID values are meaningful. In the key management scheme described in		KID values are meaningful. In the key management scheme described in
	Section 5.1, each sender has a different context; in the scheme		Section 5.1, each sender has a different context; in the scheme
	described in Section 5.2, all senders share the same context.		described in Section 5.2, all senders share the same context.
	skipping to change at page 35, line 34 ¶		skipping to change at line 1521 ¶
	+--------------+--------------+-----+------+----------+----------+		+--------------+--------------+-----+------+----------+----------+
	| Full-band | 10 ms | 100 | 128 | 17.2 | 13.4% |		| Full-band | 10 ms | 100 | 128 | 17.2 | 13.4% |
	| stereo music | | | | | |		| stereo music | | | | | |
	+--------------+--------------+-----+------+----------+----------+		+--------------+--------------+-----+------+----------+----------+
	Table 4: SFrame Overhead for Audio Streams		Table 4: SFrame Overhead for Audio Streams
	B.3. Video		B.3. Video
	Video frames can be larger than an MTU and thus are commonly split		Video frames can be larger than an MTU and thus are commonly split
	across multiple frames. Table 5 and Table 6 show the estimated		across multiple frames. Tables 5 and 6 show the estimated overhead
	overhead of encrypting a video stream, where SFrame is applied per		of encrypting a video stream, where SFrame is applied per frame and
	frame and per packet, respectively. The choices of resolution,		per packet, respectively. The choices of resolution, frames per
	frames per second, and bandwidth roughly reflect the capabilities of		second, and bandwidth roughly reflect the capabilities of modern
	modern video codecs across a range from very low to very high		video codecs across a range from very low to very high quality.
	quality.
	+=============+=====+===========+===============+============+		+=============+=====+===========+===============+============+
	| Scenario | fps | Base kbps | Overhead kbps | Overhead % |		| Scenario | fps | Base kbps | Overhead kbps | Overhead % |
	+=============+=====+===========+===============+============+		+=============+=====+===========+===============+============+
	| 426 x 240 | 7.5 | 45 | 1.3 | 2.9% |		| 426 x 240 | 7.5 | 45 | 1.3 | 2.9% |
	+-------------+-----+-----------+---------------+------------+		+-------------+-----+-----------+---------------+------------+
	| 640 x 360 | 15 | 200 | 2.6 | 1.3% |		| 640 x 360 | 15 | 200 | 2.6 | 1.3% |
	+-------------+-----+-----------+---------------+------------+		+-------------+-----+-----------+---------------+------------+
	| 640 x 360 | 30 | 400 | 5.2 | 1.3% |		| 640 x 360 | 30 | 400 | 5.2 | 1.3% |
	+-------------+-----+-----------+---------------+------------+		+-------------+-----+-----------+---------------+------------+
	skipping to change at page 38, line 29 ¶		skipping to change at line 1638 ¶
	configuration information. In applications that use SDP for		configuration information. In applications that use SDP for
	negotiating RTP media streams [RFC8866], an appropriate extension to		negotiating RTP media streams [RFC8866], an appropriate extension to
	SDP could provide this function.		SDP could provide this function.
	Applying SFrame per frame also requires that packetization and		Applying SFrame per frame also requires that packetization and
	depacketization be done in a generic manner that does not depend on		depacketization be done in a generic manner that does not depend on
	the media content of the packets, since the content being packetized		the media content of the packets, since the content being packetized
	or depacketized will be opaque ciphertext (except for the SFrame		or depacketized will be opaque ciphertext (except for the SFrame
	header). In order for such a generic packetization scheme to work		header). In order for such a generic packetization scheme to work
	interoperably, one would have to be defined, e.g., as proposed in		interoperably, one would have to be defined, e.g., as proposed in
	[I-D.gouaillard-avtcore-codec-agn-rtp-payload].		[RTP-PAYLOAD].
	+---+-+-+-------+-+-------------+-------------------------------+<-+		+---+-+-+-------+-+-------------+-------------------------------+<-+
	|V=2|P|X| CC |M| PT | sequence number | |		|V=2|P|X| CC |M| PT | sequence number | |
	+---+-+-+-------+-+-------------+-------------------------------+ |		+---+-+-+-------+-+-------------+-------------------------------+ |
	| timestamp | |		| timestamp | |
	+---------------------------------------------------------------+ |		+---------------------------------------------------------------+ |
	| synchronization source (SSRC) identifier | |		| synchronization source (SSRC) identifier | |
	+===============================================================+ |		+===============================================================+ |
	| contributing source (CSRC) identifiers | |		| contributing source (CSRC) identifiers | |
	| .... | |		| .... | |
End of changes. 27 change blocks.
	122 lines changed or deleted		117 lines changed or added
This html diff was produced by rfcdiff 1.48.