<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!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) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-avtcore-cryptex-08" number="9335" submissionType="IETF"
category="std" consensus="true" updates="3711" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" version="3">

<!-- xml2rfc v2v3 conversion 3.13.1 -->
  <front>
    <title>Completely
    <title abbrev="Completely Encrypting RTP Header Extensions and CSRCs">Completely Encrypting RTP Header Extensions and Contributing Sources</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-avtcore-cryptex-08"/> name="RFC" value="9335"/>
    <author initials="J." surname="Uberti" fullname="Justin Uberti">
      <organization>Clubhouse</organization>
      <organization></organization>
      <address>
        <email>justin@uberti.name</email>
      </address>
    </author>
    <author initials="C." surname="Jennings" fullname="Cullen Jennings">
      <organization>Cisco</organization>
      <address>
        <email>fluffy@iii.ca</email>
      </address>
    </author>
    <author initials="S." surname="Garcia Murillo" fullname="Sergio Garcia Murillo">
      <organization>Millicast</organization>
      <address>
        <email>sergio.garcia.murillo@cosmosoftware.io</email>
      </address>
    </author>
    <date year="2022" month="August" day="04"/> year="2023" month="January"/>
    <area>ART</area>
    <workgroup>AVTCORE</workgroup>
    <keyword>SRTP</keyword>
    <abstract>
      <t>While the Secure Real-time Transport Protocol (SRTP) provides confidentiality
for the contents of a media packet, a significant amount of metadata is left
unprotected, including RTP header extensions and contributing sources (CSRCs).
However, this data can be moderately sensitive in many applications. While
there have been previous attempts to protect this data, they have had limited
deployment, due to complexity as well as technical limitations.</t>
      <t>This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts
header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of
facilitating deployment.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <section anchor="problem-statement">
        <name>Problem Statement</name>
        <t>The Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711"/> mechanism provides message
authentication for the entire RTP packet, packet but only encrypts the RTP payload.
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,
certain fields need to remain as cleartext because they are used for key
scheduling (e.g., RTP SSRC synchronization source (SSRC) and sequence number).</t>
        <t>However, as noted in <xref target="RFC6904"/>, the security requirements can be different for
information carried in RTP header extensions, including the per-packet sound
levels defined in <xref target="RFC6464"/> and <xref target="RFC6465"/>, which are specifically noted as
being sensitive in the Security Considerations section sections of those RFCs.</t>
        <t>In addition to the contents of the header extensions, there are now enough
header extensions in active use that the header extension identifiers
themselves can provide meaningful information in terms of determining the
identity of the endpoint and/or application. Accordingly, these identifiers
can be considered a fingerprinting issue.</t>
        <t>Finally, the CSRCs included in RTP packets can also be sensitive, potentially
allowing a network eavesdropper to determine who was speaking and when during
an otherwise secure conference call.</t>
      </section>
      <section anchor="previous-solutions">
        <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
header extension values. However, it has not seen significant adoption, adoption and
has a few technical shortcomings.</t>

<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
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
the most popular SRTP implementations had a significant bug in this area
that was not detected for five years.</t>
        <t>Second, it the mechanism only protects the header extension values, values and not their ids identifiers or
lengths. It also does not protect the CSRCs. As noted above, this leaves
a fair amount of potentially sensitive information exposed.</t>
<t>Third, it the mechanism bloats the header extension space. Because each extension must
be offered in both unencrypted and encrypted forms, twice as many header
extensions must be offered, which will in many cases push implementations
past the 14-extension limit for the use of one-byte extension headers
defined in <xref target="RFC8285"/>. Accordingly, in many cases, implementations will need to use
two-byte headers in many cases, headers, which are not supported well by some
existing implementations.</t>
        <t>Finally, the header extension bloat combined with the need for backwards backward
compatibility results in additional wire overhead. Because two-byte
extension headers may not be handled well by existing implementations,
one-byte extension identifiers will need to be used for the unencrypted
(backwards compatible)
(backward-compatible) forms, and two-byte for the encrypted forms.
Thus, deployment of <xref target="RFC6904"/> encryption for header extensions <xref target="RFC6904"/> will
typically result in multiple extra bytes in each RTP packet, compared
to the present situation.</t>
      </section>
      <section anchor="goals">
        <name>Goals</name>
        <t>From the previous analysis, the desired properties of a solution are:</t>
<ul spacing="normal">
          <li>Build
          <li>Built on the existing <xref target="RFC3711"/> SRTP framework <xref target="RFC3711"/> (simple to understand)</li>
          <li>Build
          <li>Built on the existing <xref target="RFC8285"/> header extension framework <xref target="RFC8285"/> (simple to implement)</li>
          <li>Protection of header extension ids, identifiers, lengths, and values</li>
          <li>Protection of CSRCs when present</li>
          <li>Simple signaling</li>
          <li>Simple crypto transform and SRTP interactions</li>
          <li>Backward compatible compatibility with unencrypted endpoints, if desired</li>
          <li>Backward compatible compatibility with existing RTP tooling</li>
        </ul>
	<t>The last point deserves further discussion.  While considering other possible
	solutions that would have encrypted more of the RTP
	header (e.g., the number of CSRCs), lack of support on CSRCs) were considered, the inability to parse the
	resultant packets with current tools was inevitable and the additional a generally higher level of
	complexity outweighed the slight improvement in confidentiality by fixing previous in
	these solutions.  Hence, a new more pragmatic approach was needed taken to solve
	the described problem described in <xref target="problem-statement"/>.</t>
      </section>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section anchor="design">
      <name>Design</name>
      <t>This specification proposes a mechanism to negotiate encryption of all
RTP header extensions (ids, lengths, and values) as well as CSRC values. It
reuses the existing SRTP framework, is accordingly simple to implement, and
is backward compatible with existing RTP packet parsing code, even when
support for the mechanism has been negotiated.</t>
      <t>Except when explicitly stated otherwise, Cryptex reuses all the framework procedures, transforms transforms, and considerations described in <xref target="RFC3711"/>.</t>
    </section>
    <section anchor="sdp-considerations">
      <name>SDP Considerations</name>
      <t>Cryptex support is indicated via a new "a=cryptex" SDP attribute defined in this specification.</t>
      <t>The new "a=cryptex" attribute is a property attribute as defined in <xref target="RFC8866"/> section 5.13 and target="RFC8866" sectionFormat="of" section="5.13"/>; it therefore takes no value, value 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 (in either an offer or an answer) indicates that
the endpoint is capable of receiving RTP packets encrypted with Cryptex, as defined below.</t>
      <t>Once each peer has verified that the other party supports receiving RTP packets encrypted with Cryptex, senders can unilaterally decide whether to use or not to use the Cryptex mechanism on a per packet 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 all RTP-based "m=" sections belonging to the same bundle group. This ensures that the encrypted MID Media Identifier (MID) header extensions can be processed, allowing to associate RTP streams to be associated with the correct "m=" section in each BUNDLE group as specified in <xref target="RFC9143"/> section 9.2. target="RFC9143" sectionFormat="of" section="9.2"/>. When used with BUNDLE, this attribute is assigned to the TRANSPORT category <xref target="RFC8859"/>.</t>
      <t>Both endpoints can change the Cryptex support status by modifying the session as specified in  <xref target="RFC3264"/> section 8. target="RFC3264" sectionFormat="of" section="8"/>. Generating subsequent SDP offers and answers <bcp14>MUST</bcp14> use the same procedures for including the "a=cryptex" attribute as the ones on the initial offer and answer.</t>
    </section>
    <section anchor="rtp-header-processing">
      <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
one-byte and two-byte header extensions. In order to allow a receiver to determine
if an incoming RTP packet is using the encryption scheme in this specification,
two new values are defined:</t>
      <ul spacing="normal">
        <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>
      </ul>
      <t>In the case of using two-byte header extensions, the extension id identifier with value 256 <bcp14>MUST NOT</bcp14>
be negotiated, as the value of this id identifier is meant to be contained in the "appbits" of the
"defined by profile" field, which are is not available when using the values above.</t>
<t>Note that as per <xref target="RFC8285"/> target="RFC8285"/>, it is not possible to mix one-byte and two-byte headers on the same RTP packet. Mixing one-byte and two-byte headers on the same RTP stream requires negotiation of the "extmap-allow-mixed" SDP attribute as defined in <xref target="RFC8285"/> section 4.1.2.</t> target="RFC8285" sectionFormat="of" section="6"/>.</t>
      <t>Peers <bcp14>MAY</bcp14> negotiate both Cryptex and the Encryption of Header Extensions mechanism defined in <xref target="RFC6904"/> via SDP offer/answer as described in <xref target="sdp-considerations"/>, and if both mechanisms are supported, either one can be used for any given packet. However, if a packet is encrypted with Cryptex, it <bcp14>MUST NOT</bcp14> also use <xref target="RFC6904"/> header extension encryption, encryption <xref target="RFC6904"/>, and vice versa.</t>
      <t>If

<t> If one of the peers has advertised both the ability to receive cryptex both Cryptex and the ability to receive
header extensions encrypted as per <xref target="RFC6904"/> in the SDP
exchange, it is <bcp14>RECOMMENDED</bcp14> for that the other peer to use Cryptex
rather than the mechanism in <xref target="RFC6904"/> when sending RTP packets
so that all the header extensions and CSRCS are encrypted unless encrypted. However, if there is a
compelling reason to use the mechanism in <xref target="RFC6904"/> (e.g. (e.g., a
need for some header extensions to be sent in the clear so that so they are
processable by RTP middleboxes) in which case, it middleboxes), the other peer <bcp14>SHOULD</bcp14> use
the mechanism in <xref target="RFC6904"/> instead.</t>
      <section anchor="sending">
        <name>Sending</name>
        <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"/> header extensions <xref target="RFC8285"/> follows the steps below. This mechanism <bcp14>MUST NOT</bcp14> be
used with header extensions other than the variety described in <xref target="RFC8285"/> variety.</t> target="RFC8285"/>.</t>
        <t>If the RTP packet contains one-byte headers, the 16-bit RTP header
        extension tag <bcp14>MUST</bcp14> be set to 0xC0DE to indicate that the encryption
        has been applied, applied and the one-byte framing is being used. Otherwise, If the RTP
        packet contains two-byte headers, the header extension tag
        <bcp14>MUST</bcp14> be set to 0xC2DE to indicate encryption has been applied, applied and the
        two-byte framing is being used.</t> used.

	</t>
        <t>If the packet contains CSRCs but no header extensions, an empty extension block
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
indicate an extension block is present. This is necessary to provide the receiver
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> <xref target="encryption-procedure"/> ("Encryption Procedure").</t>
      </section>
      <section anchor="receiving">
        <name>Receiving</name>
        <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
formatted according to this specification. If the field does not match
one of the values defined above, the implementation <bcp14>MUST</bcp14> instead
handle it according to the specification that defines that value.</t>
        <t>Alternatively, if the implementation considers the use of this specification mandatory and the "defined by profile" field does not match one of the values defined above, it <bcp14>MUST</bcp14> stop the processing of the RTP packet and report an error for the RTP stream.</t>
        <t>If the RTP packet passes this check, it is then decrypted according to
Decryption Procedure, as described in
<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
block was added as indicated above, it can be left as-is as is and will be
processed normally.</t>
      </section>
    </section>
    <section anchor="encryption-and-decryption">
      <name>Encryption and Decryption</name>
      <section anchor="packet-structure">
        <name>Packet Structure</name>
        <t>When this mechanism is active, the SRTP packet is protected as follows:</t>
        <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[
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
  |V=2|P|X|  CC   |M|     PT      |       sequence number         | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  |                           timestamp                           | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  |           synchronization source (SSRC) identifier            | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| |            contributing source (CSRC) identifiers             | |
| |                               ....                            | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
X |  0xC0 or 0xC2 |    0xDE       |           length              | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |                  RFC 8285 header extensions                   | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |                          payload  ...                         | |
| |                               +-------------------------------+ |
| |                               | RTP padding   | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~          SRTP MKI Master Key Identifier (MKI) (OPTIONAL)          ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| :                 authentication tag (RECOMMENDED)              : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                                                                   |
+- Encrypted Portion* Portion                       Authenticated Portion ---+
]]></artwork>
        </figure>
        <ul spacing="normal">
          <li>Note
        <t>Note that, as required by <xref target="RFC8285"/>, the 4 bytes at the start of the extension block are not encrypted.</li>
        </ul> encrypted.</t>
        <t>Specifically, the encrypted portion Encrypted Portion <bcp14>MUST</bcp14> include any CSRC identifiers, any
RTP header extension (except for the first 4 bytes), and the RTP payload.</t>
      </section>
      <section anchor="encryption-procedure">
        <name>Encryption Procedure</name>
        <t>The encryption procedure is identical to that of <xref target="RFC3711"/> except for the
	Encrypted Portion of the SRTP packet. The plaintext input to the cipher is as follows:</t>

        <artwork><![CDATA[
Plaintext = CSRC identifiers (if used) || header extension data ||
     RTP payload || RTP padding (if used) || RTP pad count (if used). used)
]]></artwork>
        <t>Here "header extension data" refers to the content of the RTP extension field,
excluding the first four bytes (the RFC 8285 extension header). header <xref target="RFC8285"/>).  The first <tt>4 * CSRC count (CC)</tt> bytes of the ciphertext are placed in the CSRC field of the RTP header.
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
to replace a "defined by profile" field from <xref target="RFC8285"/> with its counterpart
defined in RTP <xref target="rtp-header-processing"/> ("RTP Header Processing above Processing") and encrypt at the same time.</t>

<t>For AEAD Authenticated Encryption with Associated Data (AEAD) ciphers (e.g., GCM), AES-GCM), the 12-byte fixed header and the four-byte header
extension header (the "defined by profile" field and the length) are considered
AAD,
additional authenticated data (AAD), even though they are non-contiguous in the packet if CSRCs are present.</t>
        <artwork><![CDATA[
Associated Data: fixed header || extension header (if X=1)
]]></artwork>
        <t>Here "fixed header" refers to the 12-byte fixed portion of the RTP header, and
"extension header" refers to the four-byte RFC 8285 extension header <xref target="RFC8285"/> ("defined
by profile" and extension length).</t>
        <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
identifiers, resulting in an intermediate representation of the form shown in
<xref target="intermediate-packet"/>.  After encryption, the CSRCs (now encrypted) and
extension header would need to be swapped back to their original positions. A
similar operation can be done when decrypting to create contiguous ciphertext
and AAD inputs.</t>
        <figure anchor="intermediate-packet">
          <name>An RTP packet transformed Packet Transformed to make Make Cryptex cipher inputs contiguous</name> Cipher Inputs Contiguous</name>
          <artwork align="center"><![CDATA[
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
  |V=2|P|X|  CC   |M|     PT      |       sequence number         | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  |                           timestamp                           | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  |           synchronization source (SSRC) identifier            | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  |  0xC0 or 0xC2 |    0xDE       |           length              | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<+
| |            contributing source (CSRC) identifiers             | |
| |                               ....                            | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |                  RFC 8285 header extensions                   | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |                          payload  ...                         | |
| |                               +-------------------------------+ |
| |                               | RTP padding   | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                                                                   |
+- Plaintext Input                                     AAD Input ---+
]]></artwork>
        </figure>
        <t>Note: This
        <t>Note that this intermediate representation is only displayed as reference for implementations and is not meant to be sent on the wire.</t>
      </section>
      <section anchor="decryption-procedure">
        <name>Decryption Procedure</name>
        <t>The decryption procedure is identical to that of <xref target="RFC3711"/> except
for the Encrypted Portion of the SRTP packet, which is as shown in the section above.</t>
        <t>To minimize changes to surrounding code, the decryption mechanism can choose
to replace the "defined by profile" field with its no-encryption counterpart
from <xref target="RFC8285"/> and decrypt at the same time.</t>
      </section>
    </section>
    <section anchor="backwards-compatibility">
      <name>Backwards
      <name>Backward Compatibility</name>
      <t>This specification attempts to encrypt as much as possible without interfering
with backwards backward compatibility for systems that expect a certain structure from
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>
      <t>This specification also attempts to reuse the key scheduling from SRTP, which
depends on the RTP packet sequence number and SSRC identifier. Accordingly,
these values are also not encrypted.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>All security considerations in <xref target="RFC3711"/> section 9 target="RFC3711" sectionFormat="of" section="9"/> are applicable to this specification, except section 9.4. Confidentiality specification; the exception is Section <xref target="RFC3711" sectionFormat="bare" section="9.4"/>, because confidentiality of the RTP Header which is the purpose of this specification.</t>
      <t>The risks of using weak or NULL authentication with SRTP, described in Section 9.5 of <xref target="RFC3711"/>, target="RFC3711" sectionFormat="of" section="9.5"/>, apply to encrypted header extensions as well.</t>
      <t>This specification extends SRTP by expanding the Encrypted Portion of the RTP packet,
as shown in Packet Structure. <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,
this is necessarily an improvement.</t>
      <t>The RTP fields that are left unencrypted (see rationale above) are as follows:</t>
      <ul spacing="normal">
        <li>RTP version</li>
        <li>padding bit</li>
        <li>extension bit</li>
        <li>number of CSRCs</li>
        <li>marker bit</li>
        <li>payload type</li>
        <li>sequence number</li>
        <li>timestamp</li>
        <li>SSRC identifier</li>
        <li>number of <xref target="RFC8285"/> header extensions</li> extensions <xref target="RFC8285"/></li>
      </ul>
      <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
sensitivity. In the event any of these values need to be encrypted, SRTP
is likely the wrong protocol to use and a fully-encapsulating fully encapsulating protocol
such as DTLS is preferred (with its attendant per-packet overhead).</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="sdp-cryptex-attribute">
        <name>SDP cryptex Attribute</name>
        <t>This document updates the "attribute-name (formerly "att-field")" subregistry of the "Session Description Protocol (SDP) Parameters" as specified in Section 8.2.4 of registry (see <xref target="RFC8866"/>. target="RFC8866" sectionFormat="of" section="8.2.4"/>). Specifically, it adds the SDP "a=cryptex" attribute to the Attribute Names (&lt;attribute-name&gt;) registry for use at both the media level and the session level usage.</t>
        <t>Contact name: IETF level.</t>
	<dl spacing="normal">
          <dt>Contact name:</dt>
	  <dd>IETF AVT Working Group or IESG if the AVT Working Group is closed</t>
        <t>Contact closed</dd>
          <dt>Contact email address: avt@ietf.org</t>
        <t>Attribute name: cryptex</t>
        <t>Attribute syntax: This address:</dt>
	  <dd>avt@ietf.org</dd>
          <dt>Attribute name:</dt>
	  <dd>cryptex</dd>
          <dt>Attribute syntax:</dt>
	  <dd>This attribute takes no values.</t>
        <t>Attribute semantics: N/A</t>
        <t>Attribute value: N/A</t>
        <t>Usage level: session, media</t>
        <t>Charset dependent: No</t>
        <t>Purpose: The values.</dd>
          <dt>Attribute semantics:</dt>
	  <dd>N/A</dd>
          <dt>Attribute value:</dt>
	  <dd>N/A</dd>
          <dt>Usage level:</dt>
	  <dd>session, media</dd>
          <dt>Charset dependent:</dt>
	  <dd>No</dd>
          <dt>Purpose:</dt>
	  <dd>The presence of this attribute in the SDP indicates that the
	  endpoint is capable of receiving RTP packets encrypted with Cryptex
	  as described in this document.</t>
        <t>O/A procedures: SDP document.</dd>
          <dt>O/A procedures:</dt>
	  <dd>SDP O/A procedures are described in Section 4 of this document.</t>
        <t>Mux Category: TRANSPORT</t>
      </section>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors wish to thank Lennart Grahl for pointing out many <xref target="sdp-considerations" format="counter"/> of the issues with the existing
header encryption mechanism, as well as suggestions for this proposal.
Thanks also to Jonathan Lennox, Inaki Castillo, and Bernard Aboba for their review and suggestions.</t>
	  document.</dd>
          <dt>Mux Category:</dt>
	  <dd>TRANSPORT</dd>
	</dl>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3550">
          <front>
            <title>RTP: A Transport Protocol for Real-Time Applications</title>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
              <organization/>
            </author>
            <author fullname="S. Casner" initials="S." surname="Casner">
              <organization/>
            </author>
            <author fullname="R. Frederick" initials="R." surname="Frederick">
              <organization/>
            </author>
            <author fullname="V. Jacobson" initials="V." surname="Jacobson">
              <organization/>
            </author>
            <date month="July" year="2003"/>
            <abstract>
              <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 multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the 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 algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.  [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/rfc3711">
          <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 traffic 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/rfc8285">
          <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 extension feature of RTP (the Real-time Transport Protocol).  It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is decentralized.  The actual 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/rfc8859">
          <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 sending 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/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <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 signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  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/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <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 protocol  specifications.  This document aims to reduce the ambiguity by clarifying that 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/rfc8866">
          <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 is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This 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/rfc9143">
          <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 with 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 descriptions ("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 BUNDLE transport form a BUNDLE group. </t>
              <t>This specification defines a new RTP Control Protocol (RTCP) Source 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/rfc3264">
          <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 make 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 participant answers with the desired session from their perspective.  This offer/answer model is most useful in unicast sessions where information from both participants 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>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8285.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8859.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8866.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9143.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC6464" target="https://www.rfc-editor.org/info/rfc6464">
          <front>
            <title>A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication</title>
            <author fullname="J. Lennox" initials="J." role="editor" surname="Lennox">
              <organization/>
            </author>
            <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 conferences, 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 decode 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/rfc6465">
          <front>
            <title>A Real-time Transport Protocol (RTP) Header Extension for Mixer-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="Marocco">
              <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 audio conferences to deliver information about the audio level of individual participants.  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/rfc6904">
          <front>
            <title>Encryption of Header Extensions in the Secure Real-time Transport 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 authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets.  However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality.  This document provides 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 specify 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/rfc7714">
          <front>
            <title>AES-GCM Authenticated Encryption in the Secure Real-time Transport 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>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6464.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6465.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6904.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7714.xml"/>

      </references>
    </references>
    <section anchor="test-vectors">
      <name>Test Vectors</name>
      <t>All values are in hexadecimal and represented in network order (big endian).</t>
      <section anchor="aes-ctr">
        <name>AES-CTR</name>
        <t>The following section subsections list the test vectors for using cryptex Cryptex with AES-CTR as per <xref target="RFC3711"/></t> target="RFC3711"/>.</t>

<t>Common values are organized as follows:</t>
        <artwork><![CDATA[
Rollover Counter:          00000000
Master Key:                e1f97a0d3e018be0d64fa32c06de4139
Master Salt:               0ec675ad498afeebb6960b3aabe6
Crypto Suite:              AES_CM_128_HMAC_SHA1_80
Session Key:               c61e7a93744f39ee10734afe3ff7a087
Session Salt:              30cbbc08863d8c85d49db34a9ae1
Authentication Key:        cebe321f6ff7716b6fd4ab49af256a156d38baa4
]]></artwork>
        <section anchor="rtp-packet-with-1-byte-header-extension">
          <name>RTP Packet with 1-byte header extension</name> One-Byte Header Extension</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    900f1235
    decafbad
    cafebabe
    bede0001
    51000200
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    900f1235
    decafbad
    cafebabe
    c0de0001
    eb923652
    51c3e036
    f8de27e9
    c27ee3e0
    b4651d9f
    bc4218a7
    0244522f
    34a5
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-2-byte-header-extension">
          <name>RTP Packet with 2-byte header extension</name> Two-Byte Header Extension</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    900f1236
    decafbad
    cafebabe
    10000001
    05020002
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    900f1236
    decafbad
    cafebabe
    c2de0001
    4ed9cc4e
    6a712b30
    96c5ca77
    339d4204
    ce0d7739
    6cab6958
    5fbce381
    94a5
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-1-byte-header-extension-and-csrc-fields">
          <name>RTP Packet with 1-byte header extension One-Byte Header Extension and CSRC fields</name> Fields</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f1238
    decafbad
    cafebabe
    0001e240
    0000b26e
    bede0001
    51000200
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f1238
    decafbad
    cafebabe
    8bb6e12b
    5cff16dd
    c0de0001
    92838c8c
    09e58393
    e1de3a9a
    74734d67
    45671338
    c3acf11d
    a2df8423
    bee0
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-2-byte-header-extension-and-csrc-fields">
          <name>RTP Packet with 2-byte header extension Two-Byte Header Extension and CSRC fields</name> Fields</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f1239
    decafbad
    cafebabe
    0001e240
    0000b26e
    10000001
    05020002
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f1239
    decafbad
    cafebabe
    f70e513e
    b90b9b25
    c2de0001
    bbed4848
    faa64466
    5f3d7f34
    125914e9
    f4d0ae92
    3c6f479b
    95a0f7b5
    3133
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-empty-1-byte-header-extension-and-csrc-fields">
          <name>RTP Packet with empty 1-byte header extension Empty One-Byte Header Extension and CSRC fields</name> Fields</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f123a
    decafbad
    cafebabe
    0001e240
    0000b26e
    bede0000
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f123a
    decafbad
    cafebabe
    7130b6ab
    fe2ab0e3
    c0de0000
    e3d9f64b
    25c9e74c
    b4cf8e43
    fb92e378
    1c2c0cea
    b6b3a499
    a14c
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-empty-2-byte-header-extension-and-csrc-fields">
          <name>RTP Packet with empty 2-byte header extension Empty Two-Byte Header Extension and CSRC fields</name> Fields</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f123b
    decafbad
    cafebabe
    0001e240
    0000b26e
    10000000
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f123b
    decafbad
    cafebabe
    cbf24c12
    4330e1c8
    c2de0000
    599dd45b
    c9d687b6
    03e8b59d
    771fd38e
    88b170e0
    cd31e125
    eabe
]]></artwork>
]]></sourcecode>
        </section>
      </section>
      <section anchor="aes-gcm">
        <name>AES-GCM</name>
        <t>The following section subsections list the test vectors for using cryptex Cryptex with AES-GCM as per <xref target="RFC7714"/></t> target="RFC7714"/>.</t>
        <t>Common values are organized as follows:</t>
        <artwork><![CDATA[
    Rollover Counter:          00000000
    Master Key:                000102030405060708090a0b0c0d0e0f
    Master Salt:               a0a1a2a3a4a5a6a7a8a9aaab
    Crypto Suite:              AEAD_AES_128_GCM
    Session Key:               077c6143cb221bc355ff23d5f984a16e
    Session Salt:              9af3e95364ebac9c99c5a7c4
]]></artwork>
        <section anchor="rtp-packet-with-1-byte-header-extension-1">
          <name>RTP Packet with 1-byte header extension</name> One-Byte Header Extension</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    900f1235
    decafbad
    cafebabe
    bede0001
    51000200
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    900f1235
    decafbad
    cafebabe
    c0de0001
    39972dc9
    572c4d99
    e8fc355d
    e743fb2e
    94f9d8ff
    54e72f41
    93bbc5c7
    4ffab0fa
    9fa0fbeb
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-2-byte-header-extension-1">
          <name>RTP Packet with 2-byte header extension</name> Two-Byte Header Extension</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    900f1236
    decafbad
    cafebabe
    10000001
    05020002
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    900f1236
    decafbad
    cafebabe
    c2de0001
    bb75a4c5
    45cd1f41
    3bdb7daa
    2b1e3263
    de313667
    c9632490
    81b35a65
    f5cb6c88
    b394235f
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-1-byte-header-extension-and-csrc-fields-1">
          <name>RTP Packet with 1-byte header extension One-Byte Header Extension and CSRC fields</name> Fields</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f1238
    decafbad
    cafebabe
    0001e240
    0000b26e
    bede0001
    51000200
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f1238
    decafbad
    cafebabe
    63bbccc4
    a7f695c4
    c0de0001
    8ad7c71f
    ac70a80c
    92866b4c
    6ba98546
    ef913586
    e95ffaaf
    fe956885
    bb0647a8
    bc094ac8
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-2-byte-header-extension-and-csrc-fields-1">
          <name>RTP Packet with 2-byte header extension Two-Byte Header Extension and CSRC fields</name> Fields</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f1239
    decafbad
    cafebabe
    0001e240
    0000b26e
    10000001
    05020002
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f1239
    decafbad
    cafebabe
    3680524f
    8d312b00
    c2de0001
    c78d1200
    38422bc1
    11a7187a
    18246f98
    0c059cc6
    bc9df8b6
    26394eca
    344e4b05
    d80fea83
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-empty-1-byte-header-extension-and-csrc-fields-1">
          <name>RTP Packet with empty 1-byte header extension Empty One-Byte Header Extension and CSRC fields</name> Fields</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f123a
    decafbad
    cafebabe
    0001e240
    0000b26e
    bede0000
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f123a
    decafbad
    cafebabe
    15b6bb43
    37906fff
    c0de0000
    b7b96453
    7a2b03ab
    7ba5389c
    e9331712
    6b5d974d
    f30c6884
    dcb651c5
    e120c1da
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="rtp-packet-with-empty-2-byte-header-extension-and-csrc-fields-1">
          <name>RTP Packet with empty 2-byte header extension Empty Two-Byte Header Extension and CSRC fields</name> Fields</name>
          <t>RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f123b
    decafbad
    cafebabe
    0001e240
    0000b26e
    10000000
    abababab
    abababab
    abababab
    abababab
]]></artwork>
]]></sourcecode>
          <t>Encrypted RTP Packet:</t>
          <artwork><![CDATA[
          <sourcecode type="test-vectors"><![CDATA[
    920f123b
    decafbad
    cafebabe
    dcb38c9e
    48bf95f4
    c2de0000
    61ee432c
    f9203170
    76613258
    d3ce4236
    c06ac429
    681ad084
    13512dc9
    8b5207d8
]]></artwork>
]]></sourcecode>
        </section>
      </section>
    </section>

    <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>
  <!-- ##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

-->

</rfc>