doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc8073.txt b/doc/rfc/rfc8073.txt
new file mode 100644
index 0000000..5702d09
--- /dev/null
+++ b/doc/rfc/rfc8073.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB)                            K. Moriarty
+Request for Comments: 8073                                       M. Ford
+Category: Informational                                       March 2017
+ISSN: 2070-1721
+
+
+ Coordinating Attack Response at Internet Scale (CARIS) Workshop Report
+
+Abstract
+
+   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.
+
+   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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Architecture Board (IAB)
+   and represents information that the IAB has deemed valuable to
+   provide for permanent record.  It represents the consensus of the
+   Internet Architecture Board (IAB).  Documents approved for
+   publication by the IAB are not a candidate 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
+   http://www.rfc-editor.org/info/rfc8073.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty & Ford               Informational                     [Page 1]
+
+RFC 8073                          CARIS                       March 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 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
+   (http://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  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Sessions and Panel Groups . . . . . . . . . . . . . . . . . .   4
+     2.1.  Coordination between CSIRTs and Attack Response
+           Mitigation Efforts  . . . . . . . . . . . . . . . . . . .   5
+     2.2.  Scaling Response to DDoS and Botnets Effectively and
+           Safely  . . . . . . . . . . . . . . . . . . . . . . . . .   8
+     2.3.  DNS and RIRs: Attack Response and Mitigation  . . . . . .   9
+     2.4.  Trust Privacy and Data Markings Panel . . . . . . . . . .  10
+   3.  Workshop Themes . . . . . . . . . . . . . . . . . . . . . . .  11
+   4.  Next Steps  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+     4.1.  RIR and DNS Provider Resources  . . . . . . . . . . . . .  12
+     4.2.  Education and Guidance  . . . . . . . . . . . . . . . . .  12
+     4.3.  Transport Options . . . . . . . . . . . . . . . . . . . .  12
+     4.4.  Updated Template for Information Exchange Groups  . . . .  13
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
+   6.  Informative References  . . . . . . . . . . . . . . . . . . .  13
+   Appendix A. Workshop Attendees  . . . . . . . . . . . . . . . . .  15
+   IAB Members at the Time of Approval . . . . . . . . . . . . . . .  15
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty & Ford               Informational                     [Page 2]
+
+RFC 8073                          CARIS                       March 2017
+
+
+1.  Introduction
+
+   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.
+
+   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.
+
+   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.
+
+   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 [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.
+
+   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
+
+
+
+Moriarty & Ford               Informational                     [Page 3]
+
+RFC 8073                          CARIS                       March 2017
+
+
+   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 [AGENDA].
+
+   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 [KME] for additional information on
+   possible approaches to accomplish more effective attack response and
+   information exchanges with methods that require fewer analysts.
+
+   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.
+
+2.  Sessions and Panel Groups
+
+   After an initial presentation to set the stage and elaborate the
+   goals of the workshop, the day was divided into five sessions as
+   follows:
+
+   1.  Coordination between CSIRTs and attack-response mitigation
+       efforts
+
+   2.  Scaling response to Distributed Denial-of-Service (DDoS) and
+       botnets effectively and safely
+
+   3.  Infrastructure: DNS and RIR providers and researchers
+
+   4.  Trust and Privacy with the exchange of potentially sensitive
+       information
+
+   5.  Implications for Internet architecture and next steps
+
+   The remainder of this report will provide more detail on each of
+   these sessions.
+
+
+
+
+
+Moriarty & Ford               Informational                     [Page 4]
+
+RFC 8073                          CARIS                       March 2017
+
+
+2.1.  Coordination between CSIRTs and Attack Response Mitigation Efforts
+
+   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:
+
+   o  What is the use case for their organization?
+
+   o  Where are they focusing their efforts?
+
+   o  How can others engage with their organization?
+
+   o  Who participates in their organization today?
+
+   For each of the following organizations, additional information can
+   be found in their template submissions [ISOC].
+
+   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.
+
+   o  ENISA is the European Network and Information Security Agency
+      [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.
+
+   o  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 [APWG] in addition to their template submission.
+
+   o  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
+
+
+
+Moriarty & Ford               Informational                     [Page 5]
+
+RFC 8073                          CARIS                       March 2017
+
+
+      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 [REN-ISAC].
+
+   o  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 [CERT.BR].
+
+   o  MyCERT's mission is to address the security concerns of Malaysian
+      Internet users and reduce the probability of successful attacks
+      [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.
+
+   o  The CERT Coordination Center (CERT/CC) has been operational since
+      1998 on an international and national scale [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.
+
+   Highlights from the panel discussion:
+
+   o  Passive surveillance by state actors has impacted incident
+      response activities due to the erosion of trust between
+      communities.
+
+
+
+
+
+
+Moriarty & Ford               Informational                     [Page 6]
+
+RFC 8073                          CARIS                       March 2017
+
+
+   o  Government involvement in information exchange efforts has not
+      been productive.  Despite lots of discussion, there have not been
+      useful outcomes.
+
+   o  There is more interest in consuming feeds of information than
+      sharing information.
+
+   o  Ego has been a big issue for improving data sharing, as have
+      reputation-related concerns when sharing or receiving data.
+
+   o  There is a perception of weakness around organizations that share
+      attack information in some regions.
+
+   o  Sharing in isolation doesn't help, it must lead to operational
+      return on investment.
+
+   o  Language barriers have been an issue for some national CSIRTs.
+
+   o  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.
+
+   o  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).
+
+   o  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.
+
+   o  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.
+
+   o  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.
+
+
+
+Moriarty & Ford               Informational                     [Page 7]
+
+RFC 8073                          CARIS                       March 2017
+
+
+2.2.  Scaling Response to DDoS and Botnets Effectively and Safely
+
+   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 [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.
+
+   Key points from the discussion:
+
+   o  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.
+
+   o  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.
+
+   o  There are ad hoc trust groups within the operations security
+      (OPSEC) community today.  The Cybercrime Response Advisory Group
+      (CRAG) is one example.
+
+   o  Filtering and triage is an issue, but this is a solvable problem.
+
+   o  The IETF DDOS Open Threat Signaling (DOTS) working group was
+      discussed and compared to a previous effort, Real-time Inter-
+      network defense (RID) [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.
+
+   o  The IETF Interface to Network Security Functions (I2NSF) effort
+      was discussed to explore ways of leveraging infrastructure to
+      combat DDoS attacks.
+
+
+
+
+
+Moriarty & Ford               Informational                     [Page 8]
+
+RFC 8073                          CARIS                       March 2017
+
+
+   o  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 [AGENDA]).
+
+   o  Trust and reputation of data sources is still a concern.
+
+   o  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.
+
+   o  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).
+
+   o  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.
+
+2.3.  DNS and RIRs: Attack Response and Mitigation
+
+   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.
+
+   Key discussion points:
+
+   o  The use of passive DNS in attack mitigation was described.
+
+   o  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.
+
+
+
+
+
+Moriarty & Ford               Informational                     [Page 9]
+
+RFC 8073                          CARIS                       March 2017
+
+
+   o  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.
+
+   o  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.
+
+   o  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.
+
+2.4.  Trust Privacy and Data Markings Panel
+
+   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.
+
+   Key points from the panel discussion:
+
+   o  Operationally focused groups do retain/rate/re-mark confidence
+      levels based upon the submitter's reputation.
+
+   o  The Traffic Light Protocol (TLP) [TLP] was discussed.  While TLP
+      is useful to some groups who exchange data, others find that it is
+      not granular enough for their needs.
+
+   o  In many cases, when data is shared, the user never knows, and
+      there is no way to manage that disclosure.
+
+   o  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.
+
+
+
+
+
+Moriarty & Ford               Informational                    [Page 10]
+
+RFC 8073                          CARIS                       March 2017
+
+
+   o  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?
+
+   o  Observing participants noted that there appear to be cabals
+      operating the groups based on the current trust notions.  This was
+      not disputed.
+
+   o  Transparency is vital to maintain trust.
+
+   o  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.
+
+   o  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.
+
+   o  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.
+
+   o  There was common agreement that reputation is fundamental.
+
+3.  Workshop Themes
+
+   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:
+
+   1.  Exchanging data should not be just for the purpose of creating
+       blacklists that could be redundant efforts.
+
+   2.  Involving service providers and vendors to better coordinate and
+       scale response is key.
+
+
+
+
+
+
+
+Moriarty & Ford               Informational                    [Page 11]
+
+RFC 8073                          CARIS                       March 2017
+
+
+   Secondly, information security practitioners are a scarce resource:
+
+   1.  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.
+
+   2.  Leveraging resources to better scale response, using fewer
+       resources is critical.
+
+4.  Next Steps
+
+4.1.  RIR and DNS Provider Resources
+
+   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.
+
+4.2.  Education and Guidance
+
+   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 [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.
+
+4.3.  Transport Options
+
+   One of the more lively discussions was the need for better transports
+   for information exchange.  Real-time Inter-network Defense (RID)
+   [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) [RFC6120]
+   inherently meets the requirements for today's information exchanges
+
+
+
+Moriarty & Ford               Informational                    [Page 12]
+
+RFC 8073                          CARIS                       March 2017
+
+
+   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 [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 [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 [ROLIE].
+
+4.4.  Updated Template for Information Exchange Groups
+
+   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.
+
+5.  Security Considerations
+
+   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.
+
+6.  Informative References
+
+   [AGENDA]   "Agenda: Coordinating Attack Response at Internet Scale
+              (CARIS) Workshop", 2015,
+              <https://www.iab.org/activities/workshops/caris/agenda/>.
+
+   [APPALA]   Cam-Winget, N., Ed., Appala, S., and S. Pope, "XMPP
+              Protocol Extensions for Use with IODEF", Work in Progress,
+              draft-ietf-mile-xmpp-grid-01, October 2016.
+
+   [APWG]     "APWG Homepage", <http://www.antiphishing.org>.
+
+   [CERT.BR]  "Brazilian National Computer Emergency Response Team
+              Homepage", <http://www.cert.br/en/>.
+
+
+
+
+Moriarty & Ford               Informational                    [Page 13]
+
+RFC 8073                          CARIS                       March 2017
+
+
+   [CERTCC]   "CERT Coordination Center Homepage",
+              <https://www.cert.org>.
+
+   [DD1]      Dittrich, D., "Taking Down Botnets - Background", April
+              2015, <https://www.iab.org/wp-content/IAB-uploads/2015/
+              04/CARIS_2015_submission_21.pdf>.
+
+   [ENISA]    "European Union Agency for Network and Information
+              Security Homepage", <https://www.enisa.europa.eu>.
+
+   [ISOC]     "CARIS Workshop Template Submissions 2015",
+              <https://www.internetsociety.org/doc/
+              caris-workshop-template-submissions-2015>.
+
+   [KME]      Moriarty, K., "Kathleen Moriarty Blog Series", July 2015,
+              <http://blogs.rsa.com/author/kathleen-moriarty/>.
+
+   [MYCERT]   "Malaysia Computer Emergency Response Team Homepage",
+              <https://www.mycert.org.my/en/>.
+
+   [REN-ISAC] "Research and Education Networking Information Sharing and
+              Analysis Center Homepage", <http://ren-isac.net>.
+
+   [REST]     Fielding, R., "Architectural Styles and the Design of
+              Network-based Software Architectures", Ph.D. Dissertation,
+              University of California, Irvine, 2000,
+              <http://www.ics.uci.edu/~fielding/pubs/dissertation/
+              fielding_dissertation.pdf>.
+
+   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
+              Defeating Denial of Service Attacks which employ IP Source
+              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
+              May 2000, <http://www.rfc-editor.org/info/rfc2827>.
+
+   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
+              March 2011, <http://www.rfc-editor.org/info/rfc6120>.
+
+   [RFC6545]  Moriarty, K., "Real-time Inter-network Defense (RID)",
+              RFC 6545, DOI 10.17487/RFC6545, April 2012,
+              <http://www.rfc-editor.org/info/rfc6545>.
+
+   [ROLIE]    Field, J., Banghart, S., and D. Waltermire, "Resource-
+              Oriented Lightweight Information Exchange", Work in
+              Progress, draft-ietf-mile-rolie-06, March 2017.
+
+   [TLP]      "Traffic Light Protocol (TLP) Matrix and Frequently Asked
+              Questions", <https://www.us-cert.gov/tlp>.
+
+
+
+Moriarty & Ford               Informational                    [Page 14]
+
+RFC 8073                          CARIS                       March 2017
+
+
+Appendix A.  Workshop Attendees
+
+   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.
+
+IAB Members at the Time of Approval
+
+   The IAB members at the time this memo was approved were (in
+   alphabetical order):
+
+      Jari Arkko
+      Ralph Droms
+      Ted Hardie
+      Joe Hildebrand
+      Russ Housley
+      Lee Howard
+      Erik Nordmark
+      Robert Sparks
+      Andrew Sullivan
+      Dave Thaler
+      Martin Thomson
+      Brian Trammell
+      Suzanne Woolf
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty & Ford               Informational                    [Page 15]
+
+RFC 8073                          CARIS                       March 2017
+
+
+Acknowledgements
+
+   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).
+
+   Thanks are also due to the CARIS workshop sponsors:
+
+   o  FIRST provided a room and excellent facilities in partnership with
+      their annual conference in Berlin.
+
+   o  The Internet Society hosted the social event, a boat ride through
+      the canals of Berlin.
+
+   o  EMC Corporation provided lunch, snacks, and coffee throughout the
+      day to keep the attendees going.
+
+Authors' Addresses
+
+   Kathleen M. Moriarty
+   176 South Street
+   Hopkinton, MA
+   United States of America
+
+   Email: Kathleen.Moriarty@dell.com
+
+
+   Mat Ford
+   Galerie Jean-Malbuisson 15
+   Geneva
+   Switzerland
+
+   Email: ford@isoc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty & Ford               Informational                    [Page 16]
+