RFC 8953

Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report

📅 published December 2020, from ietf

Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report 🎀

Okay bestie, so this is RFC 8953 💅 It's an Independent Submission written by K. Moriarty from the Center for Internet Security, dated December 2020, with ISSN 2070-1721. It's Category: Informational, so it's not a standards-track spec 🙈 The title block doesn't list anything it obsoletes or updates.

Abstract ✨

Okay so the Coordinating Attack Response at Internet Scale (CARIS) 2 workshop 🌸, sponsored by the Internet Society, went down on 28 February and 1 March 2019 in Cambridge, Massachusetts, USA. The crowd was giant: regional, national, international, and enterprise Computer Security Incident Response Teams (CSIRTs) 🦋, operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and people from standards communities. It picked up where the first CARIS workshop left off, and the focus was on scaling incident prevention and detection as the Internet industry moves to a stronger and more ubiquitous deployment of session encryption 🔐 It's giving big-picture energy, no cap 🔥

Status of This Memo 📜

This document is not an Internet Standards Track specification; it is published for informational purposes.

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8953.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents 🧚

   1.  Introduction
   2.  Accepted Papers
   3.  CARIS2 Goals
   4.  Workshop Collaboration
     4.1.  Breakout 1 Results: Standardization and Adoption
       4.1.1.  Wide Adoption
       4.1.2.  Limited Adoption
     4.2.  Breakout 2 Results: Preventative Protocols and Scaling
           Defense
     4.3.  Breakout 3 Results: Incident Response Coordination
     4.4.  Breakout 4 Results: Monitoring and Measurement
       4.4.1.  IP Address Reputation
       4.4.2.  Server Name Authentication Reputation C (SNARC)
       4.4.3.  Logging
       4.4.4.  Fingerprinting
     4.5.  Taxonomy and Gaps Session
   5.  Next Steps
   6.  Summary
   7.  Security Considerations
   8.  IANA Considerations
   9.  References
     9.1.  Informative References
   Acknowledgements
   Author's Address

1. Introduction 🦋

Okay so the CARIS 2 workshop [CARISEvent], sponsored by the Internet Society, happened on 28 February and 1 March 2019 in Cambridge, Massachusetts, USA. Everyone from regional, national, international, and enterprise Computer Security Incident Response Teams (CSIRTs), operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and standards folks showed up 🙌 This workshop continued the work from the first CARIS workshop [RFC8073], with a focus on scaling incident prevention and detection as the Internet industry moves to a stronger and more ubiquitous deployment of session encryption.

Now here's the spicy part 🌶️ The team was also thinking about the related initiative to form a research group, Stopping Malware and Researching Threats [SMART], in the Internet Research Task Force (IRTF). So the prevention side included looking at research opportunities to improve protocols, and figuring out whether there are ways to improve attack detection during the protocol design phase that could later influence protocol development in the IETF. That's one way to think about scaling response: prevention, plus letting new detection methods evolve in a post-encrypted world 👑 The proposed SMART Research Group hasn't progressed yet, but the work to better scale incident response keeps going through the projects proposed at CARIS2 and in future CARIS workshops ✨

2. Accepted Papers 📚

Researchers from around the world sent in position and research papers summarizing key aspects of their work, to help shape the shared content of the workshop. The accepted papers may be found at [CARISEvent] and include:

  • Visualizing Security Automation: Takeshi Takahashi, NICT, Japan
  • Automating Severity Determination: Hideaki Kanehara, NICT, Japan
  • OASIS's OpenC2: Draper and DoD
  • Automated IoT Security: Oscar Garcia-Morchon and Thorsten Dahm
  • Taxonomies and Gaps: Kirsty P., UK NCSC
  • FIRST: Thomas Schreck, Siemens
  • NetSecWarriors: Tim April, Akamai
  • Measured Approaches to IPv6 Address Anonymization and Identity Association: Dave Plonka and Arthur Berger, Akamai

The program committee worked to fill in the agenda with meaningful and complementary sessions 🗓️ to round out the theme and encourage collaboration toward advancing research on the goals of the workshop. These sessions included:

  • Manufacturer Usage Description (MUD) [RFC8520]: Eliot Lear, Cisco
  • TF-CSIRT: Mirjam Kühne, RIPE NCC
  • M2M Sharing Revolution: Scott Pinkerton, DoE ANL
  • Comparing OpenC2 with existing efforts, e.g., I2NSF [I2NSF]: Chris Inacio
  • Alternate Sharing and Mitigation Models: Kathleen Moriarty, Dell EMC

The presentations gave attendees useful background on current research work 🧠 along with the challenges that still need solving for forward progress, and chances to collaborate on better scaling attack response and prevention.

3. CARIS2 Goals 🎯

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 additional training will likely not address the lack of information security professionals to fill the job gap. Currently, there is approximately a three-million-person deficit [deficit] for security professionals worldwide, and that is only expected to grow 😭 In preparing for the workshop, the chair and program committee considered that this gap cannot be filled through training, but instead requires measures to reduce the number of information security professionals needed through new architectures and research toward attack prevention.

CARIS2 was specifically focused on the industry shift toward increased use of stronger session encryption (TLS 1.3 [RFC8446], QUIC [QUIC], tcpcrypt [RFC8548], etc.) and on how prevention and detection can advance in this new paradigm 🔐 So the goals for this workshop included:

  • Scale attack response, including ways to improve prevention, as the Internet shifts to use of stronger and more ubiquitous encryption.
    • Determine research opportunities
    • Consider methods to improve protocols and provide guidance toward goal. For instance, are there ways to build detection of threats into protocols, since they cannot be monitored on the wire in the future?
  • Identify promising research ideas to seed a research agenda to input to the proposed IRTF SMART Research Group.

4. Workshop Collaboration 🫶

Both CARIS workshops brought together a set of individuals who had not previously collaborated toward the goals of scaling attack response. That matters, because the participants span lots of areas of Internet technology work, conduct research, bring a global perspective, have access to different data sets and infrastructure, and are influential in their own areas of expertise 🌈 The specific goals, contributions, and participants of the CARIS2 workshop were all considered when designing the breakout sessions, so they could both identify and advance research through collaboration. The breakout sessions varied in format to keep attendees engaged and collaborating; some involved the full set of attendees while others used groups.

The workshop focused on identifying potential areas for collaboration and advancing research. The five breakout topics were:

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

4.1. Breakout 1 Results: Standardization and Adoption 🧁

Okay so this breakout session picked up on points raised in the earlier talks about the hurdles for automating security controls, detection, and response. The teams presenting noted several challenges they still face today 😤 The group worked toward identifying standard protocols and data formats that succeeded in achieving adoption, plus several that failed or only achieved limited adoption. The results from the evaluation were interesting and could help with greater adoption when new work areas are developed. The following subsections detail the results.

Stay tuned for the rest of the breakout results, bestie 🌈✨

4.1.1. Wide Adoption 🌸

Okay so bestie, TLS literally replaced SSL 💅

The team noticed there was a clear need for session encryption at the transport layer to protect application data 🔐. E-commerce was the driving force back then, and the downside was for anyone who didn't adopt 😬. Other things that helped adoption were modular design, clean interfaces, and being first to market 🏁.

SNMP lets you do configuration management on devices, with extension points for private configuration and management settings ⚙️. It is widely adopted, and after decades it's only now being replaced by a newer option, YANG (a data modeling language) 🦋. YANG makes configuration management work through the Network Configuration Protocol (NETCONF) or RESTCONF. SNMP answered a real need: configuration, telemetry, and network management 📊. Its development considered the connection between the user, vendor, and developers 🫶. Adoption did hit some bumps going from SNMPv1.1 to 1.2, because there was no compelling reason to switch 🙈. SNMPv3 gained adoption because it's more resilient to attacks, with improved authentication and encryption 🛡️.

IP Flow Information Export (IPFIX) was identified as achieving wide adoption for several reasons 🌈. The low cost of entry, wide vendor support, diverse user base, and wide set of use cases spanning multiple technology areas were some of the key drivers cited ✨.

X.509 was looked at because it was so successful at gaining adoption 👑. Being abstract from crypto, open, customizable, and extensible were some of the reasons cited for its success 💜. The team deemed it a good solution to a good problem, and they noticed that government adoption helped it succeed 🏛️.

4.1.2. Limited Adoption 🥀

Next, each team looked at solutions that have not enjoyed wide adoption 👀.

Structured Threat Information eXpression (STIX) and the Incident Object Description Exchange Format (IODEF) are kind of similar in their goals, but they were picked for evaluation by two separate groups, and they had some common findings 🤝.

STIX has had limited adoption by the financial sector, but there's no single, definitive end user 🏦. It's still in development, with the US government as the primary developer in partnership with OASIS 🇺🇸. People are interested in using STIX to manage content, but users don't really care what technology is used for the exchange 🤷‍♀️. The initial goals may not wind up matching the end result for STIX, since managing content may be the primary use case 📦.

IODEF was specified by National Research and Education Networks (NRENs) and Computer Security Incident Response Teams (CSIRTs), and it was formalized in the IETF [RFC7970] 📝. The user is the security operations center (SOC) 🖥️. There are several implementations, but it is not widely adopted 😔. When it comes to exchange, users are more interested in indicators than full event information, and this applies to STIX as well 🔍. Sharing and trust are extra hurdles, since many people are not willing to disclose information 🔒.

DNS-Based Authentication of Named Entities (DANE) has DNSSEC as a dependency, and that's a hurdle toward adoption (too many dependencies) 😵‍💫. It has a roll-your-own adoption model, which is risky 💀. There are some large pockets of adoption, but there's still a lot of work to do to get widespread adoption 🌱. A regulatory requirement led to partial adoption in Germany, which naturally resulted in documentation being written in German 🇩🇪. That might lead to further adoption in German-speaking countries 🗣️. Progress has also been made in the Netherlands through the creation of a website: <internet.nl> 🇳🇱. The website lets you test your website for a number of standards (IPv6, DNSSEC, DANE, etc.) 🧪. <internet.nl> is a collaboration of industry organizations, companies, and the government in the Netherlands, and it is available for worldwide use 🌍.

IP version 6 (IPv6) has struggled 😭. 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, and the breakout team considered that too ambiguous 🌀. Too many new requirements have been added over its 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 🌟.

4.2. Breakout 2 Results: Preventative Protocols and Scaling Defense 🛡️

This breakout session followed the sessions on MUD, Protocol for Automated Vulnerability Assessment (PAVA), and Protocol for Automatic Security Configuration (PASC), which have themes of automation at scale 🤖. MUD was designed for Internet of Things (IoT), so scaling was a major consideration 📈. The PAVA and PASC work builds off of MUD and keeps some of the same themes 🔁. This breakout session focused on groups brainstorming preventative measures and on enabling vendors to deploy mitigations 🧠.

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 📊. The overall value of MUD is clear, but the use of MUD and what traffic is expected for a particular device should be considered sensitive information, since 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), is not encrypted from the local client to the DHCP server at this point in time (there is some interest in correcting this, but it hasn't received enough support yet) 😤. As a result, it is possible to leak information and reveal data about the devices the MUD files would be applied to 🫣. This could multicast out information such as network characteristics, firmware versions, manufacturers, etc. 📡. There was some discussion on the use of 802.11 to improve connections [IEEE802.11] 📶. Several participants from this group plan to research this further and identify options to prevent information leakage while achieving the stated goals of MUD 🔬.

The next group discussed a proposal that one of the participants had already begun developing, namely privacy for rendezvous service 🎀. The basic idea was to encrypt Server Name Indication (SNI) using DNS to obtain public keys 🔑. The suffix on server IPv6 would be unique to a TLS session (information missing) 🧩. The discussion on this proposal was fruitful, since the full set of attendees engaged, with special interest from the incident responders in being involved in early review cycles 🙌. Incident responders are very interested in understanding how protocols will change and in assessing 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 decided this was a valuable exchange for understanding the impacts of changes early, for incident detection and mitigation, for devising new strategies, and for providing assessments of the impact of protocol changes on security in the round 💡.

The third group reported back on trust exchanges that rely heavily on relationships between individuals 🤝. They were concerned with scaling the trust model and with finding ways to do that better 📐. The group dove deeper into this topic 🤿.

The fourth group discussed useful data for incident responders 🚑. This built on the first breakout session (Section 4.1) 🔗. The group determined that indicators of compromise (IoCs) are what most organizations and groups are able to successfully exchange 🎯. Ideally, these would be fixed and programmable 🛠️. They discussed developing a richer format for sharing event threats 🌟. When reporting back to the group, a successful solution used in the EU was mentioned: the Malware Information Sharing Platform (MISP) [MISP] 🇪🇺. This will be considered in the review of existing efforts to determine whether anything new is needed 📋.

4.3. Breakout 3 Results: Incident Response Coordination 🚨

Incident response coordination currently does not scale 📉. This breakout session focused on brainstorming 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 📚.

Supporting:

  • Trust between individuals in incident response teams 🫶
  • Volume of strong signals and automated discovery 📡
  • Need to protect network as a forcing function 🏰
  • Law and legal catalyst, motivator to stay on top ⚖️
  • Current efforts supported by profit and company interests, but those may shift 💰
  • Fear initially results in activity or in terms of the diagram used, a burst of wind, but eventually leads to complacency 🌬️

What creates drag:

  • Lack of clear Key Performance Indicators (KPIs) 📉
  • Too many standards 😩
  • Potential for regional borders to impact data flows 🗺️
  • Ease of use for end users 🫠
  • Speed to market without security considerations 🏃‍♀️
  • Legal framework slow to adapt 🐌
  • Disconnect in actual/perceived risk 🙃
  • Regulatory requirements preventing data sharing 🚧
  • Lack of clarity in shared information 🌫️
  • Behind the problem/reactionary 😬
  • Lack of resources/participation 🫥
  • Monoculture narrows focus 🥱

Looming problems:

  • Dynamic threat landscape 🌪️
  • Liability 🧾
  • Vocabulary collision 💥
  • Lack of target/adversary clarity 🎭
  • Bifurcation of Internet 🌗
  • Government regulation 🏛️
  • Confusion around metrics 🤯
  • Sensitivity of intelligence (trust) 🔐
  • Lack of skilled analysts 🧑‍💻
  • Lack of "fraud loss" data sharing 💸
  • Stakeholder/leader confusion 🙈
  • Unknown impact of emerging technologies 👻
  • Overcentralization of the Internet 🕸️
  • New technologies and protocols 🧪
  • Changes in application-layer configurations (e.g., browser resolvers) 🌐

4.4. Breakout 4 Results: Monitoring and Measurement 📊

The fourth breakout session followed Dave Plonka's talk on IPv6 aggregation to provide privacy for IPv6 sessions 🎤. Essentially, IPv6 provides additional capabilities for monitoring sessions end to end 🔍. Dave and his coauthor, Arthur Berger, primarily focus on measurement research, but they found a way to aggregate sessions to help maintain 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 🙌.

This breakout session 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, and then the four highest were explored by the breakout groups 🏆. Groups agreed to work further on the proposed ideas 🫶✨.

4.4.1. IP Address Reputation 🌸

okay so bestie, we need to understand how hosts and services get their addresses and configs, especially with IPv6 [PlonkaBergerCARIS2] 🌐. There are two big reasons. First, sharing IP-address info helps with attack response while still protecting the privacy of victims and possible attackers 🔐. Second, it helps with abuse, since you can change how packets get treated, like dropping them or rate-limiting them 🚦. The tea is that there's currently no database analysts and researchers can check to find out things like how long IPv6 addresses last, or the prefix length where an address is expected to stay stable over time 🫣.

The researchers suggest either making a brand-new database (think something like PeeringDB 🗂️) or extending existing databases, like the regional Internet registries (RIRs), so they hold this info and let people run arbitrary queries 💅. The prefix info could come from networks that are willing to share it, or from measurement algorithms that reverse-engineer reasonable values from Internet measurements [PlonkaBergerKIP] 📊. For the first option, networks have a reason to share because it keeps their users' privacy respected and limits collateral damage. Without it, access control lists could hit way more of that network's addresses than necessary, especially during abuse situations 🙅‍♀️. This is an early idea, so if you want to help build it out, Dave Plonka is the lead contact 🧚.

4.4.2. Server Name Authentication Reputation C (SNARC) 💜

SNARC is a mechanism that gives value to trust indicators, and those values are used to decide who's good and who's bad 😤. It would be able to tell client and server connections apart, and it would be human readable 🙌. It also builds on zero trust networking and avoids consolidation, which means it's supportive of legit new players 🌱. SNARC has a similar vibe to the IP reputation/BGP ranking idea I just mentioned above 🔁. Right now SNARC isn't defined by any RFC, but one would really help customers and design teams that are working with existing solutions 📘.

The group plans to look into the visual side and the underlying principles as they start this work 👀. They'll do it in stages: researching "trust" indicators first, then "trust" value calculations, then research actions to apply to "trust" 🧠. The big goal is to tackle blind trust, which is one of the challenges that came up with information and incident exchanges 💀. Trent Adams is the lead contact if you want to work with this team ✨.

4.4.3. Logging 📝

The group brought up the idea of putting logging capabilities into applications at compile time 🛠️. The result would be a more consistent set of logs that cover an agreed set of conditions, which is so clean 🧹. A log-injecting compiler would bump up logging for those applications and make logged activity more uniform, and that's giving organization 🗃️. Endpoint logging also needs to go up, because encrypted transport use keeps growing 🔒. Nalini Elkins is the lead contact if you want to help develop this further 🫶.

4.4.4. Fingerprinting 🔍

Fingerprinting has been used for loads of stuff on the Web, including security, and it's only going to matter more as stronger encryption gets deployed 📈. The cool part is that fingerprinting lets you identify traffic without decrypting it 🕵️‍♀️. The group talked about privacy considerations too, and how to balance getting the security benefits (spotting malicious traffic, information leakage, threat indicators, and so on) with keeping privacy intact ⚖️. They want to find ways to validate authenticity without identifying the source of the traffic 🪪. They're also worried about scaling issues 😬. William Weinstein is the lead contact for anyone who wants to work with this team 💖.

4.5. Taxonomy and Gaps Session 🧁

At the start of day two, Kirsty Paine and Mirjam Kühne put together a workshop-style session (Kirsty led it) to talk about taxonomies used in incident response, attacks, and threat detection 🎀. They compared solutions and looked for gaps 🔎. The main goal was to pick a path forward by choosing the language for the proposed SMART Research Group 🗣️. A bunch of taxonomies were presented for review and discussion. The topic is still open, but participants highlighted these key points:

  • A single taxonomy might not be the way to go 🙃, because which taxonomy you use depends on the problem you're trying to solve, e.g., attribution of the attack, mitigation steps, technical features, or organizational impact measurements.
  • A tool to map between taxonomies should be automated 🤖, since groups or nations have requirements to use specific taxonomies.
  • The level of detail needed for management reporting and for the analyst investigating the incident can be super different 📊. At the workshop, one attendee said that for management reporting they only use 8 categories to lighten the load on analysts 🧘‍♀️, whereas some of the taxonomies have 52 categories 😵‍💫.
  • How you plan to use the taxonomy matters 🎯, and it can vary between use cases. Take sharing data with external entities versus internal only, for example. The taxonomy you pick depends on what you plan to do with it. Some people said they need attribute-based dynamic anthologies instead of rigid taxonomies, and others said rigid taxonomies work for them. From feedback in the session, a rigid taxonomy did not work for many 🙅‍♀️.
  • [RFC4949] was briefly discussed as a possibility 📖. However, there's a clear need to update the terminology in this publication around this space in particular 🔄. This will likely be raised in the Security Area Advisory Group (SAAG) during the open mic session, hopefully with proposed new definitions that show the issue and how terms have evolved over time ⏳.
  • Within a taxonomy, prioritization matters for understanding the impact of threats or an attack 🚨. How do you map that between different taxonomies? What is the problem to be solved, and what tooling is required? 🤔
  • Attack attribution got varying degrees of interest 🕵️. Some felt the public sector cared more about attribution than about individuals. They were interested in possible motivations behind an attack and in whether there were other likely victims based on those motivations 🎭. Knowing whether the source was an individual actor, organized crime, or a nation state mattered 🌍.

The result of this discussion wasn't to narrow it down to one taxonomy 💅. Instead, the focus shifted to mappings between taxonomies and the use cases for exchanging or sharing information, which could eventually lead to a common method for discussing threats and attacks 🌈. Researchers need a common vocabulary, not necessarily a common taxonomy 💜.

5. Next Steps 🦋

The next steps from the CARIS2 workshop come in two parts:

  1. The research initiatives spawned from the second CARIS workshop need more exploration and development 🌱. Fostering that development and creating communities around each proposed project is the first step, with reports going back out to the SMART mailing list 📬.
  2. The second initiative is planning for the next CARIS workshop 🗓️.

6. Summary 💖

When we wrapped up the workshop, we reviewed the list of agreed projects to get a feel for actual interest in following up 🧐. Over the two-day workshop, a bigger set of potential research items got generated, and that gave participants a chance to reassess their commitments so they better match expected outcomes ✅. The highest-ranking projects in terms of interest for driving the ideas forward were:

  • Traffic fingerprinting 🔍
  • SNARC 🧠
  • Attack coordination solutions and automated security 🤝
  • Cryptographic rendezvous 🔐
  • L2 discovery 🧚

7. Security Considerations 💀

There are no security considerations, as this is an informational workshop summary report 🙈.

8. IANA Considerations 🎀

This document has no IANA actions 📭.

9. References 📚

9.1. Informative References

[CARISEvent]
           Internet Society, "CARIS2: Coordinating Attack Response at
           Internet Scale", February 2019,
           <https://www.internetsociety.org/events/caris2>.

[deficit]  Morgan, S., "Cybersecurity Talent Crunch To Create 3.5
           Million Unfilled Jobs Globally By 2021", October 2019,
           <https://cybersecurityventures.com/jobs/>.

[I2NSF]    IETF, "Interface to Network Security Functions (i2nsf)",
           <https://datatracker.ietf.org/wg/i2nsf/about>.

[IEEE802.11]
           IEEE, "IEEE 802.11 WIRELESS LOCAL AREA NETWORKS",
           <https://www.ieee802.org/11/>.

[MISP]     MISP, "Malware Information Sharing Platform",
           <https://www.misp-project.org/>.

[PlonkaBergerCARIS2]
           Plonka, D. and A. Berger, "Measured Approaches to IPv6
           Address Anonymization and Identity Association", CARIS2
           Paper Submission, March 2019,
           <https://www.internetsociety.org/events/caris2>.

[PlonkaBergerKIP]
           Plonka, D. and A. Berger, "kIP: a Measured Approach to
           IPv6 Address Anonymization", July 2017,
           <https://arxiv.org/abs/1707.03900>.

[QUIC]     Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
           and Secure Transport", Work in Progress, Internet-Draft,
           draft-ietf-quic-transport-33, 13 December 2020,
           <https://tools.ietf.org/html/draft-ietf-quic-transport-
           33>.

[RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
           FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
           <https://www.rfc-editor.org/info/rfc4949>.

[RFC7970]  Danyliw, R., "The Incident Object Description Exchange
           Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
           November 2016, <https://www.rfc-editor.org/info/rfc7970>.

[RFC8073]  Moriarty, K. and M. Ford, "Coordinating Attack Response at
           Internet Scale (CARIS) Workshop Report", RFC 8073,
           DOI 10.17487/RFC8073, March 2017,
           <https://www.rfc-editor.org/info/rfc8073>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

[RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
           Description Specification", RFC 8520,
           DOI 10.17487/RFC8520, March 2019,
           <https://www.rfc-editor.org/info/rfc8520>.

[RFC8548]  Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
           Q., and E. Smith, "Cryptographic Protection of TCP Streams
           (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
           <https://www.rfc-editor.org/info/rfc8548>.

[SMART]    IRTF, "Stopping Malware and Researching Threats (smart)",
           <https://datatracker.ietf.org/group/smart/about/>.

Acknowledgements ✨

okay bestie, big thank you to every single CARIS2 workshop participant 🫶 you brought your ideas, your energy, and your willingness to collaborate, and that's how we push attack response forward at Internet scale 🌍💜

a huge shoutout to the program committee for reviewing the program materials, the papers, and the guidance on the workshop format 🎀 the squad: Mat Ford (Internet Society, UK) 🌸, Jamie Gillespie (APNIC, AU) 🦋, Chris Inacio (CERT/CC, US) 💅, Mirja Kühlewind (ETH Zurich, CH) 🧚, Mirjam Kühne (RIPE NCC, NL) 💖, Carlos Martinez (LACNIC, UY) ⭐, Kathleen M. Moriarty, Chair (Dell EMC) 👑, Kirsty Paine (NCSC, UK) 🔥, and Takeshi Takahashi (NICT, JP) 🍓

thank you to Megan Hyland (Dell EMC) 🌈 for reviewing the format of the breakout sessions and for the tools that made collaborating so smooth 🙈

and thank you to the minute takers, Akashaya Khare and Thinh Nguyen (Dell EMC OCTO Cambridge Dojo team) 📝✨ literally the unsung heroes, iykyk

Author's Address 🦋

Kathleen M. Moriarty Center for Internet Security 31 Tech Valley Drive East Greenbush, NY 12061 United States of America

Email: kathleen.moriarty.ietf@gmail.com 💌

📦 where this page comes from