Internet DRAFT - draft-moriarty-caris2
draft-moriarty-caris2
Internet Engineering Task Force K. Moriarty
Internet-Draft Dell Technologies
Intended status: Informational 9 October 2020
Expires: 12 April 2021
Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop
Report
draft-moriarty-caris2-04
Abstract
The Coordinating Attack Response at Internet Scale (CARIS) 2
workshop, sponsored by the Internet Society, took place 28 February
and 1 March 2019 in Cambridge, Massachusetts, USA. Participants
spanned regional, national, international, and enterprise 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 scaling incident prevention and detection as the Internet
industry moves to a stronger and a more ubiquitous deployment of
session encryption.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 April 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Moriarty Expires 12 April 2021 [Page 1]
Internet-Draft CARIS2 Report October 2020
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
2. Accepted Papers . . . . . . . . . . . . . . . . . . . . . . . 3
3. CARIS2 Goals . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Workshop Collaboration . . . . . . . . . . . . . . . . . . . 5
4.1. Breakout 1 Results: Standardization and Adoption . . . . 5
4.1.1. Wide adoption: . . . . . . . . . . . . . . . . . . . 6
4.1.2. Limited Adoption . . . . . . . . . . . . . . . . . . 6
4.2. Breakout 2 Results:Preventative Protocols and Scaling
Defense . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Breakout 3 Results: Incident Response Coordination . . . 9
4.4. Breakout 4 Results: Monitoring and Measurement . . . . . 11
4.4.1. IP Address Reputation . . . . . . . . . . . . . . . . 11
4.4.2. Server Name Authentication Reputation C (SNARC) . . . 12
4.4.3. Logging . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.4. Fingerprinting . . . . . . . . . . . . . . . . . . . 12
4.5. Taxonomy and Gaps Session . . . . . . . . . . . . . . . . 13
5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Informative References . . . . . . . . . . . . . . . . . 15
10.2. URL References . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop
workshop [CARISEvent], sponsored by the Internet Society, took place
28 February and 1 March 2019 in Cambridge, Massachusetts, USA.
Participants spanned regional, national, international, and
enterprise Computer Security Incident Response Teams (CSIRT),
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 [RFC8073],
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
Moriarty Expires 12 April 2021 [Page 2]
Internet-Draft CARIS2 Report October 2020
to form a research group [SMART] in the Internet Research Task Force
(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 SMART has not progressed, the work to better scale
incident response continues through the projects proposed at CARIS2
as well in future CARIS workshops.
2. Accepted Papers
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
workshop [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 (PASC and PAVA): 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 to advance research towards the goals of the workshop.
These sessions included:
Manufacturer Usage Description (MUD) [RFC8520]: Eliot Lear, Cisco
TF-CSIRT: Mirjam Kuhne, RIPE NCC
M2M Sharing Revolution, Scott Pinkerton, DoE ANL
Moriarty Expires 12 April 2021 [Page 3]
Internet-Draft CARIS2 Report October 2020
Comparing OpenC2 with existing efforts, e.g. [I2NSF]: Chris
Inacio
Alternate Sharing and Mitigation Models: Kathleen Moriarty,
DellEMC
The presentations provided interesting background to familiarize
workshop attendees with current research work, challenges that
require addressing for forward progress, and opportunities to
collaborate in the desire to better scale 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 it is unlikely that additional training will address the
lack of information security professionals to fill the job gap.
Currently, there is approximately a 3 million person deficit
[defecit] for security professionals worldwide and it's only expected
to grow. In preparing for the workshop, the chair and programme
committee considered that this gap cannot be filled through training,
but the gap requires measures to reduce the number of information
security professionals needed through new architectures and research
towards attack prevention. CARIS 2 was specifically focused on the
industry shift towards the increased use of stronger session
encryption (TLSv1.3 [RFC8446], QUIC [I-D.ietf-quic-transport],
TCPcrypt [RFC8548], etc.) and how prevention and detection can
advance in this new paradigm. As such 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/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.
Moriarty Expires 12 April 2021 [Page 4]
Internet-Draft CARIS2 Report October 2020
4. Workshop Collaboration
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, 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, contributions, and the participants 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 the full set of attendees and breakout groups.
The Workshop focused in trying to help identify potential areas for
collaboration and advance research. To do this, the workshop
included 5 different breakout sessions focused on:
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 on what potential
areas of research or future workshops could be held to improve on
the scalability of incident response.
4. Monitoring and Measurement:brainstorm on methods to perform
monitoring and measurement with the heightened need and
requirement to address privacy.
5. Taxonomy and Gaps: brainstorm on away forward for the proposed
SMART group
4.1. Breakout 1 Results: Standardization and Adoption
This breakout session considered points raised in the preceding talks
on hurdles for automating security controls, detection, and response
as the teams presenting noted several challenges they still face
today. The breakout 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:
Moriarty Expires 12 April 2021 [Page 5]
Internet-Draft CARIS2 Report October 2020
4.1.1. Wide adoption:
Secure Sockets Layer (SSL), now replaced by Transport Layer Security
(TLS) protocol.
Observations: There was a clear need for session encryption at the
transport layer to protect application data. eCommerce 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.
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
after decades being replaced by a newer alternative, YANG (a data
modeling language) facilitating configuration management via NETCONF
or RESTCONF. The SNMP protocol facilitated an answer to a needed
problem set: configuration, telemetry, and network management. It's
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.
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 the wide set of use cases spanning
multiple technology areas were some of the key drivers cited.
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.
4.1.2. Limited Adoption
Next each team evaluated solutions that have not enjoyed wide
adoption.
Although STIX and IODEF are somewhat similar in their goals, the
standards were selected for evaluation by two separate groups with
some common findings.
*Structured Threat Information eXpression (STIX)* has had limited
adoption by the financial 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
Moriarty Expires 12 April 2021 [Page 6]
Internet-Draft CARIS2 Report October 2020
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 as managing content may be the
primary use case.
Incident Object Description Exchange Format (IODEF) was specified by
national research and education networks (NREN) and computer security
incident response teams (CSIRT) and formalized in the IETF. 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
and this applies to STIX as well. Sharing and trust are additional
hurdles as many are not willing to disclose information.
DNS-based Authentication of Named Entities (DANE) has DNSsec as a
dependency, which is a hurdle towards 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. The website allows you you to 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 is available for worldwide
use.
IP version 6 (IPv6) has 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 and the
breakout team considered it 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 next breakout followed the sessions on MUD, PAVA (Protocol for
Automated Vulnerability Assessment), and PASC (Protocol for Automatic
Security Configuration) which have themes of automation at scale.
MUD was designed for 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 was focused on
Moriarty Expires 12 April 2021 [Page 7]
Internet-Draft CARIS2 Report October 2020
groups brainstorming on preventative measures and 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.
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 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) 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, etc. There was
some discussion on the use of 802.11 to improve connections. Several
participants from this group planned to research this further and
identify options to prevent information leakage while achieving the
stated goals of MUD.
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 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 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 and to provide assessments on the impact of protocol
changes on security in the round.
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 dove deeper into this topic.
The fourth breakout group discussed useful data for incident
responders. This built on the first breakout session. 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
Moriarty Expires 12 April 2021 [Page 8]
Internet-Draft CARIS2 Report October 2020
richer event threat sharing format. When reporting back to the
group, a successful solution used in the EU was mentioned, Malware
Information Sharing Platform (MISP) [MISP]. This will be considered
in their review of existing efforts to determine if 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 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.
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
Creating Drag:
* Lack of clear KPIs
* Too many standards
* Regional border 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
Moriarty Expires 12 April 2021 [Page 9]
Internet-Draft CARIS2 Report October 2020
* 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
* Over-centralization of the Internet
* New technologies and protocols
* Changes in application layer configurations (e.g. browser
resolvers)
Moriarty Expires 12 April 2021 [Page 10]
Internet-Draft CARIS2 Report October 2020
4.4. Breakout 4 Results: Monitoring and Measurement
The fourth breakout 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 co-author Arthur Berger primarily focus on measurement 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.
This breakout 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 highest then explored by the breakout groups.
Groups agreed to work further on the proposed ideas.
4.4.1. IP Address Reputation
There is a need to understand address assignment and configuration
for hosts and services, especially with IPv6 [PlonkaBergerCARIS2] in
(1) sharing IP address-related information to inform attack response
efforts, while still protecting the privacy of victims and possible
attackers, and (2) mitigating abuse by altering the treatment, e.g.,
dropping or rate-limiting, of packets. Currently, there is no
database for analysts and researchers can consult to, for instance,
determine to lifetimes of IPv6 addresses or the prefix length at
which the address is expected to be stable over time. The
researchers propose either introduce a new database (compare
PeerdingDB) or extending existing databases (e.g., the RIRs'), to
contain such information and allowing arbitrary queries. The prefix
information would either be provided by networks, who are willing, or
based on measurement algorithms that reverse-engineer reasonable
values based on Internet measurements [PlonkaBergerKIP]. In the
former case, the incentive of networks to provide such information is
to so 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, the lead to contact if interested to help
develop this further is Dave Plonka.
Moriarty Expires 12 April 2021 [Page 11]
Internet-Draft CARIS2 Report October 2020
4.4.2. Server Name Authentication Reputation C (SNARC)
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, would be
human readable, builds on zero trust networking, and avoids
consolidation 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 RFC would help customers and
design team on existing solutions. They planned 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, the lead contact is: Trent Adams.
4.4.3. Logging
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
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 increased use of encrypted transport continues. The
lead for contact if interested to develop this further is Nalini
Elkins.
4.4.4. Fingerprinting
Fingerprinting has been used for numerous applications on the web,
including security, and will become of increasing importance with the
deployment of stronger encryption. This 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 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, the lead contact is: William Weinstein.
Moriarty Expires 12 April 2021 [Page 12]
Internet-Draft CARIS2 Report October 2020
4.5. Taxonomy and Gaps Session
At the start of day 2, Kirsty Paine and Mirjam Kuhne prepared and
Kirsty led a 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 selecting language to be used in the proposed SMART group.
Several taxonomies were presented for review and discussion. The
topic remains open, the following key points were highlighted by
participants:
* 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. attribution of the attack, mitigation steps, technical
features or organizational impact measurements.
* A tool to map between taxonomies should be automated as there are
requirements within groups or nations to use specific taxonomies.
* 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 for management reporting
they only use 8 categories to lighten the load on analysts,
whereas some of the taxonomies contain 52 categories.
* How you plan to use the taxonomy matters and may vary between use
cases. Take for 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.
* [RFC4949] was briefly discussed as a 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 during
open mic, hopefully with proposed new definitions to demonstrate
the issue and evolution of terms over time.
* Within a taxonomy, prioritization matters to understand the impact
of threats or an attack. How do you map that between differing
taxonomies? (problem to be solved; possible tooling required)
Moriarty Expires 12 April 2021 [Page 13]
Internet-Draft CARIS2 Report October 2020
* Attack attribution had varying degrees of interest. Some felt the
public sector cared more about attribution; not about individuals,
but the possible motivations behind an attack and likely other
victims based on these motivations. Understanding if the source
was an individual actor, organized crime, or a nation state
mattered.
The result of this discussion was not to narrow down to one 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.
5. Next Steps
The next steps from the CARIS2 workshop are twofold.
* The research initiatives spawned from the second CARIS 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.
* The second initiative will be planning for the next CARIS
workshop.
6. Summary
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 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:
* Traffic fingerprinting
* SNARC
* Attack coordination solutions/automated security
* Cryptographic Rendezvous
* L2 discovery
Moriarty Expires 12 April 2021 [Page 14]
Internet-Draft CARIS2 Report October 2020
7. Security Considerations
There are no security considerations as this is an informational
workshop summary report.
8. IANA Considerations
This memo includes no request to IANA.
9. Acknowledgements
Thank you to each of the CARIS2 participants who brought their ideas,
energy and willingness to collaborate to advance attack response at
Internet scale.
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.
Thank you to Megan Hyland, DellEMC, for her review and guidance on
the breakout session format and tools to enable successful
collaboration.
Thank you to the minute takers, Akashaya Khare and Thinh Nguyen,
DellEMC OCTO Cambridge Dojo team.
10. References
10.1. Informative References
[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>.
[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>.
[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>.
Moriarty Expires 12 April 2021 [Page 15]
Internet-Draft CARIS2 Report October 2020
[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>.
[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>.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-31, 24 September 2020,
<https://tools.ietf.org/html/draft-ietf-quic-transport-
31>.
10.2. URL References
[CARISEvent]
Internet Society, "CARIS Event Information and Accepted
Papers https://www.internetsociety.org/events/caris2",
2019.
[I2NSF] IETF, "Interface to Network Security Functions (i2nsf)
https://datatracker.ietf.org/wg/i2nsf/about".
[defecit] Morgan, S., "Cybersecurity Talent Crunch To Create 3.5
Million Unfilled Jobs Globally By 2021
https://cybersecurityventures.com/jobs/".
[MISP] MISP-project.org, "Malware Information Sharing Platform
https://www.misp-project.org/", 2019.
[SMART] IRTF, "Stopping Malware and Researching Threats
https://datatracker.ietf.org/group/smart/about/", 2019.
[PlonkaBergerCARIS2]
CARIS2, "CARIS2 Paper Submission,", 2019.
[PlonkaBergerKIP]
Arxiv, "kIP: a Measured Approach to IPv6 Address
Anonymization https://arxiv.org/abs/1707.03900", 2017.
Author's Address
Moriarty Expires 12 April 2021 [Page 16]
Internet-Draft CARIS2 Report October 2020
Kathleen M Moriarty
Dell Technologies
176 South Street
Hopkinton, MA 01748
United States
Email: kathleen.moriarty.ietf@gmail.com
Moriarty Expires 12 April 2021 [Page 17]
