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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-fink-coin-sec-priv-03"
     category="info" >

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes" ?>

  <front>
    <title abbrev="Enhancing Security and Privacy">
      Enhancing Security and Privacy with In-Network Computing </title>
    <author initials="I" surname="Fink" fullname="Ina Berenice Fink">
      <organization>RWTH Aachen University</organization>
      <address>
        <postal>
          <street>Ahornstr. 55</street>
          <city>Aachen</city>
          <code>D-52062</code>
          <country>Germany</country>
        </postal>
        <phone>+49-241-80-21419</phone>
        <email>fink@comsys.rwth-aachen.de</email>
      </address>
    </author>
    <author initials="K" surname="Wehrle" fullname="Klaus Wehrle">
      <organization>RWTH Aachen University</organization>
      <address>
        <postal>
          <street>Ahornstr. 55</street>
          <city>Aachen</city>
          <code>D-52062</code>
          <country>Germany</country>
        </postal>
        <phone>+49-241-80-21401</phone>
        <email>wehrle@comsys.rwth-aachen.de</email>
      </address>
    </author>

    <date year="2021" month="October" day="22"/>

    <area>General</area>
    <workgroup>COINRG</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>
        With the growing interconnection of devices, cyber security and data protection are of increasing importance. This is especially the case regarding cyber-physical systems due to their close entanglement with the physical world. Misbehavior and information leakage can lead to financial and physical damage and endanger human lives and well-being. Thus, hard security and privacy requirements are necessary to be met. Furthermore, a thorough investigation of incidents is essential for ultimate protection. Computing in the Network (COIN) allows the processing of traffic and data directly in the network and at line-rate. Thus, COIN presents a promising solution for efficiently providing security and privacy mechanisms as well as network monitoring. This document discusses select mechanisms to demonstrate how COIN concepts can be applied to counter existing shortcomings of cyber security and data privacy.
      </t>
    </abstract>
  </front>

  <middle>


<section anchor="problems" title="Introduction">

<t>With the ongoing digitalization, previously isolated devices and systems are increasingly connected to the Internet, concerning all aspects of life. In particular, in the context of Cyber-Physical Systems (CPS) and the (Industrial) Internet of Things, machines and infrastructure are equipped with additional sensors and CPUs to allow for automatization and higher processing efficiency. The entanglement of the sensors with the physical world leads to high sensitivity of the transmitted and collected data.</t>

<t>Consequently, digitalization expands the attack surface and the possible impacts of cyber attacks, increasing the importance of proper protection mechanisms.</t>

<t>Devices in CPS are often resource-constrained and do not offer the possibility to implement elaborate security mechanisms. Furthermore, legacy devices and communication protocols are often still used in industrial networks but were not designed to face the security and privacy challenges the new interconnection brings. Thus, communication and access are often unprotected.</t>

<t>Upgrading legacy devices with protection mechanisms is an effortful and expensive procedure. A promising approach for retrofitting security is the deployment of suitable mechanisms within the network. To date, this is mainly realized using middle-boxes, leading to overhead and the need for additional hardware.</t>

<t>One general and widespread security component is Intrusion Detection Systems (IDS) to detect and, ideally, prevent undesired events in a network. However, IDS are usually implemented in software, again running on middle-boxes or edge devices in the same network. Thus, their reaction time is limited as well as their information gain, which is usually addressed by deploying additional IDS components for traffic monitoring.</t>

<t>Last, the after-treatment of incidents in networks is critical to detect exploited vulnerabilities and prevent future attacks. Network forensics serves to retrace and comprehend the origin and course of malicious events. However, to provide high performance, the underlying monitoring of network traffic requires dedicated networking devices and/or expensive subscriptions to respective features, leading to high costs.</t>

<t>One common problem is that security is usually provided by software solutions. These often require additional hardware and lead to performance overhead, which is especially unfavorable in the context of time-sensitive applications, e.g., in industry. Existing high-performance solutions, e.g., running on traditional networking devices, require dedicated, costly, and unsustainable hardware.</t>

<t>Computing in the Network (COIN) covers these shortfalls by using programmable networking devices to conduct dynamic and custom processing of network packets at line-rate. Thus, security-related functions and packet inspection can be implemented and applied centrally in the network, e.g., at a programmable switch.</t>

<t>This draft explores the opportunities of COIN for improving security and privacy as follows: We first describe feasible mechanisms for preventing attacks and intrusion in the first place. Then, we present which mechanisms we can implement with COIN for detecting intrusion and undesired behavior when it has already taken place. Last, we explore how COIN can improve network monitoring for detecting, analyzing and following up incidents, thus fixing vulnerabilities.</t>

</section>
<section anchor="prevention" title="Protection Mechanisms">

<t>The common ground for providing security and data privacy is to protect against unauthorized access.
That protection is primarily provided by basic security mechanisms such as encryption, integrity checks, authentication, and authorization. These are often missing in resource-constrained environments or regarding legacy industrial devices. <xref target="RFC7744"/> thoroughly discusses the need for authentication and authorization in resource-restrained environments. <xref target="RFC8576"/> presents security and privacy risks and challenges specific to the IoT. In the following, we describe how COIN can help to retrofit suitable mechanisms.</t>

<section anchor="enc" title="Encryption and Integrity Checks">

<t>Encryption is critical to preserve confidentiality when transmitting data. Integrity checks prevent undetected manipulation, which can remain unnoticed even despite encryption, e.g., in case of flipped bits. Due to resource-constraints, many devices in CPS do not provide encryption or calculation of check-sums.</t>

<t>By default, secure cryptographic functions are not supported by current programmable switches either and hard to realize due to their computational constraints.
However, there are efforts by researchers to implement AES encryption with scrambled lookup tables <xref target="CHEN"/> and cryptographically secure keyed hash functions <xref target="YOO"/> on existing programmable hardware switches.
Furthermore, future generations of programmable hardware switches might provide secure cryptographic functions by design.</t>

<t>With secure cryptography at hand, COIN would allow to encrypt and hash packet contents efficiently while passing a respective programmable networking device.
Concretely, data could be encrypted and supplemented with a check-sum directly at the first networking device passed by a packet before forwarding it through the Internet to its designated destination. Subsequent decryption and integrity checks could be executed at the last networking device before the destination. Alternatively, this could be implemented at the destination if supported by the respective device. 
This approach does not require deployment of or forwarding to additional middle-boxes. Thus, no additional attack surface or processing overhead is introduced, presenting a promising foundation for retrofitting security in time-sensitive scenarios such as industrial processes.</t>

<t>Another use-case is the implementation of whole standards for secure communication on programmable networking devices, offering new flexibility.
For example, researchers examined the benefits of deploying IPsec and MACsec on programmable switches <xref target="HAUSER-IPsec"/>,<xref target="HAUSER-MACsec"/> but their implementations only target software switches due to the missing cryptographic capabilities of existing programmable hardware switches.</t>

<t>Future research is needed to clarify if and at which costs hardware for enabling cryptographic calculations could and should be embedded in future generations of programmable networking devices.</t>

</section>
<section anchor="auth" title="Authentication and Authorization">

<t>Authentication and authorization mechanisms are needed to avoid unauthorized access to devices and their manipulation in the first place. With COIN, networking devices can flexibly decide whether to forward packets, thus offer efficient and fine-granular access control.</t>

<t>One possibility is to conduct a handshake between the sender and networking device before starting the communication with industrial devices. Cryptographic calculations (e.g. required for certificate-based authentication) can be offloaded to the control plane if not feasible in the data plane of the networking device due to computational constraints.
Existing research also proposed and implemented authentication in the data plane, e.g., using port-knocking <xref target="ALMAINI"/>.
Authorization information can be stored in tables in the data plane or requested from the control plane.
Since authentication and authorization is only needed when starting or refreshing a connection, the necessity and overhead for consulting the control plane are limited.
Subsequent to the authentication and authorization process, the respective decisions can be flexibly enforced by the networking device. For example, different fine-granular policies can be linked to different authorization levels and different devices.
In the case of unsuccessful authorization or authentication, networking devices can inform the network administrator about possible intrusion of the system.</t>

<t>Overall, COIN can realize efficient and flexible access control, reducing overhead and attack surface.</t>

</section>
<section anchor="ips" title="Policies">

<t>Control processes can include communication between various parties. Even despite authorization and authentication mechanisms, undesired behavior can occur. For instance, malicious third-party software might be installed on the approved device and thus implicitly gain access. 
Depending on the involved devices and their capabilities, proper authorization and authentication might not be possible at all.
An effective way to exclude malicious behavior nevertheless is policy-based access control.</t>

<t><xref target="RFC8520"/> proposes the Manufacturer Usage Description (MUD), a standard for defining the communication behavior of IoT devices, which use specific communication patterns. The definition is primarily based on domain names, ports, and protocols (e.g., TCP and UDP). Further characteristics as the TLS usage <xref target="I-D.draft-ietf-opsawg-mud-tls-05"/> or the required bandwidth of a device <xref target="I-D.draft-lear-opsawg-mud-bw-profile-01"/> can help to define connections more narrowly.
By defining the typical behavior, we can exclude deviating communication, including undesired behavior.
Likewise to IoT devices, industrial devices usually serve a specific purpose. Thus, applying MUD or similar policies is viable in industrial scenarios as well.</t>

<t>The problem that remains is the efficient enforcement of such policies through fine-granular and flexible traffic filtering. While middle-boxes increase costs and processing overhead, primary SDN approaches as OpenFlow allow only filtering based on match-action rules regarding fixed protocol header fields. Evaluation of traffic statistics for, e.g., limiting the bandwidth, requires consultation of the remote controller. This leads to latency overheads, which are not acceptable in time-sensitive scenarios.</t>

<t>In contrast, the COIN paradigm allows flexible filtering even concerning the content of packets and connection metadata. Furthermore, traffic filtering can be executed by programmable networking devices at line-rate.</t>

<t>Last, not only network communication behavior of devices can be defined in policies. For example, COIN can be also used to consider additional (contextual) parameters, e.g., the time of day or activity of other devices in the network <xref target="KANG"/>.</t>

</section>
<section anchor="patches" title="In-Network Vulnerability Patches">

<t>Resource-constrained devices are typically hard to update. Thus, device vulnerabilities often cannot be fixed after deployment. As a remedy and special case of policies, rules could be defined to describe known attack signatures. By enforcing these rules at programmable networking devices, e.g., by dropping matching traffic, COIN would offer an efficient way to avoid exploitation of device vulnerabilities. Another potential advantage is the easy and extensive roll-out of such “in-network patches” in the form of (automatic) software updates of the networking device.</t>

<t>Future research is needed to evaluate the potential and benefits of in-network patches compared to traditional security measures, e.g., firewalls, and provide proof of concepts using existing devices and vulnerabilities.</t>

</section>
<section anchor="privacy" title="Anonymization">

<t>Due to their interconnection with the physical world, the generation of sensitive data is inherent to CPS. Smart infrastructure leads to the collection of sensitive (user) data. In industrial networks, information about confidential processes is gathered. Such data is increasingly shared with other entities to increase production efficiency or enable automatic processing.</t>

<t>Despite the benefits of data exchange, manufacturers and individuals might not want to share sensitive information. While deployment of privacy mechanisms is usually not possible at resource-constrained or legacy devices, COIN has the potential to apply privacy mechanisms in a flexible and comprehensive manner.</t>

<t>Data could be pseudonymized at networking devices by, e.g., extracting and replacing specific values. Furthermore, elaborate anonymization techniques could be implemented in the network by sensibly decreasing the data accuracy. For example, concepts like k-Anonymity could be applied by aggregating the values of multiple packets before forwarding the result. Noise addition could be implemented by adding a random number to values. Similarly, the state-of-the-art technique differential privacy could be implemented by adding noise to responses to statistical requests.</t>

<t>Indeed, recent research exploits programmable hardware switches to implement performant and light-weight anonymization of communication by rewriting source addresses and information and hiding path information, e.g., using randomization <xref target="MOGHADDAM"/>. Similarly, <xref target="WANG"/> realizes traffic obfuscation by encrypting IPv4 addresses in the data plane.</t>

<t>Future research is needed to implement and evaluate further privacy mechanisms and COIN’s potential for this field.</t>

</section>
</section>
<section anchor="detection" title="Intrusion and Anomaly Detection">

<t>Ideally, attacks are prevented from the outset. However, in the case of incidents, fast detection is critical for limiting damage.
Deployment of sensors, e.g., in industrial control systems, can help to monitor the system state and detect anomalies. This can be used in combination with COIN to detect intrusion and to provide advanced safety measures, as described in the following.</t>

<section anchor="ids" title="Intrusion Detection">
<t>Data of sensors or monitored communication behavior can be compared against expected patterns to detect intrusion. Even if intrusion prevention is deployed and connections are allowed when taken individually, subtle attacks might still be possible. For example, a series of values might be out of line if put into context even though the individual values are unobtrusive. Anomaly detection can be used to detect such abnormalities and notify the network administrator for further assessment.</t>

<t>While intrusion detection systems (IDS) are usually deployed at middle-boxes or external servers, COIN provides the possibility to detect anomalies at-line rate, e.g., by maintaining statistics about traffic flows. This decreases costs and latency, which is valuable for a prompt reaction. Another advantage is that one central networking device can monitor traffic from multiple devices. In contrast, multiple distributed middle boxes are usually needed to achieve the same information gain.
Last, programmable networking devices can be used to preprocess traffic and reduce load on subsequent in IDS components as examined by <xref target="LEWIS"/>.</t>

<t>Besides intrusion, anomalies can also imply safety risks. In the following, we pick up the potential of COIN to support safety.</t>

</section>
<section anchor="deadmans" title="Dead Man’s Switch">
<t><xref target="I-D.draft-irtf-coinrg-use-cases-00"/> addresses the potential of COIN for improving industrial safety. Detection of an anomaly in the sensor data or operational flow can be used to automatically trigger an emergency shutdown of a system or single system components if the data indicates an actual hazard. Apart from that, other safety measures like warning systems or isolation of areas can be implemented. While we do not aim at replacing traditional dead man’s switches, we see the potential of COIN to accelerate the detection of failures. Thus, COIN can valuably complement existing safety measures.</t>

</section>
</section>
<section anchor="monitoring" title="Network Monitoring">
<t>After detecting an incident, it is essential to investigate its origin and scope. The results of this analysis can be used to allow for consistent recovery, to adapt protection mechanisms, and prevent similar events in the future.
For enabling potential investigation, traffic is constantly captured (e.g., in the form of flow records), which requires dedicated hardware in large networks. Furthermore, it might be preferable to exclude traffic, e.g., from specific subnets, from the analysis. Dynamic and fine-granular traffic filtering is not possible with traditional networking devices, leading to storage and processing overhead.</t>

<t>With COIN, networking devices can be programmed to export traffic characteristics without significant overhead when forwarding a packet. Furthermore, monitoring can be done more flexibly, e.g., by applying fine-granular traffic filtering. Also, header fields of particular interest can be efficiently extracted.
Therefore, COIN can considerably decrease the load and increase the efficiency of security-related network monitoring.</t>

<t>The presented prospects are underlined by recent work. For example, in <xref target="SONCHACK"/>, flow records are created in the control plane of programmable hardware switches while expensive packet preprocessing is offloaded to the data plane.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">
<t>When implementing security and privacy measures in networking devices, their security and failure resistance is critical. 
Related research questions to clarify in the future are stated in <xref target="I-D.draft-kutscher-coinrg-dir-02"/>.</t>

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

<t>N/A</t>

</section>
<section anchor="conclusion" title="Conclusion">

<t>COIN has the potential to improve and retrofit security and privacy, especially with regard to resource-restrained and legacy devices.</t>

<t>First, COIN can provide intrusion prevention mechanisms like authentication and efficient enforcement of (context-based) policies. Easily deployable in-network patches of device vulnerabilities could further improve security. Encryption and integrity checks are limited by the current hardware but already targeted by recent research.</t>

<t>Second, COIN allows examining packet contents at networking devices, which can help implement fast and comprehensive anomaly and intrusion detection.</t>

<t>Last, COIN can contribute to an efficient and targeted traffic monitoring for incident analysis.</t>

<t>Further investigation of the feasibility and potential of the presented mechanisms is subject to future research.</t>

</section>

</middle>

<back>


  <references title='Informative References'>

<!-- MUD -->


<reference  anchor="RFC8520" target='https://www.rfc-editor.org/info/rfc8520'>
<front>
<title>Manufacturer Usage Description Specification</title>
<author initials='E.' surname='Lear' fullname='E. Lear'><organization /></author>
<author initials='R.' surname='Droms' fullname='R. Droms'><organization /></author>
<author initials='D.' surname='Romascanu' fullname='D. Romascanu'><organization /></author>
<date year='2019' month='March' />
<abstract><t>This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs).  The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function.  The initial focus is on access control.  Later work can delve into other aspects.</t><t>This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.</t></abstract>
</front>
<seriesInfo name='RFC' value='8520'/>
<seriesInfo name='DOI' value='10.17487/RFC8520'/>
</reference>

<!-- IoT Security -->


<reference  anchor="RFC8576" target='https://www.rfc-editor.org/info/rfc8576'>
<front>
<title>Internet of Things (IoT) Security: State of the Art and Challenges</title>
<author initials='O.' surname='Garcia-Morchon' fullname='O. Garcia-Morchon'><organization /></author>
<author initials='S.' surname='Kumar' fullname='S. Kumar'><organization /></author>
<author initials='M.' surname='Sethi' fullname='M. Sethi'><organization /></author>
<date year='2019' month='April' />
<abstract><t>The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication.  The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS).  However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities.  In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats.  Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems.  This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.</t><t>This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).</t></abstract>
</front>
<seriesInfo name='RFC' value='8576'/>
<seriesInfo name='DOI' value='10.17487/RFC8576'/>
</reference>

<!-- ACE Use Cases -->


<reference  anchor="RFC7744" target='https://www.rfc-editor.org/info/rfc7744'>
<front>
<title>Use Cases for Authentication and Authorization in Constrained Environments</title>
<author initials='L.' surname='Seitz' fullname='L. Seitz' role='editor'><organization /></author>
<author initials='S.' surname='Gerdes' fullname='S. Gerdes' role='editor'><organization /></author>
<author initials='G.' surname='Selander' fullname='G. Selander'><organization /></author>
<author initials='M.' surname='Mani' fullname='M. Mani'><organization /></author>
<author initials='S.' surname='Kumar' fullname='S. Kumar'><organization /></author>
<date year='2016' month='January' />
<abstract><t>Constrained devices are nodes with limited processing power, storage space, and transmission capacities.  In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.</t><t>This document includes a collection of representative use cases for authentication and authorization in constrained environments.  These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.</t><t>Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol.  However, most conclusions apply generally.</t></abstract>
</front>
<seriesInfo name='RFC' value='7744'/>
<seriesInfo name='DOI' value='10.17487/RFC7744'/>
</reference>

<reference anchor="ALMAINI" target="https://link.springer.com/article/10.1007/s00607-020-00835-4">
  <front>
    <title>Lightweight edge authentication for software defined networks</title>

    <author fullname="Amar Almaini" initials="A" surname="Almaini">
          <organization />

</author>

    <author fullname="Ahmed Al-Dubai" initials="A" surname="Al-Dubai">
          <organization />

</author>

    <author fullname="Imed Romdhani" initials="I" surname="Romdhani">
          <organization />

</author>

    <author fullname="Martin Schramm" initials="M" surname="Schramm">
          <organization />

</author>

    <author fullname="Ayoub Alsarhan" initials="A" surname="Alsarhan">
          <organization />

</author>

    <date year="Computing 103, 291–311 (2021), August 2020" />

</front>

</reference>

<reference anchor="CHEN" target="https://dl.acm.org/doi/abs/10.1145/3405669.3405819">
  <front>
    <title>Implementing AES Encryption on Programmable Switches via Scrambled Lookup Tables</title>

    <author fullname="Xiaoqi Chen" initials="X" surname="Chen">
          <organization />

</author>

    <date year="In Proceedings of the Workshop on Secure Programmable Network Infrastructure, August 2020" />

</front>

</reference>

<reference anchor="HAUSER-IPsec" target="https://ieeexplore.ieee.org/document/9151942">
  <front>
    <title>P4-IPsec: Site-to-Site and Host-to-Site VPN With IPsec in P4-Based SDN</title>

    <author fullname="Frederik Hauser" initials="F" surname="Hauser">
          <organization />

</author>

    <author fullname="Marco Häberle" initials="M" surname="Häberle">
          <organization />

</author>

    <author fullname="Mark Schmidt" initials="M" surname="Schmidt">
          <organization />

</author>

    <author fullname="Michael Menth" initials="M" surname="Menth">
          <organization />

</author>

    <!-- <date month='August' day='4' year='2019' /> -->

    <date year="In IEEE Access, vol. 8, July 2020" />

</front>

</reference>

<reference anchor="HAUSER-MACsec" target="https://ieeexplore.ieee.org/document/9044731">
  <front>
    <title>P4-MACsec: Dynamic Topology Monitoring and Data Layer Protection With MACsec in P4-Based SDN</title>

    <author fullname="Frederik Hauser" initials="F" surname="Hauser">
          <organization />

</author>

    <author fullname="Marco Häberle" initials="M" surname="Häberle">
          <organization />

</author>

    <author fullname="Mark Schmidt" initials="M" surname="Schmidt">
          <organization />

</author>

    <author fullname="Michael Menth" initials="M" surname="Menth">
          <organization />

</author>

    <!-- <date month='August' day='4' year='2019' /> -->

    <date year="In IEEE Access, vol. 8, March 2020" />

</front>

</reference>

<reference anchor="KANG" target="https://www.usenix.org/conference/usenixsecurity20/presentation/kang">
  <front>
    <title>Programmable In-Network Security for Context-aware BYOD Policies</title>

    <author fullname="Qiao Kang" initials="Q" surname="Kang">
          <organization />

</author>

    <author fullname="Adam Morrison" initials="A" surname="Morrison">
          <organization />

</author>

    <author fullname="Yuxin Tang" initials="Y" surname="Tang">
          <organization />

</author>

    <author fullname="Ang Chen" initials="A" surname="Chen">
          <organization />

</author>

    <author fullname="Xiapu" initials="X" surname="Luo">
          <organization />

</author>

    <!-- <date month='August' day='4' year='2019' /> -->

    <date year="In Proceedings of the 29th USENIX Security Symposium (USENIX Security 20), August 2020" />


</front>

</reference>

<reference anchor="LEWIS" target="https://ieeexplore.ieee.org/document/9040044">
  <front>
    <title>P4ID: P4 Enhanced Intrusion Detection</title>

    <author fullname="Benjamin Lewis" initials="B" surname="Lewis">
          <organization />

</author>

    <author fullname="Matthew Broadbent" initials="A" surname="Broadbent">
          <organization />

</author>

    <author fullname="Nicholas Race" initials="N" surname="Race">
          <organization />

</author>

    <!-- <date month='August' day='4' year='2019' /> -->

    <date year="2019 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), November 2019" />


</front>

</reference>

<reference anchor="WANG" target="https://arxiv.org/abs/2006.00097">
  <front>
    <title>Programmable In-Network Obfuscation of Traffic</title>

    <author fullname="Liang Wang" initials="L" surname="Wang">
          <organization />

</author>

    <author fullname="Hyojoon Kim" initials="H" surname="Kim">
          <organization />

</author>

    <author fullname="Prateek Mittal" initials="P" surname="Mittal">
          <organization />

</author>

    <author fullname="Jennifer Rexford" initials="J" surname="Rexford">
          <organization />

</author>

    <date year="arXiv:2006.00097 [cs.NI], 2020" />

</front>

</reference>

<reference anchor="MOGHADDAM" target="https://arxiv.org/abs/1911.09642">
  <front>
    <title>Programmable In-Network Obfuscation of Traffic</title>

    <author fullname="Hooman Mohajeri Moghaddam" initials="H" surname="Moghaddam">
          <organization />

</author>

    <author fullname="Arsalan Mosenia" initials="A" surname="Mosenia">
          <organization />

</author>

    <date year="arXiv:1911.09642 [cs.CR], November 2019" />


</front>

</reference>

<reference anchor="SONCHACK" target="https://dl.acm.org/doi/abs/10.1145/3190508.3190558">
  <front>
    <title>Turboflow: Information Rich Flow Record Generation on Commodity Switches</title>

    <author fullname="John Sonchack" initials="J" surname="Sonchack">
          <organization />

</author>

    <author fullname="Adam J. Aviv" initials="A" surname="Aviv">
          <organization />

</author>

    <author fullname="Eric Keller" initials="E" surname="Keller">
          <organization />

</author>

    <author fullname="Jonathan M. Smith" initials="J" surname="Smith">
          <organization />

</author>

    <date year="In Proceedings of the Thirteenth EuroSys Conference, April 2018" />


</front>

</reference>

<reference anchor="YOO" target="https://arxiv.org/abs/1911.09642">
  <front>
    <title>Secure Keyed Hashing on Programmable Switches</title>

    <author fullname="Sophia Yoo" initials="S" surname="Yoo">
          <organization />

</author>

    <author fullname="Xiaoqi Chen" initials="X" surname="Chen">
          <organization />

</author>

    <date year="In Proceedings of the ACM SIGCOMM 2021 Workshop on Secure Programmable Network INfrastructure, August 2021" />


</front>

</reference>

<reference anchor="I-D.draft-kutscher-coinrg-dir-02">
  <front>
    <title>Directions for Computing in the Network</title>


    <author fullname="Dirk Kutscher" initials="D" surname="Kutscher">
          <organization />

</author>

    <author fullname="Teemu Karkkainen" initials="T" surname="Karkkainen">
          <organization />

</author>

    <author fullname="Joerg Ott" initials="J" surname="Ott">
          <organization />

 </author>


    <date month="July" day="31" year="2020" />


    <abstract>      <t>In-network computing can be conceived in many different ways - from
   active networking, data plane programmability, running virtualized
   functions, service chaining, to distributed computing.

   This memo proposes a particular direction for Computing in the
   Networking (COIN) research and lists suggested research challenges.</t>
</abstract>


</front>


  <seriesInfo name="Internet-Draft" value="draft-kutscher-coinrg-dir-02" />

  <format type="TXT" target="https://datatracker.ietf.org/doc/html/draft-kutscher-coinrg-dir-02" />

</reference>

<reference anchor="I-D.draft-irtf-coinrg-use-cases-00">
  <front>
    <title>Use Cases for In-Network Computing</title>


    <author fullname="Ike Kunze" initials="I" surname="Kunze">
          <organization />

</author>

    <author fullname="Klaus Wehrle" initials="K" surname="Wehrle">
          <organization />

</author>

    <author fullname="Dirk Trossen" initials="D" surname="Trossen">
          <organization />

</author>

    <author fullname="Marie-Jose Montpetit" initials="M.J" surname="Montpetit">
          <organization />

</author>


    <date month="February" day="17" year="2021" />


    <abstract>      <t>Computing in the Network (COIN) comes with the prospect of deploying
   processing functionality on networking devices, such as switches and
   network interface cards.  While such functionality can be beneficial
   in several contexts, it has to be carefully placed into the context
   of the general Internet communication.  This document discusses some
   use cases to demonstrate how real applications can benefit from COIN
   and to showcase essential requirements that have to be fulfilled by
   COIN applications.</t>
</abstract>


</front>


  <seriesInfo name="Internet-Draft" value="draft-irtf-coinrg-use-cases-00" />

  <format type="TXT" target="https://tools.ietf.org/html/draft-irtf-coinrg-use-cases-00" />

</reference>

<reference anchor="I-D.draft-ietf-opsawg-mud-tls-05">
  <front>
    <title>Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices</title>


    <author initials="T" surname="Reddy" fullname="Tirumaleswar Reddy">
          <organization />

</author>


    <author initials="D" surname="Wing" fullname="Dan Wing">
          <organization />

</author>


    <author initials="B" surname="Anderson" fullname="Blake Anderson">
          <organization />

</author>



    <date month="July" day="27" year="2021" />


    <abstract>      <t>This memo extends the Manufacturer Usage Description (MUD)
   specification to incorporate (D)TLS profile parameters.  This allows
   a network security service to identify unexpected (D)TLS usage, which
   can indicate the presence of unauthorized software or malware on an
   endpoint.</t>
</abstract>


</front>


  <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-mud-tls-05" />

  <format type="TXT" target="https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-05" />

</reference>

<reference anchor="I-D.draft-lear-opsawg-mud-bw-profile-01">
  <front>
    <title>Bandwidth Profiling Extensions for MUD</title>


    <author initials="E" surname="Lear" fullname="Eliot Lear">
          <organization />

</author>


    <author initials="O" surname="Friel" fullname="Owen Friel">
          <organization />

</author>



    <date month="July" day="8" year="2019" />


    <abstract>      <t>Manufacturer Usage Descriptions (MUD) are a means by which devices can establish expectations about how they are intended to behave, and how the network should treat them. Earlier work focused on access control. This draft specifies a means by which manufacturers can express to deployments what form of bandwidth profile devices are expected to have with respect to specific services.</t>
</abstract>


</front>


  <seriesInfo name="Internet-Draft" value="draft-lear-opsawg-mud-bw-profile-01" />

  <format type="TXT" target="https://datatracker.ietf.org/doc/html/draft-lear-opsawg-mud-bw-profile-01" />

</reference>

<!-- ![:include:](I-D.meyer-xmpp-e2e-encryption)

![:include:](I-D.ietf-xmpp-3920bis) -->

  </references>


</back>
</rfc>

