<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-core-echo-request-tag-14" number="9175" category="std" consensus="true" updates="7252" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title abbrev="Echo, Request-Tag, and Token Processing">CoAP: Processing">Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-core-echo-request-tag-14"/> name="RFC" value="9175"/>
    <author initials="C." surname="Amsuess" surname="Amsüss" fullname="Christian Amsüss">
      <organization/>
      <address>
        <email>christian@amsuess.com</email>
      </address>
    </author>
    <author initials="J." surname="Mattsson" surname="Preuß Mattsson" fullname="John Preuß Mattsson">
      <organization>Ericsson AB</organization>
      <address>
        <email>john.mattsson@ericsson.com</email>
      </address>
    </author>
    <author initials="G." surname="Selander" fullname="Göran Selander">
      <organization>Ericsson AB</organization>
      <address>
        <email>goran.selander@ericsson.com</email>
      </address>
    </author>
    <date year="2021" month="October" day="04"/> year="2022" month="February"/>
    <area>General</area>
    <workgroup>CoRE Working Group</workgroup>

    <keyword>OSCORE</keyword>
    <keyword>block-wise</keyword>
    <keyword>DTLS</keyword>
    <keyword>freshness</keyword>
    <keyword>delay</keyword>
    <keyword>denial-of-service</keyword>
    <keyword>amplification</keyword>
    <keyword>Message Body Integrity</keyword>
    <keyword>Concurrent Block-Wise</keyword>
    <keyword>Request-Response Binding</keyword>
    <keyword>Token Reuse</keyword>

    <abstract>
      <t>This document specifies enhancements to the Constrained Application Protocol
      (CoAP) that mitigate security issues in particular use cases. The Echo option enables
      a CoAP server to verify the freshness of a request or to force a client to
      demonstrate reachability at its claimed network address. The Request-Tag option
      allows the CoAP server to match block-wise message fragments belonging to the same
      request. This document updates RFC 7252 with respect to the client Token following: processing requirements,
      requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding of response to request when CoAP is used with a security protocol, and with respect to
      amplification mitigation, where mitigation (where the use of the Echo option is now recommended.</t> recommended).</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
  CORE Working Group mailing list (core@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/core/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/core-wg/echo-request-tag"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The initial suite of specifications for the Constrained Application Protocol (CoAP) suite of specifications
      (<xref target="RFC7252" format="default"/>, <xref target="RFC7641"
      format="default"/>, and
      <xref target="RFC7959" format="default"/>) was designed with the assumption that
      security could be provided on a separate layer, in particular particular, by using DTLS (<xref <xref
      target="RFC6347" format="default"/>). format="default"/>. However, for some use cases, additional
      functionality or extra processing is needed to support secure CoAP operations. This
      document specifies security enhancements to the Constrained Application Protocol (CoAP).</t>
      <t>[ Note to RFC editor: If C321 gets published before C280,
then the <xref target="RFC6347" format="default"/> references can be upgraded to draft-ietf-tls-dtls13-43 without the need for further changes;
the reference is to 6347 here because that was the stable DTLS reference when the document was last touched by the authors. ]</t> CoAP.</t>
      <t>This document specifies two CoAP options, the Echo option and the Request-Tag option:
      option. The Echo option enables a CoAP server to verify the freshness of a request,
      which can be used to synchronize state, or to force a client to demonstrate
      reachability at its claimed network address. The Request-Tag option allows the CoAP
      server to match message fragments belonging to the same request, fragmented using the
      CoAP block-wise transfer mechanism, which mitigates attacks and enables concurrent
      block-wise operations. These options in themselves do not replace the need for a
      security protocol; they specify the format and processing of data which, that, when
      integrity protected using e.g. using, e.g., DTLS (<xref <xref target="RFC6347" format="default"/>), format="default"/>, TLS (<xref
      <xref target="RFC8446" format="default"/>), format="default"/>, or OSCORE (<xref Object Security for Constrained
      RESTful Environments (OSCORE) <xref target="RFC8613" format="default"/>),
      format="default"/>, provide the additional security features.</t>
      <t>This document updates <xref target="RFC7252" format="default"/> with a
      recommendation that servers use the Echo option to mitigate amplification attacks.</t>
      <t>The document also updates the Token processing requirements for clients specified
      in <xref target="RFC7252" format="default"/>. The updated processing forbids
      non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is
      used with security, thus mitigating error cases and attacks where the client may
      erroneously associate the wrong response to a request.</t>
      <t>Each of the following sections provides a more detailed more-detailed introduction to the topic
      at hand in its first subsection.</t>
      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <t>The
	<t>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
	  to be interpreted as
	  described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/>
	  target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
	  here.
	</t>
	<t>Like <xref target="RFC7252" format="default"/>, this document is relying relies
	on the Representational State Transfer <xref target="REST" format="default"/>
	architecture of the Web.</t>
        <t>Unless otherwise specified, the terms "client" and "server" refer to "CoAP
	client" and "CoAP server", respectively, as defined in <xref target="RFC7252" format="default"/>. The term "origin server" is used as in <xref target="RFC7252" format="default"/>. The term "origin client" is used in this document to denote the client from which a request originates; to distinguish from clients in proxies.</t>
	format="default"/>.</t>
        <t>A message's "freshness" is a measure of when a message was sent on a time scale timescale
	of the recipient. A server that receives a request can either verify that the
	request is fresh or determine that it cannot be verified that the request is fresh.
	What is considered a fresh message is application dependent;
	exemplary uses are "no more than one hour 42 seconds ago" or "after this server's last
	reboot".</t>
        <t>The terms "payload" and "body" of a message are used as in <xref
	target="RFC7959" format="default"/>.  The complete interchange of a request and a
	response body is called a (REST) "operation". An operation fragmented using <xref
	target="RFC7959" format="default"/> is called a "block-wise operation". A
	block-wise operation which that is fragmenting the request body is called a "block-wise
	request operation".  A block-wise operation which that is fragmenting the response body
	is called a "block-wise response operation".</t>
        <t>Two request messages are said to be "matchable" if they occur between the same
	endpoint pair, have the same code, and have the same set of options, with the
	exception that elective NoCacheKey options and options involved in block-wise
	transfer (Block1, Block2 Block2, and Request-Tag) need not be the same.
<!-- We could also keep the Request-Tag inside the matchable criterion, but then we'd be saying "matchable except for the Request-Tag" all over the document. -->
        Two blockwise request operations are said to be matchable if any of their request
	messages are.</t> are matchable.</t>
        <t>Two matchable block-wise request operations are said to be "concurrent" if a
	block of
	the second request is exchanged even though the client still intends to exchange
	further blocks in the first operation. (Concurrent block-wise request operations
	from a single endpoint are impossible with the options of <xref target="RFC7959"
	format="default"/> (see -- see the last paragraphs of Sections 2.4 <xref target="RFC7959"
	section="2.4" sectionFormat="bare"/> and 2.5) <xref target="RFC7959" section="2.5"
	sectionFormat="bare"/> -- because the second operation's block overwrites any state
	of the first exchange.).</t> exchange.)</t>
        <t>The Echo and Request-Tag options are defined in this document.</t>
      </section>
    </section>
    <section anchor="echo" numbered="true" toc="default">
      <name>Request Freshness and the Echo Option</name>
      <section anchor="req-fresh" numbered="true" toc="default">
        <name>Request Freshness</name>
        <t>A CoAP server receiving a request is is, in general general, not able to verify when the
	request was sent by the CoAP client. This remains true even if the request was
	protected with a security protocol, such as DTLS. This makes CoAP requests
	vulnerable to certain delay attacks which that are particularly perilous in the case of
	actuators (<xref <xref target="I-D.mattsson-core-coap-attacks" format="default"/>). format="default"/>. Some
	attacks can be mitigated by establishing fresh session keys, e.g. e.g., performing a DTLS
	handshake for each request, but but, in general general, this is not a solution suitable for
	constrained environments, for example, due to increased message overhead and
	latency. Additionally, if there are proxies, fresh DTLS session keys between the
	server
	and the proxy does do not say anything about when the client made the request. In a
	general hop-by-hop setting, freshness may need to be verified in each hop.</t>
        <t>A straightforward mitigation of potential delayed requests is that the CoAP
	server rejects a request the first time it appears and asks the CoAP client to
	prove that it intended to make the request at this point in time.</t>
      </section>
      <section anchor="the-echo-option" numbered="true" toc="default">
        <name>The Echo Option</name>
        <t>This document defines the Echo option, a lightweight challenge-response
	mechanism for CoAP that enables a CoAP server to verify the freshness of a request.
	A fresh request is one whose age has not yet exceeded the freshness requirements
	set by the server. The freshness requirements are application specific and may vary
	based on resource, method, and parameters outside of CoAP CoAP, such as policies. The
	Echo option value is a challenge from the server to the client included in a CoAP
	response and echoed back to the server in one or more CoAP requests.</t>
        <t>This mechanism is not only important in the case of actuators, or other use
	cases where the CoAP operations require freshness of requests, but also in general
	for synchronizing state between a CoAP client and server, cryptographically
	verifying
	the aliveness of the client, client or forcing a client to demonstrate reachability at its
	claimed network address. The same functionality can be provided by echoing
	freshness indicators in CoAP payloads, but this only works for methods and response
	codes defined to have a payload. The Echo option provides a convention to transfer
	freshness indicators that works for all methods and response codes.</t>
        <section anchor="echo-format" numbered="true" toc="default">
          <name>Echo Option Format</name>
          <t>The Echo Option option is elective, safe-to-forward, safe to forward, not part of the cache-key, and
	  not repeatable, see repeatable (see <xref target="echo-table" format="default"/>, which extends
	  Table 4 of <xref target="RFC7252" format="default"/>).</t>
          <figure anchor="echo-table">
          <table anchor="echo-table" align="left">
            <name>Echo Option Summary</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
+--------+---+---+---+---+-------------+--------+------+---------+
| No.    | C | U | N | R | Name        | Format | Len. | Default |
+--------+---+---+---+---+-------------+--------+------+---------+
| TBD252 |   |   | x |   | Echo        | opaque | 1-40 | (none)  |
+--------+---+---+---+---+-------------+--------+------+---------+

      C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
]]></artwork>
          </figure>
	    <thead>
	      <tr>
		<th>No.</th>
		<th>C</th>
		<th>U</th>
		<th>N</th>
		<th>R</th>
		<th>Name</th>
		<th>Format</th>
		<th>Length</th>
		<th>Default</th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>
		<td>252</td>
		<td></td>
		<td></td>
		<td>x</td>
		<td></td>
		<td>Echo</td>
		<td>opaque</td>
		<td>1-40</td>
		<td>(none)</td>
	      </tr>
	    </tbody>
	  </table>
	  <t>C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable</t>
          <t>The Echo option value is generated by a server, and its content and structure
	  are implementation specific. Different methods for generating Echo option values
	  are outlined in <xref target="echo-state" format="default"/>. Clients and
	  intermediaries MUST <bcp14>MUST</bcp14> treat an Echo option value as opaque and make
	  no assumptions about its content or structure.</t>
          <t>When receiving an Echo option in a request, the server MUST <bcp14>MUST</bcp14> be
	  able to verify that the Echo option value (a) was generated by the server or some
	  other party that the server trusts, trusts and (b) fulfills the freshness requirements
	  of the application. Depending on the freshness requirements requirements, the server may verify
	  exactly when the Echo option value was generated (time-based freshness) or verify
	  that the Echo option was generated after a specific event (event-based
	  freshness). As the request is bound to the Echo option value, the server can
	  determine that the request is not older that than the Echo option value.</t>
          <t>When the Echo option is used with OSCORE <xref target="RFC8613" format="default"/>
	  format="default"/>, it MAY <bcp14>MAY</bcp14> be an Inner or Outer option, and the
	  Inner and Outer values are independent. OSCORE servers MUST <bcp14>MUST</bcp14> only
	  produce Inner Echo options unless they are merely testing for reachability of the
	  client (the same as proxies may do). The Inner option is encrypted and integrity
	  protected between the endpoints, whereas the Outer option is not protected by
	  OSCORE. As always with OSCORE, outer Outer options are visible to (and may be acted on
	  by) all proxies, proxies and are visible on all links where no additional encryption
	  (like TLS between client and proxy) is used.</t>
        </section>
      </section>
      <section anchor="echo-proc" numbered="true" toc="default">
        <name>Echo Processing</name>
        <t>The Echo option MAY <bcp14>MAY</bcp14> be included in any request or response (see
	<xref target="echo-app" format="default"/> for different applications).</t>
        <t>The application decides under what conditions a CoAP request to a resource is
	required to be fresh. These conditions can can, for example example, include what resource is
	requested, the request method and other data in the request, and conditions in the environment
	environment, such as the state of the server or the time of the day.</t>
        <t>If a certain request is required to be fresh, the request does not contain a
	fresh Echo option value, and the server cannot verify the freshness of the request
	in some other way, the server MUST NOT <bcp14>MUST NOT</bcp14> process the request further
	and SHOULD <bcp14>SHOULD</bcp14> send a 4.01 Unauthorized (Unauthorized) response with an Echo option.
	The server MAY <bcp14>MAY</bcp14> include the same Echo option value in several
	different response messages and to different clients. Examples of this could be
	time-based freshness when (when several responses are sent closely after each other other) or
	event-based freshness with (with no event taking place between the responses.</t> responses).</t>
        <t>The server may use request freshness provided by the Echo option to verify the
	aliveness of a client or to synchronize state. The server may also include the Echo
	option in a response to force a client to demonstrate reachability at its claimed
	network address. Note that the Echo option does not bind a request to any
	particular previous response, response but provides an indication that the client had access
	to the previous response at the time when it created the request.</t>
        <t>Upon receiving a 4.01 Unauthorized (Unauthorized) response with the Echo option, the client SHOULD
	<bcp14>SHOULD</bcp14> resend the original request with the addition of an Echo
	option with the received Echo option value. The client MAY <bcp14>MAY</bcp14> send a
	different request compared to the original request. Upon receiving any other
	response with the Echo option, the client SHOULD <bcp14>SHOULD</bcp14> echo the Echo
	option value in the next request to the server. The client MAY <bcp14>MAY</bcp14>
	include the same Echo option value in several different requests to the server, server or
	discard it at any time (especially to avoid tracking, tracking; see <xref target="priv-cons"
	format="default"/>).</t>
        <t>A client MUST <bcp14>MUST</bcp14> only send Echo option values to endpoints it
	received them
	from (where (where, as defined in <xref target="RFC7252" format="default"/> Section 1.2, section="1.2"
	sectionFormat="of"/>, the security association is part of the endpoint). In
	OSCORE processing, that means sending Echo option values from Outer options (or
	from non-OSCORE responses) back in Outer options, options and sending those from Inner
	options in Inner options in the same security context.</t>
        <t>Upon receiving a request with the Echo option, the server determines if the
	request is required to be fresh. If not, the Echo option MAY <bcp14>MAY</bcp14> be
	ignored. If the request is required to be fresh and the server cannot verify the
	freshness of the request in some other way, the server MUST <bcp14>MUST</bcp14> use the
	Echo option to verify that the request is fresh. If the server cannot verify that
	the request is fresh, the request is not processed further, and an error message MAY
	<bcp14>MAY</bcp14> be sent. The error message SHOULD <bcp14>SHOULD</bcp14> include a new
	Echo option.</t>
        <t>One way for the server to verify freshness is to bind the Echo option value to a
	specific point in time and verify that the request is not older than a certain
	threshold T. The server can verify this by checking that (t1 - t0) &lt; T, where t1
	is the request receive time and t0 is the time when the Echo option value was
	generated. An example message flow over DTLS is shown <xref
	target="echo-figure-time" format="default"/>.</t>
        <figure anchor="echo-figure-time">
          <name>Example Message Flow for Time-Based Freshness using Using the 'Integrity Protected
	  'Integrity&nbhy;Protected Timestamp' construction Construction of Appendix A</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
Client   Server
   |       |
   +------>|        Code: 0.03 (PUT)
   |  PUT  |       Token: 0x41
   |       |    Uri-Path: lock
   |       |     Payload: 0 (Unlock)
   |       |
   |<------+        Code: 4.01 (Unauthorized)
   |  4.01 |       Token: 0x41
   |       |        Echo: 0x00000009437468756c687521 (t0 = 9, +MAC)
   |       |
   | ...   | The round trips take 1 second, time is now t1 = 10.
   |       |
   +------>|        Code: 0.03 (PUT)
   |  PUT  |       Token: 0x42
   |       |    Uri-Path: lock
   |       |        Echo: 0x00000009437468756c687521 (t0 = 9, +MAC)
   |       |     Payload: 0 (Unlock)
   |       |
   |       | Verify MAC, compare t1 - t0 = 1 < T => permitted.
   |       |
   |<------+        Code: 2.04 (Changed)
   |  2.04 |       Token: 0x42
   |       |
]]></artwork>
        </figure>

	<t>Another way for the server to verify freshness is to maintain a cache of values
	associated to events. The size of the cache is defined by the application. In the following
	following, we assume the cache size is 1, in which case case, freshness is defined as no
	"no new event has taken place. place". At each event event, a new value is written into the
	cache. The cache values MUST <bcp14>MUST</bcp14> be different except with negligible probability. or chosen in a way so the
	probability for collisions is negligible.
	The server verifies freshness by checking that e0 equals e1, where e0 is the cached
	value when the Echo option value was generated, and e1 is the cached value at the
	reception of the request. An example message flow over DTLS is shown in <xref
	target="echo-figure-event" format="default"/>.</t>
        <figure anchor="echo-figure-event">
          <name>Example Message Flow for Event-Based Freshness using Using the 'Persistent
	  Counter' construction Construction of Appendix A</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
Client   Server
   |       |
   +------>|        Code: 0.03 (PUT)
   |  PUT  |       Token: 0x41
   |       |    Uri-Path: lock
   |       |     Payload: 0 (Unlock)
   |       |
   |<------+        Code: 4.01 (Unauthorized)
   |  4.01 |       Token: 0x41
   |       |        Echo: 0x05 (e0 = 5, number of total lock
   |       |                            operations performed)
   |       |
   | ...   | No alterations happen to the lock state, e1 has the
   |       | same value e1 = 5.
   |       |
   +------>|        Code: 0.03 (PUT)
   |  PUT  |       Token: 0x42
   |       |    Uri-Path: lock
   |       |        Echo: 0x05
   |       |     Payload: 0 (Unlock)
   |       |
   |       | Compare e1 = e0 => permitted.
   |       |
   |<------+        Code: 2.04 (Changed)
   |  2.04 |       Token: 0x42
   |       |        Echo: 0x06 (e2 = 6, to allow later locking
   |       |                            without more round-trips) round trips)
   |       |
]]></artwork>
        </figure>
        <t>When used to serve freshness requirements (including client aliveness and state
	synchronizing), the Echo option value MUST <bcp14>MUST</bcp14> be integrity protected
	between the intended endpoints, e.g. e.g., using DTLS, TLS, or an OSCORE Inner option (<xref
	<xref target="RFC8613" format="default"/>). format="default"/>.
	When used to demonstrate reachability
	at a claimed network address, the Echo option SHOULD <bcp14>SHOULD</bcp14> be a MAC Message
	Authentication Code (MAC) of the
	claimed address, address but MAY <bcp14>MAY</bcp14> be unprotected. Combining different Echo
	applications can necessitate different choices, choices; see <xref target="echo-state" format="default"/>
	format="default"/>, item 2 for an example.</t>
        <t>An Echo option MAY <bcp14>MAY</bcp14> be sent with a successful response, i.e., even though
	the request satisfied any freshness requirements on the operation. This is called a
	"preemptive" Echo value, option value and is useful when the server anticipates that the client
	will need to demonstrate freshness relative to the current response in the near future.</t>
	<t>A CoAP-to-CoAP proxy MAY <bcp14>MAY</bcp14> set an Echo option on responses, both on
	forwarded ones that had no Echo option or ones generated by the proxy (from cache
	or as an error). If it does so, it MUST <bcp14>MUST</bcp14> remove the Echo option it
	recognizes as one generated by itself on follow-up requests. When it receives an
	Echo option in a response, it MAY <bcp14>MAY</bcp14> forward it to the client (and, not
	recognizing it as an its own in future requests, relay it in the other direction as
	well) or process it on its own. If it does so, it MUST <bcp14>MUST</bcp14> ensure that
	the client's request was generated (or is re-generated) regenerated) after the Echo option value
	used
	to send to the server was first seen. (In most cases, this means that the proxy
	needs to ask the client to repeat the request with a new Echo option value.)</t>
	<t>The CoAP server side of CoAP-to-HTTP proxies MAY <bcp14>MAY</bcp14> request
	freshness, especially if they have reason to assume that access may require it (e.g.
	(e.g., because it is a PUT or POST); how this is determined is out of scope for this
	document. The CoAP client side of HTTP-to-CoAP proxies MUST <bcp14>MUST</bcp14> respond
	to Echo challenges itself if the proxy knows from the recent establishing of the
	connection that the HTTP request is fresh. Otherwise, it MUST NOT <bcp14>MUST NOT</bcp14>
	repeat an unsafe request and SHOULD <bcp14>SHOULD</bcp14> respond with a 503 Service Unavailable, Retry-After: (Service
	Unavailable) with a Retry-After value of 0 seconds and terminate any underlying
	Keep-Alive connection. If
	the HTTP request arrived in Early Data, early data, the proxy SHOULD <bcp14>SHOULD</bcp14> use a 425 Too Early
	(Too Early) response instead (see <xref target="RFC8470" format="default"/>). They MAY The
	proxy <bcp14>MAY</bcp14> also use other mechanisms to establish freshness of the
	HTTP request that are not specified here.</t>
      </section>
      <section anchor="echo-app" numbered="true" toc="default">
        <name>Applications of the Echo Option</name>
        <t>Unless otherwise noted, all these applications require a security protocol to be used,
	used and the Echo option to be protected by it.</t>
        <ol spacing="normal" type="1">
          <li>
            <t>Actuation requests often require freshness guarantees to avoid accidental or
	    malicious delayed actuator actions. In general, all non-safe unsafe methods (e.g. (e.g.,
	    POST, PUT, and DELETE) may require freshness guarantees for secure operation.
	    </t>
            <ul spacing="normal">
              <li>The same Echo option value may be used for multiple actuation requests
	      to the
	      same server, as long as the total time since the Echo option value was
	      generated is below the freshness threshold.</li>
              <li>For actuator applications with low delay tolerance, to avoid additional round-trips
	      round trips for multiple requests in rapid sequence, the server may send
	      preemptive Echo option values in successful requests, irrespectively of
	      whether or not the
	      request contained an Echo option or not. option. The client then uses the Echo option
	      with the new value in the next actuation request, and the server compares the
	      receive time accordingly.</li>
            </ul>
          </li>
          <li>
            <t>A server may use the Echo option to synchronize properties (such as state or
	    time) with a requesting client. A server MUST NOT <bcp14>MUST NOT</bcp14> synchronize a
	    property with a client which that is not the authority of the property being
	    synchronized. E.g. For example, if access to a server resource is dependent on time,
	    then the server MUST NOT <bcp14>MUST NOT</bcp14> synchronize time with a client
	    requesting access unless the client is a time authority for the server. </t>
            <t>
Note
            <t>Note that the state to be synchronized is not carried inside the Echo option.
	    Any explicit state information needs to be carried along in the messages the
	    Echo option value is sent in; the Echo mechanism only provides a partial order
	    on the messages' processing.  </t>
            <ul spacing="normal">
              <li>If a server reboots during operation operation, it may need to synchronize
	      state or
	      time before continuing the interaction. For example, with OSCORE OSCORE, it is
	      possible to reuse a partly persistently stored security context by
	      synchronizing the Partial IV (sequence number) using the Echo option option, as
	      specified in Section 7.5 of <xref target="RFC8613" format="default"/>.</li> sectionFormat="of" section="7.5"/>.</li>
              <li>A device joining a CoAP group communication <xref
	      target="I-D.ietf-core-groupcomm-bis" format="default"/> protected with OSCORE
	      <xref target="I-D.ietf-core-oscore-groupcomm" format="default"/> may be
	      required to initially synchronize its replay window state with a client by
	      using the Echo option in a unicast response to a multicast request. The
	      client receiving the response with the Echo option includes the Echo option
	      value in a subsequent unicast request to the responding server.</li>
            </ul>
          </li>
          <li>
            <t>An attacker can perform a denial-of-service attack by putting a victim's
	    address in the source address of a CoAP request and sending the request to a
	    resource with a large amplification factor. The amplification factor is the
	    ratio between the size of the request and the total size of the response(s) to
	    that request. A server that provides a large amplification factor to an
	    unauthenticated peer SHOULD <bcp14>SHOULD</bcp14> mitigate amplification attacks attacks, as
	    described in Section 11.3 of <xref target="RFC7252" format="default"/>. sectionFormat="of" section="11.3"/>. One way
	    to mitigate such attacks is that for the server responds to respond to the alleged source
	    address of the request with an Echo option in a short response message (e.g. (e.g.,
	    4.01 Unauthorized), (Unauthorized)), thereby requesting the client to verify its source
	    address. This
	    needs to be done only once per endpoint and limits the range of potential
	    victims from the general Internet to endpoints that have been previously in
	    contact with the server. For this application, the Echo option can be used in
	    messages that are not integrity protected, for example example, during discovery. (This
	    is formally recommended in <xref target="ampl-mit" format="default"/>).  </t> format="default"/>.)</t>
            <ul spacing="normal">
              <li>In the presence of a proxy, a server will not be able to distinguish
	      different origin client endpoints. endpoints, i.e., the client from which a request
	      originates. Following from the recommendation above, a
	      proxy that provides a large amplification factor to unauthenticated peers SHOULD
	      <bcp14>SHOULD</bcp14> mitigate amplification attacks. The proxy SHOULD
	      <bcp14>SHOULD</bcp14> use the Echo option to verify origin reachability reachability, as
	      described in
	      <xref target="echo-proc" format="default"/>. The proxy MAY <bcp14>MAY</bcp14>
	      forward safe requests immediately to have a cached result available when the
	      client's repeated request arrives.</li>
              <li>
                <t>Amplification mitigation is a trade-off between giving leverage to an
		attacker and causing overhead. An amplification factor of 3 (i.e., don't
		send more than three times the number of bytes received until the peer's
		address is confirmed) is considered acceptable for unconstrained
		applications in <xref target="RFC9000" format="default"/> Section 8.      </t>
                <t>
When sectionFormat="comma"
		section="8"/>.</t>
		<t>When that limit is applied and no further context is available, a safe
		default is sending initial responses no larger than 136 Bytes bytes in CoAP
		serialization. (The number is assuming a 14 + 40 + 8 Bytes Ethernet, IP IP, and UDP header headers of
		14, 40, and 8 bytes, respectively, with 4 Bytes bytes added for the CoAP header.
		Triple that minus the
		non-CoAP headers gives the 136 Bytes). bytes.) Given the token also takes up space
		in the request, responding with 132 Bytes bytes after the token is safe as
		well.</t>
              </li>
              <li>When an Echo response is sent to mitigate amplification, it MUST
	      <bcp14>MUST</bcp14> be sent as a piggybacked or Non-confirmable response,
	      never as a separate one (which would cause amplification due to
	      retransmission).</li>
            </ul>
          </li>
          <li>A server may want to use the request freshness provided by the Echo option
	  to verify the aliveness of a client. Note that that, in a deployment with hop-by-hop
	  security and proxies, the server can only verify aliveness of the closest
	  proxy.</li>
        </ol>
      </section>
      <section anchor="characterization-of-echo-applications" numbered="true" toc="default">
        <name>Characterization of Echo Applications</name>
        <t>Use cases for the Echo option can be characterized by several criteria that help
	determine the required properties of the Echo option value. These criteria apply
	both to those listed in <xref target="echo-app" format="default"/> and any novel
	applications. They provide rationale for the statements in the former, former and guidance
	for the latter.</t>
        <section anchor="time-versus-event-based-freshness" numbered="true" toc="default">
          <name>Time
          <name>Time-Based versus Event Based Event-Based Freshness</name>
          <t>The property a client demonstrates by sending an Echo option value is that the
	  request was sent after a certain point in time, time or after some event happened on
	  the server.</t>
          <t>When events are counted, they form something that can be used as a monotonic
	  but very non-uniform time line. With highly regular events and low-resolution
	  time, the distinction between time time-based and event based event-based freshness can be blurred:
"No
	  "no longer than a month ago" is similar to "since the last full moon".</t>
          <t>In an extreme form of event based event-based freshness,
	  the server can place an event whenever an Echo option value is used.
	  This makes the Echo option value effectively single-use.</t>
          <t>Event single use.</t>
          <t>Event-based and time based time-based freshness can be combined in a single Echo option
	  value,
e.g.
	  e.g., by encrypting a timestamp with a key that changes with every event
	  to obtain semantics in the style of "usable once but only for 5 minutes"-style semantics.</t> minutes".</t>
        </section>
        <section anchor="source-of-truth" numbered="true" toc="default">
          <name>Authority over Used Information</name>
          <t>Information conveyed to the server in the request Echo option value has
	  different
	  authority depending on the application. Understanding who or what is the
	  authoritative source of that information helps the server implementer implementor decide the
	  necessary protection of the Echo option value.</t>
          <t>If all that is conveyed to the server is information which that the client is
	  authorized to provide arbitrarily, arbitrarily (which is another way of saying that the
	  server has to trust the client on whatever the Echo option is being used for),
	  then the server can issue Echo option values that do not need to be protected on
	  their own. They still need to be covered by the security protocol that covers
	  the rest of the message, but the Echo option value can be just short enough to
	  be unique between this server and client.</t>
          <t>For example, the client's OSCORE sender sequence number Sender Sequence Number (as used in <xref
	  target="RFC8613" format="default"/> Appendix B.1.2) sectionFormat="comma" section="B.1.2"/>) is such information.</t>
          <t>In most other cases, there is information conveyed for which the server is the
	  authority
("The ("the request must not be older than five minutes" is counted on the
	  server's clock, not the client's) or which even involve the network (as when
	  performing amplification mitigation). In these cases, the Echo option value
	  itself needs
	  to be protected against forgery by the client,
e.g. e.g., by using a sufficiently large
	  large, random value or a MAC MAC, as described in <xref target="echo-state" format="default"/>
	  format="default"/>, items 1 and 2.</t>
          <t>For some applications, the server may be able to trust the client to also act
	  as the authority
(e.g. (e.g., when using time based time-based freshness purely to mitigate request
	  delay attacks); these need careful case-by-case evaluation.
<!-- RD's registration state is an example; RD may need to provide that evaluation now. -->
          </t>

	  <t>To issue Echo option values without own protection, integrity protection of its own, the server needs to trust the
	  client to never produce requests with attacker controlled attacker-controlled Echo option values.
	  The provisions of <xref target="echo-proc" format="default"/> (saying that an
	  Echo option value may only be sent as received from the same server) allow that.
	  The requirement stated there for the client to treat the Echo option value as
	  opaque
	  holds for these application applications like for all others.</t>
          <t>When the client is the sole authority over the synchronized property,
	  the server can still use time or events to issue new Echo option values.
	  Then, the request's Echo option value not so much proves the indicated freshness
	  to the server,
	  server but reflects the client's intention to indicate reception of responses
	  containing that value when sending the later ones.</t>
          <t>Note that a single Echo option value can be used for multiple purposes
(e.g. (e.g.,
	  to get both get
	  the sequence number information and perform amplification mitigation). In
	  this case case, the stricter protection requirements apply.</t>
        </section>
        <section anchor="protection-by-a-security-protocol" numbered="true" toc="default">
          <name>Protection by a Security Protocol</name>
          <t>For meaningful results, the Echo option needs to be used in combination with a
	  security protocol in almost all applications.</t>
          <t>When the information extracted by the server is only about a part of the
	  system outside of any security protocol, then the Echo option can also be used
	  without a security protocol (in case of OSCORE, as an outer Outer option).</t>
          <t>The only known application satisfying this requirement is network address
	  reachability, where unprotected Echo option values are used both by servers (e.g.
	  (e.g., during
	  setup of a security context) and proxies (which do not necessarily have a
	  security association with their clients) for amplification mitigation.</t>
        </section>
      </section>
      <section anchor="ampl-mit" numbered="true" toc="default">
        <name>Updated Amplification Mitigation Requirements for Servers</name>
        <t>This section updates the amplification mitigation requirements for servers in
	<xref target="RFC7252" format="default"/> to recommend the use of the Echo option to
	mitigate amplification attacks. The requirements for clients are not updated. Section 11.3 of <xref
	target="RFC7252" format="default"/> sectionFormat="of" section="11.3"/> is updated by adding the
	following text:</t>
        <t>A
        <blockquote>A CoAP server SHOULD <bcp14>SHOULD</bcp14> mitigate potential amplification
	attacks by responding to unauthenticated clients with 4.01 Unauthorized (Unauthorized) including
	an Echo option, as described in item 3 in <xref target="echo-app"
	format="default"/> item 3 of [[this document]].</t> RFC 9175.</blockquote>
      </section>
    </section>
    <section anchor="request-tag" numbered="true" toc="default">
      <name>Protecting Message Bodies using Using Request Tags</name>
      <section anchor="body-int" numbered="true" toc="default">
        <name>Fragmented Message Body Integrity</name>
        <t>CoAP was designed to work over unreliable transports, such as UDP, and includes
	a lightweight reliability feature to handle messages which that are lost or arrive out
	of order. In order for a security protocol to support CoAP operations over
	unreliable transports, it must allow out-of-order delivery of messages.</t>

	<t>The block-wise transfer mechanism <xref target="RFC7959" format="default"/>
	extends CoAP by defining the transfer of a large resource representation (CoAP
	message body) as a sequence of blocks (CoAP message payloads). The mechanism uses a
	pair of CoAP options, Block1 and Block2, pertaining to the request and response
	payload, respectively. The block-wise functionality does not support the detection
	of interchanged blocks between different message bodies to the same resource having
	the same block number. This remains true even when CoAP is used together with a
	security protocol such (such as DTLS or OSCORE, OSCORE) within the replay window (<xref <xref
	target="I-D.mattsson-core-coap-attacks" format="default"/>), format="default"/>, which is a
	vulnerability of the block-wise functionality of CoAP when using RFC7959.</t> <xref target="RFC7959" format="default"/>.</t>
        <t>A straightforward mitigation of mixing up blocks from different messages is to
	use unique identifiers for different message bodies, which would provide equivalent
	protection to the case where the complete body fits into a single payload. The ETag
	option <xref target="RFC7252" format="default"/>, set by the CoAP server,
	identifies a response body fragmented using the Block2 option.</t>
      </section>
      <section anchor="the-request-tag-option" numbered="true" toc="default">
        <name>The Request-Tag Option</name>
        <t>This document defines the Request-Tag option for identifying request bodies,
	similar to ETag, but ephemeral and set by the CoAP client. The Request-Tag is
	intended for use as a short-lived identifier for keeping apart distinct block-wise
	request operations on one resource from one client, addressing the issue described
	in <xref target="body-int" format="default"/>. It enables the receiving server to
	reliably assemble request payloads (blocks) to their message bodies, bodies and, if it
	chooses to support it, to reliably process simultaneous block-wise request
	operations on a single resource. The requests must be integrity protected if they
	should protect against interchange of blocks between different message bodies. The
	Request-Tag option is only mainly used in requests that carry the Block1 option, option and in
	Block2 requests following these.</t>
        <t>In essence, it is an implementation of the "proxy-safe elective option" used
	just to "vary the cache key" key", as suggested in <xref target="RFC7959" format="default"/> Section 2.4.</t>
	sectionFormat="comma" section="2.4"/>.</t>
        <section anchor="req-tag-format" numbered="true" toc="default">
          <name>Request-Tag Option Format</name>
          <t>The Request-Tag option is not critical, is elective, safe to forward, repeatable, and
	  part of the cache key, see key (see <xref target="req-tag-table" format="default"/>, which
	  extends Table 4 of <xref target="RFC7252" format="default"/>).</t>
          <figure anchor="req-tag-table">
          <table anchor="req-tag-table" align="left">
            <name>Request-Tag Option Summary</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
+--------+---+---+---+---+-------------+--------+------+---------+
| No.    | C | U | N | R | Name        | Format | Len. | Default |
+--------+---+---+---+---+-------------+--------+------+---------+
| TBD292 |   |   |   | x | Request-Tag | opaque |  0-8 | (none)  |
+--------+---+---+---+---+-------------+--------+------+---------+

      C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
]]></artwork>
          </figure>
	    <thead>
	      <tr>
		<th>No.</th>
		<th>C</th>
		<th>U</th>
		<th>N</th>
		<th>R</th>
		<th>Name</th>
		<th>Format</th>
		<th>Length</th>
		<th>Default</th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>
		<td>292</td>
		<td></td>
		<td></td>
		<td></td>
		<td>x</td>
		<td>Request-Tag</td>
		<td>opaque</td>
		<td>0-8</td>
		<td>(none)</td>
	      </tr>
	    </tbody>
	  </table>
	  <t>C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable</t>
          <t>Request-Tag, like the block Block options, is both a class E and a class U option in
	  terms of OSCORE processing (see Section 4.1 of <xref target="RFC8613" format="default"/>): sectionFormat="of"
	  section="4.1"/>). The Request-Tag MAY <bcp14>MAY</bcp14> be an Inner or Outer option.
	  It influences the Inner or Outer block operation, operations, respectively. The Inner and
	  Outer values are therefore independent of each other. The Inner option is
	  encrypted and integrity protected between the client and server, and it provides
	  message
	  body identification in case of end-to-end fragmentation of requests. The Outer
	  option is visible to proxies and labels message bodies in case of hop-by-hop
	  fragmentation of requests.</t>
          <t>The Request-Tag option is only used in the request messages of block-wise
	  operations.</t>

	  <t>The Request-Tag mechanism can be applied independently on the server and
	  client sides of CoAP-to-CoAP proxies proxies, as are the block options,
though Block options. However, given it
	  is safe to forward, a proxy is free to just forward it when processing an
	  operation.
	  CoAP-to-HTTP proxies and HTTP-to-CoAP proxies can use Request-Tag on their CoAP
	  sides; it is not applicable to HTTP requests.</t>
        </section>
      </section>
      <section anchor="request-tag-processing" numbered="true" toc="default">
        <name>Request-Tag Processing by Servers</name>
	<t>The Request-Tag option does not require any particular processing on the server
	side outside of the processing already necessary for any unknown elective
	proxy-safe cache-key option: option. The option varies the properties that distinguish
	block-wise operations (which includes all options except elective NoCacheKey and except Block1/2), Block1, Block2, and thus all
	operations that are elective NoCacheKey). Thus, the server cannot treat messages
	with a different list of Request-Tag options as belonging to the same operation.
<!-- not speaking of "matchable" here as that working definition explicitly excludes Request-Tag to make the rest of the document easier to read -->
        </t>
        <t>To keep utilizing the cache, a server (including proxies) MAY <bcp14>MAY</bcp14>
	discard the Request-Tag option from an assembled block-wise request when consulting
	its cache, as the option relates to the operation-on-the-wire operation on the wire and not its semantics.
	For example, a FETCH request with the same body as an older one can be served from
	the cache if the older's Max-Age has not expired yet, even if the second operation
	uses a Request-Tag and the first did not. (This is similar to the situation about
	ETag in that it is formally part of the cache key, but implementations that are
	aware of its meaning can cache more efficiently,
see efficiently (see <xref target="RFC7252" format="default"/> Section 5.4.2).</t>
	sectionFormat="comma" section="5.4.2"/>).</t>
        <t>A server receiving a Request-Tag MUST <bcp14>MUST</bcp14> treat it as opaque and make
	no assumptions about its content or structure.</t>

	<t>Two messages carrying the same Request-Tag is a necessary but not sufficient
	condition for being part of the same operation. For one, a server may still treat
	them as independent messages when it sends 2.01/2.04 2.01 (Created) and 2.04 (Changed)
	responses for every block.
	Also, a client that lost interest in an old operation but wants to start over can
	overwrite the server's old state with a new initial (num=0) Block1 request and the
	same Request-Tag under some circumstances. Likewise, that results in the new
	message not being part of the old operation.</t>
        <t>As it has always been, a server that can only serve a limited number of
	block-wise operations at the same time can delay the start of the operation by
	replying with 5.03 (Service unavailable) Unavailable) and a Max-Age indicating how long it
	expects the existing operation to go on, or it can forget about the state
	established with the older operation and respond with 4.08 (Request Entity
	Incomplete) to later blocks on the first operation.</t>
      </section>
      <section anchor="setting-the-request-tag" numbered="true" toc="default">
        <name>Setting the Request-Tag</name>
        <t>For each separate block-wise request operation, the client can choose a
	Request-Tag value, value or choose not to set a Request-Tag. It needs to be set to the
	same value (or unset) in all messages belonging to the same operation,
as otherwise operation; otherwise,
	they are treated as separate operations by the server.</t>
        <t>Starting a request operation matchable to a previous operation and even using
	the same Request-Tag value is called request "request tag recycling. recycling". The absence of a
	Request-Tag option is viewed as a value distinct from all values with a single
	Request-Tag option set; starting a request operation matchable to a previous
	operation where neither has a Request-Tag option therefore constitutes request tag
	recycling just as well (also called "recycling the absent option").</t>
        <t>Clients that use Request-Tag for a particular purpose (like in <xref
	target="req-tag-applications" format="default"/>) MUST NOT <bcp14>MUST NOT</bcp14> recycle a
	request tag unless the first operation has concluded. What constitutes a
	concluded
	operation depends on the purpose, purpose and is defined accordingly; see examples in <xref
	target="req-tag-applications" format="default"/>.</t>
        <t>When Block1 and Block2 are combined in an operation, the Request-Tag of the
	Block1 phase is set in the Block2 phase as well
for otherwise well; otherwise, the request would
	have a different set of options and would not be recognized any more.</t>
        <t>Clients are encouraged to generate compact messages. This means sending messages
	without Request-Tag options whenever possible, possible and using short values when the
	absent option cannot be recycled.</t>
        <t>Note that Request-Tag options can be present in request messages that carry no
	Block option options (for example, because a Request-Tag unaware proxy unaware of Request-Tag reassembled them),
and MUST be ignored in those.</t> them).</t>
        <t>The Request-Tag option MUST NOT <bcp14>MUST NOT</bcp14> be present in response
	messages.</t>
      </section>
      <section anchor="req-tag-applications" numbered="true" toc="default">
        <name>Applications of the Request-Tag Option</name>
        <section anchor="body-integrity" numbered="true" toc="default">
          <name>Body Integrity Based on Payload Integrity</name>
          <t>When a client fragments a request body into multiple message payloads, even if
	  the individual messages are integrity protected, it is still possible for an
	  attacker to maliciously replace a later operation's blocks with an earlier
	  operation's blocks (see Section 2.5 of <xref target="I-D.mattsson-core-coap-attacks" format="default"/>).
	  sectionFormat="of" section="2.5"/>). Therefore, the integrity protection of each
	  block does not extend to the operation's request body.</t>
          <t>In order to gain that protection, use the Request-Tag mechanism as follows:</t>
          <ul spacing="normal">
            <li>The individual exchanges MUST <bcp14>MUST</bcp14> be integrity protected end-to-end
	    end to end between the client and server.</li>
            <li>
              <t>The client MUST NOT <bcp14>MUST NOT</bcp14> recycle a request tag in a new
	      operation unless the <!-- or "all", but by this rule there can only be one --> previous operation matchable to the new one has concluded.  </t>
              <t>
If

              <t>If any future security mechanisms allow a block-wise transfer to continue
	      after an endpoint's details (like the IP address) have changed, then
	      the client MUST <bcp14>MUST</bcp14> consider messages matchable if they were sent
	      to <em>any</em> any endpoint address using the new operation's security
	      context.</t>
            </li>
            <li>
              <t>The client MUST NOT <bcp14>MUST NOT</bcp14> regard a block-wise request operation
	      as concluded unless all of the messages the client has sent in the operation
	      would be regarded as invalid by the server if they were replayed.  </t>
              <t>
When replayed.</t>
              <t>When security services are provided by OSCORE, these confirmations
	      typically result either from the client receiving an OSCORE response message
	      matching the request (an empty ACK Acknowledgement (ACK) is insufficient), insufficient) or
	      because the message's
	      sequence number is old enough to be outside the server's receive window.  </t>
              <t>
When window.</t>
              <t>When security services are provided by DTLS, this can only be confirmed if
	      there was no CoAP retransmission of the request, the request was responded
	      to, and the server uses replay protection.</t>
            </li>
          </ul>
          <!-- pending see thread "ERT and OSCORE" -->
	  <t>Authors of other documents (e.g. (e.g., applications of <xref target="RFC8613"
	  format="default"/>) are invited to mandate this subsection's behavior for clients
	  that execute block-wise interactions over secured transports. In this way, the
	  server can rely on a conforming client to set the Request-Tag option when required,
	  required and thereby have confidence in the integrity of the assembled body.</t>
          <t>Note that this mechanism is implicitly implemented when the security layer
	  guarantees ordered delivery (e.g. (e.g., CoAP over TLS <xref target="RFC8323"
	  format="default"/>). This is because because, with each message, any earlier message
	  cannot be replayed any more, so the client never needs to set the Request-Tag
	  option unless it wants to perform concurrent operations.</t>
          <t>Body integrity only makes sense in applications that have stateful block-wise
	  transfers. On applications where all the state is in the application
(e.g. (e.g.,
	  because rather than POSTing a large representation to a collection in a stateful
	  block-wise transfer, a collection item is created first, then written to once and
	  available when written completely), clients need not concern themselves with body
	  integrity and thus the Request-Tag.</t>
          <t>Body integrity is largely independent from replay protection: protection. When no replay
	  protection is available (it is optional in DTLS), a full block-wise operation may
	  be replayed,
but but, by adhering to the above, no operations will be mixed up.
<!-- the other direction was covered already, see core-coap-attacks -->
	  The only link between body integrity and replay protection is that that, without replay
	  protection, recycling is not possible.</t>
        </section>
        <section anchor="multiple-concurrent-block-wise-operations" numbered="true"
		 toc="default">
          <name>Multiple Concurrent Block-wise Block-Wise Operations</name>
          <t>CoAP clients, especially CoAP proxies, may initiate a block-wise request
	  operation to a resource, to which a previous one is already in progress, which
	  the new request should not cancel. A CoAP proxy would be in such a situation when
	  it forwards operations with the same cache-key options but possibly different
	  payloads.</t>
          <t>For those cases, Request-Tag is the proxy-safe elective option suggested in
	  the last paragraph of
	  <xref target="RFC7959" format="default"/> Section 2.4 last paragraph.</t> sectionFormat="of" section="2.4"/>.</t>
          <t>When initializing a new block-wise operation, a client has to look at other
	  active operations:</t>
          <ul spacing="normal">
            <li>If any of them is matchable to the new one, and the client neither wants to
	    cancel the old one nor postpone the new one, it can pick a Request-Tag value
	    (including the absent option) that is not in use by the other matchable
	    operations for the new operation.</li>
            <li>Otherwise, it can start the new operation without setting the Request-Tag
	    option on it.</li>
          </ul>
        </section>
        <section anchor="simpleproxy" numbered="true" toc="default">
          <name>Simplified Block-Wise Handling for Constrained Proxies</name>
          <t>The Block options were defined to be unsafe to forward because a proxy that
	  would forward blocks as plain messages would risk mixing up clients' requests.</t>
          <t>In some cases, for example example, when forwarding block-wise request operations,
	  appending a Request-Tag value unique to the client can satisfy the requirements
	  on the proxy that come from the presence of a block Block option.</t>
          <t>This is particularly useful to proxies that strive for stateless operation operations,
	  as described in <xref target="RFC8974" format="default"/> Section 4.</t> sectionFormat="comma" section="4"/>.</t>
          <t>The precise classification of cases in which such a Request-Tag option is
	  sufficient is not trivial, especially when both request and response body are
	  fragmented, and is out of scope for this document.</t>
        </section>
      </section>
      <section anchor="rationale-for-the-option-properties" numbered="true" toc="default">
        <name>Rationale for the Option Properties</name>

	<t>The Request-Tag option can be elective, because to servers unaware of the
	Request-Tag option, operations with differing request tags will not be
	matchable.</t>
        <t>The Request-Tag option can be safe to forward but part of the cache key, because
	proxies unaware of the Request-Tag option will consider operations with differing
	request tags unmatchable but can still forward them.</t>
        <t>The Request-Tag option is repeatable because this easily allows several cascaded
	stateless proxies to each put in an origin address. They can perform the steps of
	<xref target="simpleproxy" format="default"/> without the need to create an option
	value that is the concatenation of the received option and their own value, value
	and can simply add a new Request-Tag option unconditionally.</t>
        <t>In draft versions of this document, the Request-Tag option used to be critical
	and unsafe to forward. That design was based on an erroneous understanding of which
	blocks could be composed according to <xref target="RFC7959" format="default"/>.</t>
      </section>
      <section anchor="rationale-for-introducing-the-option" numbered="true" toc="default">
        <name>Rationale for Introducing the Option</name>
        <t>An alternative that was considered to the Request-Tag option for coping with the
	problem of fragmented message body integrity (<xref target="body-integrity"
	format="default"/>) was to update <xref target="RFC7959" format="default"/> to say
	that blocks could only be assembled if their fragments' order corresponded to the
	sequence numbers.</t>
        <t>That approach would have been difficult to roll out reliably on DTLS DTLS,
	where many implementations do not expose sequence numbers, and would still not
	prevent attacks like in <xref target="I-D.mattsson-core-coap-attacks" format="default"/> Section 2.5.2.</t>
	sectionFormat="of" section="2.5.2"/>.</t>
      </section>
      <section anchor="etag" numbered="true" toc="default">
        <name>Block2 / and ETag Processing</name>
        <t>The same security properties as in <xref target="body-integrity"
	format="default"/> can be obtained for block-wise response operations. The threat
	model here does not depend on an attacker: attacker; a client can construct a wrong
	representation by assembling it from blocks from different resource states. That
	can happen when a resource is modified during a transfer, transfer or when some blocks are
	still valid in the client's cache.</t>
        <t>Rules stating that response body reassembly is conditional on matching ETag
	values are already in place from Section 2.4 of <xref target="RFC7959" format="default"/>.</t> sectionFormat="of"
	section="2.4"/>.</t>
	<t>To gain equivalent protection equivalent to that described in <xref target="body-integrity"
	format="default"/>, a server MUST <bcp14>MUST</bcp14> use the Block2 option in
	conjunction with the ETag option (<xref target="RFC7252" format="default"/>, Section 5.10.6), sectionFormat="comma"
	section="5.10.6"/>) and MUST NOT <bcp14>MUST NOT</bcp14> use the same ETag value for
	different representations of a resource.</t>
      </section>
    </section>
    <section anchor="token" numbered="true" toc="default">
      <name>Token Processing for Secure Request-Response Binding</name>
      <section anchor="req-resp-bind" numbered="true" toc="default">
        <name>Request-Response Binding</name>
        <t>A fundamental requirement of secure REST operations is that the client can bind
	a response to a particular request. If this is not ensured, a client may
	erroneously associate the wrong response to a request. The wrong response may be an
	old response for the same resource or a response for a completely different
	resource (see e.g. Section 2.3 of (e.g., see <xref target="I-D.mattsson-core-coap-attacks" format="default"/>). sectionFormat="of"
	section="2.3"/>). For example, a request for the alarm status "GET /status" may be
	associated to a prior response "on", instead of the correct response "off".</t>
        <t>In HTTP/1.1, this type of binding is always assured by the ordered and reliable delivery
	delivery, as well as mandating that the server sends responses in the same order
	that the requests were received. The same is not true for CoAP CoAP, where the server (or
	an attacker) can return responses in any order and where there can be any number of
	responses to a request (see e.g. (e.g., see <xref target="RFC7641" format="default"/>). In
	CoAP, concurrent requests are differentiated by their Token. Note that the CoAP
	Message ID cannot be used for this purpose since those are typically different for
	the REST request and corresponding response in case of "separate response", see Section 2.2 of response" (see
	<xref target="RFC7252" format="default"/>.</t> sectionFormat="of" section="2.2"/>).</t>
        <t>CoAP <xref target="RFC7252" format="default"/> does not treat the Token as a
	cryptographically important value and does not give stricter guidelines than that
	the Tokens currently "in use" SHOULD <bcp14>SHOULD</bcp14> (not SHALL) <bcp14>SHALL</bcp14>) be
	unique. If used with a security protocol not providing bindings between requests
	and responses (e.g. (e.g., DTLS and TLS) TLS), Token reuse may result in situations where a
	client matches a response to the wrong request. Note that mismatches can also
	happen for other reasons than a malicious attacker, e.g. e.g., delayed delivery or a
	server sending notifications to an uninterested client.</t>
        <t>A straightforward mitigation is to mandate clients to not reuse Tokens until the
	traffic keys have been replaced. The following section formalizes that.</t>
      </section>
      <section anchor="updated-token-processing-requirements-for-clients" numbered="true"
	       toc="default">
        <name>Updated Token Processing Requirements for Clients</name>
        <t>As described in <xref target="req-resp-bind" format="default"/>, the client must
	be able to verify that a response corresponds to a particular request. This section
	updates the Token processing requirements for clients in <xref target="RFC7252"
	format="default"/> to always assure a cryptographically secure binding of responses
	to requests for secure REST operations like "coaps". The Token processing for
	servers is not updated. Token processing in Section 5.3.1 of <xref target="RFC7252" format="default"/>
	sectionFormat="of" section="5.3.1"/> is updated by adding the following text:</t>
	<blockquote>
        <t>When CoAP is used with a security protocol not providing bindings between
	requests and responses, the Tokens have cryptographic importance. The client MUST
	<bcp14>MUST</bcp14> make sure that Tokens are not used in a way so that responses
	risk being associated with the wrong request.</t>
        <t>One easy way to accomplish this is to implement the Token (or part of the Token)
	as a sequence number number, starting at zero for each new or rekeyed secure connection.
	This approach SHOULD <bcp14>SHOULD</bcp14> be followed.</t>
	</blockquote>
      </section>
    </section>
    <section anchor="sec-cons" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The freshness assertion of the Echo option comes from the client reproducing the
      same value of the Echo option in a request as it received in a previous response. If
      the Echo option value is a large random number number, then there is a high probability
      that the request is generated after having seen the response. If the Echo option
      value of the response can be guessed, e.g. e.g., if based on a small random number or a
      counter (see <xref target="echo-state" format="default"/>), then it is possible to
      compose a request with the right Echo option value ahead of time. Using guessable
      Echo option values is only permissible in a narrow set of cases described in <xref
      target="source-of-truth" format="default"/>. Echo option values MUST <bcp14>MUST</bcp14>
      be set by the CoAP server such that the risk associated with unintended reuse can be
      managed.</t>
      <t>If uniqueness of the Echo option value is based on randomness, then the
      availability of a
      secure pseudorandom number generator and truly random seeds are essential for the
      security of the Echo option. If no true random number generator is available, a truly
      random seed must be provided from an external source. As each pseudorandom number
      must only be used once, an implementation needs to get a new truly random seed after reboot,
      reboot or continuously store the state in nonvolatile memory. See (<xref <xref
      target="RFC8613" format="default"/>, Appendix B.1.1) sectionFormat="comma" section="B.1.1"/> for issues and approaches for
      writing to nonvolatile memory.</t>
      <t>A single active Echo option value with 64 (pseudo-)random (pseudo)random bits gives the same theoretical
      security level as a 64-bit MAC (as used in e.g. in, e.g., AES_128_CCM_8). If a random unique
      Echo option value is intended, the Echo option value SHOULD <bcp14>SHOULD</bcp14> contain 64 (pseudo-)random
      (pseudo)random bits that are not predictable for any other party than the server. A
      server MAY <bcp14>MAY</bcp14> use different security levels for different uses use cases
      (client aliveness, request freshness, state synchronization, network address
      reachability, etc.).</t>
      <t>The security provided by the Echo and Request-Tag options depends on the security
      protocol used. CoAP and HTTP proxies require (D)TLS to be terminated at the proxies.
      The proxies are therefore able to manipulate, inject, delete, or reorder options or
      packets. The security claims in such architectures only hold under the assumption
      that all intermediaries are fully trusted and have not been compromised.</t>

      <t>Echo option values without the protection of randomness or a MAC are limited to cases
      when the client is the trusted source of all derived properties (as per <xref
      target="source-of-truth" format="default"/>). Using them needs per-application
      consideration of both the impact of a malicious client and of implementation errors
      in clients. These Echo option values are the only legitimate case for Echo option
      values shorter
      than four bytes, which are not necessarily secret. They MUST NOT <bcp14>MUST NOT</bcp14> be
      used unless the request Echo option values in the request are integrity protected protected, as per <xref
      target="echo-proc" format="default"/>.</t>
      <t>Servers SHOULD <bcp14>SHOULD</bcp14> use a monotonic clock to generate timestamps and
      compute round-trip times. Use of non-monotonic clocks is not secure secure, as the server
      will accept expired Echo option values if the clock is moved backward. The server
      will also reject fresh Echo option values if the clock is moved forward.
      Non-monotonic clocks MAY <bcp14>MAY</bcp14> be used as long as they have deviations that
      are acceptable given the freshness requirements. If the deviations from a monotonic
      clock are known, it may be possible to adjust the threshold accordingly.</t>
      <t>An attacker may be able to affect the server's system time in various ways ways, such as
      setting up a fake NTP server or broadcasting false time signals to radio-controlled
      clocks.</t>
      <t>For the purpose of generating timestamps for the Echo option, a server MAY
      <bcp14>MAY</bcp14> set
      a timer at reboot and use the time since reboot, choosing the granularity such that
      different requests arrive at different times. Servers MAY <bcp14>MAY</bcp14>
      intermittently reset the timer and MAY <bcp14>MAY</bcp14> generate a random offset
      applied to all timestamps. When resetting the timer, the server MUST <bcp14>MUST</bcp14>
      reject all Echo option values that were created before the reset.</t>
      <t>Servers that use the List "List of Cached Random Values and Timestamps Timestamps" method described
      in <xref target="echo-state" format="default"/> may be vulnerable to resource
      exhaustion attacks. One way to minimize the state is to use the Integrity Protected Timestamp "Integrity-Protected
      Timestamp" method described in <xref target="echo-state" format="default"/>.</t>
      <section anchor="token-reuse" numbered="true" toc="default">
        <name>Token reuse</name> Reuse</name>
        <t>Reusing Tokens in a way so that responses are guaranteed to not be associated
	with the wrong request is not trivial: trivial. The server may process requests in any order,
	order and send multiple responses to the same request. An attacker may block,
	delay, and reorder messages. The use of a sequence number is therefore recommended
	when CoAP is used with a security protocol that does not provide bindings between
	requests and responses responses, such as DTLS or TLS.</t>
        <t>For a generic response to a Confirmable request over DTLS, binding can only be
	claimed without out-of-band knowledge if</t> if:</t>

	<ul spacing="normal">
          <li>the original request was never retransmitted,</li> retransmitted and</li>
          <li>the response was piggybacked in an Acknowledgement message (as a Confirmable
	  or Non-confirmable response may have been transmitted multiple times), and</li>
          <li>if times).</li>
        </ul>
	<t>If observation was used, the same holds for the registration, all re-registrations,
	  reregistrations, and the cancellation.</li>
        </ul> cancellation.</t>
        <t>(In addition, for observations, any responses using that Token and a DTLS
	sequence number earlier than the cancellation Acknowledgement message need to be
	discarded. This is typically not supported in DTLS implementations.)</t>
        <t>In some setups, Tokens can be reused without the above constraints, as a
	different component in the setup provides the associations:</t>
        <ul spacing="normal">
          <li>In CoAP over TLS, retransmissions are not handled by the CoAP layer and behaves
	  behave like a replay window size of 1. When a client is sending TLS-protected
	  requests without Observe to a single server, the client can reuse a Token as soon
	  as the previous response with that Token has been received.</li>
          <li>Requests whose responses are cryptographically bound to the requests (like in
	  OSCORE) can reuse Tokens indefinitely.
<!-- could be added but is probably not worth the lines of text * Requests whose responses reflect all the data in the request that is varied over reuses of the same token (for example, if a token is always used on a single path with the single query parameter `?t=X` for various values of X, then the response needs to contain X in a unique position) can share a token, provided the application does not rely on the freshness of the responses, or sends different requests all the time.
-->
          </li>
        </ul>
        <t>In all other cases, a sequence number approach is RECOMMENDED <bcp14>RECOMMENDED</bcp14>, as
	per <xref target="token" format="default"/>.</t>
        <t>Tokens that cannot be reused need to be handled appropriately. This could be
	solved by increasing the Token as soon as the currently used Token cannot be reused,
	reused or by keeping a list of all Tokens unsuitable for reuse.</t>
        <t>When the Token (or part of the Token) contains a sequence number, the encoding
	of the sequence number has to be chosen in a way to avoid any collisions. This is
	especially true when the Token contains more information than just the sequence
	number, e.g. e.g., the serialized state state, as in <xref target="RFC8974"
	format="default"/>.</t>
      </section>
    </section>
    <section anchor="priv-cons" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>Implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14> put any privacy-sensitive information in
      the Echo or Request-Tag option values. Unencrypted timestamps could reveal
      information about the server server, such as location or location, time since reboot, or that the
      server will accept expired certificates. Timestamps MAY <bcp14>MAY</bcp14> be used if
      the Echo option is encrypted between the client and the server, e.g. e.g., in the case of
      DTLS without
      proxies or when using OSCORE with an Inner Echo option.</t>
      <t>Like HTTP cookies, the Echo option could potentially be abused as a tracking
      mechanism that identifies a client across requests. This is especially true for
      preemptive Echo option values. Servers MUST NOT <bcp14>MUST NOT</bcp14> use the Echo option to
      correlate requests for other purposes than freshness and reachability. Clients only
      send Echo option values to the same server from which the values were received. Compared to
      HTTP, CoAP clients are often authenticated and non-mobile, and servers can therefore
      often correlate requests based on the security context, the client credentials, or
      the network address. Especially when the Echo option increases a server's ability to
      correlate requests, clients MAY <bcp14>MAY</bcp14> discard all preemptive Echo option values.</t>
      <t>Publicly visible generated identifiers, even when opaque (as all defined in this
      document are), can leak information as described in <xref
      target="I-D.irtf-pearg-numeric-ids-generation" format="default"/>. To avoid the effects
      described there, the absent Request-Tag option should be recycled as much as possible.
      (That is generally possible as long as a security mechanism is in place - -- even in the
      case of OSCORE outer block-wise transfers, as the OSCORE option's variation ensures
      that no matchable requests are created by different clients). clients.) When an unprotected
      Echo option is used to demonstrate reachability, the recommended mechanism of <xref
      target="echo-proc" format="default"/> keeps the effects to a minimum.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to add has added the following option numbers to the "CoAP Option Numbers"
      registry defined by <xref target="RFC7252" format="default"/>:</t>
      <t>[</t>
      <t>The editor is asked to suggest the numbers after TBD, as those satisfy the construction requirements set out in RFC7252:
Echo is NoCacheKey but not Unsafe or Critical, so it needs to end with 11100 in binary representation;
Request-Tag has no properties so it needs to end with 00 and not with 11100).</t>
      <t>Request-Tag was picked to not waste the precious space of less-than-one-byte options,
but such that its offset from the Block1 option it regularly occurs with can still be expressed in an 1-byte offset (27 + (13 + 255) &gt; 292).</t>
      <t>Echo was picked to be the shortest it can be in an empty message as a NoCacheKey option
(11100 in binary does not fit in a nibble, and two lower ones are already taken),
and as high as possible
      <table anchor="iana-table" align="left">
        <name>Additions to keep room for other options that might typically occur in pairs and might still use optimization around low numbers.</t>
      <t>]</t>
      <figure anchor="iana-table">
        <name>CoAP CoAP Option Numbers</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
+--------+-------------+-------------------+
| Number | Name        | Reference         |
+--------+-------------+-------------------+
| TBD252 | Echo        | [[this document]] |
|        |             |                   |
| TBD292 | Request-Tag | [[this document]] |
+--------+-------------+-------------------+
]]></artwork>
      </figure> Numbers Registry</name>
	<thead>
	  <tr>
	    <th>Number</th>
	    <th>Name</th>
            <th>Reference</th>
	  </tr>
	</thead>
	<tbody>
	  <tr>
	    <td>252</td>
	    <td>Echo</td>
            <td>RFC 9175</td>
	  </tr>
	  <tr>
	    <td>292</td>
	    <td>Request-Tag</td>
	    <td>RFC 9175</td>
	  </tr>
	</tbody>
      </table>
    </section>
  </middle>
  <back>

    <displayreference target="I-D.ietf-core-groupcomm-bis" to="GROUP-COAP"/>
    <displayreference target="I-D.ietf-core-oscore-groupcomm" to="GROUP-OSCORE"/>
    <displayreference target="I-D.irtf-pearg-numeric-ids-generation" to="NUMERIC-IDS"/>
    <displayreference target="I-D.mattsson-core-coap-attacks" to="COAP-ATTACKS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <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>
        </reference>
        <reference anchor="RFC7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7252"/>
            <seriesInfo name="RFC" value="7252"/>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7959">
          <front>
            <title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7959"/>
            <seriesInfo name="RFC" value="7959"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <author fullname="Z. Shelby" initials="Z." role="editor" surname="Shelby">
              <organization/>
            </author>
            <date month="August" year="2016"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks.  Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates.  In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS).  These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</t>
              <t>Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs.  In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers.  Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t>
              <t>A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations.  Therefore, this specification updates RFC 7252.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <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>
        </reference>
        <reference anchor="RFC8613">
          <front>
            <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8613"/>
            <seriesInfo name="RFC" value="8613"/>
            <author fullname="G. Selander" initials="G." surname="Selander">
              <organization/>
            </author>
            <author fullname="J. Mattsson" initials="J." surname="Mattsson">
              <organization/>
            </author>
            <author fullname="F. Palombini" initials="F." surname="Palombini">
              <organization/>
            </author>
            <author fullname="L. Seitz" initials="L." surname="Seitz">
              <organization/>
            </author>
            <date month="July" year="2019"/>
            <abstract>
              <t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).  OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t>
              <t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates RFC 7252.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <seriesInfo name="DOI" value="10.17487/RFC6347"/>
            <seriesInfo name="RFC" value="6347"/>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu">
              <organization/>
            </author>
            <date month="January" year="2012"/>
            <abstract>
              <t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8470">
          <front>
            <title>Using Early Data in HTTP</title>
            <seriesInfo name="DOI" value="10.17487/RFC8470"/>
            <seriesInfo name="RFC" value="8470"/>
            <author fullname="M. Thomson" initials="M." surname="Thomson">
              <organization/>
            </author>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="W. Tarreau" initials="W." surname="Tarreau">
              <organization/>
            </author>
            <date month="September" year="2018"/>
            <abstract>
              <t>Using TLS early data creates an exposure to the possibility of a replay attack.  This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data.  Techniques are described that use these mechanisms to mitigate the risk of replay.</t>
            </abstract>
          </front>
        </reference>
	<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.7252.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7959.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.8613.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8470.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7641">
          <front>
            <title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7641"/>
            <seriesInfo name="RFC" value="7641"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author>
            <date month="September" year="2015"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8323">
          <front>
            <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
            <seriesInfo name="DOI" value="10.17487/RFC8323"/>
            <seriesInfo name="RFC" value="8323"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <author fullname="S. Lemay" initials="S." surname="Lemay">
              <organization/>
            </author>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
              <organization/>
            </author>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author>
            <author fullname="B. Silverajan" initials="B." surname="Silverajan">
              <organization/>
            </author>
            <author fullname="B. Raymor" initials="B." role="editor" surname="Raymor">
              <organization/>
            </author>
            <date month="February" year="2018"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</t>
              <t>Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <seriesInfo name="DOI" value="10.17487/RFC8446"/>
            <seriesInfo name="RFC" value="8446"/>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-core-groupcomm-bis">
          <front>
            <title>Group Communication for the Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-core-groupcomm-bis-04"/>
            <author fullname="Esko Dijk">
              <organization>IoTconsultancy.nl</organization>
            </author>
            <author fullname="Chonggang Wang">
              <organization>InterDigital</organization>
            </author>
            <author fullname="Marco Tiloca">
              <organization>RISE AB</organization>
            </author>
            <date day="12" month="July" year="2021"/>
            <abstract>
              <t>   This document specifies the use of the Constrained Application
   Protocol (CoAP) for group communication, including the use of UDP/IP
   multicast as the default underlying data transport.  Both unsecured
   and secured CoAP group communication are specified.  Security is
   achieved by use of the Group Object Security for Constrained RESTful
   Environments (Group OSCORE) protocol.  The target application area of
   this specification is any group communication use cases that involve
   resource-constrained devices or networks that support CoAP.  This
   document replaces RFC7390, while it updates RFC7252 and RFC7641.

              </t>
            </abstract>
          </front>
        </reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

	<!-- [I-D.ietf-core-groupcomm-bis] I-D Exists -->
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-core-groupcomm-bis.xml"/>

	<!-- [I-D.ietf-core-oscore-groupcomm] I-D Exists -->
	<reference anchor="I-D.ietf-core-oscore-groupcomm">
<front>
<title>Group OSCORE - Secure Group Communication for CoAP</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-groupcomm-12"/>
<author fullname="Marco Tiloca">
<organization>RISE AB</organization>
</author>
<author fullname="Göran Selander">
<organization>Ericsson AB</organization>
</author>
<author fullname="Francesca Palombini">
<organization>Ericsson AB</organization>
</author>
<author initials="J" surname="Preuß Mattsson" fullname="John Preuss Preuß Mattsson">
<organization>Ericsson AB</organization>
</author>
<author fullname="Jiye Park">
<organization>Universitaet Duisburg-Essen</organization>
</author>
<date day="12" month="July" month="October" day="25" year="2021"/>
            <abstract>
              <t>   This document defines Group Object Security for Constrained RESTful
   Environments (Group OSCORE), providing end-to-end security of CoAP
   messages exchanged between members of a group, e.g., sent over IP
   multicast.  In particular, the described approach defines how OSCORE
   is used in a group communication setting to provide source
   authentication for CoAP group requests, sent by a client to multiple
   servers, and for protection of the corresponding CoAP responses.
   Group OSCORE also defines a pairwise mode where each member of the
   group can efficiently derive a symmetric pairwise key with any other
   member of the group for pairwise OSCORE communication.

              </t>
            </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-groupcomm-13"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-core-oscore-groupcomm-13.txt"/>
</reference>

	<!-- [I-D.mattsson-core-coap-attacks] I-D Exists -->
<reference anchor="I-D.mattsson-core-coap-attacks">
<front>
            <title>CoAP Attacks</title>
            <seriesInfo name="Internet-Draft" value="draft-mattsson-core-coap-attacks-01"/>
<title>Attacks on the Constrained Application Protocol (CoAP)</title>
<author initials="J" surname="Preuß Mattsson" fullname="John Preuß Mattsson">
<organization>Ericsson AB</organization>
</author>
<author fullname="John Fornehed">
<organization>Ericsson AB</organization>
</author>
<author fullname="Göran Selander">
<organization>Ericsson AB</organization>
</author>
<author fullname="Francesca Palombini">
<organization>Ericsson AB</organization>
</author>
<author fullname="Christian Amsüss">
<organization>Energy Harvesting Solutions</organization>
</author>
<date day="27" month="July" day="27" year="2021"/>
            <abstract>
              <t>   Being able to securely read information from sensors, to securely
   control actuators, and to not enable distributed denial-of-service
   attacks are essential in a world of connected and networking things
   interacting with the physical world.  This document summarizes a
   number of known attacks on CoAP and show that just using CoAP with a
   security protocol like DTLS, TLS, or OSCORE is not enough for secure
   operation.  The document also summarizes different denial-of-service
   attacks using CoAP.  The goal with this document is motivating
   generic and protocol-specific recommendations on the usage of CoAP.
   Several of the discussed attacks can be mitigated with the solutions
   in draft-ietf-core-echo-request-tag.

              </t>
            </abstract>
</front>
        </reference>
        <reference anchor="RFC8974">
          <front>
            <title>Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8974"/>
<seriesInfo name="RFC" value="8974"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author>
            <author fullname="M. Richardson" initials="M." surname="Richardson">
              <organization/>
            </author>
            <date month="January" year="2021"/>
            <abstract>
              <t>This document provides considerations for alleviating Constrained Application Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. </t>
              <t>This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header.</t>
            </abstract>
          </front> name="Internet-Draft" value="draft-mattsson-core-coap-attacks-01"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-mattsson-core-coap-attacks-01.txt"/>
</reference>

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

	<reference anchor="REST"		   target="https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf">
	  <front>
	    <title>Architectural Styles and the Design of Network-based Software
	    Architectures</title>
	    <author initials="R." surname="Fielding">
	      <organization/>
	    </author>
	    <date year="2000"/>
	  </front>
	</reference>
        <reference anchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <seriesInfo name="DOI" value="10.17487/RFC9000"/>
            <seriesInfo name="RFC" value="9000"/>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.irtf-pearg-numeric-ids-generation">
          <front>
            <title>On the Generation of Transient Numeric Identifiers</title>
            <seriesInfo name="Internet-Draft" value="draft-irtf-pearg-numeric-ids-generation-07"/>
            <author fullname="Fernando Gont">
              <organization>SI6 Networks</organization>
            </author>
            <author fullname="Ivan Arce">
              <organization>Quarkslab</organization>
            </author>
            <date day="2" month="February" year="2021"/>
            <abstract>
              <t>   This document performs an analysis of the security and privacy
   implications of different types of "transient numeric identifiers"
   used in IETF protocols, and tries to categorize them based on their
   interoperability requirements and their associated failure severity
   when such requirements are not met.  Subsequently, it provides advice
   on possible algorithms that could be employed to satisfy the
   interoperability requirements of each identifier category, while
   minimizing the negative security and privacy implications, thus
   providing guidance to protocol designers and protocol implementers.
   Finally, it describes a number of algorithms that have been employed
   in real implementations to generate transient numeric identifiers,
   and analyzes their security and privacy properties.  This document is
   a product of the Privacy Enhancement and Assessment Research Group
   (PEARG) in the IRTF.

              </t>
            </abstract>
          </front>
        </reference>

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

	<!-- [I-D.irtf-pearg-numeric-ids-generation] IRSG Review Revised I-D Needed -->
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-pearg-numeric-ids-generation.xml"/>
      </references>
    </references>
    <section anchor="echo-state" numbered="true" toc="default">
      <name>Methods for Generating Echo Option Values</name>
      <t>The content and structure of the Echo option value are implementation specific and
      determined by the server. Two simple mechanisms for time-based freshness and one for
      event-based freshness are outlined in this section, the first appendix. The "List of Cached Random
      Values and Timestamps" mechanism is RECOMMENDED
      <bcp14>RECOMMENDED</bcp14> in general, and the second general. The "Integrity-Protected Timestamp"
      mechanism is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
      in case the Echo option is encrypted between the client and the server.</t>
      <t>Different mechanisms have different tradeoffs trade-offs between the size of the Echo option
      value, the amount of server state, the amount of computation, and the security
      properties offered. A server MAY <bcp14>MAY</bcp14> use different methods and security
      levels for different uses use cases (client aliveness, request freshness, state
      synchronization, network address reachability, etc.).</t>
      <t>1. List
      <ol spacing="normal">
	<li><t>List of Cached Random Values and Timestamps. The Echo option value is a (pseudo-)random
	  (pseudo)random byte string called r. The server caches a list containing the
	  random byte strings and their initial transmission times. Assuming 72-bit random
	  values
	  and 32-bit timestamps, the size of the Echo option value is 9 bytes and the
	  amount of server state is 13n bytes, where n is the number of active Echo Option option
	  values. The security against an attacker guessing echo Echo option values is given by
	  s = bit
	  length of r - log2(n). The length of r and the maximum allowed n should be set so
	  that the security level is harmonized with other parts of the deployment, e.g., s
	  &gt;= 64. If the server loses time continuity, e.g. e.g., due to reboot, the entries
	  in the old list MUST <bcp14>MUST</bcp14> be deleted.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
      Echo
          <dl>
	    <dt>Echo option value: random value:</dt><dd>random value r
      Server State: random r</dd>
	    <dt>Server State:</dt><dd>random value r, timestamp t0
]]></artwork> t0</dd>
	  </dl>
	  <t>This method is suitable both for time- both time-based and for event-based freshness (e.g. (e.g.,
	  by clearing the cache when an event occurs), occurs) and is independent of the client
	  authority.</t>
      <t>2. Integrity Protected
	</li>
	<li><t>Integrity-Protected Timestamp. The Echo option value is an integrity protected
	integrity-protected
	  timestamp. The timestamp can have a different resolution and range. A 32-bit
	  timestamp can e.g. can, e.g., give a resolution of 1 second with a range of 136 years. The (pseudo-)random
	  (pseudo)random secret key is generated by the server and not shared with any
	  other party. The use of truncated HMAC-SHA-256 is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
	  With a 32-bit timestamp and a 64-bit MAC, the size of the Echo option value is 12 bytes
	  bytes, and the Server server state is small and constant. The security against an
	  attacker guessing echo Echo option values is given by the MAC length. If the server loses
	  time continuity, e.g. e.g., due to reboot, the old key MUST <bcp14>MUST</bcp14> be deleted
	  and replaced by a new random secret key. Note that the privacy considerations in
	  <xref target="priv-cons" format="default"/> may apply to the timestamp.
	  Therefore, it might be important to encrypt it. Depending on the choice of
	  encryption algorithms, this may require an initialization vector to be included
	  in the Echo option value, see below.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
      Echo value (see below).</t>

<dl>
            <dt>Echo option value: timestamp value:</dt><dd>timestamp t0, MAC(k, t0)
      Server State: secret t0)</dd>
            <dt>Server State:</dt><dd>secret key k
]]></artwork> k</dd>
		    </dl>

	  <t>This method is suitable both for time- both time-based and for event-based freshness (by the
	  server remembering the time at which the event took place), place) and independent of
	  the client authority.</t>
	  <t>If this method is used to additionally obtain network reachability of the
	  client, the server MUST <bcp14>MUST</bcp14> use the client's network address too, e.g. e.g.,
	  as in <tt>MAC(k, MAC(k, t0, apparent claimed network address)</tt>.</t>
      <t>3. Persistent address).</t>
	</li>
	<li><t>Persistent Counter. This can be used in OSCORE for sequence number recovery recovery,
	per Appendix B.1.2 of <xref
	target="RFC8613" format="default"/>. sectionFormat="of" section="B.1.2"/>. The Echo option
	value is a simple counter without integrity protection of its own, serialized in
	uint format. The counter is incremented in a persistent way every time the state
	that needs to be synchronized is changed (in the B.1.2 case: case described in <xref target="RFC8613"
	sectionFormat="of" section="B.1.2"/>, when a reboot
	indicates that volatile state may have been lost). An example of how such a
	persistent counter can be implemented efficiently is the OSCORE server Sender
	Sequence Number mechanism described in Appendix B.1.1 of <xref target="RFC8613" format="default"/>.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
      Echo option value: counter
      Server State: counter
]]></artwork>
	sectionFormat="of" section="B.1.1"/>.</t>

<dl>
<dt>Echo option value:</dt><dd>counter</dd>
<dt>Server State:</dt><dd>counter</dd>
</dl>

	<t>This method is suitable only if the client is the authority over the
	  synchronized property. Consequently, it cannot be used to show client aliveness.
	  It provides statements from the client similar to event based event-based freshness (but
	  without a proof of freshness).</t>
	</li>
      </ol>
	  <t>Other mechanisms complying with the security and privacy considerations may be
	  used. The use of encrypted timestamps in the Echo option provides additional protection,
	  protection but typically requires an initialization vector (a.k.a. nonce) as
	  input to the encryption algorithm, which adds a slight complication to the
	  procedure as well as overhead.</t>
    </section>
    <section anchor="request-tag-message-size-impact" numbered="true" toc="default">
      <name>Request-Tag Message Size Impact</name>
      <t>In absence of concurrent operations, the Request-Tag mechanism for body integrity
      (<xref target="body-integrity" format="default"/>) incurs no overhead if no messages
      are lost (more precisely: precisely, in OSCORE, if no operations are aborted due to repeated
      transmission failure; failure and, in DTLS, if no packets are lost and replay protection is active),
      active) or when block-wise request operations happen rarely (in OSCORE, if there is
      always only one request block-wise operation in the replay window).</t>

      <t>In those situations, no message has any Request-Tag option set, and that the
      Request-Tag value can be recycled indefinitely.</t>
      <t>When the absence of a Request-Tag option cannot be recycled any more within a
      security context, the messages with a present but empty Request-Tag option can be
      used (1 Byte byte overhead), and when that is used-up, used up, 256 values from one byte long 1-byte
      options (2 Bytes bytes overhead) are available.</t>
      <t>In situations where those overheads are that overhead is unacceptable (e.g. (e.g., because the payloads
      are known to be at a fragmentation threshold), the absent Request-Tag value can be
      made usable again:</t>
      <ul spacing="normal">
        <li>In DTLS, a new session can be established.</li>
        <li>In OSCORE, the sequence number can be artificially increased so that all lost
	messages are outside of the replay window by the time the first request of the new
	operation gets processed, and all earlier operations can therefore be regarded as
	concluded.</li>
      </ul>
    </section>
    <section anchor="change-log" numbered="true" toc="default">
      <name>Change Log</name>
      <t>[ The editor is asked to remove this section before publication. ]</t>
      <ul spacing="normal">
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-13  </t>
          <ul spacing="normal">
            <li>Minor editorial fixes.</li>
            <li>
              <t>Wording enhancements:
              </t>
              <ul spacing="normal">
                <li>nonce -&gt; initialization vector</li>
                <li>information extracted by the sever -&gt; information conveyed to the server</li>
              </ul>
            </li>
            <li>Acknowledgements updated.</li>
            <li>Changelog for -13 added (previous upload just pointed to other resources).</li>
            <li>Short title is "Echo, Request-Tag, and Token Processing" now instead of outdated acronym.</li>
            <li>Informative reference to RFC 7390 is now to draft-ietf-core-groupcomm-bis</li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-12 (addressing comments from IESG review)  </t>
          <t>
See CoRE point-to-point responses at <eref target="https://github.com/core-wg/echo-request-tag/blob/master/point-to-point.md">https://github.com/core-wg/echo-request-tag/blob/master/point-to-point.md</eref> and on CoRE mailing list.  </t>
          <ul spacing="normal">
            <li>
              <t>Add subsection "Characterization of Echo Applications".
              </t>
              <ul spacing="normal">
                <li>Changes in applications and appendices to use the newly introduced terms.</li>
                <li>In particular, some of the legitimization for using short Echo values was drawn from the applications being event based; the concept of the client being the "Authority over [the] Used Information" now legitimizes these more precisely.</li>
              </ul>
            </li>
            <li>Add subsection "Updated Amplification Mitigation Requirements for Servers". It contains the normative text updating RFC 7252 w/rt recommended mitigation methods, which previously happened in passing.</li>
            <li>
              <t>Amplification mitigation:
              </t>
              <ul spacing="normal">
                <li>Increase precision: Reachability check is performed once per endpoint (was: peer).</li>
                <li>State that amplification factor applies to the sum of all (previously: "the size of the", implicitly, single) returned packets.</li>
                <li>Fix odd wording around how the Echo value would "contain" the claimed address: was meant to contain in a cryptographic sense, now clarified in that a MAC is recommended</li>
              </ul>
            </li>
            <li>Define "preemptive Echo value" that was previously used without definition; another occurrence of the concept was simplified using the term.</li>
            <li>Add considerations for the use of DTLS without replay protection.</li>
            <li>Privacy considerations: Address concerns raised in various numeric-ids documents.</li>
            <li>Explicitly state expected security modes for Echo applications and examples.</li>
            <li>Fix of requirements for H-C proxies: They <em>MUST NOT</em> relay unsafe requests. (Previously, it only said that they SHOULD use a particular method, but not clearly that some method is mandated.)</li>
            <li>Clarify that state synchonization is an application of the freshness results in combination with some transported application data, and not an immediate result of using Echo alone.</li>
            <li>Add text to tie together applications and suggested mechanisms <!-- eg. 92070767 as I'm pretty sure I wouldn't find that when asked for it -->
            </li>
            <li>Restrict C-C proxy allowed behavior: Only safe requests (incorrectly said "idempotent") may be used to proactively populate the proxy's cache.</li>
            <li>
              <t>Justify some "SHOULD"s by outlining justification for different behavior.
              </t>
              <ul spacing="normal">
                <li>Normatively require H-C proxies to process Echo if they're justified to do so, as no alternatives are available.</li>
              </ul>
            </li>
            <li>
              <t>Reference updates:
              </t>
              <ul spacing="normal">
                <li>QUIC is now RFC9000; precise section given as amplification reference.</li>
                <li>Add note for RFC editor that RFC6347 can be upgraded to DTLS 1.3 if C321 overtakes C280</li>
                <li>Follow the core-coap-actuators to core-coap-attacks update</li>
                <li>RFC8470 reference is now normative (as using what's defined there has been RECOMMENDED already)</li>
              </ul>
            </li>
            <li>
              <t>Editorial fixes
              </t>
              <ul spacing="normal">
                <li>Rewording of confusing sentences in amplification mitigation and inner-/outer Echo values</li>
                <li>Replace "blacklist" terminology with "deny-list" where left after other changes</li>
                <li>Removed sloppy use of Echo as a verb</li>
                <li>Minor clarifications</li>
                <li>Remove duplicate statements</li>
                <li>Typography and spelling fixes</li>
              </ul>
            </li>
            <li>
              <t>Fixes that are not editorial but minor
              </t>
              <ul spacing="normal">
                <li>Freshness is about time, of which round-trip time (specialization now removed) is only a part.</li>
                <li>Reference how HTTP <em>1.1</em> does it when explaining token requirements, as that's an easily and widely understood baseline.</li>
              </ul>
            </li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-11 (addressing GenART, TSVART, OpsDir comments)  </t>
          <ul spacing="normal">
            <li>Explain the size permissible for responses before amplification mitigation by referring to the QUIC draft for an OK factor, and giving the remaining numbers that led to it. The actual number is reduced from 152 to 136 because the more conservative case of the attacker not sending a token is considered now.</li>
            <li>Added a definition for "freshness"</li>
            <li>Give more concrete example values in figures 2 and 3 (based on the appendix suggestions), highlighting the differences between the figures by telling how they are processed in the examples.</li>
            <li>Figure with option summary: E/U columns removed (for duplicate headers and generally not contributing)</li>
            <li>MAY capitalization changed for consistency.</li>
            <li>Editorial changes (IV acronym expanded, s/can not/cannot/g)</li>
            <li>Draft ietf-core-stateless has become RFC8974</li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-10 (Barry's comments)  </t>
          <ul spacing="normal">
            <li>Align terminology on attacker</li>
            <li>A number of clarifications and editorial fixes</li>
            <li>Promote DTLS and OSCORE to normative references</li>
            <li>Add counter-based version to the Methods for Generating Echo Option Values appendix</li>
            <li>Use 64-bit randomness recommendation throughout (but keep it as SHOULD so applications with strict requirements can reduce if if really needed)</li>
            <li>Speling and Capitalization</li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-09:  </t>
          <ul spacing="normal">
            <li>Allow intermediaries to do Echo processing, provided they ask at least as much freshness as they forward</li>
            <li>Emphasize that clients can forget Echo to further discourage abuse as cookies</li>
            <li>Emphasize that RESTful application design can avoid the need for a Request-Tag</li>
            <li>Align with core-oscore-groupcomm-09</li>
            <li>Add interaction with HTTP Early Data / 425 Too Early</li>
            <li>Abstract: Explicitly mention both updates to 7252</li>
            <li>Change requested option number of Echo to 252 (previous property calculation was erroneous)</li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-08:  </t>
          <ul spacing="normal">
            <li>Make amplification attack mitigation by Echo an RFC7252 updating recommendation</li>
            <li>Give some more concrete guidance to that use case in terms of sizes and message types</li>
            <li>Allow short (1-3 byte) Echo values for deterministic cases, with according security considerations</li>
            <li>Point out the tricky parts around Request-Tag for stateless proxies, and make that purely an outlook example with out-of-scope details</li>
            <li>Lift ban on Request-Tag options without Block1 (as they can legitimately be generated by an unaware proxy)</li>
            <li>Suggest concrete numbers for the options</li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-07 (largely addressing Francesca's review):  </t>
          <ul spacing="normal">
            <li>Request tag: Explicitly limit "MUST NOT recycle" requirement to particular applications</li>
            <li>Token reuse: upper-case RECOMMEND sequence number approach</li>
            <li>Structure: Move per-topic introductions to respective chapters (this avoids long jumps by the reader)</li>
            <li>Structure: Group Block2 / ETag section inside new fragmentation (formerly Request-Tag) section</li>
            <li>More precise references into other documents</li>
            <li>"concurrent operations": Emphasise that all here only matters between endpoint pairs</li>
            <li>Freshness: Generalize wording away from time-based freshness</li>
            <li>Echo: Emphasise that no binding between any particular pair of responses and requests is established</li>
            <li>Echo: Add event-based example</li>
            <li>Echo: Clarify when protection is needed</li>
            <li>Request tag: Enhance wording around "not sufficient condition"</li>
            <li>Request tag: Explicitly state when a tag needs to be set</li>
            <li>Request tag: Clarification about permissibility of leaving the option absent</li>
            <li>Security considerations: wall clock time -&gt; system time (and remove inaccurate explanations)</li>
            <li>Token reuse: describe deny-listing in a more implementation-independent way</li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-06:  </t>
          <ul spacing="normal">
            <li>Removed visible comment that should not be visible in Token reuse considerations.</li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-05:  </t>
          <ul spacing="normal">
            <li>Add privacy considerations on cookie-style use of Echo values</li>
            <li>Add security considerations for token reuse</li>
            <li>Add note in security considerations on use of nonvolatile memory when
dealing with pseudorandom numbers</li>
            <li>Appendix on echo generation: add a few words on up- and downsides of the
encrypted timestamp alternative</li>
            <li>
              <t>Clarifications around Outer Echo:      </t>
              <ul spacing="normal">
                <li>Could be generated by the origin server to prove network reachability
(but for most applications it MUST be inner)</li>
                <li>Could be generated by intermediaries</li>
                <li>Is answered by the client to the endpoint from which it received it
(ie. Outer if received as Outer)</li>
              </ul>
            </li>
            <li>Clarification that a server can send Echo preemtively</li>
            <li>Refer to stateless to explain what "more information than just the
sequence number" could be</li>
            <li>Remove explanations around 0.00 empty messags</li>
            <li>
              <t>Rewordings:      </t>
              <ul spacing="normal">
                <li>the attack: from "forging" to "guessing"</li>
                <li>"freshness tokens" to "freshness indicators" (to avoid confusion with
the Token)</li>
              </ul>
            </li>
            <li>
              <t>Editorial fixes:      </t>
              <ul spacing="normal">
                <li>Abstract and introduction mention what is updated in RFC7252</li>
                <li>Reference updates</li>
                <li>Capitalization, spelling, terms from other documents</li>
              </ul>
            </li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-04:  </t>
          <ul spacing="normal">
            <li>
              <t>Editorial fixes      </t>
              <ul spacing="normal">
                <li>Moved paragraph on collision-free encoding of data in the Token to
Security Considerations and rephrased it</li>
                <li>"easiest" -&gt; "one easy"</li>
              </ul>
            </li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-03:  </t>
          <ul spacing="normal">
            <li>Mention Token processing changes in title</li>
            <li>Abstract reworded</li>
            <li>Clarify updates to Token processing</li>
            <li>Describe security levels from Echo length</li>
            <li>Allow non-monotonic clocks under certain conditions for freshness</li>
            <li>Simplify freshness expressions</li>
            <li>Describe when a Request-Tag can be set</li>
            <li>Add note on application-level freshness mechanisms</li>
            <li>Minor editorial changes</li>
          </ul>
        </li>
        <li>
          <t>Changes since draft-ietf-core-echo-request-tag-02:  </t>
          <ul spacing="normal">
            <li>Define "freshness"</li>
            <li>Note limitations of "aliveness"</li>
            <li>Clarify proxy and OSCORE handling in presence of "echo"</li>
            <li>Clarify when Echo values may be reused</li>
            <li>Update security considerations</li>
            <li>Various minor clarifications</li>
            <li>Minor editorial changes</li>
          </ul>
        </li>
        <li>
          <t>Major changes since draft-ietf-core-echo-request-tag-01:  </t>
          <ul spacing="normal">
            <li>
              <t>Follow-up changes after the "relying on block-wise" change in -01:      </t>
              <ul spacing="normal">
                <li>Simplify the description of Request-Tag and matchability</li>
                <li>Do not update RFC7959 any more</li>
              </ul>
            </li>
            <li>Make Request-Tag repeatable.</li>
            <li>Add rationale on not relying purely on sequence numbers.</li>
          </ul>
        </li>
        <li>
          <t>Major changes since draft-ietf-core-echo-request-tag-00:
          </t>
          <ul spacing="normal">
            <li>Reworded the Echo section.</li>
            <li>Added rules for Token processing.</li>
            <li>Added security considerations.</li>
            <li>Added actual IANA section.</li>
            <li>Made Request-Tag optional and safe-to-forward, relying on block-wise to treat it as part of the cache-key</li>
            <li>Dropped use case about OSCORE Outer-block-wise (the case went away when its Partial IV was moved into the Object-Security option)</li>
          </ul>
        </li>
        <li>
          <t>Major changes since draft-amsuess-core-repeat-request-tag-00:
          </t>
          <ul spacing="normal">
            <li>The option used for establishing freshness was renamed from "Repeat" to "Echo" to reduce confusion about repeatable options.</li>
            <li>The response code that goes with Echo was changed from 4.03 to 4.01 because the client needs to provide better credentials.</li>
            <li>The interaction between the new option and (cross) proxies is now covered.</li>
            <li>Two messages being "Request-Tag matchable" was introduced to replace the older concept of having a request tag value with its slightly awkward equivalence definition.</li>
          </ul>
        </li>
      </ul>
    </section>
    <section numbered="false" anchor="acknowledgments" anchor="acknowledgements" toc="default">
      <name>Acknowledgments</name>
      <name>Acknowledgements</name>
      <t>The authors want to thank
Carsten Bormann,
Roman Danyliw,
Benjamin Kaduk,
Murray Kucherawy,
Francesca Palombini <contact fullname="Carsten Bormann"/>, <contact
      fullname="Roman Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, <contact
      fullname="Murray Kucherawy"/>, <contact fullname="Francesca Palombini"/>, and
Jim Schaad
      <contact fullname="Jim Schaad"/> for providing valuable input to the draft.</t> document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAHP1WmEAA+193ZbbVpbePZ8CoS5EukmqqvRnl8dOSiXZ1rRlKapSe2b1
9OpBkWAVXCTAAGCVOG7NyjvkKld5i1zlbt4kT5L9f/YBwJKs7mTNRbRmWjIJ
AgfnZ/9++9vT6XTQ5M0qO06Gp+XJm+PkxfyqnCRvs/+yzepmep5eTpK0WCTn
5XVWJG+qcp7VdV5cDgfpxUWV3cDvPvkXi3JepGt41KJKl800z5rldF5W2TSD
O0wruUGTXk4PHw3maZNdltXuOKmbxWC7WcB/18fJ06PHR4NBvqmOk6ba1s3R
wcFXB0eDtMrS4+T7rMiqdDW4Lavry6rcbo6T0/Lti+Rn+G8YQfI9fjYY1A2M
78/pqixgLLusHmzy4+SPTTmfJHVZNVW2rOFfuzX+40+DQbptrsrqeJBMBwn8
yQsYxuksOVnXMN6aPuPXOr2q8rrJ0wK/+7f/Jd9l6zRfHSdz/fI/pfzD2bxc
R/f8+1nyKm2aui4Ld9O/L69wFrPtv/2P+OuyukyL/F/SJi8LWLYqn+NXyckz
/9Rf4NeztfzsP2VyUefR38+Ss2wFs5JV7tHf/9v/rOBlom/gqXsfBsuVFrNa
Lo+fNijKCsaR32Qwkcnb706PDg+/kn/imuo/v3qsn355+PSR/vPJ4UP555OH
j54ewwYolq37PX3y6FAvf3ikl3/56NET/OfL6fNZ2G+0N2BU6+lFXne/Luv4
Kr1C55GvmpfpZgqfpPPrWp/2lQz5xdn5Mc1Mk1aXWXOcXDXNpj5+8OD29nYG
szLbzvNZttg++Ndlnq0WsDcfbLYX9YNFXtdZ1dCaPtCv/uw/nW0WS76znNqT
an6VN9m82cLOT86a3Sqr6fw1V1nyPKvzyyIpl8lPWYOnYnqR1tkiOSuXzS2c
mcT9OquHdGPb7vRnKn/LRnk7S76TYdEXeCqPEziEBwP8M51Ok/Sibqp03gwG
51d5ncCh366zoknqTTbP4Z3qJCuu0mKe4ad10pQ00tOywJ/lBYzuZLNZ5XN6
XZQfcDDLVTJC8TSGa9MmWedNfglPTupsvq3yZpfADMGZgjEmm7Rq8vl2lVbJ
ts6SObxvPUvO4REop5JyQ7fNivSCJirB28J9qpuswrHAX/lyR0NawpRcFXBS
cf7SROQTnAC8DrbfPINP56scXw4+WWRrfgcYF0ij+VV6ka9wbDDgHF50vkrz
NbxdwSuRpItFhWKAxuakpw4xXa3K21omJxoj7MP5VXKxKufX09scXnIN90kv
ccTpJc/qRQbS7RJlnsxvDSdaXwEf6VdGhCvuYJKvyW3eXMHFuGKN3kBelKX6
xqQ63TOveDEnOC0X+QK3R1LAQaH1wefiUsAs0q9pzeEv/OYiL+hi+A6fBxOY
4bc617dX8DB6exjvFncuDS0NC7+R/cE6pz3wdA07aal7SbYN/HOCd4bH44vJ
0Gh3wFOK8hbugMc+Aym2mPGmXsNLrbLB4F7ysmiqcrGd0x1/vZfjf37AvZ7B
7oMHwCH81L1cb+Ho4bPlaPBldTL69VeRih8+TBL+D5Bu+B/4kvwBCMoPH8bJ
bQoLSadcJwffKYXjsOZtRAfGpmteblcL2B04bzc5vF+COw2+h2ODG3eV7rJq
0jpHFzuYJFyl5+c/nsnoUA7D82fJD+VtdoO/gaUH9bnOwrGb4B7PcRQwKctt
Med/4jjg2uw9zJHfSTj5WYZjgpWrt5sN6OJEdhDtgXID2p2mqL2Dg2yxN/0r
hAys+R+Tn8qGtiIeigzeAkRi8nKZnD48OkxApNcJCOxVXl9lOJ3w7nD3oy8P
JoMGtyw+zE0TbKglbDcYDogB0Kgw/9vNZZXKuzpzqFnV0wX8z+HD6aOHtJ7l
tqHb4dTQHC+3Ffx3BQZFWlxm9df4xPAAnEW4JT43oS1+kc1TXBHaB7hbSBo0
KP54PcNPb3XoNq94/Sqt8Sxt5/SqLBpZR8Ay/Gm/lAcpp8tGazahX3ohrFqq
K/yO/4YCG896DvJSJ76WDbYrwCQrwYKi6Wiyyb8byf4bxfnELoQx8EG1Wzsl
AeMvalhquD1unbxe68yoOoXZZXOGVkZnfF4WcKQqnAt3t/gsZvQJS6+c9tAa
zMCbDDcGSNQGhrpZpfMs3sk9YvxrvGInu0hWlQw9GpITFrDCoLRSfoMJb12Q
xdml3Q5UgM1HNruc9UivSRI+QkuRPoKBvT47fQ1ug3wBxid9ISKTD0AQbPYO
yywlM2rWPhOqX51YVz1mmib1whq3A+m7zpHBPaLGT6zcZOlmrIrs2emqLm0A
eLc7FTgtC2/82o7yApfUjZ33Nd8zWhNW/vVna/7aqf56n+7X6UZxsq1Np+Mi
VxWOHjUP7RbdzEHVy5Fepzu6uMjKbb3aobYs5zlOKV50C19cRtaIiRKY3Bdw
/HHMvDPxIOOjYVC8+WWPoJxao05YZA24RjSFzmyQQ9yUm3yOQuQKhwuTjMJk
mVcgb2vwBvie8Mx795LzrFrnRbkqL3e8wNdwSkDYwGwPX707Ox9O+O/kp9f0
77cv/vO7l29fPMd/n/1w8uOP9g+94uyH1+9+fB7+FX55+vrVqxc/Pecfw6dJ
66NXJ/84ZEtk+PrN+cvXP538OORT7zc9ehfwnhcZHctqU2W4W9hamVf5BW+r
Z6dvksNHvLvQI4STwYcOnD88JbAH+FFlAQvF/0kSIt1sMjBNcpKmsOibvIGt
PsEH1FflbUHKD+bux/w6SyJ7Kh4m/LvKVjvaiYVoIxhrDd+lcsDPUDsk5yo+
4Wbg3sHgUuc76Zb4ObuAh74rVqSFUE+TtLSjxEoQ5mMNC8fbcchTyad+yOoY
Z47iMUl0jdMWsAJi54ILvNpNeGaXZNr0HVd8ZDIsqxy0iN7CDlZaf/w3OhD9
TWfBSVEWZRMdtWVVrkXLeA8K74gS6Wv6FcZFisstGFN8vQqgnOTU+5xE6omq
xfswc6bpaTxw1rK0llUgsZGaDkULBheT7dwG9HRSz9OVLRgI4HyDj5vBE1QR
oxSGL7L8hk6yjhstiCwn48usjrSR2/AlMBoa2wAkEZx9OrVie+V0A1SGcCbo
9yha995hNviZfkUKuAaZUuFC8Xf2dvjyzo5dZBt0Worm60H2PgP1kFZouuNL
wOQMi5KFEjyzgPnIEjAuQQtflkNUekMwQunl81om4r4Yf1V2UZbNUFSLbN5N
uluV6UJ25kW52A3Z7NKx4SM7u4u8lllC2ws032YFc8QCgs3Z2NUmKR5EMT6E
JgSOPE3GCE/iGLaoGiPDWXJSBNukaxi5UUR3GvaZNni3XptHdjQtFT9AjS4d
eWeo/gF2DtyDPuNJ+2YlfpRc5Z4Fy3gbXGxZLt4idZovRGoPyRZFExDO2JKF
bjkH3QtfNreZeApkh8Ke25SwiOAz5uAIXqU3WfhyXi4yFuHx53XW4GKbc2C+
a/Z+njnXNVuxjAOH7BR0b/Z7HIeYmqQYzOy8KcHiJMHUZ/WOnuGHh5OE/j6i
3zrbfMxmqRxPHeVs8Hf/Abz/nzNxnMmaus6yTcdvyemM0sc2cQnoOdjZFG+4
YDcOFjS7Tw54nZLSCdMsL04mWOvuQ1JyJcumYNzNkun0W1rMYI23lzHcHhYx
LXYi9/IqWnjZE+HiXku/s0WCa0B7JOWfqWgFA6aESXaCDd6QTjk4Fze0gcrt
5ZVXF6AI4EVRHhQLNhblF+b10hPUyRBjyUY4Qwe+z1vpnLiaNQ14ILAIK7eF
8RXz9aYEixbnwXalbjN4Ny9DRnXGi06CEoMo4NZvrui6MzUKj2aPaLsdzR6P
nT9uM2SjAoErMwhLfYubp6Y1I//UrE56Z52Y2VjEMnkJrU0dDgqZomYdRIob
DUz9UfKdudDqnNN9X28k3IWZmg9kkXZ/8es9mOYpKagPqK+9b8vaFDd86jcE
jOWSczZ08mjrBZ/e4hEWDlRlLmEIZyFJRKjCVAT6GdU2402WLzu3CN7h/mhi
vUWTpSanUe69Tq9hPeiZ5qTcbFc4fBn3HKP0OerhVbpz/geZP7AEIaYGxiws
er4CB0T3MjoupP7AoEybsqI44N1pBwrAnWHMTZ8lQQ71ESlgk1G0B6wr8tHI
fqjRY4MFBS8CRC95xzAc9LR5ichVRq+kvoKXJpGEcY8QcUBx5haPNhQFTxuc
znK1pf2CAU6aG3IrXfAtK25ycLNC0Bj2M7qzoCkWW5rKvJhXGeUq1J7AM3GV
pQvamSt4uWK+AwVtjjgawbzYFRsfYjtO5J3pnfyLmyKTPSoRhvc7OBoZv0uN
y1jsGpq69AJjcbYpzZkUsW/B9ZdoaerMXJWb6cVuCn+hxkPtPXFxKvRESe+w
QDWrEKaW5ht+RqYvTdzlVQMzdZtWCxfJxh2zge1cUOSZNl62CPsTo4FqYcbn
8Rc4Ad64DaKFjGSwVtnFEl+6vq7bRw4Hjf5usG9ZcPPr4GmJTh6NAsbDchY3
fY4KlrzbWM604ycsuep2MASsimSFs3Kb4f9iQBQsIJCJU7N6LNRFe4zGzkbF
Z0cT0STk/eTEGNrSt1clPBA36lXKm2eXkZiWkHZ0xyjmgpaQCDQeCHtfe67G
ne1tfs0d0DLhfrpBo5/TfPA13ASM/DkcrHUG+nbBphgqqjW6JzD2bUOWC7wk
z4UIvk0Jj8j7cmc36WrLrkeYclan4RVaWSM4zavtgjd2qiJU1ohijXB7FFYg
wyzCyffJ2VOB1SPXJZK+GmgLqywiiIIFqMVBHMte6xOwFOsjJz3kLFy0qJVz
0GWIN4aOhUUi2YdOLlJOxALNFCkiVa6Sx58mnAd+6QkYjrtNU5IpkaNdv5ON
qcZ/ugKLWIcQ5pleCOPXLMX/RhFsMtfj9I2oGUsioZaBJTQFQ0PDAN+cNVku
rypOY632MJ2dFUWyrjn4yLuUhY5tEfQhQngD3odciVRv192iLgwHaucGpaOE
3dQd6B0m50hsLGh07x8Pia57kX30HYeq2UyacuD6gzPP5DK0hMWrAUMjXWbT
hq5G0T6hDYyGgi0tej1TUFh8dCWanqWkWeH3Gca36IH0CYa42OLI3rMZfU4q
+FEwXSnEg3bjv9qfwe+m8ud3Pf8f/vyu9Y/w7e8GfwEXbYaggL8kp/D/7+D/
f4L/f4t/4xaSP3/RafpL8mMGJvtfkufZMt2u4IO/zSjOnz3HJPZf6Fn4/+/l
b1oDG0W5SeHowj8Op48O4K9RAYJmnPxtRiGoidPkm+QULEs8xBOYkW+SdwUu
+ARm5hvn0U5glr7ByKMsq1+ZX4+Te2F5GffxzdDvp7Pteg1CH7zEikEecEgv
i2+Gc4x8VEO/A9sinAWVGIqpyR+KRzcUempMNoFNzbFO8ZFWpJFiLTRLnudL
yic2dnTwKMlzUEB0xsE6DfTQKkQv6YVJVmK46FQCghwmxwBUtsjTCrOMFPRu
QKbhIHveETSZLDTrRzBKitLlx2sx6/zbotDWl4VT8jNafM6BiR9DGs3sYqe5
aGQgJFtOjZlj3bGOUs7nR4vi7qgJdlZZKCPc7VTvIiiu5hUcXYxBbq+W4FPX
dxkgImicVQHLSKFEFxbf81v3aDI++CXBmp83K+fBdV82ftERGoMCTrInjfGN
75q2+B4cv0yDRYT+X5OM6K/OvcGQq9uBV9gJxUINkM6Qo9VFDdgK8LZuRobI
aqHx5N5b6u5qfxllvCQb6ZKRaGu/OvlH2l0F+BsFb47XW5wAM47Fgeev8b/4
e3fmQPVpxHimj9HsI21fUs4bSlzpjdwwYZCc6OCMTIX2NiZTkiajiD6d/Mjc
iKwVWHS1LtgpR2+NdtGiHLNOl1cLarMgyyhbmCho53t9cFKDOrXAfQT84KdJ
F8rdYCczQRskXd2m4Cm6dZigpLLf8zze5Bwtgp0zUjMc14ZuCA+52I3JmDCP
lFwq90MGBYA3U1i+EqVUSDLLi+OIRytMaaEzq+/qDEjyX8e6f2B7DdRECUBc
tU8wc9ujG2RjRSZ7sfPwN7ODRs74AOkBGxNXfGEawEmUWuNUcb5iTlbaFvGi
8N5wTDAglsvMRta+JmLZneG8HckhdZ45ayJgBHcbPKkuwqAvxo9r3w8epEm6
ECBHNcaxZhK8hDvIo8gUr6h7aK470OIc5lgJ/iYE9IJ0p9wget/yzSLdway9
RPdTQ0tOwPS9fzx0i2OgZktJU7Hv2iPbVFwE+YY/3OcPR7Ku8GoJzktXDWIW
WYAC0U81qosPlzR0nVHS59Hs4BCMJQYa5f+SOeubg3aRFhZHRZ4IG1gX2SRM
j/WDgZ8bctPCjnWRA42Os0YIl0h2cpa84A0l80GJOgHX9Skz1oX6xAB5oJg6
37esUXiyGqPwD88o7t0+FcYTAXKC9VyTEsadcTZeDNqz5AQ6db11sfFwX+/W
9QBQ3J6I/FBzOBlH1QFYRYuETxdvOaxUj10VUBh/Q1wWY/v6tLKdGISn+OhY
SULQgSI3VXaTY/hWx8g+bfA8C/UsLZXlVN8VxjHnfB7Y3OjcL5FfkEBgfBNs
ErR0JZwUQCnvNmVkoX709HQiaW5ocg4JA8EPknz9KgTRDWcqGoqWP7aL7RpJ
pC96rB9OA/Nj8dTK2ffHUTLv5RqmPjPbrD2iWdKeAsx00en5zS+O2myPzSpS
vQDP2u+MduTOvdHnyyEJ4Ea3p/jOIq/nGAPOKaSKL0o7ZERokJyCRbhbb0rM
01Xp/JpizqypN1V+M8VAPPv/JzZUM/ZoCWiQYicSYkvsKHymLScMa81hvxFb
LHsRKJoJSw5nR6obJOGi0CsxxXzcQ586poi6WKcBbTbhM7XO0oKSQgvzLWXg
NLTXka02wvAYfowINbmjSccxhx9h6NGPVDNidJd+621SUvSdD1yO22DXYKq+
7z2qnTPV2Z4iMc3bqNs5rb22EFgOIMu6wFs18S6LEn5D133C/f7vmgh70I4f
A9rY4PcMas/PJu1PxQnAzYU6lu0SMdQLgRZqJkqmr5a0Y9b6WuSIHv0U5MVt
ZKwMBq8xYQAaUHP9nQSEC0/SESR1ZNPDgoMMYnN2o7QKjfuOOYh808KZl80V
Phi+Ss4jdY1GtN0PPWXY01cZyRZ+wKg5TKZJczBO/i45t/KKQ05AhWeL9AiD
bA70kqDnPiFgQDgftegNL70qbxklQbm+XKGA4qEs88ttlU3xOR8+xNFPDjAl
CUgqfN2BhA4pUIj/IaG9b/VD8EwW2XFyMDt4mIzevDsfyy/gn+GXBHmFi94/
OoxuiP/zrsqnb9Lm6jjBfH/n6+QNR7bh18noXYHXjDuD+svfSbQxHhTp/pFX
/vpT+uZTRod/cAHw6wP+89Wjh08fPfny6eMnc/zfI3gELN03yVeT5HevTk57
RpfMZjP6G7dRxZGVKt/UaKhmyaGAHyaSbuTCG9gw3ySHB7O/9QIc/eYF+Ctn
4NMX0X7xBz5ecKuJ2juJHCqcFDxXyTffYp5+nTd4BD51QxzNDh4lo1NG3ugI
6MOPTVRvGNodIwtGy0F8JQfxOzyIKNvO0RF6Rm5LwImEEoX7Ly2C88YCMPgb
8BfWm/sCGRDQNKiUkw0FJd8nJ3fEuk8K0zKfLl8RNSIeMuVb8GkaKFN0OClD
8rU0MYaujc/S4M3UBNJKGR9UfSmhVMON30qpVubuQXeFGx1SGZbWrtRZPGZ9
DOWaScOwF4jJZzxgBTuCICcb9iX5a1ZGFv5HjFHDlRNlGIJYsTQamQQNZgcL
VdBq7INml7AKFMkCHXohblikQATaULu36OiQ7CABNQFeYZIdqgrJTD/QeBaq
DD5RT7AGzw57b2J6UQGHsdXym3RM3lYzNN+kZ/6/ovk0RfMYfBgUdY8nSbFd
X6BNDetRNuAY7ZXRfX9cyl5ATWFk7qVMP/0EdtSqsd9cIe7FajQIjif1YbCN
rjiAF4+FbH3eUhkqsMf/zvTX479WNZ2KOqK3wzX6f6uGOi/0BHbKEQzlyYSM
YJSmhAiraDKkNv2T9opWWBK4hIyUKRkp40/WgxJ8+4gifEEBvDs04ZusqvOa
0o+nMAx4l89Uf5RPsiJHlDL7Uncj9lBwCJpBsHAeJ3ypxN7DV8ZdX5L3veqH
j6VkDCHmcjMEPwwFxlSUR5GO1Nz+KA8UleXNkuiF7woJpvsCgt2XEhcOczho
kIW8Ff/efocRP/EGt4W98QwPDHhs+EZBYTJA12VEyKkqMopn0FS7GPNVmc8x
UeQSLJINT/ImWydHDFAx/YTBnKLPx6fQssJctxRxXG5D/HkyyGfZbNLBY6u/
VsNQa4IkYqBpX/6Y1zbAsBmWFdUkbKosw4z7TTZ0PuxkgBsNFg/HZDrd8JhN
Ps83UrkYx09vESeuyEm/6H6IK+IHMSiawMJDTJlCeSlWVEumnzHLiMZhtBKB
QTkw2YEXMLaOQ0ewEcDmxI8ExUNpPx02xnrBRot+XPH3nUw/P3LEZVBsiFZo
42kMYkzxjlxSO3U5oVQwHj5YjPKmJ4xOPnd5iWH4mtAQRRY/Nm/qbLXkwaMk
nW43AWHHpyv35VC98AcNgUtiWnGqeZs+AtOjE8Ew8aio8r+RdxRLihfEYesq
AlTnBuWTRBzsQBaO8OvbbLUiwIDmmXKq+cI8ANx1NtgzbVKN2tpf9+sQl4tx
CvAACo9N7bNxooVTUXQmiOAAKZCNjbeUMk+Qi7PBCPyCdUkFZrSZGgY1YmDT
xsUbA3c8+Stpfe2nlepmETwUHV459hZ+4qD7mLNAHvjqAaC4+384P39jCXlc
z06OCCRGCDdreRCh8jDNzqE782xQ9nKuA7M+CqPMEZqBol8rIvKGQaVoA8E0
v3l9dj7+OrnCsICIEwuBLgh1u6VYcT0HwSOeni9rSOwttbhE3hLfLjrjhiPi
fUzLRRNm8NZaT4lEXnk1rgss4zfkKx4RdIw83F4VRwkKbB5ngmiSu+HM140U
jYY9itlTWV44I1tCkEU1ciFlQ8OndX8MliU6GaBHMBN0k+YrBgy+zZpqNz3B
PYvmHwXhaFapphykPGXjuST291m2mZ6gVeBewUKu0RukVZVL+dULqm94njbp
xM2WDBJXOk0eHT0Gc6+US00k5yDGEeIvwIL/QHX5Tw9Iz5/jFsPNyCXttUoB
Q/9yrkJnvxuMjobLu5JwFo2rdJeqYURNnHhVLbfoFsMQ7qGn4hcLYReg3lZY
HIGIhEjz6xnoKT2RiDuKD9aOPUFxht4GwEqOmYVD8FcJ2ZyXBhPAgTdZ0QNd
vtymFSjYjDM8nC2CQ5ojFggcLgxnpwgAx4ykVhUocBr/wcwPLw3qPCEAC1X+
4+5U7B+fcDzKEzzXk+T5ix9fnL8YR5Kgd1QEnWYSAWdYEK7yiwBLdgJXQDck
dwlJvF01ORrjaXdWPIuGYR7rBEk2FKLBjicXDOfFvKtZ+2BsOVN13LayIRZV
txf4jmdRptNvDTq8eAsuImrKFdy7QAB/WKeAC3IuS/zSoQIEXjvd5Igth0/4
RnEanjRUsM+iJBombrzVqAo5r3z1udRd03H0CkhgJ2Q9tu0fOCBRtrQRM75T
5hEyYy505RKxneXtYlnYfa1NSocMxHxeVugBrRBoc4TFHS10RM/p88AGOIaw
ORvUICMF+Ai4p6JHjAPTBw0ueFvuYSbl/a1TvflOb6G2r5YEo+iiGCMHYAK+
zn54kVHNQbgr+CYv8ERitabBDxT3G6GhDBlI5j28yYSX6K4hcwonGqx7bXlg
wAxadUgtq2HvEcdt5dTEqA2eZRaG/gV1YuaokEgfWWFulIPDO54UCFXFw5c3
ckMjFiyLYG1dZHa7lGSE7D8DCbVsv1zKFPPia+bq069DpYoiK7VMgZAlJHgx
K1fG97/v8t4mQggWZguHFfqwaKBL0Oqw8vG8iWrMOpgc3abKYYUnNi+2GpYg
sHUqWv87X6bnkalsuFnNLBmjrObxrbjUUYIbiDBoMOncyY2jHotLZXAAb2Ra
Xv4BbQIWYBIdHLvwScQq1WKuUfDB09ljK4Hg4IFN5QnsdjKUfinZaxfoITFA
ovhYbwtF8nBN5h4uSXDPW8WlBt69m2ISfij6y2fehVButYsWDl0a4lNCwVAs
QFXwUsYHz0jbOh4hemz0PrV3hlEMkPaQz40pMAtHWVELLEfvwNVo8rt7Moht
DsltcC0bN44ITSOWLFPriAgYPKSAPFe6Skpa4ruIGcoKmKlpuZzWYvTyhTgP
m23DAiiBL2C3g3cnERxDa7DY008JzBaBT7k4i0fkNVwMSpUVWCHpZ4ueaQmn
qBR8UN83lijHD2OKBZdl8sMJRkp8BS/LqB7zZKZuMWOGEyd99o+YkW+wTiic
sY5qzqxPGdxFLPq7Cak6lD8GBjqcPWzVJIH3I8AIz3PFelXu5gtag9bCzWJW
HfpsyDHQXdSuc9wJZoCZVnVhoGLHdmB1HA8F6bvzii52zCXjiKc2HpGUlXst
s6BaR1QNJQq6DQJBjZkAy57zdd7oRhG6lFD9y7vbeaRahohp1qrImhjMJcGp
GxT+RAnGAER06As23eYOlqQAt+/U0XZWazeA6sn24G5OUTq3qydYHBWDqzpD
xBum3HazZKSRRdLSK/IdjauTk3D40ylME0PcWMBr5pWZneZCM0N+6SRoUQ4q
MgOIVu14cqIQn404kcKU4uxoateHBTzFW3pRYtmfPP03nsS+Y1h/2jlk0dNx
xWnRwi6VF4tD560DLPFoKh/44G/rI38+RgELtqaKrSZjcKKUb0oyFtYEq/8s
RNEusadg3IZxr3G0oQ4afA/RK0eUGqTaBN2wNMF6yYpsRcDLy0yknOkWQvOn
rD+Vd2AmNX2og/qWB7bUw2TE4XQ4x/cbdqwC4xJ6gWwj8wkOSc6LHca4DVm5
hfVd8X7NiIXJtBXVqC1zy2jCnxZB1Bxz2ca5sC0860LkZ9JC/kcQvV8dHBw4
jOaXMy1elMok2J8kdoxsSqpvijJQkYoJh1dYoEnukvJWWEiNZx7AmkqXG7Dw
cEva/wJLO3z4JHlGU6P1w3BQ4RdCeq4LMjoPk5nXHHZkdX/4KPld8ugA/udL
udELHC9Iwkny8g29xbvnbxJcXaE354xg8kguh4mXaEKjwUS+GLZ9RX628FEX
W1nTspi6y2rcaLLc9jZjHfj3+Y1s9IZIGSmw1RDLCJid9QaB/O06E2cZ0UgP
Hx7pWC0KzXfDmcaZl9i4HRVaVlV8IfImLstegkldTw1Kam4pJe8lv7zcIXwW
Ex8VeGpIVkIblbZiyDbxPYqM8ju1Zx5GzTdi1/aW6ig4KBwfNSEHqTKq417n
ROaBYv5Ry3W/Tfld1IX/xCKHT6hu8NUDZM2Co7wqd2vLs0WMHwpzltKsPKs7
VYSk7uWpPXX9ZY3jJgHLZBmnVym6ZPCDfzEGEBq8D1gOBu+M0UC3r9PPA9HP
83AvnglFogtzVSpGQrbaRNWOzk1xERAfJJXyxnOuxtK7ofzYcbKMjDUEVa/Q
M/SKhSvJGHkLrivI31Ukuuiu5jyzxVykqyxEDdAdWiuFIIXiEAQicF7Q5QsM
qNnlKxD75GFgOT+iz3A1ajjQlLRPWkl7zp5YhMX8LZeErHkm+ZTqSbPIQAeP
q6xGAy1gVTBuBOmdIKUgX0FQaoV7ISaAqwyjgAmdcgarkb01J1DBgvipKb6y
ptswsw0NyZtsKROYgi0ELuec0txof5F4A5eNfk5hAyzZng1+pn2fX16RPXZJ
9TH6bLRay1ukZFFWIH4bHC0bV6x3zOVRZDC/YLvmSUZ5scJs7uJ4MPyppLBt
gDLDsNGyR1ZDFGqgunA4SKgZ4rjE1rXcIr9DyZR4LwvOpjeY1Ob5ge3cOwYe
uzvBXHKVynyT+cICrr30XJPpyKRa3nEG9qWGVJmYbAo/QdbZGy3w5GBN/6TM
CXWgLCvCbOaT7Zxu21k1KSnJRvGW6r4itSzvCGYY588z2gD0hgOYzPKCtuhw
W6dcwIpFZ1uhXsGT9Zi0IhyG4bTGphQwYWvK6CtxxkmIWuJkvcNXeumib7/e
Y3cJffqmgos/4CqF74nYY5e1k6uxwnSvP0DslqtNtccv2qXuHrM5eIfZMOoY
QzoXRaiUqorHrjdisIG4eCQKSUOEAaMUjQrmjUOBqjvmGqZkSAiy+Ihb5KCJ
XrZSYSjll4wntHdC6mgUrGLj6KurExNOJxxLWl3kIM+qfLWbDEYWdU4dvhbT
r+nORIh7KgHlSqYj8E+jEYCMvNFSckqZ4B00cTN2HPrukFGHj7gyCR8p/OKO
RCsE4Hg584oBAKQ0mGDQXU2OpWda6KTjuCqZauIlwGIlSuLWTgbC7ujPspzJ
X/D9OaiQFQyv4fxekSMpRQj0GOsqOx9sawwGPug6iHwiq9en4ulWcDQZpYGn
1zMHGIbs2exwdkSV4hRfcVuEpSEBEnilGZYwoEhHezvZplvSsdC9FfZelKAY
jIbn7nCucXLE4XblKEs8SCo9eGeT8oqV3H0s8Czn1xPLg+jUjAc2FqYAZGpQ
OVwE/Rrg/JCf6Xnv9jiRYGBy/CA0tmiHNRkd4EM5YRuml0hJSMSelyhDZasJ
ZZMJZfY2MTq6XCLzFgXLORwAxu6iXMuziDgfQWl7/HKPE6uTQ2Ge5J1EloO3
pSJdprQFEvronF3CWoKLgnGhtLOy9B63nMUjidCnqTbbSmIA5mVYsbonTRxT
W4tamgXMwYLB/CNOPtrWBIfPcDpkwxJL69vnFCm4zMkKwyWUlE7tgHJfw2VR
SiSw+iMC3e6J5SjMrzo4L3uEjwJHEbEUxHQ0nbYb+iaSLQSl1gik96SCLcRd
Ims8Qejcs2dqgSJ7hHGSuphMMvJCObZC8NVJRzv/zQIPgcQtJMbHA8bX4r34
yQ77xzO84CCoGdThLZmYp3VYAiUPpsTNP4kxEgmxXCgLF8mh2rOluNQhxe9X
URpUmXKjxKDa7B37jZUCuYpEvmDGa6MrH0OoeAWKqIYQtp57RQKVwB5HyUoU
ibWk0xYSuHPYgKjAlzQJbPYVsTNG8p6gs5qD1jvFxQshkiKZd9sErmrCpzEY
NI1QRJjb4Nf2GI+RexAhDeBIb9BJFQkAg7tEQsPS4saxYvLKg9xiTeF8RPgS
mlR5c5sqR6/VG0gxSSL6mWJnvgnXEMfVmap47frDohHxdvDSAo6Fl+uBBXv5
rsqVje40IBX6MD3UpoA0Ku7m2JkNe9pPDXVHmjdZiwNqoIx5zFqVRhXT9a5G
bLBjdCTy4A65bbCv2iF7Eu/6ciriel5oMMI3Fz5F5cURCKcrnlbOFxoxouWK
mLqSwMUiqfIIVMzNoCKUdhSUngy4PMihriPxbOTztA/JHWdaI96kklios2a7
4eBOOx09HriYjQamzNhkAx0MYw1l9xa0a+4kt54q4wFJtD1bneM776SxShzS
fhVC2m/bDVvO5N1+vWe5D2HGlB4iUQOYfU+PTxDDr/i+rWp+CsBJTkO7p7U3
08f71CQtVRL3ntEUkXSZmd2VNSTPWiYNT/jCxFsotMMlPW6TUrfzJiGT1p/J
vNj58GtPOkZHzzHkDgdHqLeI846TfaYcR8II8E8v/cc/RhDXP/2JuLtVwMF9
te7kWbnAbcuGmDJ1n6eXdXKPabq10ypzeX8X2iS4O+ySUJ756z1sMzAFHQS/
oDmMGs/BXNBRJcW7LcDGy9mKxDAt0rDWgVH73fM3QjCoGIGYxpd/zKknaanE
OaNisXKQm8CqvSqZlopzQgoLJiANIRQZUrOn4RShYqTXXJvw9a63ycV7YeMI
nolhCn4SGLI5BUtgFDpcEYR3tuOKiOWVvJO7eO243lP3tf2WRJf4CApCqKL+
NdzSzvLYuIpjjbyLYsYEFLPqx9cqWatwsYVxckcR6vZgtMHGlsFtFmiBudPC
BFW8GSOlN5piVlV5XtzYhp/t5i0mog1M3bKGFFbMXNTENRdZ6Huq171wXJU2
P3kW40NtYkHU6wLQF0zVz2bNXvr5bherprxkpORea8Fzz4d2ZIy5svCWx/98
ClH8JOAGU6OtN1Y+PtLBeZON+Ank4+v8PUVvNjq55ER0ZlYLrVFfSOyDsMYI
06rqFm9cvBo6ck4Lqb+GmgOUPV7urEArY64z3/dLO81Qr5RlTokBBj6ynRsT
CbtWfVHnKEfU7dTIJLxI3elW09uZTzqQGBuIMKD7xg0fJ0Lv6SuIkyhj2Wln
N2lGQ9PoYuEvqE03OhvZ5gr0L+Z8GOO0r7lCq91JHUr5KNFcZyJVMNQ1XXEp
gC0wXYN9U0j5kc2qsf+PtOkomf/bDiHtLvxEGa/FOjTEIvlrLWVquusDKITA
/i7oDAG1BY4AEfhkzGXri4CmNpGYjHizC8bKtVOxyaZCp5yKjkCVl9LdTsVU
3kyiJ2nREiwRuB4pdab7+MzY/tXpCVYVRRNIQ+2pytSiHVgwOVb4hQWrWj2Z
PlFw7m15qW6Lek0Bic+pp6rahaNxGHGYYpc4PjD2I2fXYdyAA5bI3EPwdoEq
FG2OYjFTh5RL5TIFay7EDxzy+ChmiwkjotJneYKleNcZcixjwPTyMgtJy6C0
1Ug9mj0S57N7ppX9+p5YYtTvPqIK758+wjQblbQm95kXj4nDPSu4kPzHJOIJ
kYhzaY0++f9zhhtn+FeeM1x5w/1iOM7w5GD65b9zzvBohbVAvWc/fpw93P1o
wnG5Rm2yYPcRfbIAkEFuJi+kexv/1zsHseQGchY48B1Eqe5LT9Gj2WELsD0+
7siXj9Agk7zPi+Vqy92XceCtC/U9RLD2mZ93UChT5JOg845MmVLHRuD511IZ
9/SHkNgEgwa9bW86V1xXF6bJsFConKLTrlaJycVQ74tDbRMkO3pjDYhwD56L
bFW3TWf3RIeE2f/Eu2RepDK832BGpaqmTlPi7m2D/yKhTAWzuYUj4K1PYIVc
HJWP1r5KNqofTW07tA7GQKrqLwnsxbqpI7oVDcploPQdKSFXR83JqnBUUtfn
cDbordzFwfcWu+IEoMUWzbomS9m0xZf9epAbW5zE7WQb+FJKzudH93Jc02BM
anjqXiv2MA1vs1/zmYNnJZNtGtbQEjpaOXyDgQuFNpwzselbVVm62LlkOxMq
YPkrRyrNNnD2gvXi0D7lHN7UgkDqSNBcRWVhnKV2KOLe/Wr5dYuJYNZDKCWF
aqmvEyIBZfhrNp0eHI21bHQbgQ2EGJEzMiGKwj5osOcQjYXT1V0K2uP9jcjd
RqRMnNTUMiEx3Mz3klSqUOu1Qghvim5I4JvrsVZYmiWT4QcTt5YKuXhzkrK0
ztWOTxeWwqOujdsGPF4rLqLVhNnSKXKEKHJSxqRflHG13+0acCfBwryFRZ/h
TscXwbiYNiHKg9qez+sku4hoK0IIwqZ2Cv8HH8Bdq8wawVBRQcDVRBVaafLd
i/PTH+KChxC8QGUhEfsVl5xZjoemw2UDhduM55muvl8nr9L30xPX7QrWjfCA
uwxz2q7zXrvJoYaP/ExqPQuzIixyervZwND+znOlW+Za8slpkBfcgTOxPmSu
PqDfCqY8W+wfuOKE9DblZsI4v5IYosnhGxCkOwtZ+smAbeou4e1jcASOmGm3
pxFiZMeEPibMhvHXdi2hfp56zMnBioJXLWc+dYIQp4ZDavqKgdmepCTjdaLM
U0sKfMcEJ662ggqNKc9qOeE1dwYOVpOL7bKqrMkXOZodgFhDoqiQ31xykhZH
i2dtNjhZIatHYAcn2Hqpjqxw0PJmd1sRXxWhwuybN/RGhsu9kR6cMeYEbxDV
22FuWKHso2K7/uZgrG5su1yrM/Pc+IBQGfO8AgGGQLM5+tHYt5xZIKSEi1KS
ofD51uwuxs+0VyR6T9yARIiCh1VaWmDNj5N9BgEVFuiK0loE/EfCpFCq0N8Y
tgnvhzn0AbdHoQJ2ytf6kYXZ31Ecc2dg9sdEh6asFdvAWjEWZ0KFjjKrww+R
H4RrckkGWd48e8861z0PU9NlgigNDJQ12hkC09V8nGSssLZGI6F1nCb63P1C
9HphKZ8vk5HmW16AVG4wiaLhR4oWccpd4illfxtbMqjOuF1kW+sIJAy9C8PO
3xUoiijOSYZRNKolfqQJBGbg+GuyFUomPvJXzgYvmygPXmdNZAtIKyMqPoHv
xpz7XoXD/RETgvRh4NFotLVMI8z3BJbWmoGwA+MGioPBGW65mGE7LFzoc4xB
4IFR78dLS0osRG07h9dgvcJyZTWhKYZe5zuYcyzXRgsxvXBlZ/2+zk2e3Sry
mu9sEVI2MGAOHfYoxP56bgfz/vWg/vQZSHpmQLrQSL97Ehx9xk/wf6nSCBQz
lzL1TAW7NFKOMhgR1kCmbhguanS6Gg3Kof7UDmAkptquC6f2vFPAkBRplUNB
Oo2GeOzFhw9jT7CDI8h8zwcS0EZW0DqkNCXYAJu65MwGP0v3GpuDNHzrfsXa
zk6+jFQinY7WNRBTfE0Ru0ybjdzxNool6aTgpALAocMLf+A6du3Sx2I3V6nW
Bxn/ltyWv9IVXWo3TT24wfSkELNAJYKvEbeAJ6+FrxRIqBGXcSUIml1uKxAh
JcjWLRbwLRh3xDwsTPgxDwaFNnCOegVEPhBK/z6Xx7D8ym7AK8VSgWG9eigV
UxNtXnW7+G1wgy0ipFXfM625ZiYkEt2wh4uag134zAUcBqOom7Jya6Uts4Mt
XA46IGOXei5olokDaZSO3CWAl76kaPseX93OUnv0rZ46s738Sj3hyRAkjzb7
gOPrLZjCM217K/ymvQgG/kCpMs1k1BCVb4rMITVMFRrcrZ0dn0RtxtEwuckX
29QpPO601lPqLMEgsoqNPUN4HQ0DSv6uMDGt2GCiahPF7rV7x9dW2Z6l1Srv
vySKsx4pMcYnNBs/V3E/kddtvZZE98g84TiYBXA4tdDxax3VHs4253IYSIFH
OlW3zoFsraqvP7yXaoKoPh4MmCvKLUv2Xsta7uIsdcHSvWHYmd7dN1HZr0qo
KAcNd+cJB+1CcRNY+iEoxCFnZi+k10K1XUmcORjoF1wwOZ1+26e7I+2u/gJe
39JZg4RYZJDZkxkXDYvgSNUY4ZL2Ylfg9sIYg5TIUr9WWEH8faLsAxu+FlVM
4fc3mrMds0oQcAbzCw0Sb6/SlGp5czhR4f00i3mbaRstGNIX8EZfOOIEwQ8G
Uy5ahft1X5+WfSt7iYGg9E6LO/GTrGtM8byoaiSiQLpKjTKo5STdalMxfjab
iHkBWidv9weNJoMRIrLKPzPwV95SGFJYMvk6WAWaNNpDjyp4JTiy20graqnX
F8swRInaLDGBvrdDp0EL2OZSGeHOWW9ggCenv2eEQQhBjMk5UXXmppGWrwUx
Zi89qrfRSHDkyysXGMNofstMMVGxoJLDmbTqfFmLigniQEcLm4yvW24xksQt
aW5T7QRG3ePLDqkZRdEEBhRkI7wDSRKtaEM5j7wDoAqHL96ecw6LFmVIkVEu
wiP9K5yqEkZVpGza0tI+Gyea7SaX3gjrFEkuMp4WIvmZq9rJEDzFzckNJckV
F+9hrmMX1pFOCQaPeQAXDoAnvRSwhUGrmRAuB9WYED4CF0Sqe0JVArms/SbM
7VVgS1zYnBPBC8sqXOAFbbY8MFpfevI1FwZmfeZ5y9rd6jEEKdHuUA248FTI
shPxLFeeH5FUJFxqaENeLwbj4UQgeIxX6+HRQ1HeHE3VU8R1naiqtZCNdIHa
DXpYvQm7ESZIMccnWOXgDj/byhYeuGOiRSzmLv6mlQAoO4WrOUroPRNjTKcb
zxyX0YLkrJlbyu/WwG9DMR1E9vfoMLjz69YPpZ0ZU3eGIqK8Ux06iAlsYahX
WsOGlJfsfCs8M0Jlktc9x9KeueZp0zuHiaE6fz1iglH4SFSEnFNh6NOmHlil
W8w5hNwiV9FLNDK12oHRr+eSKqOka+g8q+it13W2utHQw0W8EFG2KQoVtZcM
BkyzQRRDIe5LKqQjyo7ZPi/K7lcR0UgyYjuaN1ZKxRYontGN4RrvvphloFvj
Lc0ZAYKPwxq66JTw9RSljzYRU9AFFim+RxW/kbwXae4mpqa+JWuAi0wl6cgY
nI6BTQKZ8om4s7EXsNmePTPeOymcVBN/tnPFxMVitOWZuB0CV3qlXs5pOIPP
wuy9DvnKgYMHxmzQPtM8oWnm6DhWAtxtN0VkaoSPE5C3s3ELrueT7G1OKfFL
JuMP1ado3+ntBd/GlJCwn1czrQJg79fsK6Y65cCappc0ESF5+DreAz6f1s4M
19wNlKd354Ie6jdKRSZzYEhVaSspI5nkPWC1T4KhMdMBhksvq3RzpREiyVdw
KpS9kr5D4hIqUs+9KstrjPbzLk91PDop5HCJS8HqkKTUPn8kGDWmP9ioNJ3A
SxYyGgVGpika02zKIotuNpCQPtip133hbZ/f7QRqxomW0TMzGfmYYl4Lz7S9
hNsEWvIYeRTkPsQ83lxmmApAPfYC9bzW/QF/13CAeJ7xnJ7lXKCSSYRv+jOu
2w9YIqF9108d8dMbwX38eq8mK4M2lWAufPCoZtdBg5Baqd6CqwxCUMlxmPE5
UsCKxBmwr/sq9QRwfFmV19cOOS5i5L6HlLyUlpFSfO5p4ehUypMIY3IXTha0
wEat4b5NIWD0qE0Bpa+kOs2s8na7C/fucxyoOUIxyZxHA80G1hkjRKsZ4oRq
3+Gr6LZY5njDESEyDZhiXN9s0C0aQjqvL796+sjJgEczJawB+VxnDMcL+DAY
IpMEWasxkYH9SYrgjw2UfxiGmCNQ0WkAWh8CA/bWeTD0gHi/FRzPEcePEPoz
zKjD9iNxwjcGudkbn5TAqsrREB1tSqt109BoT0BSQcltHcCy3QPuG6y08myC
Jjv2B08VexGfNdYi/UBeHb3umY8OnYdk4ZRPfI9tESQfjiZUTOsYUczfieML
yORB8OARA5nWWENJEaY6cE+l9TxFrzdsejsWJfsrm63l85mwUCk1meXDU8Oy
CZ9txHv1AvCDiV4Wyizy2KTmFIngupA9RtUDLQJYR3BNEeHKrYpeeYhZtTH9
iG93QxOIw6BaRVG/vS6SwS7wWLFMXFTpksiYrPQ/OiSTvf5WHShPBFzMmYy2
dMcpRMQalfaR9XqhQXVpQsPFCduIF4cI4HMN+hJjB1tV6GGUtc9o4bOctdJ3
rF8i7cFiO1dtqNUwSL2IndoK5tphvZNGBIgix/tgWhh6KDcGNhAZDpuSqJ5c
pU4MqDWrexQKSSSF8GE8uGW7iOtPIysMhUoqCiKaFQ0WWaBgwMGivAo5iPsS
Aoc581EgiQlE4S7GuqYE0azK1AqlArMrHmzUNdwnpsRI5FbrLDlQgv6SVFSv
0XZrI6Ok8Dl7T2nV9gAmLnUnBDvUTVlaTop3E3KxH8sz+MzE7Ig3iGQcHzDW
ywFMEVSacSXruRrjvqROcZhpHdcC6RKq4GVCKylniiwKUVs+FoFPorAado5b
gIFKU2epDnZt5choJud4kEYwDG3uBgLgtipJ6voQweDC6o+kRRIZGP1FdlYe
RSKzljOMj5Fuhrec6vIE/zBwtiClGD51sQbiz8nEAlNbDiPstLoce85bHK3c
OnQweLvFNDUOxNgnYtVv+cadsFZZNwtNXeAPX5iJxo/2Lh9lwGgKvKtjtSoq
V84lf7S3VLC7GxwiKupKHpXsCT/yL1KJ6hjQncAdRaWDARB4eDB74jOsmFbQ
p3BLk2CbxlWR8f4QUkqr/MJKcGqg6A8HswNQExWViG91LZ7lLLp/vUd8oR8i
FHfPVZiGxYWcYi9y7LOLpbiLlKTEKuJuQBtOHvoC3tDZGZ7+0J0F6m7uSicZ
kxLwHEZg/lLUnRif3Lxr4dxUDDeYjloFOgaeXz1n/jF27/PuBUqIxLBB+9h4
JqPyYAKhRNekLr7Wd1gpC0sRxLCNH35yKrYF9jWGUxlcChO3pmMIynr4/Yvz
5AH/x9BeK2psjM4cRujtDYZlMZxYRyZrZFVhYMtftVwKfyIWBTw4nB1KXqTZ
bbh0UHZQbtBDxLE6zjWNZLOTILX2FtYWdAn+zfmFPrY5BooGeKjS+hOyrFoo
vtElWGrNkrHRNgsthcyxkQOopdGVTx4RwM0J97HkHZptVcTjoFAIDYGUpN6n
MrQ1kZwavjL81u9Ot1VYrDx5dEib4CUXl0980NzeEMWmbbvctRkES4NExazV
U4VeVRkgXj53kX+j/aGlVXyVEmoSnhDfy3KEYbfjj0gMeF8wmDW5P2+udmho
ID/9dshh03BUjtrdAyQo6YHYppIZdcwCkrBsVH1VUlRMxgxGT1k1SBwsPFUw
UPv9JZE7Ku8QcshmK6nFTl1TN3pArb0m4aZDDiUNlWxkhDc7++Hkxx/HgQaQ
BJtx7vRyArBFhQlIinjwmQoFuWHNnaetOTziEcAvMCouc8AdWrgLF6VzMfyp
cU9LgQSxClo5Lm8XY1QlpgjRsJ/Wea2/MmYhMUYMKJZws0CZxNS1HNNzJd1h
tQNZoNaoArRcAV0wRRbYqK1vheK/M0eqeCenQV77XKYlK0upQsJpk1UOPO1w
NzSx0S+vneEtYB2RLqFqWWl5uEiBOnMyvZrn/+ko8w7vjyDhCNzdigTFyvpD
BALWqnANyBrjNTF/2QKHM1rvV8h7WYZ49K7gai/VT5ddKFITvUdVzAtVLW25
6QrFq32mCLkjQ9Sq9ZDXpzPkiAOpjvmIOhe7ziaPZw9d6epvJin6uUMZ8reV
ChMvqTir7SfY5KDSCXgQDJWihI6pchNja6qVfBjJYWtrP6NLQ2FfrlVwxoeZ
z7EsGQywGQwIiJ12hMEQAsa96yuzApEKT31Vt+9QO/uoGX3a5r0RpRtw0k3y
L1lVcm0J+tEUpsfNfk0Mp7KRfCPMc2mEwn536BrNa0rgm8G9wDh3KnEK2YK/
3oNbIlF+Lc5rYAVED6ny0aWIqa3EFhJd4M0mCpo4NH7PPaRvr6jk2rX4lRW0
lJsun7X9jDmt05ijVCa1EQBDJdcgOThFW5RzpsOCnvs+iowkE8KdWjsh3TWS
VvsjNa4ut0gLsRA1ki9dMCupsUCsNW6x2qkBu3Yh9ayqY8mxd1ueSaDLzart
64p4rTwD5pWa1Pka3uYdCRAaKsnkqAGjVEFvkHtfnsZIwhTcnFvFUHMQv6UE
2vzZH2bRrUMbhz5aG04EhGXCo9s+tKxdKTbFilFmHZQnYrKZoppNHN/UIN5A
tiK8EoU2ZBe0Baf5jago1WO4qbPtooxXTzZQybY2vDSi1fiKmjAphBlHnhCq
1gpdBuV8ds8JbbWiZG9g38OiticUR2k92FSuQci0ZhRBsRWGPpS/5aSWCHfP
69FdNHq45VmbUxK1TXViCByqbSJB1h0UHzJuHcilPwzlZM+Z2vRZU0Rk/r8p
saE6QaDXJTZjOoPjMXKAsEnMLn04ZkYiZORhFaSSUgr4EIUiAeGe25OZxiUu
kmd2+4a235NHyYjnaTqWF7vAisjQc4UL0q4yeBUOeQc8VUZtJVA2PXkEVlJD
lMqeNZskxsmLsz8fHn3559PTV3/+kpuvpzqJkjmMd7MeiC55KF8iOkL4Wfe+
QtQnC0TxAvyONMDDd2I/o47bqQsSenSFxqIn/0jBJV9z4SegTbxFoEKWJSPF
O2tLkkkIMYQu4Lw/As2uwAbupO5MsmY+U2pQb9N0+7HgpukrkWhV0XQNI+q0
wOJMWRAsiaRMAqPnY3SMOCliLbAXWswol4cGV3mH8kMtaJB3+WaLgHwMmPwC
1sEEXZWs4ZK6KpOunjJ6Mk7Au1G+jQA/XqXYv82QKNX8Ksdw5Rab19LBR8Zk
qRoVrKFUBMuOWa0YPknttiodMaKgdkxDLXEWMvvYtxcYGAiknNpTDPpormVC
HMQ/SGvHSI5sjFIySuCN2hfGxJTNOprQMAEHDy9GJojvq4sgAnjfHn02Vt1J
QBMWenCprxSx3JDl6oyZOOciIVIqwfN0MH8sAI/lKoYWmRBVvBdawDrrcM82
BuPKLkHIrcmVTCUu6C+mGiIjvocX5GZgE8dv2aache0C4kwboruaG5JcrqZA
z2t7cH0FDzbJvrfbYKDcHVHz9tAYhgj4o9Ir6yZSS6BnvUF4b+hTzVfgwtGi
Y0eZ1v3M2RJNn0Y8FpTD5jZnxjnQEbO11uPwACnbgdsKW1RRklPOnbsjxieq
DM8uy7dPv6kmTqntVeddhKBI2+q4FuMCKcbWsx0CgtDG7dKahAXvwPvSZgy7
+7B10VknvDNxm0y0LzCaJM6GTRe/KFO9tSxv9cj2HVhb/QJS6l7j1gqh+UxJ
TbzqOVOk4CEj/976ZQvuabuBMS/Rwfzp3KxQTMaBzbDALrHkk8NCZdqW/RIs
J3b400VeTh1dPk++Yeys0BK3nOxV7VEgu9UOZuqVJ9c/42VVQq4sGktSAsin
3HWIV1OKSqjVDQOvusCYCZUTmEkdpQMsXEtwH6KL0S/lsOgxxCGxfCf8bsPV
GIKyllFiYgkusxNp9kq5XNLrCO0RBVpWbgpmXPxANzQgGt00AtiTxJGTgjfo
tGShwLoCk6WvtPhmWeNkitXy4pc/Cu/MKfeEfMtD/oMILYxdhqXCtlXl4s7m
F7I1ledUu1KLssneX6Ww0XNPRx11ni1AiVmL7EBcigMNFYVvTHja2D5haML3
GYKwyK/GpUkSTbkjgIIn2GoAFhqUjHM5/eGUkNYgvNaxF4DrNBBQ2m70qYuJ
9T8OdZBRwM1lwyQw2JET3KqFArkTiUexVeSLdDPlE++GadhsEMPLN33tMuzu
DZdJxyAJ6SuT7KcG09u0vPCXCJiUTxsI2ji3eBr1QBRkIs44lw9p+DKqIEIT
0JHvC7P0BQ4FZTcIN+S/WCLElJNniH+SBKwWDnEZhlUbNYSw+yIOkOB1vm0j
w6lO5vaQtaf3HJGn5N/njjaPtOAhCu5GEbYPiZ0x7QQYGSjW8gJ3Y2qY+W2t
ThRtrKhVSOK7vExIClXZ1H9YO2gxQYhXiswdvSS0WM4/pVREeHLNFTBhzbVm
MOSOKFNNW6C9Q7Vuxtwx/+S9M+t6UQnPFOcLJL5pGTVHcs2rRWNoAXVm4wCc
peYG8EKakuLQDImcRWTXU4VDYo1iEc5Pqx20EMW2CleeyI0TjIFQXBFtfCAw
8CIuRpq0yt9C2Jip3RdREIrrnVKqv8WtJAH7NImZr7X1+aEor9R5GZoXgmdP
g6Eb8r8yBa8vmO3G80Erz2ILp8BBrjSkEeuSyz3ZPWoFTFUS2965SmvNC0nW
GabprY2H0qixrO9mPi7QkG7RqNeB6IJr+8ZutKZUhGMNSS25WsUwetzllhix
agnSyoYDJ16UCSc7MUCGjX7vGLY0r7HyqUXapG36RsVSEmPegncIjdZChBy4
4Vh+RGiQo26wBreSKdqGmK7yecOwQ4EGfwjProgPDO6NLtc//8fmm3/4ZxIB
apeKGQOD+AcXg7QFtbCahm/+gZW1RILAwMy5loAgnldkyfNgJyG+QYfFOaiO
4TDQTwZbvxXYrimiwHiHPhtSZp0CywPivntZhBZKWmjSVa+WxIBZffvi9PWr
Vy9+ev7iefALGSTEsCraUcoYZbWBtApOnOmxpltvKm7/LaLN9l6Nndno6IMJ
jelgNTx7z1jIq9PD+Jr2GLhSeBf4xo3UEOfBcrf1Ng8hNfql78VzZx5Jlr8n
m8QiA2lJNDHZdBGbWkxDDXjh9BTB5EMhdFPmXGGJ9X7c4isoBAezp5j0bTxg
G9maKWlDQyHSSubedYZN0U5tr63YawNNhsIC6TiS36TznnwWrPKNJrRetjCk
EkLAWAXCt4nHk+8zxfrNnEK8fsS571FU9YGapRtX8q4IbLrOpeNNhjBUqgp0
facC25fLdZB3rnURVZ9jVzoc0R3hCOzfy0gEsmrDgHwsIF9a/8sw+NAOMvOB
qPA8TWSpgcHWMpkCqs80VKkYTjZhpBJfuUGYjdgnOgYDpJzjSOm8LK/zrKcB
Fs+o9ckRHPNF6BmMTauumV1Hq5xZ2PsWCfpm86p0Hsf+PY4HFLQrcgPEaQDv
GbexlK1uRIRmWLl+g7WDoWgLM4nChSws2f8hdD1TyIWy5BVx1ynvCcn+oFBM
qEzUsGqMPTtFviJBr+MCTHzzBbYEyiXW68bthpgFFGNOMLxMnTSej3laOH+J
f90zB5Z8i8LoQoMR2z8wPl71Wg5C1g7zz5IXrSKgbtaZZHxWW5Tlf//X/45k
lpIU7lunic2D52JFUb5nTwwGb7YXoF6xrbowV4fMsms6IjSlNFBh2yQ3h8LQ
S6XKisorcCmwUhomd5Wl17FQ6ZZjIYozr5rldAO+weUUZC06idN8UU81CFWS
Tj1Xsc8doP2daBEnYqhTwWIf4dtVYAlhlinCS4pUC0W+o3OxvPjxxI+q8T8X
nHS+c8xWoNjr//1f/5u2Vo0EkUiZMhCrt4rtJ6rJ9cqNMESgBSYxdgL1in1R
lK7uMgI2WoDJgw21zdpMuJ2KboO4UJWkJTGuc3ucqBqw4RVCDWEyOi030dgQ
4klZQvInKJS0XZPWfHny00lXZeZpkaK2xC9zk4YSn1sILa5BhLQRIRdeqMAZ
kriQQrif+LuhOsk7280wVQ6RBE7aP/2Rk3AZuMOSx66v+dFSXMzHXJ7GCePz
Z89lFQkC6qokraQhL1vd5AilwDVb8vzjgWo/x2atzLPc8AClTGiEUJcYtDYL
PFPOzcPDw4MDvDF2Yax2LZT81755gXAV++TSvrvCLZVjOTwFc5b+dhxCmV+H
SBx8IlBzqrdEl6LepJzewrTMFBXMFFzpKWZ5Akc8vngIDmMCWIK1BvKJGqMw
WudSqkfLOZxVqeELxXlY6Pgep0IxWUVyKE/lW4+Onia/S0aHD+F/jx4/Hiff
JkdfEVkxrUz8chcCfqZsVd1oSTOXzRtvj8Y0SIS4dVVquvZameuzzBtBteQX
RrIHuiVBFBU3KI2KQJoU7XCuooCHEboojfE4xPddlTB9Qc9rAlYAqojKCQEW
mkYScWlese7nS0J7WPz9WpLcMB5yxZEcKxRi/dOf9ndI6ekC4j/DXijsHrR7
n7zNSLzN7aN2v5GP3xn7mzzG/ia0tnbnTkNBuPNfwtf+T/xfOgzXOcWfjP47
/6Yxt7qZoJiMW5n0yry9PUzAF55S+g8l8SuK0rMF+H3IBtHcyB0l8/DrPRe7
Z2GpfNtkbSnhdh/ETrBeVdbOIpORhHBhQphnDD3IWmxeYA7D/udyVU/HthTX
ZNpurU0Z6yJTauyi6V5REQ/WKjJtauUGIUVDHKetEABcKeaCJ6EiUvfuldaj
t6Vsf4OPA8fouesvZW/O2dKQGqvSRYayLLqjBgR7F0PMqDXi+7hKib2/hpAb
8XecudYIc3jtTmFhSQNa3Im6WcuGYwv93w8C5/CfZr8l8yb98Tp7nCCeHRwT
6hqsmKAMBzMkR3n3eSo1BRSeiTpWG9bO3aR2FdURjZrkSE8QC4M/f3pEeC65
w014kYf8RYgQTD6+ZfDdvmJMhu2C/g2EVx4+LAJ+g/iTFe4SKnw8mO11HMeI
wEDaic2TgRJGFN8xiyGiDBLANsfJNwggg71VXII5gDidZAo66vJoVEgfT/+V
vtE6fY9mKlfiYxTPeRRoK2gmMjoDDKHL8WBWa+mxTkZIwKZZ+HKRbVbljivU
MYIB+zb59pvkySODL8hUrtgPx9iLwBF5w3LXZknjcjSGI21NlYeCL8Qr0G5S
bCujsBZx3zJWXp2lPo62TFLJdWfSLBjXuH3JJGympDnwz4AfC+cwJYSJO0Pi
jQRAMjFOa7BfZgvDGGLDwIeMOpdIUW/BvxQzEIyiRDpKRe2ovLTljsQNwjmO
/ml2d0b7riNf9CKJmvinYYK4HDmS4ZiRX22NLqFCIlAUpO2TSr+lmaA6rNT/
ELM/qo8k81tp28LDh0+SHcybnK22iGIkFVbtxPDzmFZTHQEK6OszYghmlLsG
m6DgAM0Pr05Op2c/nEyPHj9p6cpZ8jOPtfOqnGEMoNRPFFKHRy0pddaSTQx3
Z1BWgcQNzd9C4OCTEPrHUuWvPM14fK8V1BZOb+A7m0v1DDN8tRexXc4o4eUY
AigR7RCpZrAIZmR26k/HW1gJj3P1GS4yVytIXiPZNkjPlDzPlGxIgmowb/lc
GrDRZbTZV5d4Aq/WtRTLciGedrgK/FxsMN7AySor8cNyZZbNu/E1sXKwbgHb
LNx+otzzQmyCyzm6hnEdjHsloDs01/9XJF58+jCEgKrTA5IQIxViqiz+GmQm
oy3yG0VgYlXlYeQaGlKgADuIxBBhlpW3qOLbT4TEuI9IwOgS2gYajF8OBidd
/tmWYYKbM62YHy360fifYfwPQYS/QT6YmtySUy5e0TwbO+mKaZeoGxe2xTkp
jHNRaSWm+yIcf6izZZj/nVagOCxaQqNJiX1E4RTqQECiSz1hxWzOlcPrVISU
3o+CkPNKeVK5Uim8PKbQuC0QbRNahCZVmRC1LTGDOaMV1w7hI+1wQC+Ohvhx
IM8g8J/0ntEIpZUt8INi6At2IBoTGEq5y6gt4q2ybLmh6xtqWMWxwbpWU2pO
ykLKDjvLCBF+pksqcYQQrowC03GRRntxP01iyGh7BYR+92mygTIpeXQ65R3t
kDJAgBbTr5r4YHCGEwqr0ttjOy6JTvnSdYxo4ry3XSr87csmIFloEaVGtVVf
53qQscTpCq5tIN8kbjxkVV6GK9DjGhAvoHdrqaYx9ECKTGzu89mrxQThyIUO
zvrozYT2qAp75SDjIqpQfBnP+U26qd6vnEbp7HqWzjAhNc/GLMQwzysqtU/5
Gch9sSDRsSLtyjWec6MEZU1eguoXMLjSQeCuwEI6Cq5HvdQkDHmGNtNLQvkz
DCJ04enlGO6SZ4UTRKxAH+eDQumEwViki5Xh4eYuXC82KpLAzmQjytELMd9q
dxwE9ER+4ztsUbkJg7/MctpwCiTyhpdpvoKJ+lohYnovqTgJj99LIssO6jiw
AN3dh1yK+quU8Cuj+CUaKwFlpA6ddm7oLj0f+rh5DS7koF5jJhmRrIMxFUzc
3HKXIrDM+1siaRgnbQIYTpJlMToqoEA+1rep293FqLHpNDOtc29atd2CUxum
4LnjaPp+kkASaaPD5BmF82WfMZhS866c5sMLp9vNJEEHRKx3kmu4BBRboZSf
xsVHR3TLcLSY4t2KG4WWs00TwWuiv+Etti1cDUNMk00HWlhwQ02C6GXiIIi7
BVspwnhvGpQNEKs+XeAU0ZPJp1E4Ih8Hdh7qjI+LckKGfm8zvtj1QujYSsrc
wjAPzndranthwRJ0t+ikRUe/1ZI2hjOK6WvGC8dj7dAtJevu2WMv8VALelsp
6/HJne4vbUxAq6WEbwtyLzklcyj5sbzELGGyJ0kIdlh5o3z/IkAE8L+hFDyD
bhPMinwh96wFU0NEhtM8a5bMb0RxdnlTavdz+BDNhi+SVzky/vLTqWo3f5+R
3v4i+VkYBbPiCqG2pLePySb5gvVQMv22X13JRT5/DycTuw549x/NDrpDuAqm
6YbYAIyMD00fGk0L4Wt8DzxWfvtVybQS8HYCuxwZbnS7oZZFhNGiziX8FGVK
4doFNCLwdmfUe4pSIbgkQ1TtEYE074Q2icgQ5uXWkzrBdmRSCkTjFLs13/2l
vvENbhLNPsFgwE5Mnj786oDLCW4pfd5ayMuq3G4wZz69yOvPWfcjsCXYv6HQ
MWXf1R57+eLse0R05dntGLcHliCflthEHicMW/ZwzxcHo22Sv7tqmk19/ODB
JYja7cUMbvmAnn17+aD9+AegkC4erDGPWz2IbzpbL76VLAs/cw1iEYeIEUdy
JGkXLBau90UyhLenbVXpBiwF+OX7Xw1nYkmH2Wp3M5D6abTc51lUkQLygOQP
c2bipsmqdR3u+LJw1C0TBoeLKJHqRB0a7kzf2iyqBEV8S5XeFsEwjsbHtB7O
Mv5aMQGEjYv9b76YoAsnsZX/R/jwT1gcuAibsCx429poGXJeSydes6Bme5ZA
GXVOmDRbTMtXgfKnw6wjqLLhDJ0Dw1TSZNu5ICA0HXEi58GDgSnW2wdVE4NG
wnMkDaR2r558rOulpWX/bJPSzre3iUYd7nbsFphVj8wEfgev5KIT86uMCxaF
FFeYA8jVtzZJI1jhY/goq8Zh75wF7zmNxrFMyernYrKAfNuuFWc7Cm93nAxb
IUwklrPOJxMBaI8T5k9D107Ko20c34G7Wi6QZJQlviTf0aUzx0aYAShvMZRF
G8qu46IaESvHtJmxG2DjwdxkrMVUONRYZEKbb441fMSXqR3JuOaZMDu22rJm
zwlxkwx7EWrDxIhr3Q6IyjJCP/Sv4eALeGHOHsvcTq+eLbxTHRjhQ58rFAT+
ULRcSK2m2fagSHs6C/F93vS6o8d4f4pjSdMQmJU0l6iTousd/i30GdL7vgh9
36UFLzXzzVzCFKlWfaFmWzxqj0y9JW2aZZd56ofpqaJkj7mK+guFj36BKHx4
b6FFDtjU0RtbKoovMAA0zRcWbt7FRdKOLYuP/cTgTZTKWQkHDonjEBcR3rHF
bCwvcUr7Ti8OyV7L9UoqxpcUyP7wBcPWPprbgIbOAzwA66zEeP1QnJA26cQy
IEQ0QtQCzMuHvHHlUjYcrwn4E5nfciQlUTrkaD+AsXqVVd2VC60sXGCEilQy
cBy+Ojp4evD0yVM0U1/eX+OpaaiaFoT/Sz7wxX0EEal7xwE7slKX3OoZKyF4
UG8zZvFLTmUX7CzrqV2qjpPXvLpLX2ID1guTX+rCD2H7rxkLPRz7eIwQ+bMf
TRBLJofQUMb7XaDL5UH9PVajLne8FkPeR0Nqasx4De2e6+RvhBrQkQeB+ZPq
qRC88ftehkglnwzE495x9+EyeZCAI8uEGqtTSMORb9dtz1BnV41FIYMLWuo/
v3t5qmYjaMuvDg4Ovra2BKqrOa+EbnykbcwGDS+Im6vAdA8RTIL2Ff+E26p+
d/rk4aOn5i9vLqtUGLRJyh3OHuIbnz48OiSzo6E2UqdHXx4EjUOYS5Gzxr86
R9e3rKQIqN3Ah9/ZboFB1UdPD5wFLa8fjAgmnKHgH4z7fmgAzIETqxiLSnIY
BKcC4kXsGYWnZ6osOd61FMsOY8rYY5703R7bQtInRVZNHzCY15mC7gmMBh5e
wF/XaAUPhUelBD9nx+JluMiK3ZS/5HDBKls2giWVoiQ2ed19mVihXpWbzU7V
E8sXao+dVRd2MbuHop1FprTulCy2LG8yF9+1a853G9b3HG6tN9mKm6jYbJIm
0Xi/Fi0GhxTFOr5zFfaOCV6UzVxsAgbIJNDkt/gwkpEA51Wm4y5h73oxNg4w
Vioz93a6r9AOosqNLw5nh18wrjIXOQh6dKXAGqk6D/pQkLy09ahlLDdkoFT6
AmWH0PyX5YKsesSOzT7HqTuMnLrvs+Lk7fkkOT/7A/39elM/zyvz9cYDZxSk
uUN2eRq0pWMrrjXusHdHX+z4HPreXiSSuKOCtN19/XuxbFnpXXInSw7UrGUW
DXyN22HFUiWXPBUJiJWrWa8y9snIaToE/wAuRlRC1MlS26dzGfJNwNOTl6W5
eKZE0U42VgPpmh8UmPE18Yiq3FmS9IpDswmGcuH3+DwdAWZ2rde4pfvhp/kl
YfKPGEeVjKK6kVQTSqLG8QiOJ4TKpZC+TqHqq3kWY/b07hh3kcMnhv1OG2/O
DcdMyYSOoYc3EPCRNsdar9MKXI8XD95hId12jSapCBYqKQ1CAaOWmUB+Q2GE
dMCDMwoHHMak8hbRffN0kzfhtGrykFtMFJzSm5s/GiS0th4evfyDBlzwfKbM
GFY/QH0Fz33AceUH9szntEfD+QqdUVhDUAMiqdH7nNN5kIyeYTfx+3X3DJ4g
lDaS62UAiOg1Dt8Wi2I2zHtUFHoS5RoVuNETS1KTsPSd6FPtjErJMAp0QJqh
6KH+dHCv7lu5MzISCezGkVuZc2fBaOwqiyKd8n0EM8+JQlPM/7rlmbCRzTZn
5IpwjTaKB7RFcnRUeONlGWwHXfqzTbbibrqL5DTadp+x0AdfHYdlXVEkMCIL
Y4OPpipQ28a1y8jITi3gwIlh6lAqM/LUpXyZdguTM7DewFZFEc4JGCnpmhPr
VYU0hfRU7EOzrRpuoVjDOldUT3BBPlWthYn990SGX2yjFfkv3MaGGKipwIoD
ZnJWo5xOtN25mALnsKxbUc2Dr9xOdL1q+TekhV+Qe/ccK98fJI+OHifnZckf
6k8vago2H3u3F3cFaSpEyxiXcklhJXUGOSwfioSieiCzkuBHGIoKoWVNlSMQ
F31SHi9MqPVKGH/ObvrSdtMrpG2KdS+LiJYKFlY/rQIK8bP4mHndxA5ypKCQ
fj2ViLSxCJHOzFlSEe60pkAh1XFIfhBbEtTR/uc45+hw+pDSYeMo5ElaQuD5
INKRR4vL5zllZw2NfILPxURUzFF0TQuOUQ5c7wQcK1Esn8mKm71ZG016i/Ra
dvpmS7lWpI0B9xCBT9Yaj1Qgc8ZwHzVpwC6D+TFfYniWugn2EStq+EfKjUZ6
mLniUansuO43wktSqR33HyMP18SX1JHZ2qn1pMEnefLnbL+nyUjbyTrb8rsK
t0Y9T6nBN2UKbJu+DY3NoqNHpIXJ0PV5p2zu0AtscplDUMfLeLm7I3U6hp2N
TIS0Kc1528u6oOM703qS4+QVOi54i6bcICm3hPelgInIrDbSDxSsik2Dczqi
TBwJOinm/GWL8I8L7WKIds64+6zvUbi1WiypR57TlqakY5yWHVEkGQWd20hj
/Z0JBhehd8oc36dstxyXnwx7wRnDY5X3tQakV9J3STpBNzQHalhaXJvKudRQ
VC11LKYBIs5CUBnhY5zd6CmwUaUD27AzlKI0Mid9PvEbhO2Co4h56hl/oWxb
tU9BR49CNeORknLUo2s0SEgOX4zmYGuid/9z1rQdUx8y05BizkKDpuFHDhEH
JwUsB1/GeLus6fv5qTcWxVU2H8+glWBqmB+m3fUIBKBbuV8AY5wfGx4ySSW6
2dNvI0bCEa8BxQhyBCxsK4k8r1IOkdbjvrOtcLrEYhvSASAV3o2o3mvqcaiw
xT5H1D1xIox9GC1tF3td4sOh2TGy3+XGF+6bfsST9Dne/MHjY5/u3INQo2w5
2mvgruxWWRTHkUiST9j1ryHrCc+WF35C4T8ky93z07LQZ3bppWmfSiRlAXa3
4e96iLfDONXRRbgAvkao4j+WXo5LkJN4oPjpm6l0kbmlgWk5jDy3B6rnQ6z6
1NOWQ8XH9LWF5WQt8M8U4b9cttOpZpBOmQIZ5fjvTdYLZ7b7Jezk4BqsCTPm
HZs8lNlQqHD80WHE3oa7/CWKw/o2c12hJFNs8EGR5o5PI2pZ0Pgx59lM5oe8
KrkGbBn6cNw7sZrTs+K0wvF7UB6Po+nhHC55GoO1hshQCVhhNDcZ3k3CIyNu
2QRD40aKT3wklXQTHMwODqLa6zr8SMR6HW2PEFA65qkcovdFwBAY/VDLPYbu
JyFkxOew5kvDpwKILrH+dmQERhJxFr/IrQ4OgXmULMoXhweiAaunJBHpYASZ
u3SrWDfJ8geOAXebTl7C79XIq55YBHgirgQD5lqmymcIzUfHe17Yv+8rEu7W
sJ2FqNBATWHOY3IpT67GIr4p3VTvazwi0M+rigwKd3ZgtTEEnGGwHnTlsJQO
LMPPed+HwTuUpeo0zZkHsAtBmVruMQwSd7GZL2rmOOe4fUtLwIuG7lTb4mLS
meaKpcgb7CWjZrZ15HRKue8jW0OsmdrWoTRm37l4iLAwOD/BBie2knfEtA20
mUum6Mooxzvl6svwmJA41Ulv4eY0y/IZK3lkK6nAhk4YmSqvyI1S5btMhgaz
H7YWUPKuIeZ3pa3rEf/i+qcPcTDtX9O0eUddcq9M/6bRPO7Ie7dv/gdBJqz3
JZHunMZX6S+lZa8+eTIPbTI5xTgF10vvwVkxwkWhhy9lZAEjPZQrcZrCnVpb
j+ttcYttFA3gdxiHEpqusofVLV2Tq0RaqRqiOYr1+DuG9t4+888znVKJh/Eb
4htJ9IJA2Z1Oxp87qweK+3wrIiPgguoYwMKZkYq61OIRbkuQ+Lo9+6eVZuGs
D3H4tJ72CsHI3UiLdN9GiAHiCyVWOkl6V52MIOpfyIHmTj/46XWmkcXnVQlG
6iJExNinkmNG9s/U3XnE90CyUqqLQQ/4lhsc1ckbdF/xvf7AgKmSm0OJSfb6
AinAp6Zj+MXGdy9husZmMDWvIu+bPet4Hnw9az5pLjLlZ0304eBAuadrzbMN
39Kd2VDBPTDkiAnF2oNhwlMTdq/GomZuCK4d3kKc/ctSUftGlGMJIHz6o9nB
Q3we/H0Y5fnEpDW32Aios4YqvwLDmh+BDzH7rBnDwC1bPyI2vbEBPARqQEV9
jEGmG966ShRGYQ6jghcl2xrSe3lQaakluFqqS+3JDd0pzbpC+6vGcPk0V7ih
uMIHw3W31IYhdGbGDWKZSkKgBzQ1G1y/HouUyBbfDItyKGwsXCSGe0CdhbS4
HpymFabgkmdoeRfFZPC2hL+T5yDKVvntZPAsK35JQegnv08X2+vJ4NW2qmDn
/34Lh6lKb3eTgUUR4RSsCDKVI9vQ4O/zdXIGU5QuBkxLqM338FVT9rZd2RPt
+pnQzyxX2+Vy8H8AYCJiJHMtAQA=

-->
</rfc>