rfc9335.original.xml		rfc9335.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
			<!-- draft submitted in xml v3 -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.15 (Ruby 2.7. 0) -->		<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.15 (Ruby 2.7. 0) -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-avtcore-cryptex-08" category="std" consensus="true" updates="3711" tocIncl		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	ude="true" sortRefs="true" symRefs="true" version="3">		-ietf-avtcore-cryptex-08" number="9335" submissionType="IETF"
	<!-- xml2rfc v2v3 conversion 3.13.1 -->		category="std" consensus="true" updates="3711" obsoletes="" tocInclude="true" so
			rtRefs="true" symRefs="true" xml:lang="en" version="3">
			<!-- xml2rfc v2v3 conversion 3.13.1 -->
	<front>		<front>
	<title>Completely Encrypting RTP Header Extensions and Contributing Sources<		<title abbrev="Completely Encrypting RTP Header Extensions and CSRCs">Comple
	/title>		tely Encrypting RTP Header Extensions and Contributing Sources</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-avtcore-cryptex-08"/>		<seriesInfo name="RFC" value="9335"/>
	<author initials="J." surname="Uberti" fullname="Justin Uberti">		<author initials="J." surname="Uberti" fullname="Justin Uberti">
	<organization>Clubhouse</organization>		<organization></organization>
	<address>		<address>
	<email>justin@uberti.name</email>		<email>justin@uberti.name</email>
	</address>		</address>
	</author>		</author>
	<author initials="C." surname="Jennings" fullname="Cullen Jennings">		<author initials="C." surname="Jennings" fullname="Cullen Jennings">
	<organization>Cisco</organization>		<organization>Cisco</organization>
	<address>		<address>
	<email>fluffy@iii.ca</email>		<email>fluffy@iii.ca</email>
	</address>		</address>
	</author>		</author>
	<author initials="S." surname="Garcia Murillo" fullname="Sergio Garcia Muril lo">		<author initials="S." surname="Garcia Murillo" fullname="Sergio Garcia Muril lo">
	<organization>Millicast</organization>		<organization>Millicast</organization>
	<address>		<address>
	<email>sergio.garcia.murillo@cosmosoftware.io</email>		<email>sergio.garcia.murillo@cosmosoftware.io</email>
	</address>		</address>
	</author>		</author>
	<date year="2022" month="August" day="04"/>		<date year="2023" month="January"/>
	<area>ART</area>		<area>ART</area>
	<workgroup>AVTCORE</workgroup>		<workgroup>AVTCORE</workgroup>
	<keyword>SRTP</keyword>		<keyword>SRTP</keyword>
	<abstract>		<abstract>
	<t>While the Secure Real-time Transport Protocol (SRTP) provides confident iality		<t>While the Secure Real-time Transport Protocol (SRTP) provides confident iality
	for the contents of a media packet, a significant amount of metadata is left		for the contents of a media packet, a significant amount of metadata is left
	unprotected, including RTP header extensions and contributing sources (CSRCs).		unprotected, including RTP header extensions and contributing sources (CSRCs).
	However, this data can be moderately sensitive in many applications. While		However, this data can be moderately sensitive in many applications. While
	there have been previous attempts to protect this data, they have had limited		there have been previous attempts to protect this data, they have had limited
	deployment, due to complexity as well as technical limitations.</t>		deployment, due to complexity as well as technical limitations.</t>
	skipping to change at line 55 ¶		skipping to change at line 61 ¶
	header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of		header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of
	facilitating deployment.</t>		facilitating deployment.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<section anchor="problem-statement">		<section anchor="problem-statement">
	<name>Problem Statement</name>		<name>Problem Statement</name>
	<t>The Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711" /> mechanism provides message		<t>The Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711" /> mechanism provides message
	authentication for the entire RTP packet, but only encrypts the RTP payload.		authentication for the entire RTP packet but only encrypts the RTP payload.
	This has not historically been a problem, as much of the information carried		This has not historically been a problem, as much of the information carried
	in the header has minimal sensitivity (e.g., RTP timestamp); in addition,		in the header has minimal sensitivity (e.g., RTP timestamp); in addition,
	certain fields need to remain as cleartext because they are used for key		certain fields need to remain as cleartext because they are used for key
	scheduling (e.g., RTP SSRC and sequence number).</t>		scheduling (e.g., RTP synchronization source (SSRC) and sequence number).</t>
	<t>However, as noted in <xref target="RFC6904"/>, the security requireme nts can be different for		<t>However, as noted in <xref target="RFC6904"/>, the security requireme nts can be different for
	information carried in RTP header extensions, including the per-packet sound		information carried in RTP header extensions, including the per-packet sound
	levels defined in <xref target="RFC6464"/> and <xref target="RFC6465"/>, which a re specifically noted as		levels defined in <xref target="RFC6464"/> and <xref target="RFC6465"/>, which a re specifically noted as
	being sensitive in the Security Considerations section of those RFCs.</t>		being sensitive in the Security Considerations sections of those RFCs.</t>
	<t>In addition to the contents of the header extensions, there are now e nough		<t>In addition to the contents of the header extensions, there are now e nough
	header extensions in active use that the header extension identifiers		header extensions in active use that the header extension identifiers
	themselves can provide meaningful information in terms of determining the		themselves can provide meaningful information in terms of determining the
	identity of the endpoint and/or application. Accordingly, these identifiers		identity of the endpoint and/or application. Accordingly, these identifiers
	can be considered a fingerprinting issue.</t>		can be considered a fingerprinting issue.</t>
	<t>Finally, the CSRCs included in RTP packets can also be sensitive, pot entially		<t>Finally, the CSRCs included in RTP packets can also be sensitive, pot entially
	allowing a network eavesdropper to determine who was speaking and when during		allowing a network eavesdropper to determine who was speaking and when during
	an otherwise secure conference call.</t>		an otherwise secure conference call.</t>
	</section>		</section>
	<section anchor="previous-solutions">		<section anchor="previous-solutions">
	<name>Previous Solutions</name>		<name>Previous Solutions</name>
	<t>Encryption of Header Extensions in SRTP <xref target="RFC6904"/> was proposed in 2013 as a solution to the problem of unprotected		<t>Encryption of Header Extensions in SRTP <xref target="RFC6904"/> was proposed in 2013 as a solution to the problem of unprotected
	header extension values. However, it has not seen significant adoption, and		header extension values. However, it has not seen significant adoption and
	has a few technical shortcomings.</t>		has a few technical shortcomings.</t>
	<t>First, the mechanism is complicated. Since it allows encryption to be
			<t>First, the mechanism is complicated. Since it allows encryption to be
	negotiated on a per-extension basis, a fair amount of signaling logic is		negotiated on a per-extension basis, a fair amount of signaling logic is
	required. And in the SRTP layer, a somewhat complex transform is required		required. And in the SRTP layer, a somewhat complex transform is required
	to allow only the selected header extension values to be encrypted. One of		to allow only the selected header extension values to be encrypted. One of
	the most popular SRTP implementations had a significant bug in this area		the most popular SRTP implementations had a significant bug in this area
	that was not detected for five years.</t>		that was not detected for five years.</t>
	<t>Second, it only protects the header extension values, and not their i ds or		<t>Second, the mechanism only protects the header extension values and n ot their identifiers or
	lengths. It also does not protect the CSRCs. As noted above, this leaves		lengths. It also does not protect the CSRCs. As noted above, this leaves
	a fair amount of potentially sensitive information exposed.</t>		a fair amount of potentially sensitive information exposed.</t>
	<t>Third, it bloats the header extension space. Because each extension m ust		<t>Third, the mechanism bloats the header extension space. Because each extensio n must
	be offered in both unencrypted and encrypted forms, twice as many header		be offered in both unencrypted and encrypted forms, twice as many header
	extensions must be offered, which will in many cases push implementations		extensions must be offered, which will in many cases push implementations
	past the 14-extension limit for the use of one-byte extension headers		past the 14-extension limit for the use of one-byte extension headers
	defined in <xref target="RFC8285"/>. Accordingly, implementations will need to u		defined in <xref target="RFC8285"/>. Accordingly, in many cases, implementations
	se		will need to use
	two-byte headers in many cases, which are not supported well by some		two-byte headers, which are not supported well by some
	existing implementations.</t>		existing implementations.</t>
	<t>Finally, the header extension bloat combined with the need for backwa rds		<t>Finally, the header extension bloat combined with the need for backwa rd
	compatibility results in additional wire overhead. Because two-byte		compatibility results in additional wire overhead. Because two-byte
	extension headers may not be handled well by existing implementations,		extension headers may not be handled well by existing implementations,
	one-byte extension identifiers will need to be used for the unencrypted		one-byte extension identifiers will need to be used for the unencrypted
	(backwards compatible) forms, and two-byte for the encrypted forms.		(backward-compatible) forms, and two-byte for the encrypted forms.
	Thus, deployment of <xref target="RFC6904"/> encryption for header extensions wi		Thus, deployment of encryption for header extensions <xref target="RFC6904"/> wi
	ll		ll
	typically result in multiple extra bytes in each RTP packet, compared		typically result in multiple extra bytes in each RTP packet, compared
	to the present situation.</t>		to the present situation.</t>
	</section>		</section>
	<section anchor="goals">		<section anchor="goals">
	<name>Goals</name>		<name>Goals</name>
	<t>From the previous analysis, the desired properties of a solution are: </t>		<t>From the previous analysis, the desired properties of a solution are: </t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Build on existing <xref target="RFC3711"/> SRTP framework (simple		<li>Built on the existing SRTP framework <xref target="RFC3711"/> (sim
	to understand)</li>		ple to understand)</li>
	<li>Build on existing <xref target="RFC8285"/> header extension framew		<li>Built on the existing header extension framework <xref target="RFC
	ork (simple to implement)</li>		8285"/> (simple to implement)</li>
	<li>Protection of header extension ids, lengths, and values</li>		<li>Protection of header extension identifiers, lengths, and values</l
			i>
	<li>Protection of CSRCs when present</li>		<li>Protection of CSRCs when present</li>
	<li>Simple signaling</li>		<li>Simple signaling</li>
	<li>Simple crypto transform and SRTP interactions</li>		<li>Simple crypto transform and SRTP interactions</li>
	<li>Backward compatible with unencrypted endpoints, if desired</li>		<li>Backward compatibility with unencrypted endpoints, if desired</li>
	<li>Backward compatible with existing RTP tooling</li>		<li>Backward compatibility with existing RTP tooling</li>
	</ul>		</ul>
	<t>The last point deserves further discussion. While considering possibl		<t>The last point deserves further discussion. While other possible
	e solutions that would have encrypted more of the RTP header (e.g., the number o		solutions that would have encrypted more of the RTP
	f CSRCs), lack of support on current tools was inevitable and the additional com		header (e.g., the number of CSRCs) were considered, the inability to pars
	plexity outweighed the slight improvement in confidentiality by fixing previous		e the
	solutions. Hence, a new approach was needed to solve the described problem in <x		resultant packets with current tools and a generally higher level of
	ref target="problem-statement"/>.</t>		complexity outweighed the slight improvement in confidentiality in
			these solutions. Hence, a more pragmatic approach was taken to solve
			the problem described in <xref target="problem-statement"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="terminology">		<section anchor="terminology">
	<name>Terminology</name>		<name>Terminology</name>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14		<t>
	>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	nterpreted as		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		be interpreted as
	only when, they		described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	appear in all capitals, as shown here.</t>		when, and only when, they appear in all capitals, as shown here.
			</t>
	</section>		</section>
	<section anchor="design">		<section anchor="design">
	<name>Design</name>		<name>Design</name>
	<t>This specification proposes a mechanism to negotiate encryption of all		<t>This specification proposes a mechanism to negotiate encryption of all
	RTP header extensions (ids, lengths, and values) as well as CSRC values. It		RTP header extensions (ids, lengths, and values) as well as CSRC values. It
	reuses the existing SRTP framework, is accordingly simple to implement, and		reuses the existing SRTP framework, is accordingly simple to implement, and
	is backward compatible with existing RTP packet parsing code, even when		is backward compatible with existing RTP packet parsing code, even when
	support for the mechanism has been negotiated.</t>		support for the mechanism has been negotiated.</t>
	<t>Except when explicitly stated otherwise, Cryptex reuses all the framewo rk procedures, transforms and considerations described in <xref target="RFC3711" />.</t>		<t>Except when explicitly stated otherwise, Cryptex reuses all the framewo rk procedures, transforms, and considerations described in <xref target="RFC3711 "/>.</t>
	</section>		</section>
	<section anchor="sdp-considerations">		<section anchor="sdp-considerations">
	<name>SDP Considerations</name>		<name>SDP Considerations</name>
	<t>Cryptex support is indicated via a new "a=cryptex" SDP attribute define d in this specification.</t>		<t>Cryptex support is indicated via a new "a=cryptex" SDP attribute define d in this specification.</t>
	<t>The new "a=cryptex" attribute is a property attribute as defined in <xr		<t>The new "a=cryptex" attribute is a property attribute as defined in <xr
	ef target="RFC8866"/> section 5.13 and therefore takes no value, and can be used		ef target="RFC8866" sectionFormat="of" section="5.13"/>; it therefore takes no v
	at the session level or media level.</t>		alue and can be used at the session level or media level.</t>
	<t>The presence of the "a=cryptex" attribute in the SDP (either in an offe		<t>The presence of the "a=cryptex" attribute in the SDP (in either an offe
	r or answer) indicates that		r or an answer) indicates that
	the endpoint is capable of receiving RTP packets encrypted with Cryptex, as defi ned below.</t>		the endpoint is capable of receiving RTP packets encrypted with Cryptex, as defi ned below.</t>
	<t>Once each peer has verified that the other party supports receiving RTP		<t>Once each peer has verified that the other party supports receiving RTP
	packets encrypted with Cryptex, senders can unilaterally decide whether to use		packets encrypted with Cryptex, senders can unilaterally decide whether or not
	or not the Cryptex mechanism on a per packet basis.</t>		to use the Cryptex mechanism on a per-packet basis.</t>
	<t>If BUNDLE is in use as per <xref target="RFC9143"/> and the "a=cryptex"
	attribute is present for a media line, it <bcp14>MUST</bcp14> be present for al		<t>If BUNDLE is in use as per <xref target="RFC9143"/> and the "a=cryptex"
	l RTP-based "m=" sections belonging to the same bundle group. This ensures that		attribute is present for a media line, it <bcp14>MUST</bcp14> be present for al
	the encrypted MID header extensions can be processed, allowing to associate RTP		l RTP-based "m=" sections belonging to the same bundle group. This ensures that
	streams with the correct "m=" section in each BUNDLE group as specified in <xref		the encrypted Media Identifier (MID) header extensions can be processed, allowin
	target="RFC9143"/> section 9.2. When used with BUNDLE, this attribute is assign		g RTP streams to be associated with the correct "m=" section in each BUNDLE grou
	ed to the TRANSPORT category <xref target="RFC8859"/>.</t>		p as specified in <xref target="RFC9143" sectionFormat="of" section="9.2"/>. Whe
	<t>Both endpoints can change the Cryptex support status by modifying the s		n used with BUNDLE, this attribute is assigned to the TRANSPORT category <xref t
	ession as specified in <xref target="RFC3264"/> section 8. Generating subsequen		arget="RFC8859"/>.</t>
	t SDP offers and answers <bcp14>MUST</bcp14> use the same procedures for includi		<t>Both endpoints can change the Cryptex support status by modifying the s
	ng the "a=cryptex" attribute as the ones on the initial offer and answer.</t>		ession as specified in <xref target="RFC3264" sectionFormat="of" section="8"/>.
			Generating subsequent SDP offers and answers <bcp14>MUST</bcp14> use the same p
			rocedures for including the "a=cryptex" attribute as the ones on the initial off
			er and answer.</t>
	</section>		</section>
	<section anchor="rtp-header-processing">		<section anchor="rtp-header-processing">
	<name>RTP Header Processing</name>		<name>RTP Header Processing</name>
	<t>A General Mechanism for RTP Header Extensions <xref target="RFC8285"/> defines two values for the "defined by profile" field for carrying		<t>A General Mechanism for RTP Header Extensions <xref target="RFC8285"/> defines two values for the "defined by profile" field for carrying
	one-byte and two-byte header extensions. In order to allow a receiver to determi ne		one-byte and two-byte header extensions. In order to allow a receiver to determi ne
	if an incoming RTP packet is using the encryption scheme in this specification,		if an incoming RTP packet is using the encryption scheme in this specification,
	two new values are defined:</t>		two new values are defined:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>0xC0DE for the encrypted version of the one-byte header extensions ( instead of 0xBEDE).</li>		<li>0xC0DE for the encrypted version of the one-byte header extensions ( instead of 0xBEDE).</li>
	<li>0xC2DE for the encrypted versions of the two-byte header extensions (instead of 0x100).</li>		<li>0xC2DE for the encrypted versions of the two-byte header extensions (instead of 0x100).</li>
	</ul>		</ul>
	<t>In the case of using two-byte header extensions, the extension id with		<t>In the case of using two-byte header extensions, the extension identifi
	value 256 <bcp14>MUST NOT</bcp14>		er with value 256 <bcp14>MUST NOT</bcp14>
	be negotiated, as the value of this id is meant to be contained in the "appbits"		be negotiated, as the value of this identifier is meant to be contained in the "
	of the		appbits" of the
	"defined by profile" field, which are not available when using the values above.		"defined by profile" field, which is not available when using the values above.<
	</t>		/t>
	<t>Note that as per <xref target="RFC8285"/> it is not possible to mix one		<t>Note that as per <xref target="RFC8285"/>, it is not possible to mix one-byte
	-byte and two-byte headers on the same RTP packet. Mixing one-byte and two-byte		and two-byte headers on the same RTP packet. Mixing one-byte and two-byte heade
	headers on the same RTP stream requires negotiation of the "extmap-allow-mixed"		rs on the same RTP stream requires negotiation of the "extmap-allow-mixed" SDP a
	SDP attribute as defined in <xref target="RFC8285"/> section 4.1.2.</t>		ttribute as defined in <xref target="RFC8285" sectionFormat="of" section="6"/>.<
	<t>Peers <bcp14>MAY</bcp14> negotiate both Cryptex and the Encryption of H		/t>
	eader Extensions mechanism defined in <xref target="RFC6904"/> via SDP offer/ans		<t>Peers <bcp14>MAY</bcp14> negotiate both Cryptex and the Encryption of H
	wer as described in <xref target="sdp-considerations"/>, and if both mechanisms		eader Extensions mechanism defined in <xref target="RFC6904"/> via SDP offer/ans
	are supported, either one can be used for any given packet. However, if a packet		wer as described in <xref target="sdp-considerations"/>, and if both mechanisms
	is encrypted with Cryptex, it <bcp14>MUST NOT</bcp14> also use <xref target="RF		are supported, either one can be used for any given packet. However, if a packet
	C6904"/> header extension encryption, and vice versa.</t>		is encrypted with Cryptex, it <bcp14>MUST NOT</bcp14> also use header extension
	<t>If one of the peers has advertised both the ability to receive cryptex		encryption <xref target="RFC6904"/>, and vice versa.</t>
	and the ability to receive header extensions encrypted as per <xref target="RFC6
	904"/> in the SDP exchange, it is <bcp14>RECOMMENDED</bcp14> for the other peer		<t> If one of the peers has advertised the ability to receive both Cryptex and
	to use Cryptex rather than <xref target="RFC6904"/> when sending RTP packets so		header extensions encrypted as per <xref target="RFC6904"/> in the SDP
	all the header extensions and CSRCS are encrypted unless there is a compelling r		exchange, it is <bcp14>RECOMMENDED</bcp14> that the other peer use Cryptex
	eason to use <xref target="RFC6904"/> (e.g. a need for some header extensions to		rather than the mechanism in <xref target="RFC6904"/> when sending RTP packets
	be sent in the clear so that so they are processable by RTP middleboxes) in whi		so that all the header extensions and CSRCS are encrypted. However, if there is
	ch case, it <bcp14>SHOULD</bcp14> use <xref target="RFC6904"/> instead.</t>		a
			compelling reason to use the mechanism in <xref target="RFC6904"/> (e.g., a
			need for some header extensions to be sent in the clear so that so they are
			processable by RTP middleboxes), the other peer <bcp14>SHOULD</bcp14> use
			the mechanism in <xref target="RFC6904"/> instead.</t>
	<section anchor="sending">		<section anchor="sending">
	<name>Sending</name>		<name>Sending</name>
	<t>When the mechanism defined by this specification has been negotiated,		<t>When the mechanism defined by this specification has been negotiated,
	sending an RTP packet that has any CSRCs or contains any <xref target="RFC8285"/		sending an RTP packet that has any CSRCs or contains any header extensions <xref
	>		target="RFC8285"/> follows the steps below. This mechanism <bcp14>MUST NOT</bcp
	header extensions follows the steps below. This mechanism <bcp14>MUST NOT</bcp14		14> be
	> be		used with header extensions other than the variety described in <xref target="RF
	used with header extensions other than the <xref target="RFC8285"/> variety.</t>		C8285"/>.</t>
	<t>If the RTP packet contains one-byte headers, the 16-bit RTP header ex		<t>If the RTP packet contains one-byte headers, the 16-bit RTP header
	tension		extension tag <bcp14>MUST</bcp14> be set to 0xC0DE to indicate that the
	tag <bcp14>MUST</bcp14> be set to 0xC0DE to indicate that the encryption has bee		encryption
	n applied, and the		has been applied and the one-byte framing is being used. If the RTP
	one-byte framing is being used. Otherwise,		packet contains two-byte headers, the header extension tag
	the header extension tag <bcp14>MUST</bcp14> be set to 0xC2DE to indicate encryp		<bcp14>MUST</bcp14> be set to 0xC2DE to indicate encryption has been app
	tion has been applied,		lied and the
	and the two-byte framing is being used.</t>		two-byte framing is being used.
			</t>
	<t>If the packet contains CSRCs but no header extensions, an empty exten sion block		<t>If the packet contains CSRCs but no header extensions, an empty exten sion block
	consisting of the 0xC0DE tag and a 16-bit length field set to zero (explicitly		consisting of the 0xC0DE tag and a 16-bit length field set to zero (explicitly
	permitted by <xref target="RFC3550"/>) <bcp14>MUST</bcp14> be appended, and the X bit <bcp14>MUST</bcp14> be set to 1 to		permitted by <xref target="RFC3550"/>) <bcp14>MUST</bcp14> be appended, and the X bit <bcp14>MUST</bcp14> be set to 1 to
	indicate an extension block is present. This is necessary to provide the receive r		indicate an extension block is present. This is necessary to provide the receive r
	an indication that the CSRCs in the packet are encrypted.</t>		an indication that the CSRCs in the packet are encrypted.</t>
	<t>The RTP packet <bcp14>MUST</bcp14> then be encrypted as described in
	Encryption Procedure.</t>		<t>The RTP packet <bcp14>MUST</bcp14> then be encrypted as described in
			<xref target="encryption-procedure"/> ("Encryption Procedure").</t>
	</section>		</section>
	<section anchor="receiving">		<section anchor="receiving">
	<name>Receiving</name>		<name>Receiving</name>
	<t>When receiving an RTP packet that contains header extensions, the		<t>When receiving an RTP packet that contains header extensions, the
	"defined by profile" field <bcp14>MUST</bcp14> be checked to ensure the payload is		"defined by profile" field <bcp14>MUST</bcp14> be checked to ensure the payload is
	formatted according to this specification. If the field does not match		formatted according to this specification. If the field does not match
	one of the values defined above, the implementation <bcp14>MUST</bcp14> instead		one of the values defined above, the implementation <bcp14>MUST</bcp14> instead
	handle it according to the specification that defines that value.</t>		handle it according to the specification that defines that value.</t>
	<t>Alternatively, if the implementation considers the use of this specif ication mandatory and the "defined by profile" field does not match one of the v alues defined above, it <bcp14>MUST</bcp14> stop the processing of the RTP packe t and report an error for the RTP stream.</t>		<t>Alternatively, if the implementation considers the use of this specif ication mandatory and the "defined by profile" field does not match one of the v alues defined above, it <bcp14>MUST</bcp14> stop the processing of the RTP packe t and report an error for the RTP stream.</t>
	<t>If the RTP packet passes this check, it is then decrypted according t		<t>If the RTP packet passes this check, it is then decrypted as describe
	o		d in
	Decryption Procedure, and passed to the next layer to process		<xref target="decryption-procedure"/> ("Decryption Procedure") and passed to the
			next layer to process
	the packet and its extensions. In the event that a zero-length extension		the packet and its extensions. In the event that a zero-length extension
	block was added as indicated above, it can be left as-is and will be		block was added as indicated above, it can be left as is and will be
	processed normally.</t>		processed normally.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="encryption-and-decryption">		<section anchor="encryption-and-decryption">
	<name>Encryption and Decryption</name>		<name>Encryption and Decryption</name>
	<section anchor="packet-structure">		<section anchor="packet-structure">
	<name>Packet Structure</name>		<name>Packet Structure</name>
	<t>When this mechanism is active, the SRTP packet is protected as follow s:</t>		<t>When this mechanism is active, the SRTP packet is protected as follow s:</t>
	<figure anchor="srtp-packet">		<figure anchor="srtp-packet">
			<!-- [rfced] We added a title to Figure 1, as Figure 2 has a title.
			Please review. Also, the abbreviation MKI appears in Figure 1 but not
			anywhere else. May we expand this abbreviation in Figure 1?
			Or is there a better place in the document to expand MKI? -->
			<name>A Protected SRTP Packet</name>
	<artwork align="center"><![CDATA[		<artwork align="center"><![CDATA[
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
	|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 | |
	| | .... | |		| | .... | |
	+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	X | 0xC0 or 0xC2 | 0xDE | length | |		X | 0xC0 or 0xC2 | 0xDE | length | |
	+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| | RFC 8285 header extensions | |		| | RFC 8285 header extensions | |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| | payload ... | |		| | payload ... | |
	| | +-------------------------------+ |		| | +-------------------------------+ |
	| | | RTP padding | RTP pad count | |		| | | RTP padding | RTP pad count | |
	+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+		+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
	| ~ SRTP MKI (OPTIONAL) ~ |		| ~ SRTP Master Key Identifier (MKI) (OPTIONAL) ~ |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| : authentication tag (RECOMMENDED) : |		| : authentication tag (RECOMMENDED) : |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| |		| |
	+- Encrypted Portion* Authenticated Portion ---+		+- Encrypted Portion Authenticated Portion ---+
	]]></artwork>		]]></artwork>
			- Encrypted <span class="insert">Portion</span> Authentica ted Portion ---+
	</figure>		</figure>
	<ul spacing="normal">		<t>Note that, as required by <xref target="RFC8285"/>, the 4 bytes at th
	<li>Note that, as required by <xref target="RFC8285"/>, the 4 bytes at		e start of the extension block are not encrypted.</t>
	the start of the extension block are not encrypted.</li>		<t>Specifically, the Encrypted Portion <bcp14>MUST</bcp14> include any C
	</ul>		SRC identifiers, any
	<t>Specifically, the encrypted portion <bcp14>MUST</bcp14> include any C
	SRC identifiers, any
	RTP header extension (except for the first 4 bytes), and the RTP payload.</t>		RTP header extension (except for the first 4 bytes), and the RTP payload.</t>
	</section>		</section>
	<section anchor="encryption-procedure">		<section anchor="encryption-procedure">
	<name>Encryption Procedure</name>		<name>Encryption Procedure</name>
	<t>The encryption procedure is identical to that of <xref target="RFC371 1"/> except for the		<t>The encryption procedure is identical to that of <xref target="RFC371 1"/> except for the
	Encrypted Portion of the SRTP packet. The plaintext input to the cipher is as fo		Encrypted Portion of the SRTP packet. The plaintext input to the cipher i
	llows:</t>		s as follows:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	Plaintext = CSRC identifiers (if used) || header extension data ||		Plaintext = CSRC identifiers (if used) || header extension data ||
	RTP payload || RTP padding (if used) || RTP pad count (if used).		RTP payload || RTP padding (if used) || RTP pad count (if used)
	]]></artwork>		]]></artwork>
	<t>Here "header extension data" refers to the content of the RTP extensi on field,		<t>Here "header extension data" refers to the content of the RTP extensi on field,
	excluding the first four bytes (the RFC 8285 extension header). The first		excluding the first four bytes (the extension header <xref target="RFC8285"/>).
	<tt>4 * CSRC count (CC)</tt> bytes of the ciphertext are placed in the CSRC fiel		The first <tt>4 * CSRC count (CC)</tt> bytes of the ciphertext are placed in th
	d of the RTP header.		e CSRC field of the RTP header.
	The remainder of the ciphertext is the RTP payload of the encrypted packet.</t>		The remainder of the ciphertext is the RTP payload of the encrypted packet.</t>
	<t>To minimize changes to surrounding code, the encryption mechanism can choose		<t>To minimize changes to surrounding code, the encryption mechanism can choose
	to replace a "defined by profile" field from <xref target="RFC8285"/> with its c ounterpart		to replace a "defined by profile" field from <xref target="RFC8285"/> with its c ounterpart
	defined in RTP Header Processing above and encrypt at the same time.</t>		defined in <xref target="rtp-header-processing"/> ("RTP Header Processing") and
	<t>For AEAD ciphers (e.g., GCM), the 12-byte fixed header and the four-b		encrypt at the same time.</t>
	yte header
			<t>For Authenticated Encryption with Associated Data (AEAD) ciphers (e.g., AES-G
			CM), the 12-byte fixed header and the four-byte header
	extension header (the "defined by profile" field and the length) are considered		extension header (the "defined by profile" field and the length) are considered
	AAD, even though they are non-contiguous in the packet if CSRCs are present.</t>		additional authenticated data (AAD), even though they are non-contiguous in the packet if CSRCs are present.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	Associated Data: fixed header || extension header (if X=1)		Associated Data: fixed header || extension header (if X=1)
	]]></artwork>		]]></artwork>
	<t>Here "fixed header" refers to the 12-byte fixed portion of the RTP he ader, and		<t>Here "fixed header" refers to the 12-byte fixed portion of the RTP he ader, and
	"extension header" refers to the four-byte RFC 8285 extension header ("defined		"extension header" refers to the four-byte extension header <xref target="RFC828 5"/> ("defined
	by profile" and extension length).</t>		by profile" and extension length).</t>
	<t>Implementations can rearrange a packet so that the AAD and plaintext are		<t>Implementations can rearrange a packet so that the AAD and plaintext are
	contiguous by swapping the order of the extension header and the CSRC		contiguous by swapping the order of the extension header and the CSRC
	identifiers, resulting in an intermediate representation of the form shown in		identifiers, resulting in an intermediate representation of the form shown in
	<xref target="intermediate-packet"/>. After encryption, the CSRCs (now encrypte d) and		<xref target="intermediate-packet"/>. After encryption, the CSRCs (now encrypte d) and
	extension header would need to be swapped back to their original positions. A		extension header would need to be swapped back to their original positions. A
	similar operation can be done when decrypting to create contiguous ciphertext		similar operation can be done when decrypting to create contiguous ciphertext
	and AAD inputs.</t>		and AAD inputs.</t>
	<figure anchor="intermediate-packet">		<figure anchor="intermediate-packet">
	<name>An RTP packet transformed to make Cryptex cipher inputs contiguo us</name>		<name>An RTP Packet Transformed to Make Cryptex Cipher Inputs Contiguo us</name>
	<artwork align="center"><![CDATA[		<artwork align="center"><![CDATA[
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
	|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 | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| 0xC0 or 0xC2 | 0xDE | length | |		| 0xC0 or 0xC2 | 0xDE | length | |
	+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<+		+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<+
	| | contributing source (CSRC) identifiers | |		| | contributing source (CSRC) identifiers | |
	| | .... | |		| | .... | |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| | RFC 8285 header extensions | |		| | RFC 8285 header extensions | |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| | payload ... | |		| | payload ... | |
	| | +-------------------------------+ |		| | +-------------------------------+ |
	| | | RTP padding | RTP pad count | |		| | | RTP padding | RTP pad count | |
	+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| |		| |
	+- Plaintext Input AAD Input ---+		+- Plaintext Input AAD Input ---+
	]]></artwork>		]]></artwork>
			- Plaintext Input AAD Input ---+
	</figure>		</figure>
	<t>Note: This intermediate representation is only displayed as reference for implementations and is not meant to be sent on the wire.</t>		<t>Note that this intermediate representation is only displayed as refer ence for implementations and is not meant to be sent on the wire.</t>
	</section>		</section>
	<section anchor="decryption-procedure">		<section anchor="decryption-procedure">
	<name>Decryption Procedure</name>		<name>Decryption Procedure</name>
	<t>The decryption procedure is identical to that of <xref target="RFC371 1"/> except		<t>The decryption procedure is identical to that of <xref target="RFC371 1"/> except
	for the Encrypted Portion of the SRTP packet, which is as shown in the section a bove.</t>		for the Encrypted Portion of the SRTP packet, which is as shown in the section a bove.</t>
	<t>To minimize changes to surrounding code, the decryption mechanism can choose		<t>To minimize changes to surrounding code, the decryption mechanism can choose
	to replace the "defined by profile" field with its no-encryption counterpart		to replace the "defined by profile" field with its no-encryption counterpart
	from <xref target="RFC8285"/> and decrypt at the same time.</t>		from <xref target="RFC8285"/> and decrypt at the same time.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="backwards-compatibility">		<section anchor="backwards-compatibility">
	<name>Backwards Compatibility</name>		<name>Backward Compatibility</name>
	<t>This specification attempts to encrypt as much as possible without inte rfering		<t>This specification attempts to encrypt as much as possible without inte rfering
	with backwards compatibility for systems that expect a certain structure from		with backward compatibility for systems that expect a certain structure from
	an RTPv2 packet, including systems that perform demultiplexing based on packet		an RTPv2 packet, including systems that perform demultiplexing based on packet
	headers. Accordingly, the first two bytes of the RTP packet are not encrypted.</ t>		headers. Accordingly, the first two bytes of the RTP packet are not encrypted.</ t>
	<t>This specification also attempts to reuse the key scheduling from SRTP, which		<t>This specification also attempts to reuse the key scheduling from SRTP, which
	depends on the RTP packet sequence number and SSRC identifier. Accordingly,		depends on the RTP packet sequence number and SSRC identifier. Accordingly,
	these values are also not encrypted.</t>		these values are also not encrypted.</t>
	</section>		</section>
	<section anchor="security-considerations">		<section anchor="security-considerations">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>All security considerations in <xref target="RFC3711"/> section 9 are a		<t>All security considerations in <xref target="RFC3711" sectionFormat="of
	pplicable to this specification, except section 9.4. Confidentiality of the RTP		" section="9"/> are applicable to this specification; the exception is Section <
	Header which is the purpose of this specification.</t>		xref target="RFC3711" sectionFormat="bare" section="9.4"/>, because confidential
	<t>The risks of using weak or NULL authentication with SRTP, described in		ity of the RTP Header is the purpose of this specification.</t>
	Section 9.5 of <xref target="RFC3711"/>, apply to encrypted header extensions as		<t>The risks of using weak or NULL authentication with SRTP, described in
	well.</t>		<xref target="RFC3711" sectionFormat="of" section="9.5"/>, apply to encrypted he
			ader extensions as well.</t>
	<t>This specification extends SRTP by expanding the Encrypted Portion of t he RTP packet,		<t>This specification extends SRTP by expanding the Encrypted Portion of t he RTP packet,
	as shown in Packet Structure. It does not change how SRTP authentication		as shown in <xref target="packet-structure"/> ("Packet Structure"). It does not change how SRTP authentication
	works in any way. Given that more of the packet is being encrypted than before,		works in any way. Given that more of the packet is being encrypted than before,
	this is necessarily an improvement.</t>		this is necessarily an improvement.</t>
	<t>The RTP fields that are left unencrypted (see rationale above) are as f ollows:</t>		<t>The RTP fields that are left unencrypted (see rationale above) are as f ollows:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>RTP version</li>		<li>RTP version</li>
	<li>padding bit</li>		<li>padding bit</li>
	<li>extension bit</li>		<li>extension bit</li>
	<li>number of CSRCs</li>		<li>number of CSRCs</li>
	<li>marker bit</li>		<li>marker bit</li>
	<li>payload type</li>		<li>payload type</li>
	<li>sequence number</li>		<li>sequence number</li>
	<li>timestamp</li>		<li>timestamp</li>
	<li>SSRC identifier</li>		<li>SSRC identifier</li>
	<li>number of <xref target="RFC8285"/> header extensions</li>		<li>number of header extensions <xref target="RFC8285"/></li>
	</ul>		</ul>
	<t>These values contain a fixed set (i.e., one that won't be changed by		<t>These values contain a fixed set (i.e., one that won't be changed by
	extensions) of information that, at present, is observed to have low		extensions) of information that, at present, is observed to have low
	sensitivity. In the event any of these values need to be encrypted, SRTP		sensitivity. In the event any of these values need to be encrypted, SRTP
	is likely the wrong protocol to use and a fully-encapsulating protocol		is likely the wrong protocol to use and a fully encapsulating protocol
	such as DTLS is preferred (with its attendant per-packet overhead).</t>		such as DTLS is preferred (with its attendant per-packet overhead).</t>
	</section>		</section>
	<section anchor="iana-considerations">		<section anchor="iana-considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<section anchor="sdp-cryptex-attribute">		<t>This document updates the "attribute-name (formerly "att-field")" sub
	<name>SDP cryptex Attribute</name>		registry of the "Session Description Protocol (SDP) Parameters" registry (see <x
	<t>This document updates the "Session Description Protocol Parameters" a		ref target="RFC8866" sectionFormat="of" section="8.2.4"/>). Specifically, it add
	s specified in Section 8.2.4 of <xref target="RFC8866"/>. Specifically, it adds		s the SDP "a=cryptex" attribute for use at both the media level and the session
	the SDP "a=cryptex" attribute to the Attribute Names (&lt;attribute-name&gt;) re		level.</t>
	gistry for both media and session level usage.</t>		<dl spacing="normal">
	<t>Contact name: IETF AVT Working Group or IESG if AVT is closed</t>		<dt>Contact name:</dt>
	<t>Contact email address: avt@ietf.org</t>		<dd>IETF AVT Working Group or IESG if the AVT Working Group is closed</
	<t>Attribute name: cryptex</t>		dd>
	<t>Attribute syntax: This attribute takes no values.</t>		<dt>Contact email address:</dt>
	<t>Attribute semantics: N/A</t>		<dd>avt@ietf.org</dd>
	<t>Attribute value: N/A</t>		<dt>Attribute name:</dt>
	<t>Usage level: session, media</t>		<dd>cryptex</dd>
	<t>Charset dependent: No</t>		<dt>Attribute syntax:</dt>
	<t>Purpose: The presence of this attribute in the SDP indicates that the		<dd>This attribute takes no values.</dd>
	endpoint is capable of receiving RTP packets encrypted with Cryptex as describe		<dt>Attribute semantics:</dt>
	d in this document.</t>		<dd>N/A</dd>
	<t>O/A procedures: SDP O/A procedures are described in Section 4 of this		<dt>Attribute value:</dt>
	document.</t>		<dd>N/A</dd>
	<t>Mux Category: TRANSPORT</t>		<dt>Usage level:</dt>
	</section>		<dd>session, media</dd>
	</section>		<dt>Charset dependent:</dt>
	<section anchor="acknowledgements">		<dd>No</dd>
	<name>Acknowledgements</name>		<dt>Purpose:</dt>
	<t>The authors wish to thank Lennart Grahl for pointing out many of the is		<dd>The presence of this attribute in the SDP indicates that the
	sues with the existing		endpoint is capable of receiving RTP packets encrypted with Cryptex
	header encryption mechanism, as well as suggestions for this proposal.		as described in this document.</dd>
	Thanks also to Jonathan Lennox, Inaki Castillo, and Bernard Aboba for their revi		<dt>O/A procedures:</dt>
	ew and suggestions.</t>		<dd>SDP O/A procedures are described in Section <xref target="sdp-consi
			derations" format="counter"/> of this
			document.</dd>
			<dt>Mux Category:</dt>
			<dd>TRANSPORT</dd>
			</dl>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
	550">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.
	<front>		xml"/>
	<title>RTP: A Transport Protocol for Real-Time Applications</title>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.
	<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne		xml"/>
	">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8285.
	<organization/>		xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8859.
	<author fullname="S. Casner" initials="S." surname="Casner">		xml"/>
	<organization/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
	</author>		xml"/>
	<author fullname="R. Frederick" initials="R." surname="Frederick">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
	<organization/>		xml"/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8866.
	<author fullname="V. Jacobson" initials="V." surname="Jacobson">		xml"/>
	<organization/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9143.
	</author>		xml"/>
	<date month="July" year="2003"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.
	<abstract>		xml"/>
	<t>This memorandum describes RTP, the real-time transport protocol
	. RTP provides end-to-end network transport functions suitable for applications
	transmitting real-time data, such as audio, video or simulation data, over mult
	icast or unicast network services. RTP does not address resource reservation an
	d does not guarantee quality-of- service for real-time services. The data trans
	port is augmented by a control protocol (RTCP) to allow monitoring of the data d
	elivery in a manner scalable to large multicast networks, and to provide minimal
	control and identification functionality. RTP and RTCP are designed to be inde
	pendent of the underlying transport and network layers. The protocol supports t
	he use of RTP-level translators and mixers. Most of the text in this memorandum
	is identical to RFC 1889 which it obsoletes. There are no changes in the packet
	formats on the wire, only changes to the rules and algorithms governing how the
	protocol is used. The biggest change is an enhancement to the scalable timer al
	gorithm for calculating when to send RTCP packets in order to minimize transmiss
	ion in excess of the intended rate when many participants join a session simulta
	neously. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="64"/>
	<seriesInfo name="RFC" value="3550"/>
	<seriesInfo name="DOI" value="10.17487/RFC3550"/>
	</reference>
	<reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3
	711">
	<front>
	<title>The Secure Real-time Transport Protocol (SRTP)</title>
	<author fullname="M. Baugher" initials="M." surname="Baugher">
	<organization/>
	</author>
	<author fullname="D. McGrew" initials="D." surname="McGrew">
	<organization/>
	</author>
	<author fullname="M. Naslund" initials="M." surname="Naslund">
	<organization/>
	</author>
	<author fullname="E. Carrara" initials="E." surname="Carrara">
	<organization/>
	</author>
	<author fullname="K. Norrman" initials="K." surname="Norrman">
	<organization/>
	</author>
	<date month="March" year="2004"/>
	<abstract>
	<t>This document describes the Secure Real-time Transport Protocol
	(SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide
	confidentiality, message authentication, and replay protection to the RTP traffi
	c and to the control traffic for RTP, the Real-time Transport Control Protocol (
	RTCP). [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3711"/>
	<seriesInfo name="DOI" value="10.17487/RFC3711"/>
	</reference>
	<reference anchor="RFC8285" target="https://www.rfc-editor.org/info/rfc8
	285">
	<front>
	<title>A General Mechanism for RTP Header Extensions</title>
	<author fullname="D. Singer" initials="D." surname="Singer">
	<organization/>
	</author>
	<author fullname="H. Desineni" initials="H." surname="Desineni">
	<organization/>
	</author>
	<author fullname="R. Even" initials="R." role="editor" surname="Even
	">
	<organization/>
	</author>
	<date month="October" year="2017"/>
	<abstract>
	<t>This document provides a general mechanism to use the header ex
	tension feature of RTP (the Real-time Transport Protocol). It provides the opti
	on to use a small number of small extensions in each RTP packet, where the unive
	rse of possible extensions is large and registration is decentralized. The actu
	al extensions in use in a session are signaled in the setup information for that
	session. This document obsoletes RFC 5285.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8285"/>
	<seriesInfo name="DOI" value="10.17487/RFC8285"/>
	</reference>
	<reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8
	859">
	<front>
	<title>A Framework for Session Description Protocol (SDP) Attributes
	When Multiplexing</title>
	<author fullname="S. Nandakumar" initials="S." surname="Nandakumar">
	<organization/>
	</author>
	<date month="January" year="2021"/>
	<abstract>
	<t>The purpose of this specification is to provide a framework for
	analyzing the multiplexing characteristics of Session Description Protocol (SDP
	) attributes when SDP is used to negotiate the usage of a single 5-tuple for sen
	ding and receiving media associated with multiple media descriptions.</t>
	<t>This specification also categorizes the existing SDP attributes
	based on the framework described herein.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8859"/>
	<seriesInfo name="DOI" value="10.17487/RFC8859"/>
	</reference>
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner">
	<organization/>
	</author>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized.
	This document defines these words as they should be interpreted in IETF document
	s. This document specifies an Internet Best Current Practices for the Internet
	Community, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba">
	<organization/>
	</author>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="RFC8866" target="https://www.rfc-editor.org/info/rfc8
	866">
	<front>
	<title>SDP: Session Description Protocol</title>
	<author fullname="A. Begen" initials="A." surname="Begen">
	<organization/>
	</author>
	<author fullname="P. Kyzivat" initials="P." surname="Kyzivat">
	<organization/>
	</author>
	<author fullname="C. Perkins" initials="C." surname="Perkins">
	<organization/>
	</author>
	<author fullname="M. Handley" initials="M." surname="Handley">
	<organization/>
	</author>
	<date month="January" year="2021"/>
	<abstract>
	<t>This memo defines the Session Description Protocol (SDP). SDP i
	s intended for describing multimedia sessions for the purposes of session announ
	cement, session invitation, and other forms of multimedia session initiation. Th
	is document obsoletes RFC 4566.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8866"/>
	<seriesInfo name="DOI" value="10.17487/RFC8866"/>
	</reference>
	<reference anchor="RFC9143" target="https://www.rfc-editor.org/info/rfc9
	143">
	<front>
	<title>Negotiating Media Multiplexing Using the Session Description
	Protocol (SDP)</title>
	<author fullname="C. Holmberg" initials="C." surname="Holmberg">
	<organization/>
	</author>
	<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
	<organization/>
	</author>
	<author fullname="C. Jennings" initials="C." surname="Jennings">
	<organization/>
	</author>
	<date month="February" year="2022"/>
	<abstract>
	<t>This specification defines a new Session Description Protocol (
	SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used wit
	h the SDP offer/answer mechanism to negotiate the usage of a single transport (5
	-tuple) for sending and receiving media described by multiple SDP media descript
	ions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and
	the media is referred to as "bundled media". The "m=" sections that use the BUN
	DLE transport form a BUNDLE group. </t>
	<t>This specification defines a new RTP Control Protocol (RTCP) So
	urce Description (SDES) item and a new RTP header extension.</t>
	<t>This specification updates RFCs 3264, 5888, and 7941. </t>
	<t>This specification obsoletes RFC 8843.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9143"/>
	<seriesInfo name="DOI" value="10.17487/RFC9143"/>
	</reference>
	<reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3
	264">
	<front>
	<title>An Offer/Answer Model with Session Description Protocol (SDP)
	</title>
	<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
	<organization/>
	</author>
	<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
	">
	<organization/>
	</author>
	<date month="June" year="2002"/>
	<abstract>
	<t>This document defines a mechanism by which two entities can mak
	e use of the Session Description Protocol (SDP) to arrive at a common view of a
	multimedia session between them. In the model, one participant offers the other
	a description of the desired session from their perspective, and the other part
	icipant answers with the desired session from their perspective. This offer/ans
	wer model is most useful in unicast sessions where information from both partici
	pants is needed for the complete view of the session. The offer/answer model is
	used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK
	]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="3264"/>
	<seriesInfo name="DOI" value="10.17487/RFC3264"/>
	</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RFC6464" target="https://www.rfc-editor.org/info/rfc6
	464">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6464.
	<front>		xml"/>
	<title>A Real-time Transport Protocol (RTP) Header Extension for Cli		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6465.
	ent-to-Mixer Audio Level Indication</title>		xml"/>
	<author fullname="J. Lennox" initials="J." role="editor" surname="Le		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6904.
	nnox">		xml"/>
	<organization/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7714.
	</author>		xml"/>
	<author fullname="E. Ivov" initials="E." surname="Ivov">
	<organization/>
	</author>
	<author fullname="E. Marocco" initials="E." surname="Marocco">
	<organization/>
	</author>
	<date month="December" year="2011"/>
	<abstract>
	<t>This document defines a mechanism by which packets of Real-time
	Transport Protocol (RTP) audio streams can indicate, in an RTP header extension
	, the audio level of the audio sample carried in the RTP packet. In large confe
	rences, this can reduce the load on an audio mixer or other middlebox that wants
	to forward only a few of the loudest audio streams, without requiring it to dec
	ode and measure every stream that is received. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6464"/>
	<seriesInfo name="DOI" value="10.17487/RFC6464"/>
	</reference>
	<reference anchor="RFC6465" target="https://www.rfc-editor.org/info/rfc6
	465">
	<front>
	<title>A Real-time Transport Protocol (RTP) Header Extension for Mix
	er-to-Client Audio Level Indication</title>
	<author fullname="E. Ivov" initials="E." role="editor" surname="Ivov
	">
	<organization/>
	</author>
	<author fullname="E. Marocco" initials="E." role="editor" surname="M
	arocco">
	<organization/>
	</author>
	<author fullname="J. Lennox" initials="J." surname="Lennox">
	<organization/>
	</author>
	<date month="December" year="2011"/>
	<abstract>
	<t>This document describes a mechanism for RTP-level mixers in aud
	io conferences to deliver information about the audio level of individual partic
	ipants. Such audio level indicators are transported in the same RTP packets as
	the audio data they pertain to. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6465"/>
	<seriesInfo name="DOI" value="10.17487/RFC6465"/>
	</reference>
	<reference anchor="RFC6904" target="https://www.rfc-editor.org/info/rfc6
	904">
	<front>
	<title>Encryption of Header Extensions in the Secure Real-time Trans
	port Protocol (SRTP)</title>
	<author fullname="J. Lennox" initials="J." surname="Lennox">
	<organization/>
	</author>
	<date month="April" year="2013"/>
	<abstract>
	<t>The Secure Real-time Transport Protocol (SRTP) provides authent
	ication, but not encryption, of the headers of Real-time Transport Protocol (RTP
	) packets. However, RTP header extensions may carry sensitive information for w
	hich participants in multimedia sessions want confidentiality. This document pr
	ovides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP
	header extensions in SRTP.</t>
	<t>This document updates RFC 3711, the Secure Real-time Transport
	Protocol specification, to require that all future SRTP encryption transforms sp
	ecify how RTP header extensions are to be encrypted.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6904"/>
	<seriesInfo name="DOI" value="10.17487/RFC6904"/>
	</reference>
	<reference anchor="RFC7714" target="https://www.rfc-editor.org/info/rfc7
	714">
	<front>
	<title>AES-GCM Authenticated Encryption in the Secure Real-time Tran
	sport Protocol (SRTP)</title>
	<author fullname="D. McGrew" initials="D." surname="McGrew">
	<organization/>
	</author>
	<author fullname="K. Igoe" initials="K." surname="Igoe">
	<organization/>
	</author>
	<date month="December" year="2015"/>
	<abstract>
	<t>This document defines how the AES-GCM Authenticated Encryption
	with Associated Data family of algorithms can be used to provide confidentiality
	and data authentication in the Secure Real-time Transport Protocol (SRTP).</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7714"/>
	<seriesInfo name="DOI" value="10.17487/RFC7714"/>
	</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="test-vectors">		<section anchor="test-vectors">
	<name>Test Vectors</name>		<name>Test Vectors</name>
	<t>All values are in hexadecimal and represented in network order (big end ian).</t>		<t>All values are in hexadecimal and represented in network order (big end ian).</t>
	<section anchor="aes-ctr">		<section anchor="aes-ctr">
	<name>AES-CTR</name>		<name>AES-CTR</name>
	<t>The following section list the test vectors for using cryptex with AE		<t>The following subsections list the test vectors for using Cryptex wit
	S-CTR as per <xref target="RFC3711"/></t>		h AES-CTR as per <xref target="RFC3711"/>.</t>
	<t>Common values are organized as follows:</t>
			<t>Common values are organized as follows:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	Rollover Counter: 00000000		Rollover Counter: 00000000
	Master Key: e1f97a0d3e018be0d64fa32c06de4139		Master Key: e1f97a0d3e018be0d64fa32c06de4139
	Master Salt: 0ec675ad498afeebb6960b3aabe6		Master Salt: 0ec675ad498afeebb6960b3aabe6
	Crypto Suite: AES_CM_128_HMAC_SHA1_80		Crypto Suite: AES_CM_128_HMAC_SHA1_80
	Session Key: c61e7a93744f39ee10734afe3ff7a087		Session Key: c61e7a93744f39ee10734afe3ff7a087
	Session Salt: 30cbbc08863d8c85d49db34a9ae1		Session Salt: 30cbbc08863d8c85d49db34a9ae1
	Authentication Key: cebe321f6ff7716b6fd4ab49af256a156d38baa4		Authentication Key: cebe321f6ff7716b6fd4ab49af256a156d38baa4
	]]></artwork>		]]></artwork>
	<section anchor="rtp-packet-with-1-byte-header-extension">		<section anchor="rtp-packet-with-1-byte-header-extension">
	<name>RTP Packet with 1-byte header extension</name>		<name>RTP Packet with One-Byte Header Extension</name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	900f1235		900f1235
	decafbad		decafbad
	cafebabe		cafebabe
	bede0001		bede0001
	51000200		51000200
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	900f1235		900f1235
	decafbad		decafbad
	cafebabe		cafebabe
	c0de0001		c0de0001
	eb923652		eb923652
	51c3e036		51c3e036
	f8de27e9		f8de27e9
	c27ee3e0		c27ee3e0
	b4651d9f		b4651d9f
	bc4218a7		bc4218a7
	0244522f		0244522f
	34a5		34a5
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-2-byte-header-extension">		<section anchor="rtp-packet-with-2-byte-header-extension">
	<name>RTP Packet with 2-byte header extension</name>		<name>RTP Packet with Two-Byte Header Extension</name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	900f1236		900f1236
	decafbad		decafbad
	cafebabe		cafebabe
	10000001		10000001
	05020002		05020002
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	900f1236		900f1236
	decafbad		decafbad
	cafebabe		cafebabe
	c2de0001		c2de0001
	4ed9cc4e		4ed9cc4e
	6a712b30		6a712b30
	96c5ca77		96c5ca77
	339d4204		339d4204
	ce0d7739		ce0d7739
	6cab6958		6cab6958
	5fbce381		5fbce381
	94a5		94a5
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-1-byte-header-extension-and-csrc-fields ">		<section anchor="rtp-packet-with-1-byte-header-extension-and-csrc-fields ">
	<name>RTP Packet with 1-byte header extension and CSRC fields</name>		<name>RTP Packet with One-Byte Header Extension and CSRC Fields</name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f1238		920f1238
	decafbad		decafbad
	cafebabe		cafebabe
	0001e240		0001e240
	0000b26e		0000b26e
	bede0001		bede0001
	51000200		51000200
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f1238		920f1238
	decafbad		decafbad
	cafebabe		cafebabe
	8bb6e12b		8bb6e12b
	5cff16dd		5cff16dd
	c0de0001		c0de0001
	92838c8c		92838c8c
	09e58393		09e58393
	e1de3a9a		e1de3a9a
	74734d67		74734d67
	45671338		45671338
	c3acf11d		c3acf11d
	a2df8423		a2df8423
	bee0		bee0
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-2-byte-header-extension-and-csrc-fields ">		<section anchor="rtp-packet-with-2-byte-header-extension-and-csrc-fields ">
	<name>RTP Packet with 2-byte header extension and CSRC fields</name>		<name>RTP Packet with Two-Byte Header Extension and CSRC Fields</name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f1239		920f1239
	decafbad		decafbad
	cafebabe		cafebabe
	0001e240		0001e240
	0000b26e		0000b26e
	10000001		10000001
	05020002		05020002
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f1239		920f1239
	decafbad		decafbad
	cafebabe		cafebabe
	f70e513e		f70e513e
	b90b9b25		b90b9b25
	c2de0001		c2de0001
	bbed4848		bbed4848
	faa64466		faa64466
	5f3d7f34		5f3d7f34
	125914e9		125914e9
	f4d0ae92		f4d0ae92
	3c6f479b		3c6f479b
	95a0f7b5		95a0f7b5
	3133		3133
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-empty-1-byte-header-extension-and-csrc- fields">		<section anchor="rtp-packet-with-empty-1-byte-header-extension-and-csrc- fields">
	<name>RTP Packet with empty 1-byte header extension and CSRC fields</n ame>		<name>RTP Packet with Empty One-Byte Header Extension and CSRC Fields< /name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f123a		920f123a
	decafbad		decafbad
	cafebabe		cafebabe
	0001e240		0001e240
	0000b26e		0000b26e
	bede0000		bede0000
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f123a		920f123a
	decafbad		decafbad
	cafebabe		cafebabe
	7130b6ab		7130b6ab
	fe2ab0e3		fe2ab0e3
	c0de0000		c0de0000
	e3d9f64b		e3d9f64b
	25c9e74c		25c9e74c
	b4cf8e43		b4cf8e43
	fb92e378		fb92e378
	1c2c0cea		1c2c0cea
	b6b3a499		b6b3a499
	a14c		a14c
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-empty-2-byte-header-extension-and-csrc- fields">		<section anchor="rtp-packet-with-empty-2-byte-header-extension-and-csrc- fields">
	<name>RTP Packet with empty 2-byte header extension and CSRC fields</n ame>		<name>RTP Packet with Empty Two-Byte Header Extension and CSRC Fields< /name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f123b		920f123b
	decafbad		decafbad
	cafebabe		cafebabe
	0001e240		0001e240
	0000b26e		0000b26e
	10000000		10000000
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f123b		920f123b
	decafbad		decafbad
	cafebabe		cafebabe
	cbf24c12		cbf24c12
	4330e1c8		4330e1c8
	c2de0000		c2de0000
	599dd45b		599dd45b
	c9d687b6		c9d687b6
	03e8b59d		03e8b59d
	771fd38e		771fd38e
	88b170e0		88b170e0
	cd31e125		cd31e125
	eabe		eabe
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="aes-gcm">		<section anchor="aes-gcm">
	<name>AES-GCM</name>		<name>AES-GCM</name>
	<t>The following section list the test vectors for using cryptex with AE S-GCM as per <xref target="RFC7714"/></t>		<t>The following subsections list the test vectors for using Cryptex wit h AES-GCM as per <xref target="RFC7714"/>.</t>
	<t>Common values are organized as follows:</t>		<t>Common values are organized as follows:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	Rollover Counter: 00000000		Rollover Counter: 00000000
	Master Key: 000102030405060708090a0b0c0d0e0f		Master Key: 000102030405060708090a0b0c0d0e0f
	Master Salt: a0a1a2a3a4a5a6a7a8a9aaab		Master Salt: a0a1a2a3a4a5a6a7a8a9aaab
	Crypto Suite: AEAD_AES_128_GCM		Crypto Suite: AEAD_AES_128_GCM
	Session Key: 077c6143cb221bc355ff23d5f984a16e		Session Key: 077c6143cb221bc355ff23d5f984a16e
	Session Salt: 9af3e95364ebac9c99c5a7c4		Session Salt: 9af3e95364ebac9c99c5a7c4
	]]></artwork>		]]></artwork>
	<section anchor="rtp-packet-with-1-byte-header-extension-1">		<section anchor="rtp-packet-with-1-byte-header-extension-1">
	<name>RTP Packet with 1-byte header extension</name>		<name>RTP Packet with One-Byte Header Extension</name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	900f1235		900f1235
	decafbad		decafbad
	cafebabe		cafebabe
	bede0001		bede0001
	51000200		51000200
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	900f1235		900f1235
	decafbad		decafbad
	cafebabe		cafebabe
	c0de0001		c0de0001
	39972dc9		39972dc9
	572c4d99		572c4d99
	e8fc355d		e8fc355d
	e743fb2e		e743fb2e
	94f9d8ff		94f9d8ff
	54e72f41		54e72f41
	93bbc5c7		93bbc5c7
	4ffab0fa		4ffab0fa
	9fa0fbeb		9fa0fbeb
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-2-byte-header-extension-1">		<section anchor="rtp-packet-with-2-byte-header-extension-1">
	<name>RTP Packet with 2-byte header extension</name>		<name>RTP Packet with Two-Byte Header Extension</name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	900f1236		900f1236
	decafbad		decafbad
	cafebabe		cafebabe
	10000001		10000001
	05020002		05020002
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	900f1236		900f1236
	decafbad		decafbad
	cafebabe		cafebabe
	c2de0001		c2de0001
	bb75a4c5		bb75a4c5
	45cd1f41		45cd1f41
	3bdb7daa		3bdb7daa
	2b1e3263		2b1e3263
	de313667		de313667
	c9632490		c9632490
	81b35a65		81b35a65
	f5cb6c88		f5cb6c88
	b394235f		b394235f
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-1-byte-header-extension-and-csrc-fields -1">		<section anchor="rtp-packet-with-1-byte-header-extension-and-csrc-fields -1">
	<name>RTP Packet with 1-byte header extension and CSRC fields</name>		<name>RTP Packet with One-Byte Header Extension and CSRC Fields</name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f1238		920f1238
	decafbad		decafbad
	cafebabe		cafebabe
	0001e240		0001e240
	0000b26e		0000b26e
	bede0001		bede0001
	51000200		51000200
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f1238		920f1238
	decafbad		decafbad
	cafebabe		cafebabe
	63bbccc4		63bbccc4
	a7f695c4		a7f695c4
	c0de0001		c0de0001
	8ad7c71f		8ad7c71f
	ac70a80c		ac70a80c
	92866b4c		92866b4c
	6ba98546		6ba98546
	ef913586		ef913586
	e95ffaaf		e95ffaaf
	fe956885		fe956885
	bb0647a8		bb0647a8
	bc094ac8		bc094ac8
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-2-byte-header-extension-and-csrc-fields -1">		<section anchor="rtp-packet-with-2-byte-header-extension-and-csrc-fields -1">
	<name>RTP Packet with 2-byte header extension and CSRC fields</name>		<name>RTP Packet with Two-Byte Header Extension and CSRC Fields</name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f1239		920f1239
	decafbad		decafbad
	cafebabe		cafebabe
	0001e240		0001e240
	0000b26e		0000b26e
	10000001		10000001
	05020002		05020002
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f1239		920f1239
	decafbad		decafbad
	cafebabe		cafebabe
	3680524f		3680524f
	8d312b00		8d312b00
	c2de0001		c2de0001
	c78d1200		c78d1200
	38422bc1		38422bc1
	11a7187a		11a7187a
	18246f98		18246f98
	0c059cc6		0c059cc6
	bc9df8b6		bc9df8b6
	26394eca		26394eca
	344e4b05		344e4b05
	d80fea83		d80fea83
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-empty-1-byte-header-extension-and-csrc- fields-1">		<section anchor="rtp-packet-with-empty-1-byte-header-extension-and-csrc- fields-1">
	<name>RTP Packet with empty 1-byte header extension and CSRC fields</n ame>		<name>RTP Packet with Empty One-Byte Header Extension and CSRC Fields< /name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f123a		920f123a
	decafbad		decafbad
	cafebabe		cafebabe
	0001e240		0001e240
	0000b26e		0000b26e
	bede0000		bede0000
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f123a		920f123a
	decafbad		decafbad
	cafebabe		cafebabe
	15b6bb43		15b6bb43
	37906fff		37906fff
	c0de0000		c0de0000
	b7b96453		b7b96453
	7a2b03ab		7a2b03ab
	7ba5389c		7ba5389c
	e9331712		e9331712
	6b5d974d		6b5d974d
	f30c6884		f30c6884
	dcb651c5		dcb651c5
	e120c1da		e120c1da
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="rtp-packet-with-empty-2-byte-header-extension-and-csrc- fields-1">		<section anchor="rtp-packet-with-empty-2-byte-header-extension-and-csrc- fields-1">
	<name>RTP Packet with empty 2-byte header extension and CSRC fields</n ame>		<name>RTP Packet with Empty Two-Byte Header Extension and CSRC Fields< /name>
	<t>RTP Packet:</t>		<t>RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f123b		920f123b
	decafbad		decafbad
	cafebabe		cafebabe
	0001e240		0001e240
	0000b26e		0000b26e
	10000000		10000000
	abababab		abababab
	abababab		abababab
	abababab		abababab
	abababab		abababab
	]]></artwork>		]]></sourcecode>
	<t>Encrypted RTP Packet:</t>		<t>Encrypted RTP Packet:</t>
	<artwork><![CDATA[		<sourcecode type="test-vectors"><![CDATA[
	920f123b		920f123b
	decafbad		decafbad
	cafebabe		cafebabe
	dcb38c9e		dcb38c9e
	48bf95f4		48bf95f4
	c2de0000		c2de0000
	61ee432c		61ee432c
	f9203170		f9203170
	76613258		76613258
	d3ce4236		d3ce4236
	c06ac429		c06ac429
	681ad084		681ad084
	13512dc9		13512dc9
	8b5207d8		8b5207d8
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+0863bbxpn/8RSzyo+VGokhCPACbd2NIjmOU8vWWk6bnrYn
	HQADCWsQ4AKgJNZ2nmVfYV9h98X2u8xgBiSkxI3d9oeVc2ISBGa++31wdHTk
	pVVSyqU6Fmkts/YoV212JG/apKrVUVJvVq26OxovvDZvC7jptFquCtWqYiMe
	l/RzXl6Jl68uxDdKpqoWj+9aVTZ5VTZClincX7Z1Hq/ptstqXSeq8RLZqquq
	3hyLpk29fFUfi7ZeN+1kPI7GE0/WSh6Lk5evvNuqfn1VV+sVfP3dq9MXLx97
	r9UGrqbH4hI29ZoWNvlBFlUJsG1g6fUqhcWbYxHMfd/zVvmx+GNbJYeiqeq2
	VlkDnzZL/PBnz5Pr9rqqj70jT8BfXsJj347Ed7Gq25wuMWG+BdDy0r1e1Vey
	zP8qW8ATaFKs4+tq3Sj6TS1lXhyL/6SHvlzTQyNciLahTU5H4ltVlkCSxjOb
	nK6LQpXuddgELudNUnndqlmxzrLNl3mejxLp2RUvR+KJrJNcivN1nRdF1a17
	qeqrvNr9lVY/hy95IpvW7tDQ/aMrun+05Pu/TKpmWTVV1t4Cc0Z55XllVS8B
	/xt1DM++/Po0mE7H5iOQXn9cTBZT83ExjY49Ly+zrSdn4Sy0H83ts2gMV72j
	oyMh46atZdJ63u+v80KJ9loBWsm6VuKlksVRmy+VeFXLslkBk8VFXQHHq0Ls
	o4gciFVd3eSpakRSlRl8KNtcFnm78QAQWguug8y2jagyIcVSpUColUxeq/YQ
	vjf5VZlnQKWyFXJZreEfuG+pWgmSJkXeiEJlrbcuYZ9WJa1KD4EnSbFOjWZc
	s2aovmYkrmY0rBli//Ty5WlzMPK+qW7VjaoPAUDYgXYCCESsxLKCxSRpYIPr
	ISVhQ7GU5UbI1QoZinLZjASRywMUgVLXEm6LFYjYqlY3OYirkG2rlivAu62E
	Bt5uhzurDT92LVNR5MsccPNStSqqzRLodSjStcJnE7IJd0BSIRtxq4oC/4Xl
	rkuApeBHNUye94p2qJI1riG0viLHSWUPmbtItmalEiI8PnlINEtVlpdw9ynb
	JdxGilLdAjuSa9DIZgmPy1ZDRDRSbKUab5gLRG/6BPrbALPxwRrEq8F7xJlq
	kjpfIQSuXJ2BWKFcgBwB827z9prAvqoA2yrzMpnkBaEMv1qCjVicl3maAlu8
	p8D/Kl0nuLj3yPnzvM8+w93iQi3FJSyjiFRvPlvxtaPGXHuH5HwvZXjzRivo
	u3cO0ToVWQLe8kqRZURFYeILoyl4CTcC7hgFAQEWVekQmm7kOzZFJdMRc/wa
	eFVWrYDPbVWjXMAzJI9SaLwOkZ/LdXKNCoardLYCQEhkXecgfyDp+JPmJq66
	zMt8CYQ32oByuK9GV6NDAgMJAgRbrg7+DdVEpmlOAuUlYJklXMlyVaQAnFIp
	SnONhrBEUJJCyRrErAU4EwnywSoBFhCFJSWqgDvymuRapWsSBWffS5AsEqxG
	/dcaiKNEuV6CNwDlttrNRIG1YEdiDZq9d+9YCxpkK2JTwwpA9yUZKW0G0jzL
	QK9BLgAMb4BSuOSg9XHNE26zUvURcxPNUJl6BcBWNFrZHNDAToPUIErm+xRB
	vb3OgWVIlU5jkbeMl2y8WJGFc21VZ8EROwgRmpxsGmklYE1okAxUQHTYCu3G
	U8s7ZNO24XaEwkWVjR8CV1a3IKPV+up6wBQgwxOCjtks28EFBbsPkJi6Qbu6
	bFRxo5gnWodAhSR68Gxd9OQXsVb1kmBNFX7MS80Bj1cFUmg8VJmuqhz9TZl+
	AULmWPWROEkgNEPmFRtCD+B1odLikWiiIgtAwssrVa9qWBK3zJtmrYCiX+cl
	coqFjQ0hS4YVHpYLRlAWTYVLd5w8FKuqZXdabDz4X3WLy6NFbjFyEwqcR5PW
	1QpEDHlm8FYgM5W4BeEHiZGv6SGQqlswOeBTAMwrD/arkHe3eaMVgXAikQdV
	QhEbaTupvdllVaxJgjzPRKYsRbuBKSBHHsbROIIGWLiqGsZ+MvYD9i+NXthI
	nbZWuLTj9HeEStzIYq3AC3fKnredFWzQ8PUii7RadX7Ou6aNM3Bs1os2EKpC
	VL7E6JCYVzcts87a8bxh14fCotKRuMyRWLAvMacxNlojEyuvhDgc+IeaWpEl
	BltgMYhlkzcYA2Uyr53gx7q+orrKE9jW0yYK9jwp007FkciF3JClAzou1a31
	zncQ84OXQg1BuM0CHgBG0LJXYTtYEIl31ZFJzLgY5BCGFyBi4IeJOFXTgpyu
	1oWsGSBy8WhLtcHB6KYf5sXrK0YB4MJkxCODcKt5h1JM4KD9z9BmbMBPIE/A
	pFVlSowm4LVwNMO2hIHnwAbXhZuAyjm4IjDokAtctdcgPU9bVry0Ury9jdS0
	0gLJjReRcYVqSYAXpH3eDvMcne0ZZWuq1B1pAcdqNeMTgyu/D5EGrIQaia+0
	k1QS3IH9dQmJEPgA2DojcwSEjUG1QXc6hhEJ7DeEBE33bQ7Ciw4eI1ve1XNs
	Ni4s7MLGEd1CwtLFw5DbANlW6+Z6m+3eCtIewscPHZGnWLWLdxAdIBlkl0fx
	plUOVgxO4207SUx43r3bstLbEkcgmngD80Ywl7yBXrYPv+tiyXisVxjbweMU
	a8cbUi0gTd6wfe9vt23pd/hHvEWtjAmVLpwlCJEUMXgBSPxS8C6gurBqjOEt
	xiXNumgbN6wCQ3WLISLIYY0bWbEwOHo7RARUKVxAZoIhg+DYYnYfUofeAFMc
	P9incexEbMRXK3vefoedMNgV6sAIIUpmxx0bBvdEFSPcNdxrI30UGte5OHYX
	19iNPxBar92sdOzEhCUpgH9zwBxvrqVAMIjepGRuHE6wa/vJXgoiA4AE9HvN
	kQO5yyeQooCH/LquluY2nQwC6zZk7vEy5AJojMkjYgFD6eS484WwFWbn4qt1
	XpDv6BjlZhhkb7NaguHHeGCf0yuS+hI5j9Wbg/tXYWXaFdjBFTsBwQUv2Ejq
	CGAgjAM8tYllHrMx3nmSoyIKTDRB4ZZL3rPzgvYScblyHBsuzU4HIlWsYZDp
	AYS1zDkix3rnWkUTBmLEnhmWPPRwRz3Ke6qKgKMMsZDkBTGmhHVUjUFrtq4x
	woJMoknWlO7qikEXPOJS4Aoa2sGwvuHw+LZaA8uoPGAhXla1MkGsk3vorIhs
	CuVAHWkPgA2ADQUVbNVQCiDao8wGUWjI74JhgrxOIhykkbCSY3GcAkS1bm9V
	fnWt+KamgM8tygZE55xGg/JsFYLQzmT5HWFr1KHDFuI3jDgPdaEBQvG6Qt2j
	aADMCxsYuP1GGc1J6jxm3aE4kVzDbur+Dv0rhcMVRFEbr1cAQJ5Baimw1NmI
	vfPvLl/tHfK/4vkL+vzy8X989/Tl4zP8fPnNybNn3QdP33H5zYvvnp3ZT/bJ
	0xfn54+fn/HDcFX0Lnl75yd/2GO92Htx8erpi+cnz/a6iKir3aA/YuNK0g20
	0xmfpQE889Xpxf/+tx8CDf4FVHri+xGoNH9Z+HMKvUG9eDeKmvgrptoeUBtC
	K/IvYM0TuQIZKBpKmyEcvkUPUmMm86s/ImX+fCx+HScrP/yNvoAI9y4amvUu
	Es12r+w8zEQcuDSwTUfN3vUtSvfhPflD77uhu3PR884UGh3PSkne9MtkJoVp
	qJDZ1cQq0QX6ri9Ckw5+Z7hGuX+fkTxwq3yoxV2m87SFPIDqaOQljTXqe4FD
	jPalDY/EgAnnLAjui3+WqdPVC/B/DV5KqhT0FXKukmTJM5bFuG9LGMyzqAZl
	8yCQpsd3iVq1bPUhFoZsKm8RzpbzJJOWHnZlSI00yiiub90TcCNRkNFiDNc5
	ha7861Y9eirD2sE+FNOKs4vtIsmbz5p0ddRf453nGBADmsE9Rxuacl4obnKp
	zdmefKR7PHsCt5Et16SVW/1pd8RsxBZqewX7NLLYBA8b57rcKiuRFVjMZmAF
	TN1nOsLEm418rTL0KK18TckPCxrLoq5zUFinqzWNLtpS/QqSKF3Kp68aYnbi
	Seek7oFep69AkH2Vk5NEE1RyqoErAytvVX3Q0ZSdotcr3mAyLlfks2C3WiUq
	v+lLbOO4TpJqzbVDl06xgmQYwH+BYFPYt1K68gkxNka7qS1YkXCiIgDVNeub
	99wa6ENBORJ4XeaFxMAFg9IUBCDF0o2iTTh1QWLo5LVTB6tfpqZgNJQKCljL
	y8RX3z0/e/aY5ZIWwvoL3Pnmzb+DTER+GOha4wNsarooF1XbtG4g6lGUs5IL
	iFX/JtBRoMIRQAKY7y0f7RnBa4jS5RUV5TiGbkCPRbzGjERQG3IkyOSCiUSd
	tmS3tDx/ejZgS7WwkjloGsxVu2oZljuapkrINlPbo62VXDY2DQNLWWPC7wLb
	pQCajASdkJ2auvqlaWmejEYTjPNUybpD2/AqunDQ1+IGPQ4HOQjMq5cnzy8v
	Xrx8JUwTV4fqi2lExuorzO27yJUwR2m4Uj0RMWYJbSpEWxCALas0zzamJm1U
	eRsjYxonVIo2KC1G4okqyQ5ipXkdc8m9JQ0mnWWby1rbsGDoej4z2RpqkpJ+
	gXxY+iR7uQr7UVWp+xU5hpTaTNgdgSxOh/yCpQBj80dDf96JxqYQ550mIVTD
	XXY3UzL9MchYTW3MOL29zp5QXSqDOH+PWx90CzYNkPo2re5lvjsiDc4ezGGd
	siHggp3Ulmar2OtB8iJRYrl46XpsELB1Y8jsBCbYUVmqYd9ziNUScj0aQwxD
	NXKQkoojMb47HZ89HsjWAbKmay0oW9YZCn7KpoWreOv47qvHZ48PRnrpyUNL
	d62I+ym3tbY/Hh9wd4N0XXLFSVPl3kUOdYRlE1pWZCKJmExnwsS/WHqz0c2h
	EVu+kYBFE5wiK7Bz0eqIHlsr0gYAqASrVZy3zZ7G0LtfoLbrVfJGghuh0I3N
	juG4YSBWLYEGzyHzZpva+YJ/sbKdk7hQBdSkpADqMr8TD4lsp5uk5lb0RuKc
	M773e5iNsylWNx1lHanaA64s5eqIdOII4FPpdmw1GAUxlsakhSMf7LTnXSgy
	WCd/cCJ4Kp92LXDtIn+q52Gd8k5fj2tUGBR29vILNlwMaS8yHYg733FEBmpO
	kHU7sWp21UoIyTmWApL3wjfyy+VGXOUYshv+2LYJFp6swbgvbjEOH5Msqpij
	gXcR3KkCWYOj0xusN6MiSw5RqrKLE1fEBmrLpDdYEEO4CVsqReh6KHWPyQKK
	ZIs9A7fsWganIG4UwILvBKXqjl3qoVYKJ6fsTJOOBJWN1LpsRXL8Bkv0O2Co
	nBj9bUeKTdWlNvcPUVwSsy0G67IAJ6f7r5QOYAoHWSOuDkrUcA9qm0lUKqLk
	RAsGlrYHtm1NK7I1hKFuPcJKFoT+1c16HXaRBQJjhajxDEZc3WE6m5faYKH1
	JZrqvH4bOG24uZJ6yZTCoSRVbuWVjmncdWBDWeehZwgv3cYr40JiB/rBxUh0
	1myc+arj/wca21nFnT+yYq1aNTqf4EDWQtypTqw8GxfurldZ2cEl3eDjRta5
	ajesO3YIhPDoIN7yudqR+bMj8C2D4wpeK6+6SL5R5J+0g8eKgc6/dkLxHp2p
	f07Oj7XRBjmYqnNLXPCYAuI+Ei+6HN8b7JgMwzTZgukhUDxjGGxzYRCUjpjb
	hGRhwOkbyIsH4gNgEA53bfp9nuS1R8abayfauBlySm7DS8MOrv3oIFGj+VdV
	V6CkXVXEW2GQ17Ys7Fz7n07H794ddATCIh6klJb84nsRO+mZXtmH/3kd7RD8
	PuBOuqelF8MBRZpdb/QMG01g4BYmEvUo8kyN6nViYsYdXNr2DJguGDgyTPDi
	WFSv2bzjIh1HfGGyCrYYL00erm2GzcsHlL5j9HDs90D41REWgmhYj1I3zlg1
	sjSWhU17bvkSEqYex3neTr1HaCnkDbpeNDydXHuOn9QRnYGt60errf4dw6jt
	qcdNP5pT6MOhtiwnUaZLcvALbQjkPSkg2yhprJQ6rtnQpiZuadzm7oCBXgI8
	ssXctitA3E/tPjHETxLDSH7TViszT6LzQbd1YmQSAKgV5cqoEnWNMwfaxduA
	dNDmriB3JzJhIQpFwYQLJMOp6gTYobl3pnallxWXluvqACWOxdFoh9Y8RMFz
	lQkjQiwz9VNGMtE31NyhQJ8MypG2NNbos8bfUryVspLZ8qUlpI4icQAXbjnK
	ORyh1i/4sa7cImhYuSjQNznqifdafIeTcTuPyWhdtvU6aYEond/vuVEqbfNs
	VDcAY0PXblgI8dGeGVLWH3/8kSbH4W8sdv/8gWuTgWuBXcSHGwIRiqmYiblY
	iOh9rullPj/6hf/9+nO90tvfPZq8vXj7/VshTk/x+/lbun7xSv+u4d4alOwQ
	eyvefiiYupXeivv/uonRB+752DA1mzK5ritzyEAPiIt9nCo9cAYdhmD6/Def
	P/qF/+mV3vbpNDCyzhPrB73RiyGY3j5Icfwbwd9DvzvYfSCKf48wYfCDMTXG
	bwzj+A6CoV2OaBv1kWEapBMOx2OQPRCP30+ntx9MMh/knQknxEPs+/lS8PnR
	w38/Cya9JxvflFyb8x3EGEfhPiDvtKV7K34chIS8wPlvn4p909Q9uAfmHz8C
	7453dtka7se4f98pIWwBd/wRYPrlf5p3RybcBp96AUES4POr4QdOLNL2XoES
	Rf73zbH4rKnb1VGXC9AI85Es8qvy0V6icMJhT9ApuEd7jl9/53niV6IrXVKB
	1cyydikRZ8gcE4R6iMs0LVtZt93g91bKYyqoblZy6QzZH25VoVcaLR1d0yx3
	VzpwbTSGdJvBxj8md9T+NlFmhoPGBuoDm8T1jnhghDSU+HAS5STCXaOFOn8p
	c6TgqFLauTk9P9YHxdvhtaHbpVvYpT5vIXEm5Q6rQ6t12x0YyFfUzG12A7CL
	7olHO9QS+3lG6fiBePt2l2J0Ogt+YDfu0AUvukaot0zfGnU/jQga7xssm+0N
	brUH8kUtrf4pCDd5cEblqCDvASGdhhazNAMHrmVxnx40XmZ7QPMADPsr85j3
	lxDknSikIT89PfiLXkeDwGQmYlL9rZCJbSTQo5w67UyKjUhc+AROymNiW+vl
	O+eL7KGJTgtYEED2Kj4clP9V6SYkEQ1S4RoPuthZka3CkY3nuX1ZVTiji5Vb
	QgWyloe6aTha6dbFqJKGqRDRS9XYnXfnhgdbg5zkuIPRncHAXgSGqDjXC4px
	8vjkTFOoMZN2T07PD3RlbaKrS9iHMKJrVBglwK3G7YzmsmA8gKxZiYOjA2K3
	PXrinZyc6UGc9hpP3tiabFmV2EZo86s1jtv1CzG5Gbzk6i3XfFhNT0yvHFI3
	0IXjPmKgVrsowGrfP/IPXL1yH9pWpz7FVn1DY0WVR5T2trfbXs2S+F71EvuG
	wJ5LYGK9nUtnAmOivzVMjiJaK1nX1GTvOiWmEI5AABs4he9sHBDWc8iPI+S3
	crUyBoIbuztOaUt8kEdez6nw3DJVMUvu+WIPGKcyWlRrzcpeu4zGZHmYLy+9
	N2/cR7Qzxnl6cZK1aAmdlo0t4+3z2S6t/wfEmR2oeWDVmQgnjFGqcQCV2ZXj
	cE9+hdPy2GXM9QToideAEcEDJDjQZE7Z8TG8qtRtTV1Q0bWrBFjSsm3WNLZG
	jGq/yBPyTc3oUwXgUwVgF6ZfUgH4wDB9qBz5l1Ylujzrn68q8ZGz7U8VgH/u
	CsDHyGxtRvKUcpif84dehe/uZbYDTvUnMtyTfkfKzC6z81zK13acwORU5Msc
	h7f3jid6jnWz7oFQIG948j/NmxX2FFJOos1hX5rI24p6qL2g+y7O2BINBOih
	HTyHxpnpUFODM9NU/aLMtHuFyM/JTM1YFGefJuTR44489WMmod4rcXFw+KnE
	5Sei+S5TKasjJx1y85ad7IZfy3FvhmLOKjX05qDu6OB9zZbBMw3ue0q6ZEi/
	KQIHZcw4GIJfrVsWtYyOL3mE0u4JPx7GofmSTQOr626iulvhpK0U5t0QjWn3
	UFrncZ/2ZtJx1A6K9taBKJHi2lSZ83s0a8ZDx5WZcdLjGs3umX6doeOgYy+x
	dhuDA6WhIdrhJJRLQDqrQIvh+SLn1RXEWRRXLaf4phdVpt0MnLP3dphGp9z6
	NZM+TtgYbJQ7sElw7ZS2hl8Jcb+weCdFYV+TsXWkYusghR2AZgD4nQp6jHBg
	zNQUn+zcdDhCwHonxxy+6BS+03HKZ9c1nsYZbjPrCYM6b143dubzVsnXGGs9
	/+7Zs+1KLQkzs6g3cnDZgThlO2WxPiREN47qDJyjb8yJnmEZovtAEMiW0Znc
	lSy7YtK9ps+xfJ5r8LY7qXTGveui62FxuJn365OA3gjGB47LjbiVm5F4knN9
	AdTOPX5ou648TWOxp+GlmE6WoGD2B0nyYkOJqz0w6AyC6DfFcOe61n1n98Tm
	fqOUYPmTeFQRzTkXRXr1xiNaTY8MwzcTosQ5Hi91isD0fevIJFxZyvo1XOGf
	TfjVblYKvm7pJlzpkhk8p9rX0t7qDx25bYgIVoX1dAq9WwTLJDjDs5+P1OiQ
	BiD0CdHyX1ueQ0GWosNxju8f4JbuWwd09bw1BR86J1bFdFiVog46awoU9JwX
	/WzNFKBQMP8tqE7G3zHqkN8eh29JyF8r/ZqJW0i2rqhHTy9M0sOJPBGVrYti
	gz5Rrpp1wecMzJ1eox3R2atnl3pKCbwP1v/3O4+KJrhMMVBxXrdjDslTWefk
	+cnPsHs8enh20Q2Ynpip4vverEU+/8H3WV1IPLAGPrPZ2zlwcdkdsZiMQmtc
	+MzWSPSbETjAk6ZNN6c6fHBCV8Y6wMVz2L0R+3/6dXfPEb677k+/OQBvdZWD
	D2ZXraeL8YwPv1fJPe61xvdWAR3xhYMSfDi//e7p41df46sDxe/BbiDTntBB
	GVjs6ePLJ1hoxB9xQKbAV15Q6N0tQW/EQ4xAIJtjIW/aL/HtiKOqvuIbLQq8
	m0Z2+0fI5Ft5p+Nghw69U23NaOcx2B8NH2z9/IuT7V/pIeeX7xB/psWxIc0h
	U0tjdS1rVFN26yAh8HDFP12wmzrm1knviFz/PJAdQe4ffNMF9F988G1nmK53
	4BgPwX1x4pzVOSZQ+tf0cZAB7xh2GNkFCf3z9Z047V5J2Z1wgugieV1Wt4VK
	r/jdWzsKya6BXyOJJ7aaa50vlK/FM1WW2Np7UsvrguSXqENjXuuWX+9h3nOG
	L2RyTnyZw63dPO9Aa+LQPYXbrK8gRWj1xG/NWPJRYFlgUwUAajjmAvi+Be9E
	ThBBrO4OxdP/+x/5OgcawBLgo7jH9xXO09WpOImrWJoWXF4LPCGPB+FRA+22
	+t12GGnjsXYIXn8HZAeqDNAMgzYnFMyxRHsn8XghvsZNT7yxE2AOmvdJcVl6
	P87RnYNglwec3508vjw6ffWSucFull85xowvcv2mlxbhumG4CCMOuYwpJfrr
	tXoT+BxKoW1ZLu1bhxB2/SLQ7Ykuk46/xCt4HuqUUyinFz/Wf92950B9uPO3
	arPTsVd+Fs3lOA3U2F/EapzOwkwGk2Q8S1XoB9H2GpeyaLcXGatkNp/KNIwW
	MlMqjmfRbBwHUsZq1j1/yu+vuFznmLf3KwuPL384Pf/Bnyx++Ob85PSHy29O
	/B8WFnzjYQbgT2a+mssomIdhFkRK+eN5EAIQQZYBVov5zhoD8AfjJI6TMfid
	IF0kiyngkcawSiSV3z1/0g+XXVASFatg4mcz2HPuz+JZloYyDiOZTaYz6U9n
	abCIpQxRnj4jS6XDVBIKf/gYFh/r4xsdrkfjceZPgml3AURbZrFMuwvwVcVA
	+e4CmCoFwmBRmfrwdeKIh4z5v7/lgtM4/1AAJ+MtgFUcTYLZdOJgkIC8Bla4
	skWqJnNlpTWBbwrusVQIZ1M/jTJ7IQkn/kJaCRlPwnA6mdg7QASmwzyb/C08
	m70HCXxWYEuC8RQ5Np78PXn2PgAnky2ehSqNkiS0d8zk3J/EgeVINEumiZxb
	BgRBlIaTcWgXBXM0nzs2aAZJ9SyaLqwgZHGigoXdNrqXZ/foWXfISGdg9/Fw
	QiRZvAdJkBxqEo7dC+N4Mvun0cz3R2kBpl0BFy3ASZb5s9R5ZFt3o8kiAKOa
	WCpEaroIoq6fCB4oVQEY2+7CPAQbns6sYITT2dwPHEiTQCaZ79tt5STNFuEk
	cEgLuv8+uvt+chB9UDn4B2v7+6OUzcdq6geOJEfjOIon1srv2IMYhD1chJaH
	mZSzMJxZIzPNgnSeBVb9/ck08kPHqGdhOpYqsmQJklkWziOLdDSV42weWzgC
	kJthOeATTB/EKsgPKg3aKvxdjcD7YACqOI5nzmaZmsh4rKzyaSNgMVABeN5Z
	aB+ZTJNIzUNrFeIwyRYqtGtk4PNVMLfy4icQlCbKQhrPIMQMIyse0ocFH+D1
	B9H8+IPy2t+O1P8OvH4fDJI4m4SJbzUuDIKx8hPHFE+2eD2NojQNp3aXJEpn
	i3lsFX0cqEU8jey2EDVnECM7fmYR+2Bi7KJJGvjgeKxeK4TS5GdPTs8/WH4G
	a/VfFwPAhf/IBA2FCLxBMA7BK8zG8/FiHI3lOB6DlgGJsu01hhI0OZa+nEhQ
	FzmVEIjJBfhb6cjQg8nZydkPmKFheoaUNj88kJWN53NIzMIgiScTP06C6TTL
	JkE6zaJFKH1H/h/IyiB9ClQ0DWYhiGQSJVGUTOU8+ZRF/UyAdyKxIIrmkzSx
	9nI6nyRh6hhQtciQV3ZRMNFBFk/solGYRekis0I3DdV8koVOvBdALj1NnOAt
	y8A7ZNZuRxn46FjFn1KrnwfwQCg1n8owscIQTpPUd5kQxGk8T6Wl+ST2VTCZ
	Bc62EBnNnBg7iWbBJIysOC/8OABjYXfJpkk8SxbW9MdBBCH3NPuUb32sfGuG
	ygRZtN1snkH+61zY0fKFTOcJ+FP7SDIfy8U4ceBYzGaxE3vNYhktpqGVSZVF
	fjBdOBciMOBS2kUzuDJbLKxwxPF4FoJfsReSMeTiECh8SsI+UhIWzBbj6SS0
	TFlAkDSJHWnesRzJfJH6rrwHkDRP4sTe4fty7i/m1nL4i0k4A79tyZKMp1GS
	zBxOR5B8O/Ed2JkoBPDtLmGownjseK/FOFNy8Skz+7CZmT+FnCh2kqhgHo1n
	meOudzKzeB5Hs3BqH5lLEKHAAXgey2mwiKy5UFEQ+HMnJ5jF0zSahxawLBgn
	YB2slUrBc0x9x2NBLD9O/FR+Stc+aLoGdA4WkFnbyGARZ2C7HX+xna7NfAVp
	98SyN4N9gb/2jvls5gcTp+iaBokK3RgmGc9kEk6cOu3Cl+nYEQBwJ34v9oQE
	cDKepwu3tef9P5Md+eozcAAA
			<section anchor="acknowledgements" numbered="false">
			<name>Acknowledgements</name>
			<t>The authors wish to thank <contact fullname="Lennart Grahl"/> for
			pointing out many of the issues with the existing header encryption
			mechanism, as well as suggestions for this proposal. Thanks also to
			<contact fullname="Jonathan Lennox"/>, <contact fullname="Inaki
			Castillo"/>, and <contact fullname="Bernard Aboba"/> for their reviews
			and suggestions.</t>
			</section>
			</back>
	</rfc>		</rfc>
End of changes. 116 change blocks.
	827 lines changed or deleted		369 lines changed or added
This html diff was produced by rfcdiff 1.48.