<?xml version='1.0' encoding='utf-8'?>
<!--
    DOCTYPE processing

To use this XML template, the rfc2629.dtd from the xml2rfc distribution should
be in the local directory. The xml2rfc distribution is available from
http://xml.resource.org/

 The ENTITY clauses create an include of the named XML files, which
contains references written in xml2rfc format.

 XML2RFC offers an include feature described in the XML2RFC README
  file.  That syntax, however, contradicts the DTD requirements to
  have <reference> elements within the <references> element, so an
  XML parser is likely to find your XML file invalid.  It may be
  possible that XML2RFC will change their DTD so that the XML file
  remains valid when their style of include is used.
-->
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!-- Document  section

Specify the category attribute per RFC2026
options are info, std, bcp, or exp.

docname is the name of the output document. This is optional;
the default is to use the base portion of the XML filename.

For Internet-drafts, indicate which intellectual property notice
to use per the rules of RFC3978. The value (as of this template) can be:
    trust200902 -
    noModificationTrust200902 -
    noDerivativesTrust200902 -
    pre5378Trust200902 -

 The Intellectual Property section will be generated automatically by
  XML2RFC, based on the ipr attribute in the rfc element.

If this document obsoletes an RFC, specify the RFC in the "obsoletes" attribute
If this document updates an RFC, specify the RFC in the "updates" attribute
--> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent"
     category="info" docName="draft-moriarty-caris2-04" number="8953"
     ipr="trust200902" sortRefs="true" symRefs="true" tocInclude="true"
     xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 2.22.3 -->

  <front>
    <title abbrev="CARIS2 Report">Coordinating Attack Response at Internet
    Scale 2 (CARIS2) Workshop Report</title>
    <seriesInfo name="Internet-Draft" value="draft-moriarty-caris2-04"/> name="RFC" value="8953"/>
    <author fullname="Kathleen M M. Moriarty" initials="K" surname="Moriarty">
      <organization>Dell Technologies</organization>

<organization>Center for Internet Security
</organization>
      <address>
        <postal>
          <street>176 South Street</street>
          <city>Hopkinton</city>
          <region>MA</region>
          <code>01748</code>
          <street>31 Tech Valley Drive</street>
          <city>East Greenbush</city>
          <region>NY</region>
          <code>12061</code>
          <country>United States</country> States of America</country>
        </postal>
        <email>kathleen.moriarty.ietf@gmail.com</email>
      </address>

    </author>
    <date year="2020"/>
    <!-- IETF area is optional --> year="2020" month="December" />
    <area>Security</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>Network Management</keyword>
    <keyword>Attack Response</keyword>
    <keyword>CARIS</keyword>
    <keyword>Incident</keyword>
    <!--add additional keywords here for IETF website search engine -->
    <abstract>

      <t>The Coordinating Attack Response at Internet Scale (CARIS) 2
      workshop, sponsored by the Internet Society, took place on 28 February
      and 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned
      regional, national, international, and enterprise CSIRTs, Computer Security
      Incident Response Teams (CSIRTs), operators, service providers, network
      and security operators, transport operators and researchers, incident
      response researchers, vendors, and participants from standards
      communities. This workshop continued the work started at the first CARIS
      workshop, with a focus for CARIS 2 on scaling incident prevention and detection as
      the Internet industry moves to a stronger and a more ubiquitous
      deployment of session encryption.</t>
    </abstract>
  </front>
  <middle>
    <section>
      <!-- v2v3: Moved attribute title to <name/> -->
      <name>Introduction</name>
      <t>The Coordinating Attack Response at Internet Scale (CARIS) 2
      workshop <xref target="CARISEvent">workshop</xref>, target="CARISEvent"></xref>, sponsored by the
      Internet Society, took place on 28 February and 1
      March 2019 in Cambridge, Massachusetts, USA. Participants spanned
      regional, national, international, and enterprise Computer Security
      Incident Response Teams (CSIRT), (CSIRTs), operators,
      service providers, network and security operators, transport operators
      and researchers, incident response researchers, vendors, and
      participants from standards communities. This workshop continued the
      work started at the first CARIS workshop <xref target="RFC8073">RFC8073</xref>,
      target="RFC8073"></xref>, with a focus for CARIS 2 on scaling
      incident prevention and detection as the Internet industry moves to
      a stronger and a more ubiquitous deployment of session encryption.

      Considering the related initiative to form a research group (Stopping
      Malware and Researching Threats <xref target="SMART">SMART</xref> target="SMART"></xref>) in the
      Internet Research Task Force (IRTF) (IRTF), the focus on prevention included
      consideration of research opportunities to improve protocols and
      determine if there are ways to improve attack detection
      devleoped during
      the protocol design phase that could later influence protocol
      development in the IETF. This is one way to think about scaling
      response, through prevention and allowing for new methods to evolve for
      detection in a post-encrypted world.

Although the proposed SMART Research Group has not yet progressed, the work to better
scale incident response continues through the projects proposed at CARIS2 as
well as in future CARIS workshops.</t>
    </section>

    <section>
      <!-- v2v3: Moved attribute title to <name/> -->
      <name>Accepted Papers</name>
      <t>Researchers from around the world submitted position and research
      papers summarizing key aspects of their work to help form the shared
      content of the workshop.

The accepted papers may be found at <xref target="CARISEvent">workshop</xref>,
      target="CARISEvent"></xref> and include:</t>
      <!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/> split. -->
      <ul empty="true" spacing="normal">
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Visualizing
        <li><t>Visualizing Security Automation: Takeshi Takahashi, <contact fullname="Takeshi
        Takahashi"/>, NICT,
          Japan</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Automating Japan</t></li>
        <li><t>Automating Severity Determination: Hideaki Kanehara, <contact fullname="Hideaki
        Kanehara"/>, NICT,
          Japan</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>OASIS's OpenC2, Japan</t></li>
        <li><t>OASIS's OpenC2: Draper and DoD</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Automated DoD</t></li>
        <li><t>Automated IoT Security (PASC and PAVA): Oscar Garcia-Morchon and
          Thorsten Dahm</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Taxonomies Security: <contact fullname="Oscar Garcia-Morchon"/> and
          <contact fullname="Thorsten Dahm"/></t></li>
        <li><t>Taxonomies and Gaps: Kirsty P., <contact fullname="Kirsty P."/>, UK NCSC</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>FIRST: Thomas Schreck, Siemens</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>NetSecWarriors: Tim April, Akamai</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Measured NCSC</t></li>
        <li><t>FIRST: <contact fullname="Thomas Schreck"/>, Siemens</t></li>
        <li><t>NetSecWarriors: <contact fullname="Tim April"/>, Akamai</t></li>
        <li><t>Measured Approaches to IPv6 Address Anonymization and Identity
        Association: Dave Plonka and Arthur Berger, Akamai</li> <contact fullname="Dave Plonka"/> and <contact
        fullname="Arthur Berger"/>, Akamai</t></li>
      </ul>
      <t>The program committee worked to fill in the agenda with meaningful
      and complementary sessions to round out the theme and encourage
      collaboration to advance research towards toward the goals of the workshop.
      These sessions included:</t>
      <!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/> split. -->

      <ul empty="true" spacing="normal">
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>
          <xref target="RFC8520">Manufacturer
        <li><t> Manufacturer Usage Description
          (MUD)</xref>: Eliot Lear, Cisco</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>TF-CSIRT: Mirjam Kuhne, (MUD) <xref
        target="RFC8520"></xref>: <contact fullname="Eliot Lear"/>, Cisco</t></li>
        <li><t>TF-CSIRT: <contact fullname="Mirjam Kühne"/>, RIPE NCC</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>M2M NCC</t></li>
        <li><t>M2M Sharing Revolution, Scott Pinkerton, Revolution: <contact fullname="Scott Pinkerton"/>,
        DoE ANL</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Comparing ANL</t></li>
        <li><t>Comparing OpenC2 with existing efforts, e.g. e.g., <xref
        target="I2NSF">I2NSF</xref>: Chris
          Inacio</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Alternate <contact fullname="Chris Inacio"/></t></li>
        <li><t>Alternate Sharing and Mitigation Models: Kathleen Moriarty,
          DellEMC</li> <contact
        fullname="Kathleen Moriarty"/>, Dell EMC</t></li>
      </ul>
      <t>The presentations provided interesting background to familiarize
      workshop attendees with current research work, challenges that require
      addressing must be
      addressed for forward progress, and opportunities to collaborate in the
      desire to better scale attack response and prevention.</t>
    </section>
    <section>
      <!-- v2v3: Moved attribute title to <name/> -->
      <name>CARIS2 Goals</name>
      <t>The goal of each CARIS workshop has been to focus on the challenge of
 improving the overall security posture.  The approach has been to
 identify intrinsic or built-in protection capabilities for improved defense,
 automation, and scaling attack response through collaboration and
 improved architectural patterns.

It has been assumed that it is
 unlikely that additional training will likely not address the lack
of information security professionals to fill the job gap.  Currently, there
is approximately a <xref target="defecit">3 million person target="deficit">three-million-person deficit</xref>
for security professionals worldwide worldwide, and it's that is only expected to grow. In
preparing for the workshop, the chair and programme program committee considered that
this gap cannot be filled through training, training but the
   gap requires measures to reduce the
number of information security professionals needed through new architectures
and research towards toward attack prevention. CARIS 2 CARIS2 was specifically focused on the
industry shift towards toward the increased use of stronger session encryption (<xref
target="RFC8446">TLSv1.3</xref>, <xref
target="I-D.ietf-quic-transport">QUIC</xref>, <xref target="RFC8548">TCPcrypt</xref>,
target="RFC8548">tcpcrypt</xref>, etc.) and how prevention and detection can
advance in this new paradigm. As such such, the goals for this workshop
included:</t>
      <!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/> split. -->
      <ul spacing="normal">
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Scale
        <li><t>Scale attack response, including ways to improve prevention, as
          the Internet shifts to use of stronger and more ubiquitous
          encryption.</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>
          <!-- v2v3: Replaced <list style="symbols"/> with <ul/> -->
          encryption.</t>
          <ul spacing="normal">
            <!-- v2v3: Replaced <t/> with <li/> -->
            <li>Determine research opportunities</li>
            <!-- v2v3: Replaced <t/> with <li/> -->

            <li>Consider methods to improve protocols/provide protocols and provide guidance
            toward goal. For instance, are there ways to build detection of
            threats into protocols protocols, since they cannot be monitored on the wire
            in the future?</li>
          </ul>
        </li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Identify promising research ideas to seed a research agenda to
          input to the proposed IRTF SMART research group.</li> Research Group.</li>
      </ul>
    </section>
    <section>
      <!-- v2v3: Moved attribute title to <name/> -->
      <name>Workshop Collaboration</name>
      <t>Both CARIS workshops brought together a set of individuals who had
   not previously collaborated toward the goals of scaling attack
   response.

 This is important as the participants span various areas of Internet
 technology work, conduct research, provide a global perspective, have access
 to varying data sets and infrastructure, and are influential in their area of
 expertise.

The specific goals of the CARIS 2 workshop, goals, contributions, and the participants of the CARIS2 workshop
were all considered in the design of the breakout sessions to both identify
and advance research through collaboration.

The breakout sessions varied in format to keep attendees engaged and
      collaborating, involving
collaborating; some involved the full set of attendees and breakout
      groups.</t>
      <t>The Workshop while others utilized
groups.
</t>

      <t>
   The workshop focused in trying to help identify on identifying potential areas for collaboration and advance research.  To do this, the workshop
      included 5 different breakout sessions focused on:</t>
   advancing research.
</t>

      <ol spacing="normal"> spacing="normal" type="1">
      <li>Standardization and adoption: Adoption: identify widely adopted and pervasive
      standard protocols and data formats as well as those that failed. </li>
      <li>Preventative Protocols and Scaling Defense: identify protocols to
      address automation at scale.</li>
      <li>Incident Response Coordination: brainstorm on what potential areas
      of research or future workshops could be held to improve on the
      scalability of incident response.</li>
      <li>Monitoring and Measurement:brainstorm on Measurement: brainstorm methods to perform
      monitoring and measurement with the heightened need and requirement to
      address privacy.</li>
      <li>Taxonomy and Gaps: brainstorm on away a way forward for the proposed SMART group</li>
      Research Group.</li>
      </ol>

      <section>
        <!-- v2v3: Moved attribute title to <name/> -->

      <section anchor="breakout_1">
        <name>Breakout 1 Results: Standardization and Adoption</name>
        <t>This breakout session considered points raised in the preceding
        talks on hurdles for automating security controls, detection, and response as
        response; the teams presenting noted several challenges they still
        face today. The breakout session worked toward identifying standard protocols
        and data formats that succeeded in achieving adoption as well as
        several that failed or only achieved limited adoption. The results
        from the evaluation were interesting and could aid in achieving
        greater adoption when new work areas are developed.  The results follow:</t> following
	subsections detail the results.
        </t>
        <section>

        <name>Wide adoption:</name>
        <t>Secure Sockets Layer (SSL), now replaced by Adoption</name>
        <t>
   The Transport Layer Security (TLS) protocol has replaced the Secure Sockets
   Layer (SSL) protocol.</t>
        <t>Observations: There was a clear need for session encryption at the
        transport layer to protect application data. eCommerce E-commerce was a driving
        force at the time with a downside to those who did not adopt. Other
        positive attributes that aided adoption were modular design, clean
        interfaces, and being first to market.</t>

        <t>Simple

        <t>The Simple Network Management Protocol (SNMP) enables configuration
        management of devices with extension points for private configuration
        and management settings. SNMP is widely adopted and is only now now, after
        decades
        decades, being replaced by a newer alternative, YANG (a data modeling
	language) facilitating that facilitates configuration management via NETCONF the Network
	Configuration Protocol (NETCONF) or RESTCONF.
         The SNMP protocol facilitated an
        answer to a needed problem set: configuration, telemetry, and network
        management. It's Its development considered the connection between the
        user, vendor, and developers. Challenges did surface for adoption from
        SNMPv1.1 to 1.2, as there was no compelling reason for adoption. SNMPv3
        gained adoption due to its resilience to attacks by providing
        protection through improved authentication and encryption.</t>

        <t>IP Flow Information Export (IPFix) (IPFIX) was identified as achieving wide
        adoption for several reasons. The low cost of entry, wide vendor
        support, diverse user base, and the wide set of use cases spanning
        multiple technology areas were some of the key drivers cited.</t>
        <t>X.509 was explored for its success in gaining adoption. The
        solution being abstract from crypto, open, customizable, and
        extensible were some of the reasons cited for its successful adoption.
        The team deemed it a good solution to a good problem and observed that
        government adoption aided its success.</t>
        </section>

        <section>
        <name>Limited Adoption</name>
        <t>Next
        <t>Next, each team evaluated solutions that have not enjoyed wide
        adoption.</t>
        <t>Although STIX Structured Threat Information eXpression (STIX) and IODEF
	the Incident Object Description Exchange Format (IODEF) are somewhat similar in their goals, the
        standards were selected for evaluation by two separate groups with
        some common findings.</t>
        <t><strong>Structured Threat Information eXpression (STIX)</strong>
        <t>STIX
	has had limited adoption by the financial sector, sector but no
        single, definitive end user. The standard is still in development with
        the US government as the primary developer in partnership with OASIS.
        There is interest in using STIX to manage content, but users don't
        really care about what technology is used for the exchange. The
        initial goals may not wind up matching the end result for STIX STIX, as
        managing content may be the primary use case.</t>

        <t>Incident Object Description Exchange Format (IODEF)

        <t>IODEF was specified
        by national research National Research and education networks (NREN) Education Networks (NRENs) and computer security incident response teams (CSIRT) Computer
	Security Incident Response Teams (CSIRTs) and formalized in the IETF.
	IETF <xref target="RFC7970"/>. The user is the
        security operations center (SOC). While there are several
        implementations, it is not widely adopted. In terms of exchange, users
        are more interested in indicators than full event information information, and this
        applies to STIX as well. Sharing and trust are additional hurdles as
        many are not willing to disclose information.</t>

        <t>DNS-based

        <t>DNS-Based Authentication of Named Entities (DANE) has DNSsec DNSSEC as a
        dependency, which is a hurdle towards toward adoption (too many
        dependencies). It has a roll-your-own adoption model, which is risky.
        While there are some large pockets of adoption, there is still much
        work to do to gain widespread adoption. A regulatory requirement gave
        rise to partial adoption in Germany, which naturally resulted in
        production of documentation written in German - -- possibly giving rise
        to further adoption in German-speaking countries. There has also been
        progress made in the Netherlands through the creation of a website,
        internet.nl. website:
        <eref target="internet.nl" brackets="angle"/>. The website allows you you to test your website for a
        number of standards (IPv6, DNSSEC, DANE DANE, etc.). Internet.nl <eref
	target="internet.nl" brackets="angle"/> is a
        collaboration of industry organizations, companies, and the government
        in the Netherlands, Netherlands and is available for worldwide use.</t>

        <t>IP version 6 (IPv6) has struggled struggled, and the expense of running a dual
        stack was one of the highest concerns on the list discussed in the
	workshop breakout. The end user for IPv6 is
        everyone
        everyone, and the breakout team considered it too ambiguous. Too many new requirements have been added
        over its 20 year 20-year life. The scope of necessary adoption is large with
        many peripheral devices. Government requirements for support have
        helped somewhat with improved interoperability and adoption, but
        features like NAT being added to IPv4 slowed adoption. With no new
        features being added to IPv4 and lessons learned, there's still a
        possibility for success.</t>
        </section>
      </section>

      <section>
        <!-- v2v3: Moved attribute title to <name/> -->
        <name>Breakout 2 Results:Preventative Results: Preventative Protocols and Scaling Defense</name>
        <t>This next breakout session followed the sessions on MUD, PAVA (Protocol Protocol for
        Automated Vulnerability Assessment), Assessment (PAVA), and PASC (Protocol Protocol for Automatic
        Security Configuration) Configuration (PASC), which have themes of automation at scale. MUD
        was designed for IoT Internet of Things (IoT), and as such, scaling was a major consideration.
        The PAVA and PASC work builds off of MUD and maintains some of the
        same themes. This next breakout session was focused on groups brainstorming on
        preventative measures and enabling vendors to deploy mitigations.</t>

        <t>One group dove a bit deeper into MUD and layer 2 (L2) discovery.
        MUD changes sets of filtering control
        management to the vendor or intermediary MUD vendors for a predictable
        platform that scales well.  While the overall value of MUD is clear, the
        use of MUD and what traffic is expected for a particular device should be considered
        sensitive information information, as it could be used to exploit a device. MUD has
        an option of using L2 discovery to share MUD files. L2 discovery, like
        the dynamic host configuration protocol (DHCP) Dynamic Host Configuration Protocol (DHCP), is not encrypted from
        the local client to the DHCP server at this point in time (there is
        some interest to correct this, but it hasn't received enough support
        yet). As a result, it is possible to leak information and reveal data
        about the devices for which the MUD files would be applied. This could
        multicast out information such as network characteristics, firmware
        versions, manufacturer, manufacturers, etc.

There was some discussion on the use of 802.11 to improve connections. connections <xref
target="IEEE802.11"/>. Several participants from this group
        planned plan to research
this further and identify options to prevent information leakage while
achieving the stated goals of MUD.</t>

        <t>The next group discussed a proposal one of the participants had
        already begun developing, namely privacy for rendezvous service. The
        basic idea was to encrypt SNI Server Name Indication (SNI) using DNS to obtain public keys. The
        suffix on server IPv6 would be unique to a TLS session (Information (information
        missing). The discussion on this proposal was fruitful fruitful, as the full set
        of attendees engaged, with special interest from the incident
        responders to be involved in early review cycles. Incident responders
        are very interested to understand how protocols will change and to
        assess the overall impact of changes on privacy and security
        operations. Even if there are no changes to the protocol proposals
        stemming from this review, the group discussion landed on this being a
        valuable exchange to understand early the impacts of changes for
        incident detection and mitigation, to devise new strategies strategies, and to
        provide assessments on the impact of protocol changes on security in
        the round.</t>

        <t>The

<t>
 The third group reported back on trust exchanges relying heavily on
 relationships between individuals.  They were concerned with scaling the
 trust model and finding ways to do that better.  The third breakout group dove deeper into
 this topic.</t> topic.

</t>

        <t>The fourth breakout group discussed useful data for incident
        responders. This built on the first breakout session. session (<xref target="breakout_1"/>). The group
        determined that indicators of compromise (IOCs) (IoCs) are what most
        organizations and groups are able to successfully exchange. Ideally,
        these would be fixed and programmable. They discussed developing a
        richer event threat format for sharing format. event threats. When reporting back to the group,
        a successful solution used in the EU was mentioned, mentioned: the <xref
	target="MISP">Malware
	Information Sharing Platform (MISP)</xref>. This
        will be considered in their the review of existing efforts to determine if
        anything new is needed.</t>
      </section>
      <section>
        <!-- v2v3: Moved attribute title to <name/> -->
        <name>Breakout 3 Results: Incident Response Coordination</name>
        <t>Incident response coordination currently does not scale. This
        breakout session focused on brainstorming on incident response and
        coordination, looking specifically at what works well for teams today,
        what is holding them back, and what risks loom ahead. Output from this
        session could be used to generate research and to dive deeper in a
        dedicated workshop on these topics.</t>

        <t>Supporting:</t>
        <!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/> split. -->
        <ul spacing="normal">
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Trust between individuals in incident response teams</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Volume of strong signals and automated discovery</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Need to protect network as a forcing function</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Law and legal catalyst, motivator to stay on top</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Current efforts supported by profit and company interests, but
            those may shift</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Fear initially results in activity or in terms of the diagram
	  used, a burst of wind, but eventually leads to complacency</li>
        </ul>
        <t>Creating Drag:</t>
        <!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/> split. -->
        <t>What creates drag:</t>
        <ul spacing="normal">
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Lack of clear KPIs</li>
          <!-- v2v3: Replaced <t/> with <li/> --> Key Performance Indicators (KPIs)</li>
          <li>Too many standards</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Regional border

          <li>Potential for regional borders to impact data flows</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Ease of use for end users</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Speed to market without security considerations</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Legal framework slow to adapt</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Disconnect in actual/perceived risk</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Regulatory requirements preventing data sharing</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Lack of clarity in shared information</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Behind the problem/reactionary</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Lack of resources/participation</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Monoculture narrows focus</li>
        </ul>
        <t>Looming problems:</t>
        <!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/> split. -->
        <ul spacing="normal">
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Dynamic threat landscape</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Liability</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Vocabulary collision</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Lack of target/adversary clarity</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Bifurcation of Internet</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Government regulation</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Confusion around metrics</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Sensitivity of intelligence (trust)</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Lack of skilled analysts</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Lack of "fraud loss" data sharing</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Stakeholder/leader confusion</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Unknown impact of emerging technologies</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Over-centralization
          <li>Overcentralization of the Internet</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>New technologies and protocols</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Changes in application layer application-layer configurations (e.g. (e.g., browser
            resolvers)</li>
        </ul>
      </section>
      <section>
        <!-- v2v3: Moved attribute title to <name/> -->
        <name>Breakout 4 Results: Monitoring and Measurement</name>

        <t>The fourth breakout session followed Dave Plonka's <contact fullname="Dave Plonka"/>'s talk on IPv6 aggregation
        to provide privacy for IPv6 sessions. Essentially, IPv6 provides
        additional capabilities for monitoring sessions end-to-end. end to end. Dave and
        his co-author Arthur Berger coauthor, <contact fullname="Arthur Berger"/>, primarily focus on measurement research, research
        but found a way to aggregate sessions to assist with maintaining user
        privacy. If you can devise methods to perform management and
        measurement, or even perform security functions, while accommodating
        methods to protect privacy, a stronger result is likely. This also
        precludes the need for additional privacy improvement work to defeat
        measurement objectives.</t>
        <t>This breakout session was focused on devising methods to perform monitoring
        and measurement, coupled with advancing privacy considerations. The
        full group listed out options for protocols to explore and ranked
        them, with the 4 four highest then explored by the breakout groups. Groups
        agreed to work further on the proposed ideas.</t>

        <section>
        <name>IP Address Reputation</name>

        <t>There is a need to understand address assignment and configuration
        for hosts and services, especially with IPv6 <xref
	target="PlonkaBergerCARIS2"/> in (1) sharing IP address-related IP-address-related
        information to inform attack response efforts, efforts while still protecting
        the privacy of victims and possible attackers, attackers and (2) mitigating
        abuse by altering the treatment, e.g., dropping or rate-limiting, of
        packets. Currently, there is no database for that analysts and researchers
        can consult to, for instance, determine to the lifetimes of IPv6 addresses
        or the prefix length at which the address is expected to be stable
        over time. The researchers propose either introduce introducing a new database (compare
        PeerdingDB)
        PeeringDB) or extending existing databases (e.g., the RIRs'), regional
	Internet registries (RIRs)) to
        contain such information and allowing arbitrary queries. The prefix
        information would either be provided by networks, who networks that are willing, willing or
        based on measurement algorithms that reverse-engineer reasonable
        values based on Internet measurements <xref
	target="PlonkaBergerKIP"/>.

In the former case, the incentive of networks to provide such information is
to so ensure that privacy of their users is respected and to limit collateral
damage caused by access control lists affecting more of that network's
addresses than necessary, e.g., in the face of abuse.

This is an early idea, idea; <contact
fullname="Dave Plonka"/> is the lead
        to contact if
for those interested in helping to help develop this further is Dave
        Plonka.</t> further.</t>
        </section>

        <section>
        <name>Server Name Authentication Reputation C (SNARC)</name>
        <t>SNARC is a mechanism to
	assign value to trust indicators, used to
        make decisions about good or bad actors.

The mechanism would be able to distinguish between client and server in connections,
connections and would be human readable, readable. In addition, it builds on zero trust networking,
networking and avoids
        consolidation consolidation, thus supporting legitimate new players. The group planned to
        research visual aspects and underlying principles as they begin work
        on this idea.

SNARC has a similar theme to the IP reputation/BGP ranking idea mentioned
above. An

SNARC is not currently defined by an RFC; however, such an RFC would help
customers and design
        team teams on existing solutions. They planned

The group plans to research visual aspects and underlying principles as they
begin work in several
        stages, on this idea.  They plan to begin work in several stages,
researching "trust" indicators, "trust" value calculations, and research
actions to apply to "trust".

The overarching goal is to address blind trust, one of the challenges
identified with information/incident exchanges. If interested to work further with
        this team, <contact fullname="Trent
Adams"/> is the lead contact is: Trent Adams.</t> for those interested in working with this
team.</t>
        </section>

        <section>
        <name>Logging</name>
        <t>The breakout group presented the possibility of injecting logging
        capabilities at compile time for applications, resulting in a more
        consistent set of logs, covering an agreed set of conditions. If the Using
        a log-injecting compiler were used this would increase logging for those
        applications and improve the uniformity of logged activity. Increasing
        logging capabilities at the endpoint is necessary as the shift towards toward
        increased use of encrypted transport continues. The <contact fullname="Nalini
        Elkins"/> is the lead for contact
        if for those interested to develop
        in developing this further is Nalini Elkins.</t> further.</t>
        </section>

        <section>
        <name>Fingerprinting</name>
        <t>Fingerprinting has been used for numerous applications on the web, Web,
        including security, and will become of increasing importance with the
        deployment of stronger encryption. This Fingerprinting provides a method to
        identify traffic without using decryption. The group discussed privacy
        considerations and balancing how you achieve the security benefits
        (identifying malicious traffic, information leakage, threat
        indicators, etc.). They are interested to derive in deriving methods to validate
        the authenticity without identifying the source of traffic. They are
        also concerned with scaling issues. If interested to work further with
        this team, <contact fullname="William
        Weinstein"/> is the lead contact is: William Weinstein.</t> for those interested in working
        with this team.</t>
        </section>
      </section>
      <section>
        <!-- v2v3: Moved attribute title to <name/> -->

        <name>Taxonomy and Gaps Session</name>
        <t>At the start of the second day 2, Kirsty Paine and Mirjam Kuhne of the workshop, <contact
        fullname="Kirsty Paine"/> and <contact fullname="Mirjam Kühne"/>
        prepared and (and Kirsty led led) a workshop style workshop-style session to discuss
        taxonomies used in incident response, attacks, and threat detection,
        comparing solutions and identifying gaps.

  The primary objective was to determine a path forward by selecting the
  language to be used in the proposed SMART group. Research Group.

 Several taxonomies were presented for review and discussion. The topic
 remains open, but the following key points were highlighted by
 participants:</t>
        <!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/> split. -->
        <ul spacing="normal">
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>A single taxonomy might not be the way to go, because which
            taxonomy you use depends on what problem you are trying to solve;
            e.g. solve,
            e.g., attribution of the attack, mitigation steps, technical
            features
            features, or organizational impact measurements.</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>A tool to map between taxonomies should be automated automated, as there
            are requirements within groups or nations to use specific
            taxonomies.</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>The level of detail needed for reporting to management and for
            the analyst investigating the incident can be very different. At
            the workshop, one attendee mentioned that that, for management reporting reporting,
            they only use 8 categories to lighten the load on analysts,
            whereas some of the taxonomies contain 52 categories.</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>How you plan to use the taxonomy matters and may vary between
            use cases. Take Take, for instance instance, sharing data with external entities
            versus internal only. The taxonomy selected depends on what you
            plan to do with it. Some stated a need for attribute-based dynamic
            anthologies as opposed to rigid taxonomies used by others. A rigid
            taxonomy did not work for many from feedback in the session.</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li><xref target="RFC4949">RFC4949</xref> target="RFC4949"></xref> was briefly discussed as a possibility, however possibility; however, there
            is a clear need to update terminology in this publication around
            this space in particular. This is likely to be raised in SAAG the Security
	    Area Advisory Group (SAAG) during the open mic, mic session,
            hopefully with proposed new definitions to demonstrate the issue
            and evolution of terms over time.</li>
          <!-- v2v3: Replaced <t/> with <li/> -->
          <li>Within

<li>
  Within a taxonomy, prioritization matters to understand the impact of
  threats or an attack.  How do you map that between differing taxonomies? (problem
  What is the problem to be solved; possible solved, and what tooling
            required)</li>
          <!-- v2v3: Replaced <t/> with <li/> --> is required?

</li>

      <li>Attack attribution had varying degrees of interest.

Some felt the public sector cared more about attribution; attribution, not about
            individuals, but the
individuals.  They were interested in possible motivations behind an attack
and
            likely determining if there were other likely victims based on these motivations.

Understanding if the source was an individual actor, organized crime, or a
nation state mattered.</li> mattered.
	  </li>

        </ul>
        <t>The result of this discussion was not to narrow down to one
        taxonomy,
        taxonomy but to think about mappings between taxonomies and the use
        cases for exchanging or sharing information, eventually giving rise to
        a common method to discuss threats and attacks. Researchers need a
        common vocabulary, not necessarily a common taxonomy.</t>
      </section>
    </section>

    <section>
      <!-- v2v3: Moved attribute title to <name/> -->
      <name>Next Steps</name>
      <t>The next steps from the CARIS2 workshop are twofold. </t>
      <ul spacing="normal"> twofold:</t>
      <ol spacing="normal" type="1">
      <li>The research
      initiatives spawned from the second CARIS workshop require further exploration
      and development. Fostering this development and creating communities
      around each proposed project is the first step, with reports back out to
      the SMART mailing list.</li>
      <li>The second initiative will be planning for the next CARIS workshop.
      </li>
      </ul>
      </ol>
    </section>
    <section>
      <!-- v2v3: Moved attribute title to <name/> -->
      <name>Summary</name>
      <t>Wrapping
      <t>When wrapping up the workshop, we reviewed the list of agreed projects to
      get a feel for actual interest as a follow up. Through the course of the
      2-day
      two-day workshop, a larger set of potential research items had
      been generated, and this gave participants a chance to reassess commitments to
      better have them match expected outcomes. The highest ranking projects in
      terms of interest to drive the ideas forward included the following:</t>
      <!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/> split. -->

      <ul spacing="normal">
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Traffic fingerprinting</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>SNARC</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Attack coordination solutions/automated solutions and automated security</li>
        <!-- v2v3: Replaced <t/> with <li/> -->
        <li>Cryptographic Rendezvous</li>
        <!-- v2v3: Replaced <t/> with <li/> --> rendezvous</li>
        <li>L2 discovery</li>
      </ul>
    </section>
    <section>
      <!-- v2v3: Moved attribute title to <name/> -->
      <name>Security Considerations</name>
      <t>There are no security considerations considerations, as this is an informational
      workshop summary report.</t>
    </section>
    <section>
      <!-- v2v3: Moved attribute title to <name/> -->
      <name>IANA Considerations</name>
      <t>This memo includes document has no request to IANA.</t>
    </section>
    <section>
      <!-- v2v3: Moved attribute title to <name/> -->
      <name>Acknowledgements</name>
      <t>Thank you to each of the CARIS2 participants who brought their ideas,
      energy and willingness to collaborate to advance attack response at
      Internet scale.</t>
      <t>A big thank you to each member of the program committee for your
      review of program materials, papers, and guidance on the workshop
      format: Mat Ford, Internet Society, UK, Jamie Gillespie, APNIC, AU,
      Chris Inacio, CERT/CC, US, Mirja Kuhlewind, ETH Zurich, CH, Mirjam
      Kuhne, RIPE NCC, NL, Carlos Martinez, LACNIC, UY, Kathleen M. Moriarty,
      Dell EMC (Chair), Kirsty Paine, NCSC, UK, and Takeshi Takahashi, NICT,
      JP.</t>
      <t>Thank you to Megan Hyland, DellEMC, for her review and guidance on
      the breakout session format and tools to enable successful
      collaboration.</t>
      <t>Thank you to the minute takers, Akashaya Khare and Thinh Nguyen,
      DellEMC OCTO Cambridge Dojo team.</t> IANA actions.</t>
    </section>
  </middle>
  <back>
 <!-- References Section -->

    <displayreference target="I-D.ietf-quic-transport" to="QUIC"/>
    <references>
      <name>References</name>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8073.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7970.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8548.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-quic-transport.xml"/>
      </references>

      <references>
        <name>URL References</name> href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-quic-transport.xml"/>

        <reference anchor="CARISEvent"> anchor="CARISEvent" target="https://www.internetsociety.org/events/caris2">
          <front>
            <title>CARIS Event Information and Accepted Papers
          https://www.internetsociety.org/events/caris2</title>
            <title>CARIS2: Coordinating Attack Response at Internet Scale</title>
            <author>
              <organization>Internet Society</organization>
            </author>
            <date month="February" year="2019"/>
          </front>
        </reference>

        <reference anchor="I2NSF"> anchor="I2NSF" target="https://datatracker.ietf.org/wg/i2nsf/about">
          <front>
            <title>Interface to Network Security Functions (i2nsf)
          https://datatracker.ietf.org/wg/i2nsf/about</title> (i2nsf)</title>
            <author>
              <organization>IETF</organization>
            </author>
            </front>
        </reference>

        <reference anchor="defecit"> anchor="deficit" target="https://cybersecurityventures.com/jobs/">
          <front>
            <title>Cybersecurity Talent Crunch To Create 3.5 Million Unfilled Jobs Globally By 2021
          https://cybersecurityventures.com/jobs/</title> 2021</title>
            <author fullname="Steve Morgan">
              <organization>Cybercrime Magazine</organization>
            </author>
	    <date month="October" year="2019"/>
          </front>
        </reference>

    <reference anchor="MISP"> anchor="IEEE802.11" target="https://www.ieee802.org/11/">
          <front>
            <title>IEEE 802.11 WIRELESS LOCAL AREA NETWORKS</title>
            <author>
              <organization>IEEE</organization>
            </author>
          </front>
    </reference>

        <reference anchor="MISP" target="https://www.misp-project.org/">
          <front>
            <title>Malware Information Sharing Platform
          https://www.misp-project.org/</title> Platform</title>
            <author>
              <organization>MISP-project.org</organization>
              <organization>MISP</organization>
            </author>
            <date year="2019"/>
          </front>
        </reference>

        <reference anchor="SMART"> anchor="SMART" target="https://datatracker.ietf.org/group/smart/about/">
          <front>
            <title>Stopping Malware and Researching Threats
          https://datatracker.ietf.org/group/smart/about/</title> (smart)</title>
            <author>
              <organization>IRTF</organization>
            </author>
            <date year="2019"/>
          </front>
        </reference>

        <reference anchor="PlonkaBergerCARIS2"> anchor="PlonkaBergerCARIS2" target="https://www.internetsociety.org/events/caris2">
          <front>
            <title>CARIS2 Paper Submission,</title>
            <author>
            <title>Measured Approaches to IPv6 Address Anonymization and
            Identity Association</title>
            <author fullname="David Plonka">
              <organization>CARIS2</organization>
            </author>
            <author fullname="Arthur Berger">
              <organization>CARIS2</organization>
            </author>
            <date month="March" year="2019"/>
          </front>
<refcontent>CARIS2 Paper Submission</refcontent>
        </reference>

        <reference anchor="PlonkaBergerKIP"> anchor="PlonkaBergerKIP" target="https://arxiv.org/abs/1707.03900">
          <front>
            <title>kIP: a Measured Approach to IPv6 Address Anonymization
          https://arxiv.org/abs/1707.03900</title>
            <author>
              <organization>Arxiv</organization> Anonymization</title>
            <author fullname="David Plonka">
              <organization/>
            </author>
            <author fullname="Arthur Berger">
              <organization/>
            </author>
            <date month="July" year="2017"/>
          </front>

        </reference>
      </references>
    </references>
    <section numbered="false">
      <name>Acknowledgements</name>
      <t>Thank you to each of the CARIS2 workshop participants who brought their ideas,
      energy, and willingness to collaborate to advance attack response at
      Internet scale.</t>
      <t>A big thank you to each member of the program committee for your
      review of program materials, papers, and guidance on the workshop
      format: <contact fullname="Mat Ford"/> (Internet Society, UK); <contact
      fullname="Jamie Gillespie"/> (APNIC, AU);
      <contact fullname="Chris Inacio"/> (CERT/CC, US); <contact
      fullname="Mirja Kühlewind"/> (ETH Zurich, CH); <contact fullname="Mirjam
      Kühne"/> (RIPE NCC, NL); <contact fullname="Carlos Martinez"/> (LACNIC,
      UY); <contact fullname="Kathleen M. Moriarty"/>, Chair
      (Dell EMC); <contact fullname="Kirsty Paine"/> (NCSC, UK); and
      <contact fullname="Takeshi Takahashi"/> (NICT, JP).</t>
      <t>Thank you to <contact fullname="Megan Hyland"/> (Dell EMC) for her review and guidance on
      the format of breakout sessions and tools to enable successful
      collaboration.</t>
      <t>Thank you to the minute takers, <contact fullname="Akashaya Khare"/>
      and <contact fullname="Thinh Nguyen"/> (Dell EMC OCTO Cambridge Dojo team).</t>
    </section>
  </back>

</rfc>