rfc9490.original.xml   rfc9490.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.22 (Ruby 3.1. <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.0.2
4) --> ) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-iab-m-ten-workshop-02" category="info" consensus="true" submissionType="IAB" to -iab-m-ten-workshop-02" category="info" consensus="true" submissionType="IAB" to
cInclude="true" sortRefs="true" symRefs="true" version="3"> cInclude="true" sortRefs="true" symRefs="true" version="3" number="9490">
<!-- xml2rfc v2v3 conversion 3.18.0 --> <!-- xml2rfc v2v3 conversion 3.18.1 -->
<front>
<title abbrev="M-TEN workshop report">Report from the IAB workshop on Manage <front>
ment Techniques in Encrypted Networks (M-TEN)</title> <title abbrev="M-TEN Workshop Report">Report from the IAB Workshop on Manage
<seriesInfo name="Internet-Draft" value="draft-iab-m-ten-workshop-02"/> ment Techniques in Encrypted Networks (M-TEN)</title>
<seriesInfo name="RFC" value="9490"/>
<author initials="M." surname="Knodel" fullname="Mallory Knodel"> <author initials="M." surname="Knodel" fullname="Mallory Knodel">
<organization>Center for Democracy &amp; Technology</organization>
<address> <address>
<email>mknodel@cdt.org</email> <email>mknodel@cdt.org</email>
</address> </address>
</author> </author>
<author initials="W." surname="Hardaker" fullname="Wes Hardaker"> <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization/> <organization/>
<address> <address>
<email>ietf@hardakers.net</email> <email>ietf@hardakers.net</email>
</address> </address>
</author> </author>
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization/> <organization/>
<address> <address>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<date year="2023" month="August" day="14"/> <date year="2024" month="January"/>
<keyword>encryption</keyword> <keyword>encryption</keyword>
<keyword>network management</keyword> <keyword>network management</keyword>
<abstract> <abstract>
<t>The “Management Techniques in Encrypted Networks (M-TEN)” workshop was convened by the Internet Architecture Board (IAB) from 17 October 2022 to 19 Oct ober 2022 as a three-day online meeting. The workshop was organized in three par ts to discuss ways to improve network management techniques in support of even b roader adoption of encryption on the Internet. This report summarizes the worksh op's discussion and identifies topics that warrant future work and consideration .</t> <t>The "Management Techniques in Encrypted Networks (M-TEN)" workshop was conven ed by the Internet Architecture Board (IAB) from 17 October 2022 to 19 October 2 022 as a three-day online meeting. The workshop was organized in three parts to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. This report summarizes the workshop's d iscussion and identifies topics that warrant future work and consideration.</t>
<t>Note that this document is a report on the proceedings of the <t>Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are those workshop. The views and positions documented in this report are those
of the expressed during the workshop by participants and do not of the expressed during the workshop by participants and do not
necessarily reflect IAB views and positions.</t> necessarily reflect IAB views and positions.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
intarchboard.github.io/m-ten-workshop-public/draft-iab-m-ten-workshop.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-iab-m-ten-workshop/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/intarchboard/m-ten-workshop-public"/>.<
/t>
</note>
</front> </front>
<middle> <middle>
<section anchor="intro">
<section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet
architecture. This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working
groups of the Internet Engineering Task Force (IETF).</t>
<t>User privacy and security are constantly being improved by increasingly strong and more widely deployed encryption. This workshop aims to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet.</t> <t>User privacy and security are constantly being improved by increasingly strong and more widely deployed encryption. This workshop aims to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet.</t>
<t>Network management techniques need to evolve to work effectively and re <t>Network management techniques need to evolve to work effectively and re
liably in the presence of ubiquitous traffic encryption and support techniques t liably in the presence of ubiquitous traffic encryption and to support user priv
hat enhance user privacy. In an all-encrypted network, it is not viable to rely acy. In an all-encrypted network, it is not viable to rely on unencrypted metada
on unencrypted metadata for network monitoring and security functions, troublesh ta for network monitoring and security functions, troubleshooting devices, and p
ooting devices, and passive traffic measurements. New approaches are needed to t assive traffic measurements. New approaches are needed to track network behavior
rack network behaviors, e.g., by directly cooperating with endpoints and applica s, e.g., by directly cooperating with endpoints and applications, increasing use
tions, increasing use of in-band telemetry, increasing use of active measurement of in-band telemetry, increasing use of active measurement approaches, and priv
approaches, and privacy-preserving inference techniques.</t> acy-preserving inference techniques.</t>
<t>The aim of this IAB online workshop from October 17-19, 2022, has been <t>The aim of this IAB online workshop from October 17-19, 2022, has been
to provide a platform to explore the interaction between network management and to provide a platform to explore the interaction between network management and
traffic encryption and initiate new work on collaborative approaches that promot traffic encryption and to initiate work on collaborative approaches that promote
e security and user privacy while supporting operational requirements. As such t security and user privacy while supporting operational requirements. As such, t
he workshop addressed the following questions:</t> he workshop addressed the following questions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>What are actionable network management requirements?</li> <li>
<li>Who is willing to work on collaborative solutions?</li> <t>What are actionable network management requirements?</t>
<li>What are the starting points for collaborative solutions?</li> </li>
<li>
<t>Who is willing to work on collaborative solutions?</t>
</li>
<li>
<t>What are the starting points for collaborative solutions?</t>
</li>
</ul> </ul>
<section anchor="about-this-workshop-report-content"> <section anchor="about-this-workshop-report-content">
<name>About this workshop report content</name> <name>About This Workshop Report Content</name>
<t>This document is a report on the proceedings of the workshop. The <t>This document is a report on the proceedings of the workshop. The
views and positions documented in this report are those of the views and positions documented in this report are those of the
expressed during the workshop by participants and do not necessarily workshop participants and do not necessarily
reflect IAB views and positions.</t> reflect IAB views and positions.</t>
<t>Furthermore, the content of the report comes from presentations given <t>Furthermore, the content of the report comes from presentations given
by workshop participants and notes taken during the discussions, by workshop participants and notes taken during the discussions,
without interpretation or validation. Thus, the content of this without interpretation or validation. Thus, the content of this
report follows the flow and dialog of the workshop but does not report follows the flow and dialog of the workshop but does not
attempt to capture a consensus.</t> attempt to capture a consensus.</t>
</section> </section>
</section> </section>
<section anchor="workshop-scope-and-discussion"> <section anchor="workshop-scope-and-discussion">
<name>Workshop Scope and Discussion</name> <name>Workshop Scope and Discussion</name>
<t>The workshop was organized across three days with all-group discussion slots, one per day. The following topic areas were identified and the program co mmittee organized paper submissions into three main themes for each of the three discussion slots. During each discussion, those papers were presented sequentia lly with open discussion held at the end of each day.</t> <t>The workshop was held across three days with all-group discussion slots , one per day. The following topic areas were identified, and the program commit tee organized paper submissions into three main themes for each of the three dis cussion slots. During each discussion, those papers were presented sequentially with open discussion held at the end of each day.</t>
<section anchor="day1"> <section anchor="day1">
<name>“Where we are” - Requirements and Passive Observations</name> <name>"Where We Are" - Requirements and Passive Observations</name>
<t>The first day of the workshop agenda focused on the existing state of <t>The first day of the workshop focused on the existing state of the re
the relationship between network management and encrypted traffic from various lationship between network management and encrypted traffic from various angles.
angles. Presentations ranged from discussing classifiers using machine-learning Presentations ranged from discussing classifiers using machine learning to reco
to recognize traffic, to advanced techniques for evading traffic analysis, to us gnize traffic, to advanced techniques for evading traffic analysis, to user priv
er privacy considerations.</t> acy considerations.</t>
<t>After an introduction that covered the goals of the workshop and the <t>After an introduction that covered the goals of the workshop and the
starting questions (as described in <xref target="intro"/>), there were four pre starting questions (as described in <xref target="intro"/>), there were four pre
sentations, followed by open discussion.</t> sentations followed by open discussion.</t>
<section anchor="traffic-classification-and-network-management"> <section anchor="traffic-classification-and-network-management">
<name>Traffic classification and network management</name> <name>Traffic Classification and Network Management</name>
<t>Many existing network management techiques are passive in nature: t <t>Many existing network management techniques are passive in nature:
hey don't rely on an explicit signals from end hosts to negotiate with network m they don't rely on explicit signals from end hosts to negotiate with network mid
iddleboxes, but instead rely on inspecting packets to recognize traffic and appl dleboxes but instead rely on inspecting packets to recognize traffic and apply v
y various policies. Traffic classification, as a passive technique, is being cha arious policies. Traffic classification, as a passive technique, is being challe
llenged by increasing encryption.</t> nged by increasing encryption.</t>
<t>Traffic classification is commonly performed by networks to infer w <t>Traffic classification is commonly performed by networks to infer w
hat applications and services are being used. This information is in turn used f hat applications and services are being used. This information is in turn used f
or capacity and resource planning, Quality-of-Service (QoS) monitoring, traffic or capacity and resource planning, Quality-of-Service (QoS) monitoring, traffic
prioritization, network access control, identity management, and malware detecti prioritization, network access control, identity management, and malware detecti
on. However, since classification traditionally relies on recognizing unencrypte on. However, since classification commonly relies on recognizing unencrypted pro
d properties of packets in a flow, increasing encryption of traffic can decrease perties of packets in a flow, increasing encryption of traffic can decrease the
the effectiveness of classification.</t> effectiveness of classification.</t>
<t>The amount of classification that can be performed on traffic also <t>The amount of classification that can be performed on traffic also
provides a useful insight onto how "leaky" the protocols used by applications ar provides useful insight into how "leaky" the protocols used by applications are
e, and points to areas where information is visible to any observer, which may b and points to areas where information is visible to any observer, who may or may
e malicious or not.</t> not be malicious.</t>
<t>Traditionally, classification has been based on experts crafting sp <t>Frequently, classification has been based on specific rules crafted
ecific rules, but there is also a move toward using maching learning to recogniz by experts, but there is also a move toward using machine learning to recognize
e patterns. "Deep learning" machine learning models generally rely on analyzing patterns. "Deep learning" machine-learning models generally rely on analyzing a
a large set of traffic over time, and have trouble reacting quickly to changes i large set of traffic over time and have trouble reacting quickly to changes in
n traffic patterns.</t> traffic patterns.</t>
<t>Models that are based on closed-world data sets also become less us <t>Models that are based on closed-world data sets also become less us
eful over time, as traffic changes. <xref target="JIANG"/> describes experiments eful over time as traffic changes. <xref target="JIANG"/> describes experiments
that showed that a model that performs with high accuracy on an initial data se that show that a model that performed with high accuracy on an initial data set
t became severely degraded when running on a newer data set that contained traff becomes severely degraded when running on a newer data set that contains traffic
ic from the same applications. Even in as little time as one week, the traffic c from the same applications. Even in as little time as one week, the traffic cla
lassification would become degraded. However, the set of features in packets and ssification would become degraded. However, the set of features in packets and f
flows that were useful for models stayed mostly consistent, even if the models lows that were useful for models stayed mostly consistent, even if the models th
themselves needed to be updated. Models where the feature space is reduced to fe emselves needed to be updated. Models where the feature space is reduced to fewe
wer features showed better resiliency, and could be retrained more quickly. Base r features showed better resiliency and could be retrained more quickly. Based o
d on this, <xref target="JIANG"/> recommends more work and research on determini n this, <xref target="JIANG"/> recommends more work and research to determine wh
ng which set of features in IP packets are most useful for focused machine learn ich set of features in IP packets are most useful for focused machine-learning a
ing analysis. <xref target="WU"/> also recommends further research investment in nalysis. <xref target="WU"/> also recommends further research investment in Arti
Artificial Intelligent (AI) analysis for network management.</t> ficial Intelligence (AI) analysis for network management.</t>
</section> </section>
<section anchor="preventing-traffic-analysis"> <section anchor="preventing-traffic-analysis">
<name>Preventing traffic analysis</name> <name>Preventing Traffic Analysis</name>
<t>Just as traffic classification is continually adapting, techniques <t>Just as traffic classification is continually adapting, techniques
to prevent traffic analysis and obfuscate application and user traffic are conti to prevent traffic analysis and to obfuscate application and user traffic are co
nually evolving. An invited talk from the authors of <xref target="DITTO"/> shar ntinually evolving. An invited talk from the authors of <xref target="DITTO"/> s
ed a novel approach with the workshop for how to build a very robust system to p hared a novel approach with the workshop for how to build a very robust system t
revent unwanted traffic analysis.</t> o prevent unwanted traffic analysis.</t>
<t>Usually traffic obfuscation is performed by changing the timing of <t>Usually traffic obfuscation is performed by changing the timing of
packets or adding padding data. The practices can be costly and negatively impac packets or by adding padding to data. The practices can be costly and negatively
t performance. DITTO demonstrated the feasibility of applying traffic obfuscatio impact performance. <xref target="DITTO"/> demonstrated the feasibility of appl
n on aggregated traffic in the network with minimal overhead and in line speed.< ying traffic obfuscation on aggregated traffic in the network with minimal overh
/t> ead and inline speed.</t>
<t>While traffic obfuscation techniques are today not widely deployed, <t>While traffic obfuscation techniques are not widely deployed today,
this study underlines, together with the need for continuous effort to keep tra this study underlines the need for continuous effort to keep traffic models upd
ffic models updated over time, the challenges of classification of encrypted tra ated over time, the challenges of the classification of encrypted traffic, as we
ffic as well as opportunities to further enhance user privacy.</t> ll as the opportunities to further enhance user privacy.</t>
</section> </section>
<section anchor="users-and-privacy"> <section anchor="users-and-privacy">
<name>Users and privacy</name> <name>Users and Privacy</name>
<t>The Privacy Enhancements and Assessments Research Group is working <t>The Privacy Enhancements and Assessments Research Group (PEARG) is
on a document to discuss guidelines for how to measure traffic on the Internet i working on a document to discuss guidelines for measuring traffic on the Interne
n a safe and privacy-friendly way (<xref target="I-D.irtf-pearg-safe-internet-me t in a safe and privacy-friendly way <xref target="I-D.irtf-pearg-safe-internet-
asurement"/>). These guidelines and principles provide another angle onto the di measurement"/>. These guidelines and principles provide another view on the disc
scussion of passive classification and analysis of traffic.</t> ussion of passive classification and analysis of traffic.</t>
<t>Consent for collection and measurement of metadata is an important <t>Consent for collection and measurement of metadata is an important
consideration in deploying network measurement techniques. This consent can be e consideration in deploying network measurement techniques. This consent can be g
xplicitly given as informed consent, or can be given by proxy or be only implied iven explicitly as informed consent, given by proxy, or may be only implied. For
. For example, a user of a network might need to consent to certain measurement example, a user of a network might need to consent to certain measurement and t
and traffic treatment when joining a network.</t> raffic treatment when joining a network.</t>
<t>Various techniques for data collection can also improve user privac <t>Various techniques for data collection can also improve user privac
y, such as discarding data after a short period of time, masking out aspects of y, such as discarding data after a short period of time, masking aspects of data
data that contain user-identifying information, reducing the accuracy of collect that contain user-identifying information, reducing the accuracy of collected d
ed data, and aggregating data.</t> ata, and aggregating data.</t>
</section> </section>
<section anchor="discussion"> <section anchor="discussion">
<name>Discussion</name> <name>Discussion</name>
<t>The intents and goals of users, application developers, and network <t>The intents and goals of users, application developers, and network
operators align in some cases, but not others. One of the recurring challenges operators align in some cases, but not in others. One of the recurring challeng
that came up was not having a clear way to understand or communicate intents and es that was discussed was the lack of a clear way to understand or to communicat
requirements. Both traffic classification and traffic obfuscation attempt to ch e intents and requirements. Both traffic classification and traffic obfuscation
ange the visibility of traffic without cooperation of other parties: traffic cla attempt to change the visibility of traffic without cooperation of other parties
ssification is a network attempting to inspect application traffic without coord : traffic classification is an attempt by the network to inspect application tra
ination from applications, and traffic obfuscation is an attempt to hide that sa ffic without coordination from applications, and traffic obfuscation is an attem
me traffic as it transits a network.</t> pt by the application to hide that same traffic as it transits a network.</t>
<t>Traffic adaptation and prioritization is one dimension in which the <t>Traffic adaptation and prioritization is one dimension in which the
incentives for cooperation seem most clear. Even if an application is trying to incentives for cooperation seem most clear. Even if an application is trying to
prevent leaking metadata, it could benefit from signals from network about sudd prevent the leaking of metadata, it could benefit from signals from the network
en capacity changes that can help it adapt its application quality, such as bitr about sudden capacity changes that can help it adapt its application quality, s
ates and codecs. Such signalling may not be appropriate for the most privacy-sen uch as bitrates and codecs. Such signaling may not be appropriate for the most p
sitive applications, like Tor, but could be applicable for many others. There ar rivacy-sensitive applications, like Tor, but could be applicable for many others
e existing protocols that involve explicit signaling between applications and ne . There are existing protocols that involve explicit signaling between applicati
tworks, such as Explicit Congestion Notification (ECN) <xref target="RFC3168"/>, ons and networks, such as Explicit Congestion Notification (ECN) <xref target="R
but that has yet to see wide adoption.</t> FC3168"/>, but that has yet to see wide adoption.</t>
<t>Managed networks (such a private corporate networks) was brought up <t>Managed networks (such as private corporate networks) were brought
in several comments as a particularly challenging area for being able to meet m up in several comments as particularly challenging for meeting management requir
anagement requirements while maintaining encryption and privacy. These networks ements while maintaining encryption and privacy. These networks can have legal a
can have legal and regulated requirements for detection of specific fraudulent o nd regulated requirements for detection of specific fraudulent or malicious traf
r malicious traffic.</t> fic.</t>
<t>Personal networks that enable managed parental controls have simila <t>Personal networks that enable managed parental controls have simila
r complications with encrypted traffic and user privacy. In these scenarios, the r complications with encrypted traffic and user privacy. In these scenarios, the
parental controls being operated by the network may be as simple as a DNS filte parental controls that are operated by the network may be as simple as a DNS fi
r, and can be made ineffective by a device routing traffic to an alternate DNS r lter, which can be made ineffective by a device routing traffic to an alternate
esolver.</t> DNS resolver.</t>
</section> </section>
</section> </section>
<section anchor="day2"> <section anchor="day2">
<name>“Where we want to go” - Collaboration Principles</name> <name>"Where We Want to Go" - Collaboration Principles</name>
<t>The second day of the workshop agenda focused on the emerging techniq <t>The second day of the workshop focused on the emerging techniques for
ues for analysing, managing or monitoring encrypted traffic. Presentations range analyzing, managing, or monitoring encrypted traffic. Presentations covered adv
d from discussing advanced classification and identification, including machine- anced classification and identification, including machine-learning techniques,
learning techniques, for the purposes of manging network flows, monitoring or mo for the purposes of managing network flows or monitoring or monetizing usage.</t
netising usage.</t> >
<t>After an introduction that covered the goals of the workshop and the starting questions (as described in <xref target="intro"/>), there were three pr esentations, followed by open discussion.</t> <t>After an introduction that covered the goals of the workshop and the starting questions (as described in <xref target="intro"/>), there were three pr esentations, followed by open discussion.</t>
<section anchor="first-party-collaboration-for-network-management"> <section anchor="first-party-collaboration-for-network-management">
<name>First party collaboration for network management</name> <name>First-Party Collaboration for Network Management</name>
<t>It is the intention of encryption to create a barrier between entit <t>It is the intent of end-to-end encryption of traffic to create a ba
ies inside the communication channel and everyone else, including network operat rrier between entities inside the communication channel and everyone else, inclu
ors, considering end-to-end encryption of traffic. Any attempt, therefore, to ov ding network operators. Therefore, any attempt to overcome that intentional barr
ercome that intentional barrier requires an intent to collaborate between the in ier requires collaboration between the inside and outside entities. At a minimum
side and outside entities. Those entities must, at a minimum, agree on the benef , those entities must agree on the benefits of overcoming the barrier (or solvin
its to overcoming the barrier (or solving the problem), that costs are proportio g the problem), agree that costs are proportional to the benefits, and agree to
nal to the benefits, and to additional limitations, or safeguards, against bad b additional limitations or safeguards against bad behavior by collaborators inclu
ehaviour by collaborators including the inclusion of other non-insiders <xref ta ding other non-insiders <xref target="BARNES"/>.</t>
rget="BARNES"/>.</t> <t>The Internet is designed interoperably, which means an outside enti
<t>The Internet is designed interoperably, which means an outside enti ty wishing to collaborate with the inside might be any number of intermediaries
ty wishing to collaborate with the inside might be any number of intermediaries and not, say, a specific person that can be trusted in the human sense. Addition
and not, say, a specific person that can be trusted in the human sense. Addition ally, the use of encryption, especially network-layer or transport-layer encrypt
ally the use of encryption, especially network-layer or transport-layer encrypti ion, introduces dynamic or opportunistic or perfunctory discoverability. These r
on, introduces dynamic or opportunitistic or perfunctory discoverability. These ealities point to a need to ask why an outside entity might make an engineering
realities both point to a need to interrogate the reason why any outside entity case to collaborate with the user of a network with encrypted traffic and to ask
might make an engineering case to collaborate with the user of a network with en whether the trade-offs and potential risks are worth it to the user.</t>
crypted traffic, and whether the tradeoffs and potential risks are worth it to t <t>However, the answers cannot be specific, and the determinations or
he user.</t> guidance need to be general as the encryption boundary is inevitably an applicat
<t>However, the answers cannot be specific and the determinations or g ion used by many people. Trade-offs must make sense to users who are unlikely to
uidance need to be general as the encryption boundary is inevitably an applicati be thinking about network management considerations. Harms need to be preemptiv
on used by many people. Tradeoffs must make sense to users who are unlikely to b ely reduced because, in general terms, few users would choose network management
e thinking about network management considerations. Harms need to be preemptivel benefits over their own privacy if given the choice.</t>
y reduced because in general terms few users would choose network management ben <t>Some have found that there appears to be little, if any, evidence
efits over their own privacy if given the choice.</t> that encryption causes network problems that are meaningful to the user. Since
<t>Some have found that there appears to be little if any actual evide alignment on problem solving is a prerequisite to collaboration on a
nce solution, it does not seem that collaboration across the encryption
that encryption is causing user-meaningful network problems. Since
alignment on problem-solving is a prerequisite to collaboration on a
solution it does not seem that collaboration across the encryption
boundary is called for.</t> boundary is called for.</t>
</section> </section>
<section anchor="second-and-third-party-collaboration-for-network-manage ment"> <section anchor="second-and-third-party-collaboration-for-network-manage ment">
<name>Second and third party collaboration for network management</nam <name>Second- and Third-Party Collaboration for Network Management</na
e> me>
<t>Even with the wide-scale deployment of encryption in new protocols <t>Even with the wide-scale deployment of encryption in new protocols
and techniques that prevent passive observers of network traffic from knowing th and of techniques that prevent passive observers of network traffic from knowing
e content of exchanged communications, important information such as which parti the content of exchanged communications, important information, such as which p
es communicate and sometimes even which services have been requested may still b arties communicate and sometimes even which services have been requested, may st
e able to be deduced. The future is to conceal more data and metadata from passi ill be able to be deduced. The future is to conceal more data and metadata from
ve observers and also to minimize information exposure to second parties (where passive observers and also to minimize information exposure to second parties (w
the user is the first party) by, maybe counterintuitively, introducing third-par here the user is the first party) by, maybe counterintuitively, introducing thir
ty relay services to intermediate communications. As discussed in <xref target=" d-party relay services to intermediate communications. As discussed in <xref tar
KUEHLEWIND"/>, the relay is a mechanism to separate (using additional levels of get="KUEHLEWIND"/>, the relay is a mechanism that uses additional levels of encr
encryption) two important pieces of information: knowledge of the identity of th yption to separate two important pieces of information: knowledge of the identit
e person accessing a service is separated from knowledge about the service being y of the person accessing a service is separated from knowledge about the servic
accessed. By contrast a VPN uses only one level of encryption and does not sepa e being accessed. By contrast, a VPN uses only one level of encryption and does
rate identity (first party) and service (second party) metadata.</t> not separate identity (first party) and service (second party) metadata.</t>
<t>Relay mechanisms are termed "oblivious", there is a future for spec <t>Relay mechanisms are termed "oblivious", there is a future for spec
ifications in privacy-preserving measurement (PPM), and protocols like Multiplex ifications in privacy-preserving measurement (PPM), and protocols like Multiplex
ed Application Substrate over QUIC Encryption (MASQUE) are discussed in the IETF ed Application Substrate over QUIC Encryption (MASQUE) are discussed in the IETF
. In various schemes, users are ideally able to share their identity only with t . In various schemes, users are ideally able to share their identity only with t
he entity they have identified as a trusted one. That data is not shared with th he entity they have identified as a trusted one. That data is not shared with th
e service provider. However this is more complicated for network management, but e service provider. However, this is more complicated for network management, bu
there may be opportunities for better collaboration between the network and, sa t there may be opportunities for better collaboration between the network and, s
y, the application or service at the endpoint.</t> ay, the application or service at the endpoint.</t>
<t>A queriable relay mechanism could preserve network management funct <t>A queriable relay mechanism could preserve network management funct
ions that are disrupted by encryption, such as TCP optimisation, quality of serv ions that are disrupted by encryption, such as TCP optimization, quality of serv
ice, zero-rating, parental controls, access control, redirection, content enhanc ice, zero-rating, parental controls, access control, redirection, content enhanc
ement, analytics and fraud prevention. Instead of encrypted communication betwee ement, analytics, and fraud prevention. Instead of encrypting communication betw
n only two ends and passive observation by all on-path elements, intermediate re een only two ends with passive observation by all on-path elements, intermediate
lays could be trusted parties with limited information for the purposes of colla relays could be introduced as trusted parties that get to see limited informati
boration between in-network intermediary services' support.</t> on for the purpose of collaboration between in-network intermediary services.</t
>
</section> </section>
<section anchor="visible-optional-network-management"> <section anchor="visible-optional-network-management">
<name>Visible, optional network management</name> <name>Visible, Optional Network Management</name>
<t>In encrypted communications, out of all of the possible network man <t>Out of all of the possible network management functions that might
agement functions that might be ameliorated by proxying, the ability to control be ameliorated by proxying, the ability to control congestion in encrypted commu
congestion has been researched in depth. These techniques are realized based on nications has been researched in depth. These techniques are realized based on T
TCP performance enhancing proxies (PEP) that either entirely intercept a TCP con CP performance-enhancing proxies (PEPs) that either entirely intercept a TCP con
nection or interfere with the transport information in the TCP header. However, nection or interfere with the transport information in the TCP header. However,
despite the challenge that the new encrypted protocol will limit any such in-net despite the challenge that the new encrypted protocol will limit any such in-net
work interference, these techniques can also have a negative impact on the evolv work interference, these techniques can also have a negative impact on the evolv
ability of these protocols. Therefore, instead of manipulating existing informat ability of these protocols. Therefore, a new approach was presented where, inste
ion, a new approach was presented where additional information is send using a ad of manipulating existing information, additional information is sent using a
so-called side-car protocol independent of the main transport protocol that is u so-called sidecar protocol independent of the main transport protocol that is us
sed end-to-end <xref target="WELZL"/>. E.g. side car information can contain add ed end to end <xref target="WELZL"/>. For example, sidecar information can conta
itional acknowledgements to enable in-network local retransmission faster end-to in additional acknowledgments to enable in-network local retransmission or faste
-end retransmission by reducing the signaling round trip time.</t> r end-to-end retransmission by reducing the signaling round-trip time.</t>
<t>Taking user privacy benefits for granted, there is a need to invest <t>Taking user privacy benefits for granted, there is a need to invest
igate the comparable performance outputs of various encrypted traffic configurat igate the comparable performance outputs of various encrypted traffic configurat
ions such as use of an additional "side-car" protocol, or explicit encrypted and ions such as the use of an additional sidecar protocol, or explicit encrypted an
trusted network communication using MASQUE in relation to existing techniques s d trusted network communication using MASQUE in relation to existing techniques
uch as TCP performance enhancing proxies (PEP), etc.</t> such as TCP PEPs, etc.</t>
</section> </section>
<section anchor="discussion-1"> <section anchor="discussion-1">
<name>Discussion</name> <name>Discussion</name>
<t>One size fits all? On the issue of trust, different networks or dev <t>One size fits all? On the issue of trust, different networks or dev
ices are going to have different requirements for the level of trust that they h ices will have different trust requirements for devices, users, or each other, a
ave in devices, users or each other, and vice versa. For example, imagine networ nd vice versa. For example, imagine two networks with really different security
ks with really different security requirements, like protecting children in a ho requirements, like a home network with a requirement to protect its child users
me versus a national security institution. How could one network architecture so versus a national security institution's network. How could one network architec
lve the needs of all use cases?</t> ture solve the needs of all use cases?</t>
<t>Does our destination have consequences? It seems sometimes that the <t>Does our destination have consequences? It seems sometimes that the
re may be consequences many years down the line of ubiquitous, strong encryption re may be future consequences caused by the ubiquitous, strong encryption of net
of network traffic because it will cause a reaction by intermediaries to find w work traffic because it will cause intermediaries to poke holes in what are supp
ays to poke holes in what are supposed to be long-term solutions for user privac osed to be long-term solutions for user privacy and security.</t>
y and security.</t> <t>Can we bring the user along? While there has been a focus on the go
<t>Can we bring the user along? While there has been a focus on the go od reasons why people might collaborate across the encryption barrier, there wil
od reasons for why people might collaborate across the encryption barrier, there l always be others who want to disrupt that in order to exploit the data for the
will always be others who want to disrupt that because they are motivated to ex ir own gain, and sometimes exploitation is called innovation. High-level policy
ploit the data for their own gain, and sometimes this is called innovation. What mitigations have exposed how powerless end users are against corporate practices
high-level policy mitigations have done is to expose how powerless end users ar of data harvesting. And yet interfaces to help users understand these lower-lay
e to corporate practices of data harvesting. And yet interfaces to help users un er traffic flows to protect their financial transactions or privacy haven't been
derstand these lower layer traffic flows to protect their financial transactions achieved yet. That means that engineers must make inferences about user wants.
or privacy haven't been achieved yet. That means that engineers are having to m Instead, we should make these relationships and trade-offs more visible.</t>
ake inferences about what users want. Instead we should be making these relation
ships and tradeoffs more visible.</t>
</section> </section>
</section> </section>
<section anchor="day3"> <section anchor="day3">
<name>“How we get there” - Collaboration Use cases</name> <name>"How We Get There" - Collaboration Use Cases</name>
<t>The third day focused on techniques that could actually be used to <t>The third day focused on techniques that could be used to
improve management of encrypted networks. A central theme of all of improve the management of encrypted networks.<br/>
the presentations about potential proposed paths forward included some The potential paths forward described in the presentations included some
element of collaboration between networks and subscribing clients that element of collaboration between the networks and the subscribing clients that
simultaneously want both privacy and protection. Thus, the central simultaneously want both privacy and protection. Thus, the central
theme in the third day became negotiation and collaboration.</t> theme of the third day became negotiation and collaboration.</t>
<section anchor="establishing-expected-contracts-to-enable-security-mana gement"> <section anchor="establishing-expected-contracts-to-enable-security-mana gement">
<name>Establishing expected contracts to enable security management</n <name>Establishing Expected Contracts to Enable Security Management</n
ame> ame>
<t>When thinking about enterprise networks where client behavior is <t>For enterprise networks where client behavior is
potentially managed, <xref target="COLLINS"/> proposes "Improving network potentially managed, <xref target="COLLINS"/> proposes "Improving network
monitoring through contracts", where contracts describe different monitoring through contracts", where contracts describe different
states of network behavior.</t> states of network behavior.</t>
<t>Because network operators have a limited amount of time to focus on <t>Because network operators have a limited amount of time to focus on
problems and process alerts, contracts and states let the operator problems and process alerts, contracts and states let the operator
focus on a particular aspect of a current situation or problem. The focus on a particular aspect of a current situation or problem. The
current estimate for the number of events a Security Operations Center (SOC) ope rator can handle current estimate for the number of events a Security Operations Center (SOC) ope rator can handle
is about 10 per hour. Operators must work within the limits imposed is about 10 per hour. Operators must work within the limits imposed
by their organization, and must pick between options that frequently by their organization and must pick among options that frequently
only frustrate attackers -- entirely preventing attacks is potentially only frustrate attackers -- preventing attacks entirely is potentially
impossible. Finally, operators must prioritize and manage the most impossible. Finally, operators must prioritize and manage the most
events possible.</t> events possible.</t>
<t>Validating which alerts are true positives is challenging because l ots <t>Validating which alerts are true positives is challenging because l ots
of weird traffic creates many anomalies and not all anomalies are of weird traffic creates many anomalies, and not all anomalies are
malicious events. Identifying what anomalous traffic is rooted in malicious events. Identifying which anomalous traffic is rooted in
malicious activity with any level of certainty is extremely malicious activity with any level of certainty is extremely
challenging. Unfortunately, applying the latest machine learning challenging. Unfortunately, applying the latest machine-learning
techniques has only produced mixed results. To make matters worse, techniques has produced mixed results. To make matters worse,
the large amounts of Internet-wide scanning has resulted in endless the large amounts of Internet-wide scanning has resulted in endless
traffic that is technically malicious but only creates an information traffic that is technically malicious but only creates an information
overload and challenges event prioritization. Any path forward must overload and challenges event prioritization. Any path forward must
succeed in freeing up analyst time to concentrate on the more free up analyst time to concentrate on the more
challenging events.</t> challenging events.</t>
<t>The proposed contract solution is to define a collection of accepta ble <t>The proposed contract solution is to define a collection of accepta ble
behaviors categorized into an envelope of different states that might behaviors that comprises different states that might
include IP addresses, domain names, and indicators of compromise. include IP addresses, domain names, and indicators of compromise.
Deviation from a contract might indicate that a system is acting Deviation from a contract might indicate that a system is acting
outside a normal mode of behavior, or even a normal mode of outside a normal mode of behavior or even that a normal mode of
behavior is suddenly missing. An example contract might be "this behavior is suddenly missing. An example contract might be "this
system is expected to update its base OS once a day", and if this system is expected to update its base OS once a day". If this
doesn't occur then this expectation has not been met and the system doesn't occur, then this expectation has not been met, and the system
should be checked as it failed to call home to look for (potentially should be checked as it failed to call home to look for (potentially
security related) updates.</t> security-related) updates.</t>
<t>Within the IETF, the Manufacturer Usage Description Specification <t>Within the IETF, the Manufacturer Usage Description Specification
(MUD) {?RFC8520} specification is one subset of contracts. Note that (MUD) <xref target="RFC8520"/> is one subset of contracts. Note that
contracts are likely to only succeed in a constrained, expected contracts are likely to succeed only in a constrained, expected
environment maintained by operational staff, and may not work in an environment maintained by operational staff and may not work in an
open internet environment where end users are driving all network open Internet environment where end users drive all network
connections.</t> connections.</t>
</section> </section>
<section anchor="zero-knowledge-middleboxes"> <section anchor="zero-knowledge-middleboxes">
<name>Zero Knowledge Middleboxes</name> <name>Zero-Knowledge Middleboxes</name>
<t>The world is not only shifting to increased encrypted traffic but i s <t>The world is not only shifting to increased encrypted traffic but i s
also encrypting more and more of the metadata (e.g. DNS queries and also encrypting more and more of the metadata (e.g., DNS queries and
responses). This makes network policy enforcement by middleboxes responses). This makes network policy enforcement by middleboxes
significantly more challenging. The result is the creation of a significantly more challenging. The result is a
significant tension between security enforcement and privacy significant tension between security enforcement and privacy
protection.</t> protection.</t>
<t>A goal for solving this problem should include not weakening <t>Goals for solving this problem should include
encryption, should enable networks to enforce their policies, and enabling networks to enforce their policies, but
should ideally not require newly deployed server software. Existing should not include the weakening of encryption nor the deployment of new server
solutions fail with at least one of these points.</t> software. Existing
solutions fail to meet at least one of these points.</t>
<t>A cryptographic principle of a "zero-knowledge proof" (ZKP) <xref t arget="GRUBBS"/> <t>A cryptographic principle of a "zero-knowledge proof" (ZKP) <xref t arget="GRUBBS"/>
maybe one path forward to consider. A ZKP allows a third party to may be one path forward to consider. A ZKP allows a third party to
verify that a statement is true, without revealing what the statement verify that a statement is true without revealing what the statement
actually is. Applying this to network traffic has been shown to allow actually is. Applying this to network traffic has been shown to allow
a middlebox to verify that traffic to a web server is actually a middlebox to verify that traffic to a web server is
compliant with a policy without revealing the actual contents. This compliant with a policy without revealing the actual contents. This
solution meets the above three criteria. Using ZKP within TLS 1.3 solution meets the three criteria listed above. Using ZKP within TLS 1.3
traffic turns out to be plausible.</t> traffic turns out to be plausible.</t>
<t>An example engine was built to test ZKP using encrypted DNS. Clien ts <t>An example engine using encrypted DNS was built to test ZKP. Clien ts
were able to create DNS requests that were not listed within a DNS were able to create DNS requests that were not listed within a DNS
block list. Middleboxes could verify, without knowing the exact block list. Middleboxes could verify, without knowing the exact
request, that the client's DNS request was not in the prohibited list. request, that the client's DNS request was not on the prohibited list.
Although the result was functional, the computational overhead was Although the result was functional, the computational overhead was
still too slow and future work will be needed to decrease the ZKP still too slow, and future work will be needed to decrease the ZKP-imposed
imposed latencies.</t> latencies.</t>
</section> </section>
<section anchor="red-rover-a-collaborative-approach-to-content-filtering "> <section anchor="red-rover-a-collaborative-approach-to-content-filtering ">
<name>Red Rover - A collaborative approach to content filtering</name> <name>Red Rover - a Collaborative Approach to Content Filtering</name>
<t>The principle challenge being studied is how to deal with the inher <t>The principle challenge being studied is how to handle the inherent
it
conflict between filtering and privacy. Network operators need to conflict between filtering and privacy. Network operators need to
implement policies and regulations that can originate from many implement policies and regulations that can originate from many
locations (e.g. security, governmental, parental, etc). Conversely, locations (e.g., security, governmental, parental, etc.). Conversely,
clients need to protect user's privacy and user security.</t> clients need to protect their users' privacy and security.</t>
<t>Safe browsing, originally created by Google, is one example of a <t>Safe browsing, originally created by Google, is one example of a
mechanism that tries to meet both sides of this conflict. It would be mechanism that tries to meet both sides of this conflict. It would be
beneficial to standardize this and other similar mechanisms. beneficial to standardize this and other similar mechanisms.
Operating systems could continually protect their users by ensuring Operating systems could continually protect their users by ensuring
that malicious destinations are not being reached. This would require that malicious destinations are not being reached. This would require
some coordination between cooperating clients and servers offering some coordination between cooperating clients and servers offering
protection services. These collaborative solutions may be the best protection services. These collaborative solutions may be the best
compromise between the tension of privacy vs protection based services compromise to resolve the tension between privacy services and protection servic es
<xref target="PAULY"/>.</t> <xref target="PAULY"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="conclusions"> <section anchor="conclusions">
<name>Conclusions</name> <name>Conclusions</name>
<t>Looking forward, the workshop participants identified that solving the <t>Looking forward, the workshop participants identified that solving the
entire problem space with a single approach will be challenging for entire problem space with a single approach will be challenging for
several reasons:</t> several reasons:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The scalability of many solutions will likely be an issue as some <li>
solutions are complex or expensive to implement.</li> <t>The scalability of many solutions will likely be an issue as some
<li>Collaboration between multiple parties will be required for many solutions are complex or expensive to implement.</t>
</li>
<li>
<t>Collaboration between multiple parties will be required for many
mechanisms to function, and the sets of parties required for different mechanisms to function, and the sets of parties required for different
use cases might be disjoint.</li> use cases might be disjoint.</t>
<li>There is an unanswered question of whether or not network operators </li>
be willing to participate and allow technologies into their environment <li>
requirements in exchange for technologies that prove their clients are <t>There is an unanswered question of whether or not network operators
being good net-citizens. If so, some of these solutions might be required are willing to participate by allowing new encryption technologies into their e
to exist before networks allow a certain type of increased encryption; nvironment in exchange for technologies that prove their clients are being good
consider the example of TLS Encrypted Client Hello being blocked by net-citizens. If so, some of these solutions might be required to exist before n
some network operators.</li> etworks allow a certain type of increased encryption; consider the example of TL
S Encrypted Client Hello being blocked by some network operators.</t>
</li>
</ul> </ul>
<t>The breadth of the problem space itself is another complicating <t>The breadth of the problem space itself is another complicating
factor. There is a wide variety of network architectures, and each factor. There is a wide variety of network architectures, and each
has different requirements for both data encryption and network has different requirements for both data encryption and network
management. Each problem space will have different encumbrances of management. Each problem space will have multiple, different encumbrances:
multiple types; for example, technical, legal, data ownership, for example, technical, legal, data ownership,
and regulatory concerns. New network architectures might be needed to and regulatory concerns. New network architectures might be needed to
solve this problem at a larger scope, which would in turn require solve this problem at a larger scope, which would in turn require
interoperability support from network product vendors. Education about interoperability support from network product vendors. Education about
various solutions will be required in order to ensure regulation and various solutions will be required in order to ensure regulation and
policy organizations can understand and thus support the deployment of policy organizations can understand and thus support the deployment of
developed solutions.</t> developed solutions.</t>
<t>After new technologies and related standards are developed and deployed , <t>After new technologies and related standards are developed and deployed ,
unintended consequences can emerge that weren't considered during the unintended consequences can emerge.
design of the protocol. These lead to effects in multiple directions: These lead to effects in multiple directions:
on one hand, exposed protocol values not intended for network management on one hand, exposed protocol values not intended for network management
might be used by networks to differentiate traffic; on the other hand, might be used by networks to differentiate traffic; on the other hand,
changes to a protocol might have impact on private network deployments changes to a protocol that break existing use cases might have an impact on priv
that break existing use cases. While making decisions on technology ate network deployments.
While making decisions on technology
direction and protocol design, it is important to consider the impact on direction and protocol design, it is important to consider the impact on
various kinds of network deployments and their unique requirements. various kinds of network deployments and their unique requirements.
When protocols change to make different network management functions When protocols change to make different network management functions
easier or harder, the impact on various deployment models ought to be easier or harder, the impact on various deployment models ought to be
considered and documented.</t> considered and documented.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <displayreference target="I-D.irtf-pearg-safe-internet-measurement" to="LEAR
MONTH"/>
<references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="BARNES" target="https://github.com/intarchboard/m-ten-w orkshop/blob/main/papers/Barnes-Whats-In-It-For-Me-Revisiting-the-reasons-people -collaborate.pdf"> <reference anchor="BARNES" target="https://www.iab.org/wp-content/IAB-uplo ads/2023/11/Barnes-Whats-In-It-For-Me-Revisiting-the-reasons-people-collaborate. pdf">
<front> <front>
<title>What’s In It For Me? Revisiting the reasons people collaborate< /title> <title>What's In It For Me? Revisiting the reasons people collaborate< /title>
<author initials="R." surname="Barnes" fullname="Richard L. Barnes"> <author initials="R." surname="Barnes" fullname="Richard L. Barnes">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="CASAS" target="https://github.com/intarchboard/workshop -m-ten/blob/main/papers/Casas-AI-driven-real-time-QoE-monitoring-encrypted-traff ic.pdf"> <reference anchor="CASAS" target="https://www.iab.org/wp-content/IAB-uploa ds/2023/11/Casas-AI-driven-real-time-QoE-monitoring-encrypted-traffic.pdf">
<front> <front>
<title>Monitoring User-Perceived Quality in an Encrypted Internet</tit le> <title>Monitoring User-Perceived Quality in an Encrypted Internet - AI to the Rescue</title>
<author initials="P." surname="Casas" fullname="Pedro Casas"> <author initials="P." surname="Casas" fullname="Pedro Casas">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="COLLINS" target="https://github.com/intarchboard/worksh op-m-ten/blob/main/papers/Collins-Improving-Network-Monitoring-Through-Contracts .pdf"> <reference anchor="COLLINS" target="https://www.iab.org/wp-content/IAB-upl oads/2023/11/Collins-Improving-Network-Monitoring-Through-Contracts.pdf">
<front> <front>
<title>Improving Network Monitoring Through Contracts</title> <title>Improving Network Monitoring Through Contracts</title>
<author initials="M." surname="Collins" fullname="Michael Collins"> <author initials="M." surname="Collins" fullname="Michael Collins">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="DERI" target="https://github.com/intarchboard/workshop- m-ten/blob/main/papers/Deri-nDPI-Research-Proposal.pdf"> <reference anchor="DERI" target="https://www.iab.org/wp-content/IAB-upload s/2023/11/Deri-nDPI-Research-Proposal.pdf">
<front> <front>
<title>nDPI Research Proposal</title> <title>nDPI Research Proposal</title>
<author initials="L." surname="Deri" fullname="Luca Deri"> <author initials="L." surname="Deri" fullname="Luca Deri">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="ELKINS" target="https://github.com/intarchboard/worksho p-m-ten/blob/main/papers/Elkins-Performance-Monitoring-in-Encrypted-Networks-PDM v2.pdf"> <reference anchor="ELKINS" target="https://www.iab.org/wp-content/IAB-uplo ads/2023/11/Elkins-Performance-Monitoring-in-Encrypted-Networks-PDMv2.pdf">
<front> <front>
<title>Performance Monitoring in Encrypted Networks</title> <title>Performance Monitoring in Encrypted Networks: PDMv2</title>
<author initials="N." surname="Elkins" fullname="Nalini Elkins"> <author initials="N." surname="Elkins" fullname="Nalini Elkins">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Ackermann" fullname="Mike Ackermann"> <author initials="M." surname="Ackermann" fullname="Mike Ackermann">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Tahiliani" fullname="Mohit P. Tahiliani "> <author initials="M." surname="Tahiliani" fullname="Mohit P. Tahiliani ">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Dhody" fullname="Dhruv Dhody"> <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
<organization/> <organization/>
</author> </author>
<author initials="T." surname="Pecorella" fullname="Prof. Tommaso Peco rella"> <author initials="T." surname="Pecorella" fullname="Prof. Tommaso Peco rella">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="GRUBBS" target="https://github.com/intarchboard/worksho p-m-ten/blob/main/papers/Grubbs-Zero-Knowledge%20Middleboxes.pdf"> <reference anchor="GRUBBS" target="https://www.usenix.org/conference/useni xsecurity22/presentation/grubbs">
<front> <front>
<title>Zero-Knowledge Middleboxes</title> <title>Zero-Knowledge Middleboxes</title>
<author initials="P." surname="Grubbs" fullname="Paul Grubbs"> <author initials="P." surname="Grubbs" fullname="Paul Grubbs">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Arun" fullname="Arasu Arun"> <author initials="A." surname="Arun" fullname="Arasu Arun">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Zhang" fullname="Ye Zhang"> <author initials="Y." surname="Zhang" fullname="Ye Zhang">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Bonneau" fullname="Joseph Bonneau"> <author initials="J." surname="Bonneau" fullname="Joseph Bonneau">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Walfish" fullname="Michael Walfish"> <author initials="M." surname="Walfish" fullname="Michael Walfish">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
<refcontent>31st USENIX Security Symposium (USENIX Security 22)</refcont ent>
</reference> </reference>
<reference anchor="JIANG" target="https://github.com/intarchboard/workshop -m-ten/blob/main/papers/Jiang-Towards-Designing-Robust-and-Efficient-Classifiers -for-Encrypted-Traffic-in-the-Modern-Internet.pdf"> <reference anchor="JIANG" target="https://www.iab.org/wp-content/IAB-uploa ds/2023/11/Jiang-Towards-Designing-Robust-and-Efficient-Classifiers-for-Encrypte d-Traffic-in-the-Modern-Internet.pdf">
<front> <front>
<title>Towards Designing Robust and Efficient Classifiers for Encrypte d Traffic in the Modern Internet</title> <title>Towards Designing Robust and Efficient Classifiers for Encrypte d Traffic in the Modern Internet</title>
<author initials="X." surname="Jiang" fullname="Xi Jiang"> <author initials="X." surname="Jiang" fullname="Xi Jiang">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Liu" fullname="Shinan Liu"> <author initials="S." surname="Liu" fullname="Shinan Liu">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Naama" fullname="Saloua Naama"> <author initials="S." surname="Naama" fullname="Saloua Naama">
<organization/> <organization/>
skipping to change at line 392 skipping to change at line 400
</author> </author>
<author initials="P." surname="Schmitt" fullname="Paul Schmitt"> <author initials="P." surname="Schmitt" fullname="Paul Schmitt">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Feamster" fullname="Nick Feamster"> <author initials="N." surname="Feamster" fullname="Nick Feamster">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="KNODEL" target="https://github.com/intarchboard/worksho p-m-ten/blob/main/papers/Knodel-Guidelines-for-Performing-Safe-Measurement-on-th e-Internet.pdf"> <reference anchor="KNODEL" target="https://www.iab.org/wp-content/IAB-uplo ads/2023/11/Knodel-Guidelines-for-Performing-Safe-Measurement-on-the-Internet.pd f">
<front> <front>
<title>Guidelines for Performing Safe Measurement on the Internet</tit le> <title>(Introduction) 'Guidelines for Performing Safe Measurement on t he Internet'</title>
<author initials="M." surname="Knodel" fullname="Mallory Knodel"> <author initials="M." surname="Knodel" fullname="Mallory Knodel">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="KUEHLEWIND" target="https://github.com/intarchboard/wor
kshop-m-ten/blob/main/papers/Kuehlewind-Relying-on-Relays.pdf"> <reference anchor="KUEHLEWIND" target="https://www.ericsson.com/en/blog/20
22/6/relays-and-online-user-privacy">
<front> <front>
<title>Relying on Relays</title> <title>Relying on Relays: The future of secure communication</title>
<author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind"> <author initials="M." surname="Kuehlewind" fullname="Mirja Kuehlewind"
>
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Westerlund" fullname="Magnus Westerlund "> <author initials="M." surname="Westerlund" fullname="Magnus Westerlund ">
<organization/> <organization/>
</author> </author>
<author initials="Z." surname="Sarker" fullname="Zaheduzzaman Sarker"> <author initials="Z." surname="Sarker" fullname="Zaheduzzaman Sarker">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Ihlar" fullname="Marcus Ihlar"> <author initials="M." surname="Ihlar" fullname="Marcus Ihlar">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="June"/>
</front> </front>
</reference> </reference>
<reference anchor="LEI" target="https://github.com/intarchboard/workshop-m -ten/blob/main/papers/Lei-Encrypted-Traffic-Classification-Through-Deep-Learning .pdf"> <reference anchor="LEI" target="https://www.iab.org/wp-content/IAB-uploads /2023/11/Lei-Encrypted-Traffic-Classification-Through-Deep-Learning.pdf">
<front> <front>
<title>Encrypted Traffic Classification Through Deep Learning</title> <title>Encrypted Traffic Classification Through Deep Learning</title>
<author initials="Y." surname="Lei" fullname="Yupeng Lei"> <author initials="Y." surname="Lei" fullname="Yupeng Lei">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Wu" fullname="Jun Wu"> <author initials="J." surname="Wu" fullname="Jun Wu">
<organization/> <organization/>
</author> </author>
<author initials="X." surname="Sun" fullname="Xudong Sun"> <author initials="X." surname="Sun" fullname="Xudong Sun">
<organization/> <organization/>
</author> </author>
<author initials="L." surname="Zhang" fullname="Liang Zhang"> <author initials="L." surname="Zhang" fullname="Liang Zhang">
<organization/> <organization/>
</author> </author>
<author initials="Q." surname="Wu" fullname="Qin Wu"> <author initials="Q." surname="Wu" fullname="Qin Wu">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="PAULY" target="https://github.com/intarchboard/workshop -m-ten/blob/main/papers/Pauly-Red-Rover-A-collaborative-approach-to-content-filt ering.pdf"> <reference anchor="PAULY" target="https://www.iab.org/wp-content/IAB-uploa ds/2023/11/Pauly-Red-Rover-A-collaborative-approach-to-content-filtering.pdf">
<front> <front>
<title>Red Rover</title> <title>Red Rover: A collaborative approach to content filtering</title >
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Barnes" fullname="Richard Barnes"> <author initials="R." surname="Barnes" fullname="Richard Barnes">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="WELZL" target="https://github.com/intarchboard/workshop -m-ten/blob/main/papers/Welzl-The-Sidecar-Opting-in-to-PEP-Functions.pdf"> <reference anchor="WELZL" target="https://www.iab.org/wp-content/IAB-uploa ds/2023/11/Welzl-The-Sidecar-Opting-in-to-PEP-Functions.pdf">
<front> <front>
<title>The Sidecar</title> <title>The Sidecar: 'Opting in' to PEP Functions</title>
<author initials="M." surname="Welzl" fullname="Michael Welzl"> <author initials="M." surname="Welzl" fullname="Michael Welzl">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="WU" target="https://github.com/intarchboard/workshop-m- ten/blob/main/papers/Wu-mten-taxonomy.pdf"> <reference anchor="WU" target="https://www.iab.org/wp-content/IAB-uploads/ 2023/11/Wu-mten-taxonomy.pdf">
<front> <front>
<title>Network Management of Encrypted Traffic</title> <title>Network Management of Encrypted Traffic: Detect it don't decryp t it</title>
<author initials="Q." surname="Wu" fullname="Qin Wu"> <author initials="Q." surname="Wu" fullname="Qin Wu">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Wu" fullname="Jun Wu"> <author initials="J." surname="Wu" fullname="Jun Wu">
<organization/> <organization/>
</author> </author>
<author initials="Q." surname="Ma" fullname="Qiufang Ma"> <author initials="Q." surname="Ma" fullname="Qiufang Ma">
<organization/> <organization/>
</author> </author>
<date year="2022" month="August"/> <date year="2022" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="DITTO" target="https://nsg.ee.ethz.ch/fileadmin/user_up load/publications/ditto_final_ndss22.pdf"> <reference anchor="DITTO">
<front> <front>
<title>Ditto - WAN Traffic Obfuscation at Line Rate</title> <title>ditto: WAN Traffic Obfuscation at Line Rate</title>
<author initials="R." surname="Meier" fullname="Roland Meier"> <author initials="R." surname="Meier" fullname="Roland Meier">
<organization/> <organization/>
</author> </author>
<author initials="V." surname="Lenders" fullname="Vincent Lenders"> <author initials="V." surname="Lenders" fullname="Vincent Lenders">
<organization/> <organization/>
</author> </author>
<author initials="L." surname="Vanbever" fullname="Laurent Vanbever"> <author initials="L." surname="Vanbever" fullname="Laurent Vanbever">
<organization/> <organization/>
</author> </author>
<date year="2022" month="April"/> <date year="2022" month="April"/>
</front> </front>
<refcontent>Network and Distributed Systems Security (NDSS) Symposium</r
efcontent>
<seriesInfo name="DOI" value="10.14722/ndss.2022.24056"/>
</reference> </reference>
<reference anchor="I-D.irtf-pearg-safe-internet-measurement">
<front>
<title>Guidelines for Performing Safe Measurement on the Internet</tit
le>
<author fullname="Iain R. Learmonth" initials="I. R." surname="Learmon
th">
<organization>HamBSD</organization>
</author>
<author fullname="Gurshabad Grover" initials="G." surname="Grover">
<organization>Centre for Internet and Society</organization>
</author>
<author fullname="Mallory Knodel" initials="M." surname="Knodel">
<organization>Center for Democracy and Technology</organization>
</author>
<date day="10" month="July" year="2023"/>
<abstract>
<t> Internet measurement is important to researchers from industry
,
academia and civil society. While measurement of the internet can
give insight into the functioning and usage of the Internet, it can
present risks to user privacy. This document describes briefly those
risks and proposes guidelines for ensuring that internet measurements
can be carried out safely, with examples.
</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
</abstract> rtf-pearg-safe-internet-measurement"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-pearg-safe-internet- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.316
measurement-08"/> 8.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.852
<reference anchor="RFC3168"> 0.xml"/>
<reference anchor="HARDAKER" target="https://www.iab.org/wp-content/IAB-up
loads/2023/11/Hardaker-Encrypted-Traffic-Estimation.pdf">
<front> <front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</t <title>Network Flow Management by Probability</title>
itle> <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan <organization/>
"/> </author>
<author fullname="S. Floyd" initials="S." surname="Floyd"/> <date year="2022" month="August"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="September" year="2001"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congestion
Notification) to TCP and IP, including ECN's use of two bits in the IP header.
[STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference> </reference>
</references> </references>
<section anchor="positionpapers">
<section anchor="positionpapers">
<name>Position Papers</name> <name>Position Papers</name>
<t>Interested participants were openly invited to submit position papers o n the workshop topics, including Internet-Drafts, relevant academic papers, or s hort abstracts explaining their interest. The papers below constitute the inputs that were considered relevant for workshop attendees and that focused the discu ssions themselves. The program committee grouped the papers by theme as such.</t > <t>Interested participants were openly invited to submit position papers o n the workshop topics, including Internet-Drafts, relevant academic papers, or s hort abstracts explaining their interest. The papers below constitute the inputs that were considered relevant for workshop attendees and that focused the discu ssions themselves. The program committee grouped the papers by theme.</t>
<section anchor="motivations-and-principles"> <section anchor="motivations-and-principles">
<name>Motivations and principles</name> <name>Motivations and Principles</name>
<t>Richard Barnes. “What’s In It For Me? Revisiting the reasons people c <t>Richard Barnes. "What's In It For Me? Revisiting the reasons people c
ollaborate.” <xref target="BARNES"/></t> ollaborate." <xref target="BARNES"/></t>
<t>Iain R. Learmonth, Gurshabad Grover, Mallory Knodel. “Guidelines for <t>Mallory Knodel. "(Introduction) 'Guidelines for Performing Safe Measu
Performing Safe Measurement on the Internet.” (Additional rationale) <xref targe rement on the Internet'." (Additional rationale) <xref target="KNODEL"/></t>
t="KNODEL"/></t> <t>Qin Wu, Jun Wu, Qiufang Ma. "Network Management of Encrypted Traffic:
<t>Qin Wu, Jun Wu, Qiufang Ma. “Network Management of Encrypted Traffic: Detect it don't decrypt it." <xref target="WU"/></t>
Detect it don’t decrypt it.” <xref target="WU"/></t>
</section> </section>
<section anchor="classification-and-identification-of-encrypted-traffic"> <section anchor="classification-and-identification-of-encrypted-traffic">
<name>Classification and identification of encrypted traffic</name> <name>Classification and Identification of Encrypted Traffic</name>
<t>Luca Deri. “nDPI Research Proposal.” <xref target="DERI"/></t> <t>Luca Deri. "nDPI Research Proposal." <xref target="DERI"/></t>
<t>Wes Hardaker. “Network Flow Management by Probability.”</t> <t>Wes Hardaker. "Network Flow Management by Probability." <xref target=
<t>Xi Jiang, Shinan Liu, Saloua Naama, Francesco Bronzino, Paul Schmitt, "HARDAKER"/></t>
Nick Feamster. “Towards Designing Robust and Efficient Classifiers for Encrypte <t>Xi Jiang, Shinan Liu, Saloua Naama, Francesco Bronzino, Paul Schmitt,
d Traffic in the Modern Internet.” <xref target="JIANG"/></t> Nick Feamster. "Towards Designing Robust and Efficient Classifiers for Encrypte
<t>Yupeng Lei, Jun Wu, Xudong Sun, Liang Zhang, Qin Wu. “Encrypted Traff d Traffic in the Modern Internet." <xref target="JIANG"/></t>
ic Classification Through Deep Learning.” <xref target="LEI"/></t> <t>Yupeng Lei, Jun Wu, Xudong Sun, Liang Zhang, Qin Wu. "Encrypted Traff
ic Classification Through Deep Learning." <xref target="LEI"/></t>
</section> </section>
<section anchor="ideas-for-collaboration-and-coordination-between-devices- and-networks"> <section anchor="ideas-for-collaboration-and-coordination-between-devices- and-networks">
<name>Ideas for collaboration and coordination between devices and netwo <name>Ideas for Collaboration and Coordination between Devices and Netwo
rks</name> rks</name>
<t>Michael Collins. “Improving Network Monitoring Through Contracts.” <x <t>Michael Collins. "Improving Network Monitoring Through Contracts." <x
ref target="COLLINS"/></t> ref target="COLLINS"/></t>
<t>Paul Grubbs, Arasu Arun, Ye Zhang, Joseph Bonneau, Michael Walfish. “ <t>Paul Grubbs, Arasu Arun, Ye Zhang, Joseph Bonneau, Michael Walfish. "
Zero-Knowledge Middleboxes.” <xref target="GRUBBS"/></t> Zero-Knowledge Middleboxes." <xref target="GRUBBS"/></t>
<t>Mirja Kühlewind, Magnus Westerlund, Zaheduzzaman Sarker, Marcus Ihlar <t>Mirja Kuehlewind, Magnus Westerlund, Zaheduzzaman Sarker, Marcus Ihla
. “Relying on Relays: The future of secure communication.” <xref target="KUEHLEW r. "Relying on Relays: The future of secure communication." <xref target="KUEHLE
IND"/></t> WIND"/></t>
<t>Tommy Pauly, Richard Barnes. “Red Rover: A collaborative approach to <t>Tommy Pauly, Richard Barnes. "Red Rover: A collaborative approach to
content filtering.” <xref target="PAULY"/></t> content filtering." <xref target="PAULY"/></t>
<t>Michael Welzl. “The Sidecar: ‘Opting in’ to PEP Functions.“ <xref tar <t>Michael Welzl. "The Sidecar: 'Opting in' to PEP Functions." <xref tar
get="WELZL"/></t> get="WELZL"/></t>
</section> </section>
<section anchor="other-background-material"> <section anchor="other-background-material">
<name>Other background material</name> <name>Other Background Material</name>
<t>Pedro Casas. “Monitoring User-Perceived Quality in an Encrypted Inter <t>Pedro Casas. "Monitoring User-Perceived Quality in an Encrypted Inter
net – AI to the Rescue.” <xref target="CASAS"/></t> net - AI to the Rescue." <xref target="CASAS"/></t>
<t>Nalini Elkins, Mike Ackermann, Mohit P. Tahiliani, Dhruv Dhody, Prof. <t>Nalini Elkins, Mike Ackermann, Mohit P. Tahiliani, Dhruv Dhody, Prof.
Tommaso Pecorella. “Performance Monitoring in Encrypted Networks: PDMv2.” <xref Tommaso Pecorella. "Performance Monitoring in Encrypted Networks: PDMv2." <xref
target="ELKINS"/></t> target="ELKINS"/></t>
</section> </section>
</section> </section>
<section anchor="participants"> <section anchor="participants">
<name>Workshop participants</name> <name>Workshop Participants</name>
<t>The workshop participants were Cindy Morgan, Colin Perkins, Cullen Jenn <t>The workshop participants were <contact fullname="Cindy Morgan"/>, <con
ings, Deborah Brungard, Dhruv Dhody, Eric Vyncke, Georg Carle, Ivan Nardi, Jari tact fullname="Colin Perkins"/>, <contact fullname="Cullen Jennings"/>, <contact
Arkko, Jason Livingood, Jiankang Yao, Karen O'Donoghue, Keith Winstein, Lars Egg fullname="Deborah Brungard"/>, <contact fullname="Dhruv Dhody"/>, <contact full
ert, Laurent Vanbever, Luca Deri, Mallory Knodel, Marcus Ihlar, Matteo, Michael name="Éric Vyncke"/>, <contact fullname="Georg Carle"/>, <contact fullname="Ivan
Ackermann, Michael Collins, Michael Richardson, Michael Welzl, Mike Ackermann, M Nardi"/>, <contact fullname="Jari Arkko"/>, <contact fullname="Jason Livingood"
irja Kühlewind, Mohit P. Tahiliani, Nalini Elkins, Patrick Tarpey, Paul Grubbs, />, <contact fullname="Jiankang Yao"/>, <contact fullname="Karen O'Donoghue"/>,
Pedro Casas, Qin Wu, Qiufang, Richard Barnes, Rob Wilton, Russ White, Saloua Naa <contact fullname="Keith Winstein"/>, <contact fullname="Lars Eggert"/>, <contac
ma, Shinan Liu, Srinivas C, Toerless Eckert, Tommy Pauly, Wes Hardaker, Xi Chase t fullname="Laurent Vanbever"/>, <contact fullname="Luca Deri"/>, <contact fulln
Jiang, Zaheduzzaman Sarker, and Zhenbin Li.</t> ame="Mallory Knodel"/>, <contact fullname="Marcus Ihlar"/>, <contact fullname="M
atteo"/>, <contact fullname="Michael Collins"/>, <contact fullname="Michael Rich
ardson"/>, <contact fullname="Michael Welzl"/>, <contact fullname="Mike Ackerman
n"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Mohit P. Tahilia
ni"/>, <contact fullname="Nalini Elkins"/>, <contact fullname="Patrick Tarpey"/>
, <contact fullname="Paul Grubbs"/>, <contact fullname="Pedro Casas"/>, <contact
fullname="Qin Wu"/>, <contact fullname="Qiufang Ma"/>, <contact fullname="Richa
rd Barnes"/>, <contact fullname="Rob Wilton"/>, <contact fullname="Russ White"/>
, <contact fullname="Saloua Naama"/>, <contact fullname="Shinan Liu"/>, <contact
fullname="Srinivas C"/>, <contact fullname="Toerless Eckert"/>, <contact fullna
me="Tommy Pauly"/>, <contact fullname="Wes Hardaker"/>, <contact fullname="Xi Ch
ase Jiang"/>, <contact fullname="Zaheduzzaman Sarker"/>, and <contact fullname="
Zhenbin Li"/>.</t>
</section> </section>
<section anchor="program-committee"> <section anchor="program-committee">
<name>Program Committee</name> <name>Program Committee</name>
<t>The workshop program committee members were Wes Hardaker (IAB, USC/ISI) , Mallory Knodel (IAB, Center for Democracy and Technology), Mirja Kühlewind (IA B, Ericsson), Tommy Pauly (IAB, Apple), Russ White (IAB, Juniper), Qin Wu (IAB, Huawei).</t> <t>The workshop program committee members were <contact fullname="Wes Hard aker"/> (IAB, USC/ISI), <contact fullname="Mallory Knodel"/> (IAB, Center for De mocracy and Technology), <contact fullname="Mirja Kühlewind"/> (IAB, Ericsson), <contact fullname="Tommy Pauly"/> (IAB, Apple), <contact fullname="Russ White"/> (IAB, Juniper), <contact fullname="Qin Wu"/> (IAB, Huawei).</t>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section anchor="iab-members" numbered="false">
<name>IAB Members at the Time of Approval</name>
<t>Internet Architecture Board members at the time this document was appro
ved for publication were:</t>
<ul empty="true" spacing="compact">
<li><t><contact fullname="Dhruv Dhody"/></t></li>
<li><t><contact fullname="Lars Eggert"/></t></li>
<li><t><contact fullname="Wes Hardaker"/></t></li>
<li><t><contact fullname="Cullen Jennings"/></t></li>
<li><t><contact fullname="Mallory Knodel"/></t></li>
<li><t><contact fullname="Suresh Krishnan"/></t></li>
<li><t><contact fullname="Mirja Kühlewind"/></t></li>
<li><t><contact fullname="Tommy Pauly"/></t></li>
<li><t><contact fullname="Alvaro Retana"/></t></li>
<li><t><contact fullname="David Schinazi"/></t></li>
<li><t><contact fullname="Christopher Wood"/></t></li>
<li><t><contact fullname="Qin Wu"/></t></li>
<li><t><contact fullname="Jiankang Yao"/></t></li>
</ul>
</section>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>TODO acknowledge.</t> <t>We wish to acknowledge the comments and suggestions from <contact fulln ame="Elliot Lear"/> and <contact fullname="Arnaud Taddei"/> for their comments a nd improvements to this document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA8193XLkRrLePZ6iggpbQ0d3z0ob9jmHGw4tRVJaSvNDDWc0
u7rZQAPV3ViigT4ogJzWxETsO5yb4wj7TXznN9kncX6ZWT9AN1ej9Ths3WjY
AApVWVmZX36ZVZjP51lf9bU9Myev7K7terPq2q3pN9Zcn39tHtruzm3anWkb
8zxv8rXd2qY3r22xaap/HawzVWOumqLb73pbmhe25yfMk+fz11cvTk+yfLns
7D21zj/E9jp+2UlW5L1dt93+jBpatVlWtkWTb6k7ZZev+nmVL+fbeW+buX9y
/psvMzcst5VzVdv0+x3dSz3NmmG7tN1ZVlKDZ1nRNs42bnBnpu8Gm1EPfpt9
ZvLO5mfm/NXVOf2BFtddO+zOzNtvzVv6q2rW5lv8kt3ZPV0uzzIzN1aGR2/D
X40M0WyDNLJ72wz0zs+MCc3hD+nbuF36eZtXNW75vX2Xb3e1XRTtFr/nXbE5
M5u+37mzp0+Ti0+pOWq66jfDkgRZNT1uXbZ5Vz6dyGY3LOuqOKHbaxKD6+l2
32D62EIaW1Tt8QaePib8xabf1idZlg/9pu0gHXqVoakjOT9fmO+btrQ1/7Qa
6lom8nle1zTB6cW2W+dN9XMOmZ6ZC5Kh7cyq7cyl3bZFlxd78x9Fx9q6Xe/5
GSty295xM78vyn5BzYx68HZh/kCjy+9sN+nDW1LU0SVtrbL96vcbveAWNLej
Bl8vzE0+1PtJa6/b7XafXNHGTvodfvp9vtOJI0E1bbelYd6TemRQ8PCXMV+f
v3pxdXvGLdDUrG0fZ1/nB5P/d6b76bJul0/p5c3TXb6jATz9Ou8a6+ZvN3nv
5tfN/Lqff9N28+d2/sreV67qSRPntLbntA4cLZH5zrbU2XnR1nW+bDtSmsWu
XEmfxCygrb/99b85c92Y695Qc+a5/crE9thWaHtG2jNJe9xW0Bf+b67/Vymb
VwsjHQ+/i5xfVQXmxjwbXecFbs6H9eB68+Vvvvwyo58vzm/Pf6Usg86zUA9l
eZG73M3Pr+dlRzPWQGT1vK+2dv5DezXftk3Vtx3kab35m/e0bFZVMRXh83Cv
eeNsN7+xXWGpzdL8MOR11e9hRPPUjl5jRbA2/qLwbhaGezqR3Y0tuza5clxq
L589u37xqeVGc09dm19vd117DwGpV5hHOcxfb8gcrjfzCzLhtN57N5VZeNr7
lFSK+rQJT3+EnMg8ac8mknoOLbP16OpRaV1evbr+tKK6tF01by5vrml5Oovn
5jddu2tdXk/lgbuMv8v4uz5i3LR48JrJoJ8NRR5/Pzrcq2fff3LduKrvoBq0
ANgUNoVNlaJq5mEJeKWhmy+f3385FUfSQqoYR8HIRwjpxcJI1yZiekHLs6nG
144o1nlB7oM60xyo1p09uHjk+df5pqorconT59tN1WOFT2+YtnFJk7xpy/3k
+ctNN9yPrkwfhIezRdtZstdTC9K1qwX7OjLtk7uOKsy3r958/fUnVphvu2G5
dPOfbNfOCUA81LZc2//w5W+eV2VZ22X7zh5YjvG9Jrnz46ypvHIqDPLs4yvT
J89JDbphqgHnXe6G9ML0sT8tzE+bvFlPnvuTHf08feo78oht09h8mDz3Xevs
bjO5eETj3ub1qnKbR0xhevXoVH93ff7i208709+RepNfaB/oZje/tK5aNzAK
r9olvXmeN+X8Cs61IrQ4v6hzgv+rih6ckx1IzMZrccGwJcA5zwksdoSD1J9O
dUVfZ8LrjLyOvHFpwutM8jqGqdHG6OtgeACD5HW/xn3/cWF45JOZ+GM1+nn6
1O3CPKumc3+7qRpCEfHCkade5Pl2utBv87od8tGl6ZPfkL51bfNz1bSTh7/p
YINd0U5vOLKybovNtur7Y0trfOmIef7G5lvXK3qPD7+oirvxtaP6+v2Ll5dX
zz6twko8M/92qOh/FWA3NFEdEzT3Nl+RAhIwHjqOE+et6ORjyhhbYiWLLRm0
ZJKWEI1zhP7xejaOzpIlfxidHZfgm6s/PLt6e/3i8hNLcbCb2j5UtLxf2XoP
uZGY6J/5/sCy6w0YvdzwkeP+X/9TX3Fg7rq/5IeXj5lLC/2qh8Mm8nUzuMPr
0zZ+Iu3Pu7sD/f0p39hy+PlnWnrN+I4jvbje1Pm0geckaupAvHR09p5dfWLk
+sxWR4yut5MFR/YB5F9au5s/I+QKCzud1ENbOm4lgH20YnwrHzHz5Fmpl1O/
OuwsaVC8cMSzvj1wqkMTfzxiwG8P3P4fh7LFun3U7T877vafweb/Xc//w5H+
/VCF/h2d/ZvzN8/+9Gnnn8kPWqa0att7CmnPEwqBItt5vqPwLad4pm/pCpkp
Mn+rqqZFckQFqBnDzXzErI4omSiCKSXz60mGX2IY3l49++kTe5C3tv65plVi
57dk+Yu8m7/c9RoIkdxurm7m3wxNgVVwYAvpKaNPfZwV5Jc9hvfCteNDf/OJ
xz3Mt+Cx+vxd27Tb/XRsIeKPhHO7OjQUHzHuX1gtn2D50xueTwHVD9Wwwjp+
/neCpcvr169fHhdr49YLaxe23/y8KDZPadnYvCQc8HRwtvvzsKvbvHwqRC1b
SPe0JOjU/nlF8K/+c1M69+VBvHyJO8zcvD1/Eezsy+VqcGpk855sT2PNq49m
7J7b6sCbvWprAOf00vTJH2GVG0LJ03X4Y0U4kmZ6fPWI3fwxb5b2/uDdz3IC
R/T86LKKftdVtUp+Pp+bfOmYNsoyrKK//fW//wOZjb/99X/EZMZD7gxZuXvb
0J3L/QibUfBXUBRvi576R4EZbM2T6/OvTyXR8sU/mZdF3y5txx00NEtf/Mv4
J2o8pyY7a+dlvif0A4xottbCVizYEox6ouw6dYWjEnrO7PKud2i7rBzBBUf3
7fnvimk2eySrYfqRJNyw4+wQLUSSbmOWZN5pnkxetpwa4QshUTIFqOhl5TTp
Q21tt3lHPXR8k+/85853jzWSFInsW9Mj7kJfd1WB+0lTKWajqKM3q4Flyh3H
7Uj60CMdq/Qiy160vZUnery9bIuBR1ZBoNoX7ShJobC2JIE6jIR+ykLOgyV8
X9kHx2/ZteC9QXb7Br2k4wjzDi+mWDyTxox9t+usc3RnOXSeNA+zRiqDGaJo
c0fjkteUrWnaPmssRVeOpFXvqfFVTXrEibkj/VmIdm+Z8MiyzyD9ri0HdiDm
/WcV/vyQZeCgacDVPfIsaMHZgjrV77nbEGJPvaD3LS1zaqIirNi0RsH00890
mRYRQA5a2LaYB4Qve1NaslB7uj+qg05/GG9ebf+faiOpxt99Q0OqgP7Y+7am
7tC/+Ga7WpH4Cd7UIreOorV8We999I8ptmAk6e3Dkpqq+pawuWYF0g6x1HUM
yXtZV22zYVpzSKZpgewLRQgUrMV0gxfTzFSs06QupBbUIe5xh17Sq4YmPrC1
fU4mMef4Mgg50qcjZVh56DGjEbTkbizNXcsZn9LeV6SWM9E/oHVISYe5jXGq
W5DdfDAeDNIIoWGQrsgXVvgudGRpN/l91XbUrl2sFzMoXFl1JHIaSdG2O17Z
9PoHwh0kpnLXVn61IOfm3eEsUVNIEdNBiGqJ+3pbU8/6bn/sppwnNx1A0nUd
rMzHnKe6uxfOeWU7nvY4kwtxLaTnYk1odrBo1XSHdcAewNv6L/5p/sW/zNjk
z8yG7PjSkmaTlDgRUlJrZlfnPTgB1s13tMzYzFjqAil2Lut8SdLEg0fWEAvg
uDJWpAMVOUt67EGUnS6MIH06i6yn9NcWBjZaD2onVVrzsCHo4vWcA/edGue8
Jv2k9RHU5NzRfcVmbBbzslSjiZ9X1Jv2Ac1AwjzTZ1n2nzhByXolAmD9PzL4
9H1f8WMtFs1DhazPOqzxg2G7th74ZV+l70KHyEzKsFQPsagefTb77DNzvmwH
9UWTOgijMRLU5ld7KjPyVNk/6Km82/tHPZVJPFX2y57qm6Gjhjs4jhm/QiXg
xxTksgUdhnUi1rWXNW7WyMlm1J3QtYN+Uaegq/kdrYZkLBFjuFkGU4JJ4RVE
b5DmCUKZ+7yuSkESFHVuBnekm5XLtJ+inIJnVvQvEUyV1+16OktmSe8rW8sG
O8v73m53PfSvyHeMZ3ITqlcWcONv/YO3BS0gbvkyjEEMzSP4Ly+61jnFgCWc
LJtOeBGuVEnxlqvbnsbYkn2iVYq7BfjEZccQjEtoqB0yeRGelWJaRDvXXb7F
vIHPpdfG3nD0Z2LtDjw5nAD3DvEhWtgq+2nJ0njJaf8nfV2YS5lUvjVenak+
S7ApPVXdsXBvZD2o1ySDvUiDZNqkjW9sXRrGjBZOhqEEv4EkwsuYAoa3G7T6
YCENRAJz8yoxLyyNG3WLL5dwFKq17z+jVr74IJO2qjoKCBnSTzSEbFZTwktT
n6jPuvLtu8qxvSHD09u4UGppfFPtfsn4RyTg3QCvrHtatAAqFLOSk1+Ym9FK
I6i9pif4Ti8m6kSR5EQG/mVLUiL3Nq+VoxMUUrRrTL9/4wy/5uU9IE6ZYh+e
9Pu85Ae1d9T7eu8qxw+NXMsI6mOZnK9QQ0QQqUpBLzuqAtSSOpF1m9cHdjNo
b7DowcOYJ6TspXVFVy3FeL5/Lzj6wykbBFaDDstk6MYmaqZLR5DzRMtYkz4L
oXgxpjzZeh3WmWUUp+6jGjyCkkWcsOsemVGvmxym5Qw9JlDVNp/3ASCSzIAl
yHRSZFatGwiIJxvKTytJAsfGrltBCLxowrtjdnXGho3C9N7mZWid/t4BNMNN
Etiz0tqBWgQQtw/auGvRJ+jjcSnNJDAO8NOr0gxeU0KXYkPL3LL6joKXNDSh
tXh8EirHVoww2x4WEbhL2mk8FYCIBeCPgE7ejyCoIumOYTLPhXQIy1mDoVAN
Jq+C9Ru6hu8QJJGTvDysIr0i/SKISQiwwdqa+dKhebua38qLzJMf2tvTBM/P
gnRp2dAvvZbczcL05QV8Nju1rq1natHppVGnBPdu8/oBwygtmAx2in8g1aaF
NSOlAfidSI/eXFYC9ThyrRHE0+9+5lkaSWhCjoOE3PNdq6AqqItifzo7Pnu8
kv30kSKXlm8SfBbCtQZjpDvHXfQYfdsO4s+nI2DbkQNRJ/MvQxOVrV0A59BE
mrrVUEPjq/UGeI30Y0NQ4IQM4t3+xPvHviWQ6GSiSZvGagM0JFCJISVspfhb
tjQTnUEFnkZ7MAwtexrMCAFvcljbHCE8po7WEVYUgr62F42PkzObDjzEHstc
vQ/ZBwsCqUBZKHsgWtN4wHRD7Ve+GEMgVsglJz3k0BkJ9pGDWJvjDmIHKNSR
MTcnnOrxd514xxKf2yJXSRiQZrbz+qW2jBwG61ZuatCqtAj7VEngCgyK+ETM
FHBaH92ihrFQ618Vd9QgMBlSMcI5hLXk+0n2WPrR+6ggCKyoCYGUKNQkLMER
t4M6s2SWFqCWBuOcV5m0V5Ev0HcvyOVwvcWHD8ETOZmSSuAGv58c2QM7OfRF
JKRxmuiuYr8N6SaW/cBVtmL+JfirQ0fRxXwL2cFxMqVDoA4xO6khLeGBTRA/
jHiR0aI+qQ6XfGDVTGEGe1i0m6r8wlyBwMFCd4YMWg99rnCTYyxKcOZOkHd/
3Ew/tAPJWIXqO5pYJ36rKMHKshfk2fQWBlqwUugOahE6rLMCK6yaRsAAjNaW
vGGt4MP1bByZfqoET2y9Otits/W9EklCddBCHHago6lvqjaypjlikI7RssoL
XkIEV4ZCHlyxgEPXdZoJ6AHv0C8VWdam2M+UARVh0AUSF08BU3Oq0UiBBUAJ
WBU1C+twS+pUOiXzPKna+ZrDtmHrj4oEJmHYxhyR7PVNFG5nWWapRD2oPVjU
HuxB39++oS7xakn6tZKQMfaoakjGvQTKjTnvEIsUUGQQfRTWr3Hlyfn1aWh7
THwFH6dojHDvPfzfEQSaZd9xWZB7TA0r8aJVM7BBysucU3mzEb0Hd8GvOGif
Rd1qQma0QiKtEp4Rlja8i1lKTgWcYyHdVwzw8/ouLjvJ5rATfP+eU08kX7fJ
AYtpDZP9qQO/I3ZihI8hNXgy6PFQITwytLbI7EqxlNvTYtimwxuah7xJ44ww
uaCfpdvBJCdpqMqNoRabQB+4k1lgsxPhQQvGtxRsKf+HIZK4dceEGOCX+vBC
Fq9g63WuPG61pcaCkURUspDcHCn7FlQ4athLv0rJ31ZcsA22EGg11ZV0IJi3
9brDexIpKE/sFZAFjeVELpp9wAbIWeg4w0wh+VkyGFn2lpm0Yy9K1IupnBbx
JOiYCRs/E9bH9UO5p+mh0IkrjRBZrS0vqzDtzH4LmcVKBuhAWIq56tbcwTcH
rlcsmVq21I8xV+Lh9xH0lTD0qZogXq9rNv7MGg5wTbJ0/PI/yo/LAkZmw6U8
rUC8Gw0ar+TJGKOfO0deWP4OtdW8UccoRxf8XKDkkrTFelywpStE6eM4W+Pk
g2Bah4qulFBedWTGS3ASNH9P3r//6np+uai6fjXfUbfWczwwr7SNeUJRUyDK
Ck+gN+mPNt0U1Y6ARqSQSTM2HCdTpC8IdUyJyeqSiOpIUBrMVYRUJPoLpqv6
QIBKhCBxQ1q0tooJCLZ4WHw0x0jljeJ5iEj0dhTmJk0lTLtEU4V2Qde6D2hJ
nkwUQqEEPNvS3zszHGXx/XITyM2ufbfHhSXEI/aBHCw5bWx80U1ZMwH7HVuB
JBQG6vepI98h/JOwM9itUV4hoeJ7Ap7ixRhe/aUVBxtaJgn/qDHxhC9hUSYS
LzhF5GIiLV0jM2HYc8myEir39tLkwp0AW3RsCquWaS9ZydvcyTIY4P8QzPP0
85Mp3OOXzZUT3GtmxIcrM4E03pRHALry/bcClAXHeNsZTLqs7yntWTEXK9oe
mB10A9maxIWW5JVqxJeaxfFTJvkIOEaKkdasdw4wsiCUpFENTCmvGdK0l03C
utEAuhHH4HzEuAXUYyYWDyOnxbNZAOnw8gaZxUUOPXv9jnkGsnTs+tMxjXMk
X7cw0I8zRsfcQ0ovczjBvefAMTgy/5znwkOqTcyBWAxm1y1vp3wM/8SloG/V
EE8poNGMHHknFFIuMmwZZ/QeG5/YkWSUG5g5CYgwEYljqRh1kZnp3WhtefqH
IVuU5pgywYsQjpQIuZzaKIHAkoBD7Up1b30WKErQWYJGDIJZAXy8s+J+JxKp
AC33KjKPo8AccMCrdpNTvR7kN3ZV6XbdEW8XZoHTTW4oaUlGOslHtIHe2Nh6
h2Z5/Ialk3TrX4VmisZjWTEkchpvlLZwqIBELMCdqCXSFxCy1LQhCRO6DdlI
oOT64PmQ6ah8hjGZ8hqbZ163nazDENnoTQjYOUBj5kMX6GuOqICDAkkaCRce
MMFjTulPGE/c6bnzAx7P831RBlf+afJ8a2GKzYu2j6vhydXFi1OC2l+9+ubi
t1/8l3/+8MFzJHnP/MresraScjBQC4ULCyZ583XM7jvzRF4rAusBZLsdb60M
t5yytVlynWwP4wNDhvCXcKWET5hVYUuRJBvqvKv3wXSxfSInxAIVotJXEaDK
6LEsquZ3kbmB/Z8wcwm48fgkjIjVDtRLTUa+VlO3HmoGkaNXsJfznCOsUWCe
Vl0+lEPNwKJLSK4IS25IJzjVHAlbqa/gwW1VzCQRUPa1J0Gd9MxRsEFSgvgS
ddDKgwPYOsl8c7lGz2N2ZBjgvDV9ePg2kbfYi1g9FmNU5vBo7hyQiJVZvHxx
a6SaVsN+QTHbvIQpCrwn04tarEGx2jCKbJk0JL8HRAldQpugmWl1dId5LoRz
eGTdSrrrIua5aV5uItLkDNeXmuFyFLwjD/rxKa6t7STeGwMdxZ2Ip3neWGRd
WrpyMCkfmcYKqagjDtXnN32+gQZZD+XxVFfo7yxYud1A69RJ8LPVONbPK1NO
s3QAMhzbV1qRQgL6/yCtpeWDvzav9Q2nNmFs9mlJBHz7UQImy6652KEPoO6w
iAsQBkgZCfJlTuDLdsFmc9aiYv7JCQCwCahiaExur7Fia2AZ9/DmFLvadFoP
cOEsBCaiYyXqsm1THk9BgIDZezCiYlxJgUPLsTFzlOqHdJBkCvxg1PA5nW4f
PcSt9GG4IiYnEV0JZM7/9lKAvUUGPEhlOzjkcZgYBt0wbOmvNWZW152CCZd0
1EN137snNHFOiCafySAzumV1YW10SvjB3aPeh8emAaZvX4Fcy7SN3lKTpQ2q
hZdQpLsesC0PncyRUKROlL48bOiYGApSAXqPM6hgrB58MCvotWmbuQiM7n7/
Xo5e+PBBU0AxNOdFQYiA1wT9yIqwRI5EUyo2Z1AwFjkKCdxGoVs6X4FS0cmS
EBH2nPREDiyR4jTQqrasyFHYULtCcCMHrRtd3o4d2igx1Xc0tb6qx5rNgH1E
QFSWlLFMMnC4qmVuUXdnxnLjfIcq/7zO9+hWJ2gZU6k/pc95c0TdLfdNvgUs
71LOhuwM/wRiDYWE2GMGMwHtyiX28LAAByuIni4R4XDqi3UkBNMsoK4FmZac
NkFzspfE13gyRMrb/M5ybhuG18oCLjg1+MgcHUb0x7296DCF6qxZmpkobbta
+SqnXgpMTFe5O1kT1Bw1VfV+PeBdpHyjJAUJ+wHqSTOr0DlMvDfknn9Xl0bi
BeXDbJgXFcgMSYsxWc01LMFUUUBATpdmghPOhAt6Ll+dRCI+M8nQWg704By8
jhHGRKTLeuZLMwAHOVtJsS2gu+TPoKK0Mu4EUyIeOVK1MCnmwEktW5eOiPwP
x5PM2PrcCJJU0GhSfT9iSMchY+J7xEFDsWlbd7QmMJg9IS43tiINeGhClQlF
acIMCZvZEo6iWbuFFWeQuII8fYU5hx47sHVOu63pLI719ihPpFiKnA9gRWEz
BaNhcsBi5YOvR+3A8QFaIG/iu642FwEXIs6MWQu/IVQvzr2R5oicJMduhSKs
ieZ7ljrzRYpQT1+WJlGrGvb0iVBRlupVlupVgZiC+WPFArcCAkWHq678VbCA
g+WYkCDRzSn0r63yg55XTMXYcA1rjPuk7HdcY+3ja091+tQ5Yyjfj1Hy8q7R
IrhxDaB9J/F0OYYbqEEO3GaatfcRpLgTJVVG/A9XjpCGgXxzkl70qTYtJ2HV
4wQ9ptay/UecQCa3rtm7aPC2hJh4sWgpn+yXqJwSlAUZXsn2CQ3YpBXiXHJ5
IB4m58AwIjYElEDmPh0gBdat0N+th/9+lE9iwpNtreK9VcSKp2R2gPD3nK4Z
Gt4u2A+VrPzodWQiSJfmokuogdtHAXmPwS61nyBBKTZWxOqxb9zdjEjdl9Xt
ZQ1tLea4clsZE70SjT4ZNH6IQAYsoxur46khXUp0YVehSlacfhDaGWuXHFeh
GD4U4ujf6vqlXkf4RB0u+ug7VUZdldZyrTi24W4N77kd6MXXewlFc2Q3zY83
LzA3TrjvltOzyA2Ol5gU/QZLoQIJXX4ymtGkEso8STSCLnllI0PB+7mjpDWZ
xVNoTsiuVUB+7sTHJjwvqs4wHd5TqmOsgglPC/VT/v3Jzc3zU1/S7y0FM07P
h7pHKPuO3nyeeMXbYSnJQHEWP7y5vvDbw5jxeX5++8Obq1Pu+Ei7OPlz9fob
JgV8cZsruNR1po4ql2paSR3r6uX0rDqlqA6NL1sVE8w/clEfW4W0Ipd3jSk8
pJmECch747MvPHWSAA7N+WnSbFEXqigkd1hpaUCgRDRNeGi304IgZTDG6Twh
mriEYewH0ggn8JhNqViYYVIyJ5h57XMs2GX8iNAZ4W4n+2G6sXopm6i6cRQa
hN0vsbqHZrUbdkrSpGDYG/XXFzcGNN62csoYKHvKxJV0dGZ+xvk0spNldsgH
zQ5q8miKeBMMN+hdj42pzJmwIz22x3E1C4gx7+G4Uu9aazJHKddxeOzlzvoF
k8UVF+n2njbWMTOvRK6GgqpdDohcC1s3G5tdFrqLzK1XRu8PWO84+uOFEn3I
MQLluJpUzdzPXRJERVfwud99oljkR6mYmxlhWyM3OOYimsfkhAh1YMfP41fb
TIioemTXyUSNYgC4tXXVBsqP045SLgIV19yMeGloAf7vieZQnufrYMTMECDq
Nz6kmlQFcISFEvxQoAZVTWoeVJ+UMH/H3vrm6uZUGdNKE+99xeVgLOqC3kcW
Bg0VOG2o8CuSr66YQfKGJUSS4wpGWeZoAYUPib2ZIQzfVRrthQxbQNqM8Ea1
o2zBeTOPaBQjbl6XUxXRzVoz5WcTSYXsKZvSPFSJ+BoRz1Eig5An6TNuJ3gR
zUII71PFlUdyrnaguJlJ8umJUYqUq+mSOpzcJRsXtFwswRuTalBnG19oSeCg
nSsQR2RF/+6ilKqGdAW7rONuG9l9EWYp3CpclRarJvTX+/d8HMKHDwtztVgv
+CUGL0n7BHn63HDS7bwI+ETLF1vPySdzVbcFbxLjTumGEbPKccxK2pHJDcv9
OM8cszudhGpdteO0NpgfSa2NthWEgBAmaN1xDdMIc0RGAqVnVWAk4BPzjgeR
LisyFrtB8uXe8x9mD0hGq2o9aPgbvInflDgS3omfzpMwSUyahXxWbF5SpmJy
vVTHRl+URYALVqPfSiLbC1VDkwWS+rmPMB4zY/viSOYeaXSHuIElTVr6lXmp
nKZzg0DgjhnLslrxcu1jCofzQbGsft0q7cZrNt5/kERC8wHLcvPBmnjs1MR9
rYLKwjYkKICARcYaiITySUVItUVWIslxsfHrBNLFfoXNkmkHNdeJCdWtEsWm
qstO62LNBoQDXjqwCvodlKEtWJmqH0JZvrrctkkwVHoIgZNdzVrq5bw7g8Jx
5cNXWXYJeA+utYSaN74w/F72h/MeKhLUVzgRFlSBS0LWhA5R7Jc+IqzSnlmS
ElwLT0zVTDZNz/zu8jHRPg3NAwfUi+2Xv3It5RaDMGFXUUlWgcDTPee7lkS/
aWspXn3wYI9xgwsMVN3i4FxqJ+7pZLUaWY90+zTKomjpPlDEFXYe8s05mvrK
aEUfiyl4dM2HeU+zbtsynKyLt4Hw1BN2BUmkROZRasbT9yGpAylhL8feMSrn
xDkzdz7DpyhXptHLl1eJVPP2nIQuwxbkSjxy2FYeWTRw97MJn+EDCXVOVdO0
97rJkvfWojx9LuuU9/+AzWUzyxKXRQ69Fg6DyQbLhXc7Qg4d19RbTcb6gsgk
Xx5rQn0BE0VAbMilerbkvLzAhFyZBC6PkPaSoh1x+siCdUbY8cAWSTF565ez
CgSHszRcnMwOKy8Cheu1B4PDvizRBFquFocu7OXwDGBHzj0oayictgxRK4zA
yICVDfvRnYb/rNNKiNIkx3iAlNNtPDrfijvslZKPmwqdL77x/C9iQN16EhLF
sDoPoJ516R/LEr/x9kWSxL/VJLGQgsgRp8ngCWEnFk0oVD6ZQiBJ32a+1C0B
3aM4xxvkhTHnBlU6TBQj+o4wPus3kySnii5y+ZzVchy99BtejbyxRTJPVlQ8
00Do8XgleAc5AGLJCVjZTVmFrRyZq7ZDTWpmyRByRSioak6NJIbGe4vp/mQZ
YSYjVIgdRaw7O/xuPs/mjHqrLvvKITugiS1sNykkHNIjlxPYFhxRGkS93XAY
P+L+reyyrtJaEIG1Mv5wBASt7yzIvvYNl9iwoGdWf/jgp8SZk3hYtDabJYn1
Xs+PCz0/mfmXhrH4VHj01Blvsh3xwb5zJJ+v1S4eFhJq7ODD2ri7jDe1wPmo
hc88me9nk6P+vMZGq1nSNdYU6Ustqyu8LQveIi3s0SJNSWWhSpFxB+GDwJno
m1lvbOZvgRncplVaMUHJVAKwx62f6Ze+vs354/uf3L68OA1d0xKfBifRVH41
ffEb3lpOJodCPW0CMuOMUsi4VR4TbAEPQZ3SssukLgaeJfl2gO5NxOM7HAQa
WIxdEnOvOtnyXe8zZjdWAH/iMfseGwmoB/N5jG53cReI3MAOK9HGjPsk9s98
U+kmunY8nFA+aHX/JBQ4FL9lKtHQDkp85byBsLVGVEGcWDdYPT0BJYbwn0np
lnfS2BSP84YeLFZ7iC64ZkJxV960qJSKSWY2gMmvnc1iKZV0kqbqOinqFYTE
T6SH22DTUtsKk5M0wUeqSIYcBw9QFwII17Lonll2+64HGCbhJiOjN79BPNkP
qFCCkOOeC2gIf+LiYCNRlviOTa5U9k6y1TQR1TuuMXNkYTG01+o1t7yrj4v+
nZ1l0j42EMoKZkPg6wTmXLLnCtmKyy+RBoWJQR0/reUsVFppEC39KtSgeQmB
KeUu+oni6o8QRWdgm3Him9jpWGysCaxRlSp8HHK2IOW8h4I2ZhS54dAQ9I6W
g2xF3mlVVR9ME6eEGiW5G1VW0ohU2VQnxHUHp+jNlYnJRDngiaLpRk60CEXq
fNAO2CP4jiwc+mP0SzB6cJmUp9lGCrcZr8UgSsxhZNQydcPYe+YPjSEjWrbM
a+B8OK08IeCP4Fe3QiFo79otuaNFdkmhX1p9HIckSFufVA4q93ueKlFx0jpf
hIDtVN2WE2sl99uPUOJ03owwuSVL3J7W60JFKs708Jz6OHPaK/JYJ3wMSexO
8NTIy/O+HK7pBfNnXt4aTDGKAvP9iYpEDzJBQgfws0VpPuZez4mR9uLOYKlN
sNjO0McKM359FtFksbFkWUutu17lVa3bImBvOJ6lP+q2vWNv8yS1rkmIzAWh
pzoMKN3b6B+QUhHI8zxvhlXOoW1HIBN29pL9uURAt2luKHvy/M3lqeHC3H/+
z1/+5sM4deTLvAHNrOI4/4EKY8J5clninjtrYrkDL+RksclRLroVcxbmJiO9
rii8ZbDo62dDPV04Ion0fLXy++91V5fwmPRbxpV3fkeQSVsUdDOOg/ARE3Zp
deC8s8jbOsV8ODvfHD87358zQ/Or6SMZ7KZaxUJ/2X1/7KARPhvCZcyv+vCU
d3J36iDxD89G+iT0E5wDxpWpnMoRt5XR8t6BUXCnjGCQliIL7mKVhASOFka0
0EKPfXpSRcaHvWPO+Zg7SWqN3M5rzgDDpPssNVtnb77SBsisy4YADz6C/qYd
SPekJcgdWSrUbkoSM1TXVc5jNB+geQPHOmBxpBFszigJJTfa0QFYitK5H4qf
/LEarFd+xfrcI5pXZgpcdHqan1QAUCdXPU6CICFdKUWYJZQILXR19bx5wfW8
nCJLzsca8LC55zgsaLeRAyqkglhg6wknyWIem6TRrk7Mk5++v0FZvXxp4sOH
TEoF+Myi1Ofp/ivJYVLYR49B8RGY56MiFIofaVCEbIJZh2vxR28Bds3CFhXA
QuGSH3waItydhci04kAzwpRKT08Z81aB8cF2buZbuXtZHtUUP6Z9S+u2SQWW
fkLEA/HLM8nMQillDvxSOBwCp5mkIElTik4XU6wHQu2/04QUn+XAtcBkV1GW
kQOcMX8M4Spuf/3s1nyx+G1EPkMHjmPofR1XjQInwbuJUxM6Q/YwDFUtVXKA
dmh6SI/8ID0ka0CvvpB4OeMiZZ8x1/JgqWTnyph0Vz90u66YDtfuciF9tqxb
Ch1whdpNLJ5yDjIHUQ3SQiAaQNFn+q5ZTE9JNPu5S7sSNoSFwyLbDcX+6A6/
Ozuv8YL1RstP2PjgGZ9CzGt/Atl2N/TeR4Rtw3RrJhVAfdvihCw5gyw9I/VB
64PiqQSj81JI2pmGW4ytGz59RxxDOKLbzEGjHD0Y0OcrOe/pz/r2QNEv75jM
k0oUbEhGuQKpse6fhSlKK2fJmVXscVeky30ws+EN450m4fDoGI9pzibjDRS8
tr0NTHeexIARoSvh0HXF+yIYDiJ4ypCS0up59kve0M/IhJNk2PdiknxOn/Mf
8FEXOBqYwgqKYDJP9PhEkmcJ4ak/dyOGh+nihE/mr0AsO7JinCnWLtYhdGD8
8G3brms5A4kr3HWJsddKCpnEoigfzpt8mGByfJSNP7LSyxwRYB8O2sgkSSZc
ZmuYD8Vu0p+tPMUV6Zww9ntoYlnPInsZTvEUzOiXWXqgwZg5FQzDJReOD3yT
yskYQSUpCj1glCEqZ/2Qv0GZkz+AFq9SB5fJVs9046HXrfSwUT9hvo5JigRX
otzRlYeSA0EPzppHjoL0SREpi3d9FqOQUfWLhxXYkK1Kce8S1k9z+f612fv3
fMw/F7V/BpXTInhCbs8IZ2Mo6h7FjBw/NzEpIJJNlLHiPxOGJCITPqxEHQ0f
CWzTMyTE1KShI70+87vSNKtxlmVzBlso6kxy6kxWRJFpXp9RNlfPa6Ywl7xT
AkByX59k32laFGKUM3zD+l9kU2raC36rxV9JjYqMQ3WmDHsOs6RWjQ8naIrI
SEkxVa9HWUlLoxYizRiSbjGiKyv3F6lhmuuORtnlOjRSIk5t+I08eIGvRJfT
nQ4pSVqv6SmnYbq11pSBh3AT+NimbKKRMvWqS8OKbJRTBc+hta9CGKYN+PNh
7z3oDIuog/lATzi3BS6lYJIMZZnXK5rNmezADogxWTdePl6SmU9T048ot0jY
dR5THnbe40usUnM5CVCo4d9lHip6l+4NJtBMPABeEIf5g6W21bowcmCzK7bk
QPRKkyzppWUfjrMcLyAKzm29kikWsxm3HJKFQWDbdmJUfBEC00+oJ7CyWo4l
eZXwgP3LNrzn/9HUOFt+jrcmNZ6BTI8H5RDqx/Ke2gAE9eMEPDU1bJfycShQ
HGFlYS7c7+S4R588D8zYTHaEzqQ7BI3J2m6q3SxLHDV2kjBTxWeF8QHTRwUQ
FSbgncxnvpMAi2E/U33ksHDAqt/r86CBl5zL551Gsi1IrJU/xnu09Vroxp7A
Y1NCD0hs9LfmW8CFZ6EQdGzkUlNTAYawXrbi+2yCVTh6U3ifUuJSxpRkKsUe
4U3+vPHNpHo+88cjlLE3YeshKpJGa1sPPme84X2/UgyhGS4Q9gfPZEPDu9lK
f/SGrwRAR3nDp40oHQyUX482PYI4k41ZyRri4hdf8IZPZLCceO8rm6egcaF8
ktwNb3qwnJmYafo4qR+7z+vBepSuXX5kZ0JQLr9bJo24wzLgOkiNhn7nOVVZ
5dyFLOzGb3mzhvZDGpeqlFB75rd/+87EOXSCiGBm7mLhTvAsCy020AwvYf5K
jt/1eVb5yHIQ06gqWjfE+TPmYyV7EmMLUPcdDapNbytHCbSkx95NAt8xVz8+
60Kyh7Ey259doWT9QV3Q0ZLLDOc1iWPEF378PqsoUd/RZDXogUaykZ6D1ixR
Ryl890dp6/cWlnlxB8h1o6dbmxs5ePj9Z/68azmJ+AMKS2lJ2VgE61EXx6fg
87i4Ug/wauWo5D4cm+1PNFY1CgBOPo2R7mMNiYpLHNjoUENc23vMWl7kpd3y
KYZyHAp4Jz72xX8UhRnfWvfza/W5dlsP1pJeLG3NlUZae+QPoudytxh0J8IL
feBKlrBHued1Zr1GIGGnZQD96GSi9Fw9f8LX9KxpPtRan/Td3GuyP5f6NalY
eC5lLJU/4iEelZRl4w9CLWQb/P/ZN7AXKIeI205JEYBKXi34c2Zbinw2M/Pt
QK4ux0bXbwGcSFnHn+bjjvzjnwjkLjyJW0KNZ5ktCDX5PiJ6Jl9HmulHj2bJ
t4y4Ax/5aaYzc8mHNsiesoZk1zPXsOcTRlQcOOSPZ+Pil7beHz0sjOIa/xFj
7trxLyTru/DtZrwt/RD8aEDfQJuTUZHeUBNLv1WVWsky/1HOWfKpzdno85mz
I9/DnI2+cDkbf7KS+/B/+SukKgI96THL4jfw4jTHD9bN0o/QzfRrWdzNf+xL
ffr2Z1fXOtvXJQ60nXwsIdShHInGQ71nchZLlk0+2809/HUfDdeehYKSLEu+
8jtLPt07C5/jnU0+sDubfjKXu/H4F4j1lYG/zqafoJwdflFyduwjkbPRhx/5
rQdfxzxLN/3xDpRi6Ca74bRD6f43ilnix/Rm5og5DGTg2a/jAvVlylPEKeTP
z8lK2ISv2p3R3/8u38MjvSYLgiZvrm5M/CQePRAr0Vm3XjK0gkdeS8E3Clq6
Kq9xGkzZteYid7kMItEMHBuID7cWtkLJnZ6sLWm2ZJWFYwL+9td/M+fXfi83
mZxi8Cb+4vz2nCd29OXw2eRL4LMjX/aepV/rnj329W3u+q/5+PmZke+nS/fk
m+4srPhZiREUIdSS/Plh8nmJQ9RyQUq7p14gBJlhMVIvqH8y6osB5I/5znKh
BP1waaEptHxoVa2ZihoN+qojo/LjviE5kUO01ChNWIcI8ZqQA5lYMg60BAm2
0bq8u2vxb2yLfMa5zbal9mCg72C//pTT5e9BxZqXn1+2TbveIJvzPTazmLe8
MQPlqc9QiHy1puivnx18Q45+8S5m6o7HCxB/EQJpoz1I53psqeIPurRcm9zE
a+GIvhzaiSMaNFG6m7zv4Gxe593O7mdmZN6S9eCtfPD201U/g0MiodU9uvoK
Z1++RaA9dX4jt0g6SRjLmYsZqbHW5l5hRP3MjCxM6pNn+PL1xQYpCXW1R40f
XMFPFCIsK7yNGc8bRYMXHg1OVfcALW4t6ttUj9NO8Pf5ZubN7cXT69vr0+nU
62Wte4Mju7Tbtug8b/86xFSnhxOnD0PTHU386UgWehHpQ3uaClovkLeuCNWe
+gnTn/8w5A+2OmUxnIfdNRIZvj+TMj5b/teTVV47e4I1/fLyZboPZ5H9b1Jy
f4EIigAA
</rfc> </rfc>
 End of changes. 95 change blocks. 
716 lines changed or deleted 452 lines changed or added

This html diff was produced by rfcdiff 1.48.