<?xml version="1.0" encoding="US-ASCII"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

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

<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc number="8073" ipr="trust200902" submissionType="IAB" consensus="yes" category="info">

  <front>
    <title abbrev="CARIS">Coordinating Attack Response at Internet Scale (CARIS) Workshop Report</title>

    <author initials="K." surname="Moriarty" fullname="Kathleen M. Moriarty">
      <organization></organization>
      <address>
        <postal>
          <street>176 South Street</street>
          <city>Hopkinton, MA</city>
          <country>United States of America</country>
        </postal>
        <email>Kathleen.Moriarty@dell.com</email>
      </address>
    </author>
    <author initials="M." surname="Ford" fullname="Mat Ford">
      <organization></organization>
      <address>
        <postal>
          <street>Galerie Jean-Malbuisson 15</street>
          <city>Geneva</city>
          <country>Switzerland</country>
        </postal>
        <email>ford@isoc.org</email>
      </address>
    </author>

    <date year="2017" month="March" />

    <area>General</area>
    <workgroup>Network</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in 
the title) for use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword>

<abstract>

<t>This report documents the discussions and conclusions from the
Coordinating Attack Response at Internet Scale (CARIS) workshop that
took place in Berlin, Germany on 18 June 2015. The purpose of this
workshop was to improve mutual awareness, understanding, and
coordination among the diverse participating organizations and their
representatives.</t>

<t>Note that this document is a report on the proceedings of the
workshop.  The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB
views and positions.</t>

    </abstract>

  </front>

  <middle>

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

<t>The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet
architecture.  This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working
groups of the Internet Engineering Task Force (IETF), under the
leadership of the Internet Engineering Steering Group (IESG) and area
directorates.</t>

<t>The Internet Architecture Board (IAB) and the Internet Society
(ISOC) hosted a day-long Coordinating Attack Response at Internet
Scale (CARIS) workshop on 18 June 2015 in coordination with the Forum
for Incident Response and Security Teams (FIRST) Conference in
Berlin. The workshop included members of the FIRST community, attack
response working group representatives, network and security
operators, Regional Internet Registry (RIR) representatives,
researchers, vendors, and representatives from standardization
communities. The key goals of the workshop were to improve mutual
awareness, understanding, and coordination among the diverse
participating organizations. The workshop also aimed to provide the
attendees with greater awareness of existing efforts to mitigate
specific types of attacks, and greater understanding of the options
available to collaborate and engage with these efforts.</t>

<t>The day-long workshop included a mix of invited talks and panel
discussion sessions with opportunities to collaborate throughout,
taking full advantage of the tremendous value of having these diverse
communities with common goals in one room. There were approximately 50
participants engaged in the CARIS workshop.</t>

<t>Attendance at the workshop was by invitation only.  Prior to the
workshop, existing attack-mitigation working groups were asked to
complete a survey. The data gathered through this questionnaire,
including how third parties can participate in or contribute to the
attack-mitigation working group, was shared with all of the
participants at the workshop to better enable collaboration <xref
target="ISOC"/>.  Attendees were also selected from submissions of
two-page position papers that included some key insight or challenge
relevant to the broader group. Paper topics included research topics
related to attack mitigation or information sharing/exchange, success
stories, lessons learned, and more in-depth studies on specific topics
such as privacy or trust.</t>

<t>The program committee received 25 papers and 19 template
submissions.  The template submissions will be maintained by the
Internet Society, and as a result of the workshop, they will be amended
to provide additional value to the Computer Security Incident Response
Teams (CSIRTs) and attack response communities/operators on their
information exchange capabilities.  The CARIS participants found the
template submissions to be very useful in coordinating their future
attack mitigation efforts.  This initiative is a new, open for the
global community, and hosted in a neutral location.  All submissions
are available online and are linked from the agenda <xref
target="AGENDA"/>.</t>

<t>The workshop talks and panels involved full participation from
attendees who were required to read all the submitted materials.  The
panels were organized to spur conversation between specific groups to
see if progress could be made towards more efficient and effective
attack mitigation efforts.  See <xref target="KME"/> for additional information on possible approaches to
accomplish more effective attack response and information exchanges
with methods that require fewer analysts.</t>

<t>The workshop was run under the Chatham House Rule to facilitate the
exchange of sensitive information involved with incident response.  As
such, there was no recording, but minutes were taken and used to aid
in the generation of this report.  Comments will not be attributed to
any particular attendee, nor will organizations be named in
association with any discussion topics that were not made public
through submission templates or papers by the submitter and
organization.</t>

</section>
<section anchor="panels" title="Sessions and Panel Groups">

<t>After an initial presentation to set the stage and elaborate the goals of the workshop, the day was divided into five sessions as follows:</t>

<t><list style="numbers">
  <t>Coordination between CSIRTs and attack-response mitigation efforts</t>
  <t>Scaling response to Distributed Denial-of-Service (DDoS) and botnets effectively and safely</t>
  <t>Infrastructure: DNS and RIR providers and researchers</t>
  <t>Trust and Privacy with the exchange of potentially sensitive information</t>
  <t>Implications for Internet architecture and next steps</t>
</list></t>

<t>The remainder of this report will provide more detail on each of
these sessions.</t>

<section anchor="coordination-between-csirts-and-attack-response-mitigation-efforts" title="Coordination between CSIRTs and Attack Response Mitigation Efforts">

<t>The first panel session on Coordination between CSIRTs and attack
mitigation efforts included representatives from several organizations
that submitted templates describing their organization's attack
mitigation efforts.  This panel was purposefully a cross section of
organizations attending to see if there were new opportunities to
collaborate and improve efficiency, thereby better scaling attack
mitigation.  The panelists described their efforts with the following
questions in mind:</t>

<t><list style="symbols">
  <t>What is the use case for their organization?</t>
  <t>Where are they focusing their efforts?</t>
  <t>How can others engage with their organization?</t>
  <t>Who participates in their organization today?</t>
</list></t>

<t>For each of the following organizations, additional information can
be found in their template submissions <xref target="ISOC"/>.</t>

<t>The following summaries are to be read in the context of the
workshop and not as standalone descriptions for each organization.
These summaries are a result of the workshop discussions.</t>

<t><list style="symbols">
  <t>ENISA is the European Network and Information Security Agency
  <xref target="ENISA"/>.  While ENISA provides support for the
  community in the form of education, training, and collaboration on
  security and attack mitigation, it does not offer a service for
  attack response or mitigation.</t>
  <t>The Anti-Phishing Working Group (APWG) offered examples of
  operator-driven exchanges focused on specific use cases that involve
  hundreds of participating organizations daily.  The APWG operates a
  data clearinghouse and provides infrastructure to support meaningful
  data exchanges and maintains a current set of data through these
  interactions.  More can be learned on the APWG website <xref
  target="APWG"/> in addition to their template submission.</t>
  <t>The Research and Education Networking Information Sharing and
  Analysis Center (Ren-ISAC) employs an interesting operational model
  that scales well through automation, exchanging actionable
  information between 500 universities and automatically implementing
  controls.  Since many universities cannot respond to incidents in
  real time due to a scarcity of resources, REN-ISAC leverages a small
  number of analysts to accomplish the task of protecting many
  universities through automation.  The key to the success of their
  project is providing tools that allow organizations to make use of
  incident data operationally. They are currently working to develop
  open-source tools to track metrics more formally <xref
  target="REN-ISAC"/>.</t>
  <t>CERT.br is the Brazilian Computer Emergency Response Team (CERT)
  that has made impressive progress in a short amount of time.
  CERT.br is the national focal point for incident reporting,
  collection, and dissemination of threat and attack trend information
  in Brazil. CERT.br works to increase awareness and incident-handling
  capabilities in the country as well as assisting to establish new
  CSIRTs.  In addition to providing training and awareness campaigns,
  they distribute network security honeypots and have a primary focus
  on network monitoring.  CERT.br requires active participation from
  third parties wishing to collaborate and exchange data with them
  <xref target="CERT.BR"/>.</t>
  <t>MyCERT's mission is to address the security concerns of Malaysian
  Internet users and reduce the probability of successful attacks
  <xref target="MYCERT"/>.  They have been operational since
  1997. MyCERT is responsible for incident handling of unauthorized
  intrusions, identity theft, DDoS attacks, etc. MyCERT handles
  computer security incidents in Malaysia, provides malware research,
  and technical coordination. In addition to incident response and
  coordination activities, MyCERT members provide talks and training,
  as well as local and regional security exercises.  MyCERT also
  provides incident alerts and advisories on vulnerabilities,
  breaches, etc.</t>
  <t>The CERT Coordination Center (CERT/CC) has been operational since
  1998 on an international and national scale <xref
  target="CERTCC"/>. They have long been known for their software
  vulnerability work and the national vulnerability database in the US
  (Common Vulnerabilities and Exposures -- CVEs) and informing
  organizations of vulnerabilities.  CERT/CC helps to coordinate
  between vendors and researchers for improved collaborations.
  CERT/CC provides guidance on dealing with the aftermath of
  incidents, risk assessment best practice, bug bounties, and other
  incident-related areas.</t>
</list></t>

<t>Highlights from the panel discussion:</t>

<t><list style="symbols">
  <t>Passive surveillance by state actors has impacted incident
  response activities due to the erosion of trust between
  communities.</t>
  <t>Government involvement in information exchange efforts has not been
  productive. Despite lots of discussion, there have not been useful outcomes.</t>
  <t>There is more interest in consuming feeds of information than sharing information.</t>
  <t>Ego has been a big issue for improving data sharing, as have
  reputation-related concerns when sharing or receiving data.</t>
  <t>There is a perception of weakness around organizations that share
  attack information in some regions.</t>
  <t>Sharing in isolation doesn't help, it must lead to operational return on investment.</t>
  <t>Language barriers have been an issue for some national CSIRTs.</t>
  <t>Sharing too much information leads to capacity and resource
  issues for receiving organizations.  Organizations directly
  receiving feeds can often misinterpret data and think they are under
  attack when it is not the case. Operational models are preferred
  where data exchanges have a direct impact on improving the
  efficiency of a small number of analysts to impact many.</t>
  <t>Privacy regulations restricting some organizations from sharing
  IP address information have had an impact on the effectiveness of
  incident data exchanges.  ENISA is currently running a study on this
  impact (this point was raised by several attendees).</t>
  <t>Too many efforts are using data just for blocking attacks and not
  for operational mitigation and elimination of vulnerabilities as
  part of their incident response effort.  Note: Operational efforts
  stand out in that they do eliminate threats and update data
  warehouses.</t>
  <t>Involvement of vendors is needed to better scale attack response.
  This is not seen as a need by all groups, but some sharing groups
  with an operational focus are looking for improved efficiencies to
  leverage a small number of analysts more productively.  Analysts are
  a limited resource in this technical area of expertise.</t>
  <t>Enterprises don't want more security boxes in their networks as
  they don't have the resources to manage them, so involving vendors
  doesn't mean deploying more equipment, but improving automated
  controls and the elimination of threats wherever possible.  False
  positives are still an issue, which can be problematic for some
  automation activities.</t>
</list></t>

</section>
<section anchor="scaling-response-to-ddos-and-botnets-effectively-and-safely" title="Scaling Response to DDoS and Botnets Effectively and Safely">

<t>The first invited talk at the workshop provided an interesting
history of Distributed Denial-of-Service (DDoS) attacks and the
evolution of botnets as well as the methods to combat these threats.
The paper by Dave Dittrich <xref target="DD1"/> is available to learn
more of this history. This section of the report will focus on the
workshop discussion in an effort to benefit from the workshop
attendees' thoughts concerning how to better scale our response to
these threats.</t>

<t>Key points from the discussion:</t>

<t><list style="symbols">
  <t>Of the attack types discussed, DDoS and botnets appear to be the
  furthest along in terms of efficient and effective response.  Other
  efforts can learn from this experience.  There has not been any
  interaction between these two attack types that may benefit from
  information exchange tied to remediation activities since botnets
  can be the source of DDoS attacks.</t>
  <t>There is a disparity between short-term mitigation goals and
  actual eradication of DDoS and botnet threats. The question was
  raised: how do we normalize the same data in different ways to serve
  different goals? In other words, DDoS traffic is often the result of
  botnets, but the data is not shared between the service providers
  and vendors responding to DDoS threats and those actively mitigating
  and eradicating botnets.</t>
  <t>There are ad hoc trust groups within the operations security (OPSEC)
  community today. The Cybercrime Response Advisory Group (CRAG) is one example.</t>
  <t>Filtering and triage is an issue, but this is a solvable problem.</t>
  <t>The IETF DDOS Open Threat Signaling (DOTS) working group was
  discussed and compared to a previous effort, Real-time Inter-network
  defense (RID) <xref target="RFC6545"/>.  It was stated that the two
  are similar, except DOTS makes use of current data formats and
  protocols and has the support of multiple DDoS vendors.  One of the
  goals of DOTS is to have this solution be the "glue" between vendors
  to communicate shared data using standard formats and protocols
  developed in open-source tools.</t>
  <t>The IETF Interface to Network Security Functions (I2NSF) effort
  was discussed to explore ways of leveraging infrastructure to combat
  DDoS attacks.</t>
  <t>Vendors discussed existing capabilities for DDoS mitigation,
  while data-sharing groups discussed their mitigation activities
  related to botnets (see the submissions under the heading "Panel on
  Scaling Attack Response for DDoS and BotNets" in the workshop agenda
  <xref target="AGENDA"/>).</t>
  <t>Trust and reputation of data sources is still a concern.</t>
  <t>One of the exchange groups has a goal of "automated takedowns"
  for botnets.  However, they think they will always have a need for
  manual intervention.</t>
  <t>The need for multiple levels of trust seemed to be prevalent
  among those participating in the panel discussion.  Intelligence
  agencies erode trust (this was also mentioned in the first panel in
  terms of surveillance activities from governments).</t>
  <t>Although trust was discussed in this panel and there are
  concerns, it was noted that trust is not as big a barrier for DDoS
  and botnet mitigation, and this is likely due to the operational
  experience of the participants.</t>
</list></t>

</section>
<section anchor="dns-rirs-attack-response-and-mitigation" title="DNS and RIRs: Attack Response and Mitigation">

<t>This session was a shift from other sessions in the day as the
panelists were infrastructure providers for those combating attacks.
This session was of interest to see how attack and incident responders
could better collaborate with DNS infrastructure organizations and
RIRs.  These groups have not interacted in the past, and it was
interesting to see the collaboration opportunities since the workshop
participants rely on these services to do their jobs.  From the
panelists' perspective, DNS and RIRs are separate worlds where they
spend a lot of time trying to educate policy makers about how they
work together to make the Internet work.</t>

<t>Key discussion points:</t>

<t><list style="symbols">
  <t>The use of passive DNS in attack mitigation was described.</t>
  <t>RIRs discussed the data they maintain and provide, including
  worldwide BGP update data and root DNS server data.  These datasets
  are available to share with researchers and could be of interest to
  those working on attack response.  The current way the data is made
  available does not scale, and ideas were discussed in the workshop
  to improve the scalability should this become a more widely used
  resource.</t>
  <t>Some of the global RIRs already actively coordinate with incident
  responders in their region.  In some cases, they do facilitate
  information sharing as well as provide education and training.  Data
  shared out by RIRs is anonymized.</t>
  <t>A concern was raised regarding overlapping efforts and a request was made for the IETF and ISOC to pay attention to this and help.  This workshop was one step toward that in bringing together this diverse community.  The participants wished to see this type of event repeated for future cross area collaboration between the diverse set of groups that often only meet within their silo.</t>
  <t>Standards for APIs to access data consistently from RIRs and
  scoring methods were discussed as possible ways to scale trust.
  Questions were raised as to how this might be possible.  One might
  receive unverifiable data about a network. They may be able to
  verify the source's identity, verify route origins, but won't be
  able to verify the provenance of data.</t>
</list></t>

</section>
<section anchor="trust-privacy-and-data-markings-panel" title="Trust Privacy and Data Markings Panel">

<t>Why don't organizations share data? The answer seems to be a mix of
privacy, legal, technical/mundane, cultural, and communication issues.
There are also concerns about sharing proprietary data with
competitors. Having said that, most of these reasons were dismissed as
bogus by the more operationally focused participants in the
workshop. Lawyers need contextual education for the intersection of
law and technology. Sensitive data is still an issue as one can't
control what others do with data once it is shared.</t>

<t>Key points from the panel discussion:</t>

<t><list style="symbols">
  <t>Operationally focused groups do retain/rate/re-mark confidence
  levels based upon the submitter's reputation.</t>
  <t>The Traffic Light Protocol (TLP) <xref target="TLP"/> was
  discussed.  While TLP is useful to some groups who exchange data,
  others find that it is not granular enough for their needs.</t>
  <t>In many cases, when data is shared, the user never knows, and there
  is no way to manage that disclosure.</t>
  <t>Trust is personal.  When sharing circles get too large, trust
  breaks down.  The personal relationship aspect of information
  sharing communities was emphasized by several who are actively
  exchanging data.  This was a very prevalent theme.</t>
  <t>A point of comparison was made with consumer goods, and it was
  observed that trademarks are a byproduct of the Industrial
  Revolution. The question was raised: does trust need branding?</t>
  <t>Observing participants noted that there appear to be cabals
  operating the groups based on the current trust notions.  This was
  not disputed.</t>
  <t>Transparency is vital to maintain trust.</t>
  <t>Participants working on automation have found a need to share
  with organizations of all sizes as well as a need to share both
  synchronously and asynchronously. In an automated model, they must
  ensure data sources are "authorized" and these efforts have
  encountered questions about anonymization as well as regional
  regulatory perspectives as they vary.</t>
  <t>Another automation effort found that people have different upper
  limits for trust group scale, which is sometimes based on
  individualized knowledge of other participants and having a comfort
  level with them.  Social interaction (beer) is a common thread
  amongst sharing partners to build trust relationships.  The
  relationships are formed between individuals and not necessarily
  between organizations.</t>
  <t>It's rare for any single piece of information to be clearly
  identifiable as private or public. The temptation is to say that
  information isn't Personally Identifiable Information (PII). In
  aggregate, however, non-PII can become PII.</t>
  <t>There was common agreement that reputation is fundamental.</t>
</list></t>

</section>
</section>
<section anchor="themes" title="Workshop Themes">

<t>During the course of the day, a couple of themes recurred in the discussions. Firstly, in order to better scale attack response through improvements to the efficiency and effectiveness of information exchanges:</t>

<t><list style="numbers">
  <t>Exchanging data should not be just for the purpose of creating blacklists that could be redundant efforts.</t>
  <t>Involving service providers and vendors to better coordinate and scale response is key.</t>
</list></t>

<t>Secondly, information security practitioners are a scarce resource:</t>

<t><list style="numbers">
  <t>Training and education was discussed to improve this gap, both to train information security professionals and others in IT on basic network and system hygiene.</t>
  <t>Leveraging resources to better scale response, using fewer resources is critical.</t>
</list></t>

</section>
<section anchor="nextsteps" title="Next Steps">

<section anchor="rir-and-dns-provider-resources" title="RIR and DNS Provider Resources">

<t>Workshop participants expressed an interest in expanded information about the resources and assistance offered by the RIRs and DNS providers.  Participants are going to define what is needed.</t>

</section>
<section anchor="education-and-guidance" title="Education and Guidance">

<t>Another recurring theme was the lack of knowledge in the community about basic security principles such as ingress and egress filtering explained in BCP 38 <xref target="RFC2827"/>.  The CSIRTs, operators, and vendors of attack mitigation tools found this particularly frustrating.  As a result, follow up activities may include determining if security guidance BCPs require updates or to determine whether there are opportunities to educate people on these basic principles already documented by the IETF.</t>

</section>
<section anchor="transport-options" title="Transport Options">

<t>One of the more lively discussions was the need for better
transports for information exchange.  Real-time Inter-network Defense
(RID) <xref target="RFC6545"/> was published 5 years ago. While the patterns established in RID still show promise, there are
updated solutions being worked on.  One such solution is in the IETF
DOTS working group that has an approach similar to RID with updated
formats and protocols to meet the demands of today's DDoS attacks.
While Trusted Automated eXchange of Indicator Information (TAXII --
another transport option) is just in transition to Organization for
the Advancement of Structured Information Standards (OASIS), its base
is similar to RID in its use of SOAP-like messaging, which will likely
prevent it from scaling to the demands of the Internet.  Vendors also
cited several interoperability challenges of TAXII in workshop
discussions.  Alternatively, XMPP-Grid has been proposed in the IETF
Security Automation and Continuous Monitoring (SACM) working group and
it offers promise as the data exchange protocol for deployment at
scale.  Extensible Messaging and Presence Protocol (XMPP) <xref
target="RFC6120"/> inherently meets the requirements for today's
information exchanges with features such as publish/subscribe,
federation, and use of a control channel.  XMPP-Grid is gaining
traction with at least 10 vendors using it in their products and
several more planning to add support <xref target="APPALA"/>.  Review
and discussion of this document would be helpful as it transitions to
the Managed Incident Lightweight Exchange (MILE) working group as an
outcome of the workshop.  Representational State Transfer (REST) was
also brought up as a needed interface because of the low barrier to
use <xref target="REST"/>.  The IETF MILE Working Group has discussed
a document detailing a common RESTful interface (ROLIE) that could be
used with any data format and this may also be of interest <xref
target="ROLIE"/>.</t>

</section>
<section anchor="updated-template-for-information-exchange-groups" title="Updated Template for Information Exchange Groups">

<t>One of the submission options was for organizations actively
exchanging data to submit a form describing their work to reduce
computer security incidents.  The CSIRTs, in particular, liked having
access to this information in a neutral location like the Internet
Society.  However, they wanted to see amendments to the format to
improve its usefulness.  There was a desire to have this used by
additional information exchange groups, thereby creating a living
library to improve awareness about how to become a member, benefit
from, or contribute to the success of the attack response and CSIRT
information exchange platforms.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>The CARIS workshop was focused on security and methods to improve
the effectiveness and efficiency of attack response to enable better
scaling.  This report provides a summary of the workshop discussions
and identifies some outcomes to improve security.  As such, no
additional considerations are provided in this section.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>
<?rfc include="reference.RFC.2827" ?>
<?rfc include="reference.RFC.6120" ?>
<?rfc include="reference.RFC.6545" ?>

<reference anchor="KME" target="http://blogs.rsa.com/author/kathleen-moriarty/">
  <front>
    <title>Kathleen Moriarty Blog Series</title>
    <author initials="K." surname="Moriarty" fullname="Kathleen M. Moriarty">
      <organization>EMC Corporation</organization>
    </author>
    <date year="2015" month="July"/>
  </front>
</reference>
<reference anchor="ISOC" target="https://www.internetsociety.org/doc/caris-workshop-template-submissions-2015">
  <front>
    <title>CARIS Workshop Template Submissions</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="ENISA" target="https://www.enisa.europa.eu">
  <front>
    <title>European Union Agency for Network and Information Security Homepage</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="APWG" target="http://www.antiphishing.org">
  <front>
    <title>APWG Homepage</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="REN-ISAC" target="http://ren-isac.net">
  <front>
    <title>Research and Education Networking Information Sharing and Analysis Center Homepage</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="DD1" target="https://www.iab.org/wp-content/IAB-uploads/2015/04/CARIS_2015_submission_21.pdf">
  <front>
    <title>Taking Down Botnets - Background</title>
    <author initials="D." surname="Dittrich" fullname="David Dittrich">
      <organization></organization>
    </author>
    <date year="2015" month="April" day="10"/>
  </front>
  <format type="PDF" target="https://www.iab.org/wp-content/IAB-uploads/2015/04/CARIS_2015_submission_21.pdf"/>
</reference>
<reference anchor="AGENDA" target="https://www.iab.org/activities/workshops/caris/agenda/">
  <front>
    <title>Agenda: Coordinating Attack Response at Internet Scale (CARIS) Workshop</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="TLP" target="https://www.us-cert.gov/tlp">
  <front>
    <title>Traffic Light Protocol (TLP) Matrix and Frequently Asked Questions</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="CERT.BR" target="http://www.cert.br/en/">
  <front>
    <title>Brazilian National Computer Emergency Response Team Homepage</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="MYCERT" target="https://www.mycert.org.my/en/">
  <front>
    <title>Malaysia Computer Emergency Response Team Homepage</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="CERTCC" target="https://www.cert.org">
  <front>
    <title>CERT Coordination Center Homepage</title>
    <author >
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>

<!-- draft-ietf-mile-xmpp-grid-01 IESG state: I-D Exists -->
<reference anchor='APPALA'>
<front>
<title>XMPP Protocol Extensions for Use with IODEF</title>

<author initials='N' surname='Cam-Winget' fullname='Nancy Cam-Winget'>
    <organization />
</author>

<author initials='S' surname='Appala' fullname='Syam Appala'>
    <organization />
</author>

<author initials='S' surname='Pope' fullname='Scott Pope'>
    <organization />
</author>

<date month='October' day='15' year='2015' />

</front>

<seriesInfo name='Work in Progress,' value='draft-appala-mile-xmpp-grid-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-appala-mile-xmpp-grid-01.txt' />
</reference>


<!-- I-D.ietf-mile-rolie-05 IESG state: I-D Exists -->

<reference anchor='ROLIE'>
<front>
<title>Resource-Oriented Lightweight Information Exchange</title>

<author initials='J' surname='Field' fullname='John Field'>
    <organization />
</author>

<author initials='S' surname='Banghart' fullname='Stephen Banghart'>
    <organization />
</author>

<author initials='D' surname='Waltermire' fullname='David Waltermire'>
    <organization />
</author>

<date month='October' day='31' year='2016' />

</front>

<seriesInfo name='Work in Progress,' value='draft-ietf-mile-rolie-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-mile-rolie-05.txt' />
</reference>


<reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf">
  <front>
    <title>Architectural Styles and the Design of Network-based Software Architectures</title>
    <author initials="R." surname="Fielding" fullname="Roy Thomas Fielding">
      <organization>University of California, Irvine</organization>
    </author>
    <date year="2000"/>
  </front>
  <seriesInfo name="Ph.D." value="Dissertation, University of California, Irvine"/>
  <format type="PDF" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf"/>
</reference>


    </references>

 <section title="IAB Members at the Time of Approval" numbered="no">

  <t>The IAB members at the time this memo was approved were (in alphabetical order):                                                       

<?rfc subcompact="yes" ?>
<list>
 <t>Jari Arkko</t>
 <t>Ralph Droms</t>
 <t>Ted Hardie</t>
 <t>Joe Hildebrand</t>
 <t>Russ Housley</t>
<t>Lee Howard</t>
 <t>Erik Nordmark</t>
 <t>Robert Sparks</t>
 <t>Andrew Sullivan</t>
 <t>Dave Thaler</t>
<t>Martin Thomson</t>
 <t>Brian Trammell</t>
 <t>Suzanne Woolf</t>
</list>
<?rfc subcompact="no" ?>
  </t>
  </section>

<section anchor="acknowledgements" title="Acknowledgements" numbered="no">

<t>Thanks are due to the members of the program committee (in alphabetical
order) for their efforts to make the CARIS workshop possible and a productive
session with cross area expertise: Matthew Ford (Internet Society, UK), Ted
Hardie (Google, USA), Joe Hildebrand (Cisco, USA), Eliot Lear (Cisco,
Switzerland), Kathleen M. Moriarty (EMC Corporation, USA), Andrew Sullivan
(Dyn, USA), and Brian Trammell (ETH Zurich, Switzerland).</t>

<t>Thanks are also due to the CARIS workshop sponsors:</t>

<t><list style="symbols">
  <t>FIRST provided a room and excellent facilities in partnership with their annual conference in Berlin.</t>
  <t>The Internet Society hosted the social event, a boat ride through
  the canals of Berlin.</t>
  <t>EMC Corporation provided lunch, snacks, and coffee throughout the day to keep the attendees going.</t>
</list></t>

</section>
<section anchor="workshop-attendees" title="Workshop Attendees" numbered="no">

<t>In alphabetical order by first name, workshop attendees were: Adli Wahid,
Alexey Melnikov, Andrew Sullivan, Arnold Sykosch, Brian Trammell, Chris
Morrow, Cristine Hoepers, Dario Forte, Dave Cridland, Dave Dittrich, Eliot
Lear, Foy Shiver, Frank Xialiang, Graciella Martinez, Jessica Stienberger, Jim
Duncan, Joe Hildebrand, John Bond, John Graham-Cummings, John Kristoff,
Kathleen Moriarty, Klaus Steding-Jessen, Linda Dunbar, Marco Obiso, Martin
Stiemerling, Mat Ford, Merike Kaeo, Michael Daly, Mio Suzuki, Mirjam Kuehne,
Fu TianFu, Nancy Cam-Winget, Nik Teague, Pat Cain, Roland Dobbins, Roman
Danyliw, Rosella Mattioli, Sandeep Bhatt, Scott Pinkerton, Sharifah Roziah
Mohd Kassim, Stuart Murdoch, Takeshi Takahashi, Ted Hardie, Tobias Gondrom,
Tom Millar, Tomas Sander, Ulrich Seldeslachts, Valerie Duncan, and Wes Young.</t>

</section>


  </back>
</rfc>

