<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.30 (Ruby 4.0.0) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-li-ipsecme-qkd-multipath-secret-sharing-00" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="SR Policy Energy Efficiency">Computing Energy Consumption Path in Segment Routing Networks</title>

    <author fullname="Jinming Li">
      <organization>China Mobile</organization>
      <address>
        <email>lijinming1836@163.com</email>
      </address>
    </author>
    <author fullname="MengMeng Li">
      <organization>China Mobile</organization>
      <address>
        <email>limengmeng@chinamobile.com</email>
      </address>
    </author>

    <date year="2026" month="February" day="27"/>

    <area>Routing</area>
    <workgroup>IPSECME</workgroup>
    <keyword>QKD,SRv6,secret sharing</keyword>

    <abstract>


<?line 32?>
<t>Trusted relay is currently the most practical deployment model for Quantum Key Distribution (QKD) networks. However, trusted relay nodes pose inherent security vulnerabilities, as intermediate nodes can access the plaintext random number used to derive the end-to-end QKD key, leading to complete key exposure if any single relay node is compromised. To mitigate this risk, this document proposes a Multi-Path Secret Sharing (MPSS) mechanism for QKD key relay. The core idea is to split the random number into multiple shares using a threshold secret sharing scheme, distribute each share through independent QKD relay paths planned by the Key Management Plane (KMP), and reconstruct the complete random number only at the destination node. This mechanism transforms the security model from "all-or-nothing" to "threshold security". Notably, this mechanism leverages an extended IPv6 Destination Option Header (DOH) to carry key share-related metadata and utilizes Segment Routing over IPv6 (SRv6) to enforce strict path isolation.</t>



    </abstract>



  </front>

  <middle>


<?line 34?>

<section anchor="introduction"><name>Introduction</name>

<t>The integration of Quantum Key Distribution (QKD) with classical IP networks, specifically for securing IPsec tunnels, is an active area of standardization within the IETF.</t>

<t>However, a critical challenge remains in large-scale QKD networks: the reliance on Trusted Relay Nodes. In current deployments, if a QKD link exceeds the physical distance limit, keys are decrypted, stored, and re-encrypted at intermediate nodes. If any single trusted node is compromised (physically or logically), the end-to-end secrecy of the key is completely broken. Taking an operational "QKD trunk line" as an example, 32 trusted relay nodes are distributed along a 2,000-kilometer path, and an attacker only needs to breach one node to undermine the end-to-end security of QKD.</t>

<t>This document proposes a Multi-Path Secret Sharing (MPSS) scheme to address this vulnerability. Instead of transmitting the raw key through a single path of trusted nodes, the scheme adopts a (t, n)-threshold secret sharing mechanism, splits the key material into n shares, and utilizes the physical isolation capability of network forwarding paths provided by Segment Routing over IPv6 (SRv6) <xref target="RFC8754"></xref> to transmit the shares simultaneously over n physically disjoint paths. The original key can only be reconstructed if the receiver successfully obtains at least t shares, ensuring that even if fewer than t nodes are compromised, the attacker cannot obtain any valid information about the key.</t>

<t>This mechanism can serve as a security enhancement layer for the QKD-IPsec integration architecture, effectively defending against insider threats and node compromise risks in the relay network. The scheme is designed to be compatible with the key management interfaces defined in [I-D.nagayama-ipsecme-ipsec-with-qkd] and supports various secret sharing algorithms.</t>

<section anchor="requirements-language"><name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119] (Bradner, S., "Key words for use in RFCs to Indicate Requirement 
Levels", BCP 14, RFC 2119, March 1997) and [RFC8174] (Leiba, B., 
"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, 
RFC 8174, DOI 10.17487/RFC8174, May 2017).</t>

</section>
<section anchor="terminology"><name>Terminology</name>

<t><list style="symbols">
  <t>QKD: Quantum Key Distribution.</t>
  <t>Trusted Node (TN): An intermediate node in a QKD network that temporarily holds the key material in plaintext during the relay process.</t>
  <t>Threshold Secret Sharing Scheme (SSS): A cryptographic method for distributing a secret among a group of participants, where the secret can only be reconstructed when a specific threshold number of shares are combined. Examples include Shamir's Secret Sharing and Blakley's scheme.</t>
  <t>(t, n)-Threshold Scheme: A scheme where the secret can be reconstructed only if at least $t$ out of $n$ shares are combined.</t>
  <t>SRv6: Segment Routing over IPv6.</t>
  <t>KMP: Key Management Plane, the logical entity responsible for coordinating QKD key generation, distribution, path calculation, and SRv6 policy enforcement.</t>
  <t>Disjoint Paths: Network paths that do not share any common intermediate nodes (node-disjoint) or links (link-disjoint).</t>
  <t>QKD-DOH: A proposed IPv6 Destination Option Header extension for carrying QKD share metadata.</t>
</list></t>

</section>
</section>
<section anchor="motivation"><name>Motivation</name>

<t>In traditional QKD relay networks, the security model assumes that all intermediate nodes are fully trusted. The key flow is typically:
Alice --(QKD)--&gt; TN_1 --(Classical)--&gt; TN_2 --(...)--&gt; Bob</t>

<t>If an attacker compromises TN_i, they can access the plaintext key material being relayed. As the network scales, the probability of at least one node being compromised increases, creating a significant bottleneck for high-security applications.</t>

</section>
<section anchor="proposed-architecture-mpss-over-srv6"><name>Proposed Architecture: MPSS over SRv6</name>

<section anchor="key-splitting-and-share-generation"><name>Key Splitting and Share Generation</name>

<t>Upon generation of a QKD key seed R at the source node, the KMP invokes a Threshold Secret Sharing algorithm.</t>

<t><list style="symbols">
  <t>Input: Seed R, Threshold t, Total Shares n, Algorithm Identifier.</t>
  <t>Output: Set of shares S_1, S_2, S_n.</t>
  <t>Property: Any subset of shares with size &lt; t provides no information about R.</t>
</list></t>

</section>
<section anchor="multi-path-enforcement-via-srv6"><name>Multi-Path Enforcement via SRv6</name>

<t>To ensure that the compromise of intermediate nodes does not lead to key leakage, the n shares shall be forwarded through disjoint paths as much as possible. This document leveragesSRv6 to explicitly encode these paths in the packet header.</t>

<t>The source node constructs n IPv6 packets, each carrying one share S_i, and encapsulates information such as the sharing algorithm and share sequence number into the DOH header. Each share S_i is mapped to a different SRv6 Policy through the information in the DOH header. By utilizing the SRv6 Policy mechanism, the source can ensure:</t>

<t><list style="numbers" type="1">
  <t>No two paths share a common intermediate Trusted Node</t>
  <t>Minimizing latency differences to facilitate timely reconstruction</t>
  <t>Comprehensively considering parameters such as the link quality and trust level of quantum links</t>
</list></t>

</section>
<section anchor="key-reconstruction-at-the-destination"><name>Key Reconstruction at the Destination</name>

<t>The destination node collects the incoming shares. Once t valid shares are received, the KMP reconstructs the original seed R using the corresponding inverse algorithm. The reconstructed seed is then processed to generate the final key, which is used for IPsec/IKEv2 as defined in <xref target="RFC8784"></xref> and [I-D.nagayama-ipsecme-ipsec-with-qkd].</t>

</section>
</section>
<section anchor="protocol-details"><name>Protocol Details</name>

<section anchor="ipv6-destination-option-for-qkd-metadata-qkddoh"><name>IPv6 Destination Option for QKD Metadata (QKD‑DOH)</name>

<t>To carry necessary metadata without modifying the upper-layer protocol, this document defines a new IPv6 Destination Option, which is used to map SRv6 Policies and enable the receiver to identify the sharing algorithm and parameters required for reconstruction.</t>

<figure title="QKD-DOH" anchor="block"><artwork><![CDATA[
0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |  Hdr Ext Len  |  Option Type  |Option Data Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Algorithm ID |  Total Shares |   Threshold   |  Share Index  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Key ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>Option Type: To be assigned by IANA (TBD)</t>
  <t>Option Data Format:  <list style="symbols">
      <t>Key ID (4 bytes): Identifies the QKD session</t>
      <t>Share Index (1 byte): Indicates which share (1…n) this packet carries</t>
      <t>Total Shares (1 byte): Value n</t>
      <t>Threshold (1 byte): Value t</t>
      <t>Algorithm ID (1 byte): Identifies the secret sharing algorithm used (e.g., 0x01 for Shamir, 0x02 for Blakley, etc.), ensuring extensibility</t>
    </list></t>
</list></t>

<t>This option is primarily processed by the source node and the destination node.</t>

</section>
<section anchor="integration-with-key-management-plane-kmp"><name>Integration with Key Management Plane (KMP)</name>

<t>The MPSS mechanism is transparent to the IPsec stack. The KMP interacts with the following modules:</t>

<t><list style="numbers" type="1">
  <t>QKD Quantum Layer: To fetch raw key seeds</t>
  <t>SDN Controller/PCE: To compute n disjoint paths and generate SIDs</t>
  <t>Application Layer (IPsec/IKE Daemon): To deliver the reconstructed key for use as a PPK, in accordance with <xref target="RFC8784"></xref></t>
</list></t>

<t>The KMP is responsible for synchronizing the state of share transmission, negotiating the Algorithm ID during session setup, and triggering retransmission if fewer than t shares arrive within a timeout window.</t>

</section>
</section>
<section anchor="security-analysis"><name>Security Analysis</name>

<section anchor="traditional-single-path-model"><name>Traditional Single-Path Model</name>
<t>The random number R is transmitted through a single path, and any compromised intermediate node can obtain the plaintext R, leading to the complete exposure of Key_AB. The security risk is 1/N_node (N_node is the number of intermediate nodes in the path), and the attack success rate is 100% for a single node compromise.</t>

</section>
<section anchor="mpss-mechanism"><name>MPSS Mechanism</name>
<t>R is split into N shares through (k, N) threshold secret sharing, and each share is transmitted through a completely non-overlapping path. An attacker needs to compromise at least k paths (i.e., at least one node in each of k paths) to obtain k valid shares and reconstruct R. The security improvement is reflected in two aspects:</t>

<t><list style="symbols">
  <t>Threshold Security: The attack threshold is raised from "compromise 1 node" to "compromise k paths (at least k nodes)". For (2,3) configuration, the attacker needs to compromise at least 2 non-overlapping paths (2 nodes) to reconstruct R, and the attack success rate is significantly reduced.</t>
  <t>Isolation of Shares: Since the paths are completely non-overlapping, compromising a single node only exposes a single share, and the attacker cannot obtain any information about R from a single share (due to the perfect secrecy of the threshold secret sharing algorithm).</t>
</list></t>

</section>
<section anchor="quantitative-analysis"><name>Quantitative Analysis</name>
<t>Assume that the probability of a single QKD node being compromised is P, and the MPSS mechanism uses (k, N) threshold sharing with completely non-overlapping paths (each path has m intermediate nodes). The probability of the attacker successfully reconstructing R is:</t>

<t><list style="symbols">
  <t>P_{MPSS} = C_N^k * (P^m)^k</t>
</list></t>

<t>For the traditional single-path model (1 path, m nodes), the probability of successful attack is:</t>

<t><list style="symbols">
  <t>P_{Traditional} = 1 - (1-P)^m</t>
</list></t>

<t>Example: If P=0.01 (1% compromise probability per node), m=3 (3 intermediate nodes per path), (k=2, N=3) for MPSS:</t>

<t><list style="symbols">
  <t>P_{MPSS} = C_3^2 * (0.01^3)^2 = 3 * 10^(-12)</t>
  <t>P_{Traditional} = 1 - (1-0.01)^3 ≈ 0.0297</t>
</list></t>

<t>The attack success probability of MPSS is reduced by 9 orders of magnitude compared with the traditional model, which significantly improves security.</t>

</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>This document requests IANA to assign:
   1. A new IPv6 Destination Option type under the "IPv6 Extension Header Types" registry for the QKD‑DOH defined in Section 5.1.
   2. A new "QKD Secret Sharing Algorithm IDs" registry to manage the Algorithm ID field, initially populated with:
  - 0x01: Shamir's Secret Sharing
  - 0x02: Blakley's Scheme
  - 0x03‑0xFF: Unassigned / Experimental
# Security Considerations
TBD.</t>

</section>
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
<t>The authors would like to thank the following for their valuable contributions 
of this document:
TBD</t>

</section>


  </middle>

  <back>



    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC8784">
  <front>
    <title>Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security</title>
    <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
    <author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
    <author fullname="D. McGrew" initials="D." surname="McGrew"/>
    <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
    <date month="June" year="2020"/>
    <abstract>
      <t>The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8784"/>
  <seriesInfo name="DOI" value="10.17487/RFC8784"/>
</reference>
<reference anchor="RFC8200">
  <front>
    <title>Internet Protocol, Version 6 (IPv6) Specification</title>
    <author fullname="S. Deering" initials="S." surname="Deering"/>
    <author fullname="R. Hinden" initials="R." surname="Hinden"/>
    <date month="July" year="2017"/>
    <abstract>
      <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="86"/>
  <seriesInfo name="RFC" value="8200"/>
  <seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="RFC8754">
  <front>
    <title>IPv6 Segment Routing Header (SRH)</title>
    <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
    <author fullname="D. Dukes" initials="D." role="editor" surname="Dukes"/>
    <author fullname="S. Previdi" initials="S." surname="Previdi"/>
    <author fullname="J. Leddy" initials="J." surname="Leddy"/>
    <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
    <author fullname="D. Voyer" initials="D." surname="Voyer"/>
    <date month="March" year="2020"/>
    <abstract>
      <t>Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8754"/>
  <seriesInfo name="DOI" value="10.17487/RFC8754"/>
</reference>
<reference anchor="RFC8986">
  <front>
    <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
    <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
    <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
    <author fullname="J. Leddy" initials="J." surname="Leddy"/>
    <author fullname="D. Voyer" initials="D." surname="Voyer"/>
    <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
    <author fullname="Z. Li" initials="Z." surname="Li"/>
    <date month="February" year="2021"/>
    <abstract>
      <t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
      <t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
      <t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8986"/>
  <seriesInfo name="DOI" value="10.17487/RFC8986"/>
</reference>



    </references>





  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA61a25LbRpJ9x1dU0J5Y0ktQJNvWhTHamFZ3a9SjvtDN1m5M
OCxFESiSNcTNKKBbnFvM48zj/oGf9kP8Kf6SPZlVBYJstrQzaykkkkChKisv
J09mIQzDoNJVoiaic5KnRV3pbCnOMlUuN+Ikz0ydFpXOMzGV1UroTMzUMlVZ
JW5yO/RKVfd5uTadQM7npbrDPLMbMc0THW38PGeLhY60yqJNJ4jzKJMplotL
uajCRIe6MCpKVfjDOg7TOql0gaVCXCtVFZqVLLFMOBwGkazUMi83E2GqONBF
ORFVWZtqPBy+GI4DWSo58WIFJNOyzOtiIs6ns7OTy7NgrTa4Gk/Et29P+7Ob
u6d9u4ZwawSmkln8QSZ5BvE2ygSFnojvqjzqC5OXVakWBt82KX35PpB1tcrL
SSDCQODPok4Su7Hf6SwlzVxovpGXS5npP0rS4kScrHQmxWU+14ni2yqVOpmI
RP/BPjZ6fvT0N6OnR4MoTx/OfamyJf37ZyeHychsy99ENCTlEbxCEOVZVep5
XdFesrxMMdedwracgTK5lBuZysZM/Bnea9gIFqOBN69Pnj97/rX/Cns0V79p
rr54/nQS6GzRrCCCEL5H/wk5N1Upoyq4JXuqWJQqkRuhjYjqsoS3JRtRrZRI
c1OJgkbqSCYiVkWSb9gb0zxWicDk4ttaZlWdirdqI061sXsjB+7C7D2ROXcd
iDf5vbpTZd86UbNohpmMKHKj4O0rRasLbLgudbURd3UCj5bQnq60gjdIg1GV
KlMVa7inezqSmZBRpIxhsYtE0qCPlSjhYHkqsjqdq1LUBqtWOfZRQiE8VGVx
WOUhPshLBVy2LxIlY/InjITFikRhHdwQ6iOkrEvIuRAy2wiDQYlqbYMViCfK
PNVYaiBuc5FC8CVJWq1wt9Rm3bdfEZc1qxLDafdGwJMoGkOO/JkNlZkNFdG9
nM5mPZGqaAX/M6lVvZXYSoDVsJ8oJ/liJUkWbMAU0BzvdFcV0A9k4+DHFigg
IUBNO4IY1Qq/VnkSi92AFSZaqVT1ReztDAXKaGWfp8fyekmgBUeBRmlzJKJV
EIGMIdNkGawwtw5GTnMp4fKKVTHFXSW6by+nPZg6IxdBuGCtOrKbaOyxu5s8
g8NKOwT+AEDiAGWjkF6gi63m4PmZobCwztL4mnNpGE90ZJKEeRlmOUyVLTuk
yc6OVviRzkBc5ZWcJxtn0+0iCbk6tgWrZnCcitQRAxnvnorTloDXFuvfwOOw
je7p9Zseu50syw2bljUbkgYpYlJVyVhWknWDKEv0H7HCfobIsbRdqkuoyzMq
AoIIu4XdoMuCk4vJExZjwKCQ6jgGjAVfiHMgVB5D57gXBORWFE7L0sqcLz4X
84RVIkqkMQwb59MGBQDnhYr0gq7DZOTEVpkQ+3yKr6Kq4R8JBmpWHUEPQpVy
DS3MGUOWsUNgXgk5kux4fnb7ehAEDcpIEcFGLACMkiQAY4pVAHRGGCISWS5V
aHBfsZd6ESc2WlSiZQaFYREPkjfsx1eEOAPoyGNlCxZJbGADz5fobA3LR0rF
DpVWG6sPih6eG2lCV32ys6EdYqKo3BRYCmpCeqBPGwTAJ3eHvPwhAEKcHUjy
CHsAlETXywH9Q/1JvrQ/ev19QOTgB6mA3ukOuaObi0IQj8/LfK0yBJhcM3DA
NwplvQTb7JAWIAnUAF2oDmE3B4OkCfriaHwwE7AiGnzBhkEPCJTG/eFwGK51
kiMK4ODkwlY/5CZVJaO1R4LM6jyHgAxP4BdWFbhUIxBL5P0H8N/gAPn329MB
Of6/CtMWJ2k5GcelTUuYq53NNuRC2LyMWb+ESXAGjl+L1vescI+p0puWI5ef
2JrYWNO5VWWcFxWJ2YVvZb3wUTRv0Kpv04RpzAzGgBQJG3KayFx+6O/Czo5P
N1gC7CrcDklMF1UU6fcUt1jWJYIyv9OxzQSfBbDvHLf5nlTqdWX3bDOX0ZTL
kDzy2pBf0wSZaHk6POoPuc4s8hmbK/NSLzV5Km2ZKAQ7z1y1sw4E1AuHCJHS
NK+pmWkQR8RK84oBBWEJ2gC2VDXKUuDypbUn7gKUMppqoe4xBy4BtVoe34pQ
a8zGoyEY0pBbiIP8TiYaYnlqB53LOTTnrec9d5uMaG9GlYSj5BeNp6tsRTjE
ukcAYjECZJoGARBaPG4jvyzBZisVVSBB2N9ioRidSb1qgRhiEFiSPgikjI55
p4hBcsfMwdF2p8yGGIsd4hIGWH+xBnIOTVGojF5mlr3N7RwQaY544Fyz9duG
SjBILiQsRcJpehYLfXceng4+w7C/Z1lNXRSoQRC0CBZ41X7wyASlEZ5IDfT9
xRdIDj/UuuS1jbiQ2bKGJJw7STCqg4zoXL6b3Xb69lNcXfP3m7Nv353fnJ3S
99mb44uL5osdEeDH9bsLd5++bZ88ub68PLs6tQ/jqti7dHn8+w5HbdC5nt6e
X18dX3SsvtvIxtyN9cpKK7BNwl3WOnLonFUXUAyOR6MX34vuq1LGGeXY2QCL
vG32R95TM4+nCoQR+BxeQXVkWz8iuEA0JAaivTqZitHXfRouaPI+2CCcTIxe
vHjWYztw6I+eIfS7F0rPJZ7BokHnOJ3rZe1Q5l2BvBNJLH0H5YMB2B9WDp6Y
qcp/kZStVQO6S5P3xen1uRgNB/j+/NkTtyQJsxHj4ehZz9r4ljNHjpS5CYKv
UO4hTCaPkqEBD/HkgWiD6N5e9SbiOHuYwklW2eYhFjUqlcIL4XGIMYLwgxDd
qndijzg+nhBqBFZOliYT7KWtmQ207gzJC/IJJhs5wr5Y6YhY5yqP2bpNYraF
gosJ1Lf8k+t/skchSzAvXUimRPdU1XmuTeMfx1oMJT14ktiqRDzTX3jId6g5
p9AeiDPLKghNoqSGPrG1VJf/Zva3Sj71KpHrRG1w0yKM1Y5Lly0l8U3ShwOi
gxt5sAfeGdFAnxK+rL4UhM+Q/cvsy4PyswCU6yaPJ0M7CLXR5GDZZNOGo3OA
9opiAwsVEI2RkuwX5TklYckz+/JxqTLH2lqVHf9isoHpojpx90l9JCcKdm44
ubqCxLDynfpES/QIZNq1q1zWZ6eOQSlylyc5oUEN8KBDhX2XPkKfvHtMWMGr
cYM+tjcGPhxDlFBkMcfWPltycWlm6AKrh+ourxorny+5CAHEZY58J21ZhAIA
TCTWju1uC91trXOgvERNBNB1igAzObRpWtayC0fybDYkUy2S/J4r+01hic0k
OIYdlAhDLr3C8D/E7dWHEf0+8QWYvzqmq4PBgH+/yufYw2KHPG9Ts6Hxmnew
eby7soNDc0WKYxWQxMd2sEczrrOcSrDGvEURmzhpaLqdql20IKpBIwzNQF88
/IATcC0Jd5vnVYUaT0XMNcVKL7mlaXUvC/DbiA3H6VpMvXsctyjNRBB7twFH
Ps6YT6E2I3ZcefSYsV/8tgmaIHiHGGtFEW+qiS6jqHT03QmT11SG0zatMhDP
2N0dCimiZo8idEM3BjbznGdFXRFY0OT91nMAsdu8gj1mFmYQs8f+WXFOPRlo
TJU2YK7ryk1TtZB19mGE1P5hTP+5LEb6UmW1oeSFLdVzs/MEkzCDqkD8WlSe
2mPt/ABLvbG5tFVDnW0xRNxp6XR/m1sGrVwmXO1QR6x9IHLinFdlh2KuSAbA
9zWQ0qo7ayoG6gkQeLvKhLilq7V2awUiQmkNTiK5S8lY6npKDYNquj0MjdRu
+UgOp6mPitKdS8+VMsrN6BhvQVFXiRUj0cA2Wlr+IZqkgj1ZHLNPUG1BZW2D
VhQ4Fq1mFLTkpFhVFoZgm3Pi1gjGbcUXTzvOZZkvz2TA1xQ1KdoNQ3oIAOtF
Fmfb5h9WJmBKEWqWpkvoERUCd0hYLe6Iwmu54rbSVjCnlPb0rzau2vScpj1P
q3ptBRZhlXWbSRCMqD8nAEBO7y7jHMw3bZ4WjAfiUmc6tSuTErNo0+yHagps
EMUFYRj3dnVKVVCLBxAuHA0EnfCUakUphuskuk9lka2DS8mtDLNjFO4b/VBL
hkeyBycBdrGE3P4HRzc5DzYQdbOztEebVt6z7rXfHIVASaIiV/oDZXM+SbEx
MhDX5ACVKzhbvMXVwvEWwlpbt3M1xbXDP9tbtlFcWlrC9SKwDxpQLYDjZLdL
qXgOzRNnntJaL3Ooa1nZwlfzxDl1RB1O2/OnjMDl7JPzt2d3Y1vbbItCd55i
C7//U4nok0iVQ4FQM2rzxBrjMb7h+/WXvoVL+frnv/03tXwZ7GzPFwkMe5Pl
ZtvrpUUJOEEg9GLjtVhTyRPaqr1wguyfLNg9Ul7J1P1jku3ris4FZNEKNa2M
gxRJNHKnF4LB2uaUzScQpeXppS0DrUl24wU6/Sv+BEPx8M/owLXxgWtHgRhi
8Fgcia/FN+KpeCaeixf/zLXg38P/59/gzwKsF/TIUUyB32/iEiVKJS7gv/Tb
OcXtplD47X6dkrUx4s+/hAw//bjN+z/9eH4q6EqbGfz0I67QNU8d+BeNsgQH
lbv6SFd+GWn+lb+MbOennxn06I1fQnL2yD9NxBfzJAe15JP7lx1XaHT+EgRh
25YTOvGbU5vNtavmkP/46hiF/6vTXmswm/o1575J4J03wLfQ7Vl0v8bDSN6o
xxvWZnxvDoBoDIM6PdGyl+iO+DF6ynVejItvm/y6o5//9j9ZzwKFIyCEPJjc
TrZDHrez/adManABN6Zhm/sDKjugxThP2yLtbuSxjprFoa4aLAd9Mfw4HDFY
2IKeL4z5gqviQYaqaNBr9VtdTWcrDNcMza3eadOlTm1DZZtI3Glkm3xx5j10
nGhRvtUVZfL7+EGmTbxcWWw7spTLqI0NZKThjlrZjquhasxmQVscADglpdWm
1blA0s7vuYWfxzXqKst1yDF8M+qCEgO74wLqWTXnCZRJYWkQnNnpFb1vUpXE
AMon05MzHh7xOylElPdpMBTSZNvZ+SlmAcE53lZWdk3RbRItvFyBZ/V4XhS/
NmM8SO5c17rOIfenp9O3fe6HRaAKMZ+U8dabPG1VysoxD1ocZpNFoJjZljUa
5mi+WvHnBxxAfWTGJYp62Ry87Liua6e5aMNnVRd9R8r0cml5HHy4NeODHn9D
m/idA3dgKZkyUlaHGeP8nvnEzJerx6AxG6MtobhtNRlmfAZkq6ZL6iewInbP
wm8a56LzpFZZs3OE5E/ONntl9n5bklt19uhht/a/2XlPYudsvnlPAipHXHw4
fuXa+X5/1PcnKUdPrj7wKl33qV3ToOn1HajxmuKpWrmXBLbHJf5sRrCT0grD
4a/YK5rN751BuGKUovPSR2fAKrRvTnDZc+WN6FXZXffFVe/R9yRcCbYtjh61
SOswNcuzkFoPCSoof0w2oF5x055pjjVbdXDTPPEdtq4eKMDmw6YK9GYPQxd+
LL8Y4Iy73iP5e+9e3OxZUJMAd+6khWJwQVWEpdNUb0nq4FaES+FuT4Mfn/Bk
zmRbJdJEkv3QvoTR2uaI92Dfw2hdbjbdUgN7Sa8zoPQquuP+UY+qroVe1r7H
uXO89kmljg9aBeuN3TL04I6ePuuRrZ4VV4xxHVH/F3o6b45QYSKbgCcU8ZFq
HH57VnjYafrbXfgO2dbpuS/NscklgbvFBt+X+uCx44FWjjXU7lyiG9fKYwJq
FDok3H+V4NEj6YYDuBMXTmdUYxN2NrB4zE3UbV9ov6Ho5eHjlEcaikZMt7ve
y841aehhjDsZ7dstnw5cPM7Bxg30FXWQDkBZzwbVnvQ7Vtg5a26XS1iHUIoD
bPrhT7SBv4iX4uTD1fu1+Ep0p+/T3vt1ELx2B7rtVrXVTsiy2a40KJpNCqmT
7GCjdiuMd+6tAK0sRXKMQAK7o3Dae58GgTubmdBLKtOXwwEIXXf0q3bAtRcq
KCghBGRIXx6J7tGhJFC4F0AwqLt+OYalXiLOCehJEw+1cvR+TFqhtd8f9fDj
JSq/r5Ae3nfD0bj3yU3QQ733R+Lnf/xd4Pv4xTPLP/YCfE9Z7FIMjRzhRDFf
CNAZKoJxO5WAgap2uUhSRdzQu7at2D6+RN/FDofBpkFlJhFcbpy4NpPteO+/
yUI1OFitsWOpVcflChcioJHHn+oW0MmDsi/RsKwdHnfWnKK4mpeKIdPBSks6
T9q03yuwPY92/2WmbNPqm8FoQDKMvQz8BtFeI7zNz9orcNuC+PdDFoeCI4mJ
UUKp/DJIkRe1faGOdD7hkoXqjMljp4Z+xHjSOju0x4P+1hH2Nfz4+vVEvMua
8u8JNANXpbeBUVW1Kd6ehVAesvWOo3WW3ycq5jNAg8rTciEVv+wsZGIUSk72
PX4XGiVBXgOZEr12iCuz9V6F4DSvS0rwNXdwmjeQaWkRMOa0/GNC0gT/C4KF
yNWoLgAA

-->

</rfc>

