RFC 8073

Coordinating Attack Response at Internet Scale (CARIS) Workshop Report

📅 published March 2017, from ietf

Coordinating Attack Response at Internet Scale (CARIS) Workshop Report 🎀

Okay bestie, let's do the vibe check first 💖 This is RFC 8073, written by K. Moriarty and M. Ford and published in March 2017. It's in the Informational category (ISSN 2070-1721), and the Internet Architecture Board (IAB) put it out. Its title block has no Obsoletes or Updates line, so it doesn't claim to obsolete or update any other RFC 📜✨

Abstract 🦋

This report spills the tea on the discussions and conclusions from the Coordinating Attack Response at Internet Scale (CARIS) workshop, which happened in Berlin, Germany on 18 June 2015 🌍 The whole point was to boost mutual awareness, understanding, and coordination among all the different organizations and reps who showed up 🫶

Heads up: this doc is a report on what went down at the workshop. The views and positions in it belong to the workshop participants, and they don't necessarily match the IAB's views and positions 💅

Status of This Memo 📌

This doc is not an Internet Standards Track spec. It's published for informational purposes, so no standards vibes here 🙈

It's a product of the Internet Architecture Board (IAB), and it's info the IAB decided was worth keeping on the permanent record 📚 It represents the consensus of the IAB. Documents the IAB approves for publication are not a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for the deets 🔥

For the current status, any errata, and how to give feedback, check out http://www.rfc-editor.org/info/rfc8073 🌸

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please review those carefully, because they spell out your rights and restrictions for 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

1. Introduction ✨

Okay so the IAB holds occasional workshops to look at long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture 🔭 This long-term planning is complementary to the ongoing engineering work done by IETF working groups, which runs under the IESG and area directorates 💅

The IAB and the Internet Society (ISOC) hosted a day-long CARIS workshop on 18 June 2015, in coordination with the Forum for Incident Response and Security Teams (FIRST) Conference in Berlin 🇩🇪 The crowd included folks from the FIRST community, attack response working group reps, network and security operators, Regional Internet Registry (RIR) reps, researchers, vendors, and reps from standardization communities 🤩 The big goals were to boost mutual awareness, understanding, and coordination among all these orgs. The workshop also wanted attendees to get more aware of existing efforts to mitigate specific types of attacks, and to understand better the options they have to collaborate and engage with those efforts 🦋

The day was a mix of invited talks and panel discussions, with chances to collaborate the whole way through. It really took full advantage of having these diverse communities with common goals in one room, and honestly that's so iconic 👑 There were approximately 50 participants 🫶

Attendance was by invitation only 💌 Before the workshop, existing attack-mitigation working groups were asked to fill out a survey. The data from that questionnaire, including how third parties can participate in or contribute to an attack-mitigation working group, was shared with all the participants to help them collaborate better [ISOC]. Attendees were also picked from submissions of two-page position papers that had some key insight or challenge relevant to the wider group 📝 The paper topics covered research on attack mitigation or information sharing/exchange, success stories, lessons learned, and deeper studies on specific topics like privacy or trust 🔍

The program committee got 25 papers and 19 template submissions 📂 The template submissions will be maintained by the Internet Society. As a result of the workshop, they'll be amended to add more value for the Computer Security Incident Response Teams (CSIRTs) and attack response communities/operators, specifically on their information exchange capabilities 🛠️ The CARIS participants found the template submissions super useful for coordinating their future attack mitigation efforts 🙌 This initiative is new, open to the global community, and hosted in a neutral location 🌐 All the submissions are online and 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 set up to get specific groups talking to each other, to see if progress could be made toward more efficient and effective attack mitigation efforts 💬 For more info on possible approaches to more effective attack response and information exchanges that need fewer analysts, see [KME] 🧠

The workshop ran under the Chatham House Rule to make it easier to share sensitive information involved with incident response 🤫 So there was no recording, but minutes were taken and used to help generate this report 📝 Comments won't be attributed to any particular attendee. Also, organizations won't be named alongside any discussion topics that weren't 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 lay out the goals of the workshop, the day was split into five sessions 🎀

  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 rest of this report gets into more detail on each of these sessions 🦋

2.1. Coordination between CSIRTs and Attack Response Mitigation Efforts ✨

okay so the first panel was about Coordination between CSIRTs and attack mitigation efforts 🫶 and it had reps from a bunch of orgs that sent in templates describing what they do for attack mitigation. it was on purpose a cross section of orgs, so everyone could see if there were new ways to collaborate and be more efficient, which is how you scale attack mitigation better 🧠✨ the panelists talked about their stuff with these questions in mind:

  • What is the use case for their organization?
  • Where are they focusing their efforts?
  • How can others engage with their organization?
  • Who participates in their organization today?

for each of the orgs below, more info is in their template submissions [ISOC] 📎

the summaries below are meant to be read as part of the workshop, NOT as standalone descriptions of each org 🙈 they came out of the workshop discussions, so don't take them as the final word on who these orgs are 💅

  • ENISA is the European Network and Information Security Agency [ENISA] 🇪🇺 it's giving education, training, and collaboration on security and attack mitigation, but it does not offer a service for attack response or mitigation 🫠
  • The Anti-Phishing Working Group (APWG) shared examples of operator-driven exchanges focused on specific use cases, with hundreds of participating orgs daily 🔥 they run a data clearinghouse and provide infrastructure so meaningful data exchanges can happen, and they keep a current set of data through those interactions 📊 you can learn more on the APWG website [APWG] plus their template submission 💜
  • The Research and Education Networking Information Sharing and Analysis Center (Ren-ISAC) has an interesting operational model that scales really well through automation 🤖✨ they exchange actionable info between 500 universities and automatically implement controls. lowkey genius: a lot of universities can't respond to incidents in real time because they're short on resources, so REN-ISAC uses a small number of analysts to protect many universities through automation 👑 the key to their success is giving orgs tools that let them use incident data operationally 🧚 they're now working on open-source tools to track metrics more formally [REN-ISAC] 🌈
  • CERT.br is the Brazilian Computer Emergency Response Team (CERT) and has made seriously impressive progress in a short amount of time 🇧🇷💖 it's the national focal point for incident reporting, collection, and dissemination of threat and attack trend info in Brazil. CERT.br works to boost awareness and incident-handling capabilities in the country and helps set up new CSIRTs 🌸 on top of 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 who want to collaborate and exchange data with them [CERT.BR] 🎀
  • MyCERT's mission is to address the security concerns of Malaysian Internet users and reduce the probability of successful attacks [MYCERT] 🦋 they've been operational since 1997 🍓 MyCERT handles incident response for unauthorized intrusions, identity theft, DDoS attacks, etc., handles computer security incidents in Malaysia, provides malware research, and does technical coordination 🛡️ on top of incident response and coordination, MyCERT members give talks and training, and run local and regional security exercises 🎤 they also send out incident alerts and advisories on vulnerabilities, breaches, etc. 📢
  • The CERT Coordination Center (CERT/CC) has been operational since 1998 on an international and national scale [CERTCC] 🌍 they're long known for their software vulnerability work, the national vulnerability database in the US (Common Vulnerabilities and Exposures -- CVEs), and informing orgs about vulnerabilities 😭 CERT/CC helps coordinate between vendors and researchers for better collaboration 🫶 they also give guidance on dealing with the aftermath of incidents, risk assessment best practices, bug bounties, and other incident-related stuff 💼

highlights from the panel discussion 💅:

  • Passive surveillance by state actors has impacted incident response activities because trust between communities has eroded 💀
  • Government involvement in information exchange efforts has not been productive 😩 there's been lots of discussion, but no useful outcomes yet
  • There's more interest in consuming feeds of information than in sharing information 📥
  • Ego has been a big issue for improving data sharing, and so have reputation concerns when sharing or receiving data 🙃
  • In some regions there's a perception of weakness around orgs that share attack information 🥺
  • Sharing in isolation doesn't help. It has to lead to operational return on investment 💸
  • Language barriers have been an issue for some national CSIRTs 🌐
  • Sharing too much info leads to capacity and resource issues for receiving orgs 😵‍💫 orgs directly receiving feeds can often misinterpret data and think they're under attack when they're not 🚨 operational models are preferred, where data exchanges have a direct impact on improving the efficiency of a small number of analysts so they can impact many 🧠✨
  • Privacy regulations that restrict some orgs from sharing IP address information have hurt the effectiveness of incident data exchanges 🔒 ENISA is currently running a study on this impact (several attendees brought this up) 📚
  • Too many efforts use 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 because they actually do eliminate threats and update data warehouses ✅
  • Involving vendors is needed to scale attack response better 💜 not everyone sees this as a need, but some sharing groups with an operational focus want improved efficiency so they can use a small number of analysts more productively 🧑‍💻 analysts are a limited resource in this technical area of expertise 😮‍💨
  • Enterprises don't want more security boxes in their networks because they don't have the resources to manage them 📦🙅‍♀️ so involving vendors doesn't mean deploying more equipment. it means improving automated controls and eliminating threats wherever possible 🎯 false positives are still an issue, and that can be a problem for some automation activities 🤦‍♀️

2.2. Scaling Response to DDoS and Botnets Effectively and Safely 🌟

the first invited talk at the workshop was an interesting history of Distributed Denial-of-Service (DDoS) attacks 📜 and how botnets evolved, plus the methods to fight these threats ⚔️ Dave Dittrich's paper [DD1] is the place to go if you want the full history 📖 this section focuses on the workshop discussion, so we can learn from the attendees' thoughts on how to better scale our response to these threats 🧠💖

key points from the discussion 🔑:

  • Of the attack types discussed, DDoS and botnets look furthest along when it comes to efficient and effective response 🏆 other efforts can learn from that experience. but there hasn't been any interaction between these two attack types that might benefit from information exchange tied to remediation activities, even though botnets can be the source of DDoS attacks 🤯
  • There's a disparity between short-term mitigation goals and actual eradication of DDoS and botnet threats 📉 the question came up: 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 isn't shared between the service providers and vendors responding to DDoS threats and the groups actively mitigating and eradicating botnets 🙈
  • There are ad hoc trust groups within the operations security (OPSEC) community today 🤝 the Cybercrime Response Advisory Group (CRAG) is one example 🕵️‍♀️
  • Filtering and triage is an issue, but it's a solvable problem 🧩✨
  • The IETF DDOS Open Threat Signaling (DOTS) working group was discussed and compared to an earlier effort, Real-time Inter-network defense (RID) [RFC6545] 👯‍♀️ it was said the two are similar, except DOTS makes use of current data formats and protocols and has the support of multiple DDoS vendors 🥳 one of DOTS' goals is to be the "glue" between vendors, letting them communicate shared data using standard formats and protocols developed in open-source tools 🧷💜
  • The IETF Interface to Network Security Functions (I2NSF) effort was discussed as a way to explore leveraging infrastructure to combat DDoS attacks 🛠️
  • Vendors talked about existing capabilities for DDoS mitigation, while data-sharing groups talked about 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]) 📋
  • Trust and reputation of data sources is still a concern 🥹
  • One of the exchange groups has a goal of "automated takedowns" for botnets 🎯 however, they think they'll always need manual intervention 🙋‍♀️
  • The need for multiple levels of trust seemed to be everywhere among those in the panel discussion 🪜 intelligence agencies erode trust (this also came up in the first panel, around government surveillance activities) 🕶️
  • Even though trust came up in this panel and there are concerns, it was noted that trust isn't as big a barrier for DDoS and botnet mitigation 💪 and this is likely because of the operational experience of the participants 🌈✨

2.3. DNS and RIRs: Attack Response and Mitigation 🌐

okay so this session was a total vibe shift 💅 because the panelists were the infrastructure providers helping the people fighting attacks. it was all about how attack and incident responders could work better with DNS infrastructure orgs and RIRs. these groups had literally never really interacted before, and it was so interesting to see the collab opportunities, since the workshop people rely on these services to do their jobs 🫶 from the panelists' side, DNS and RIRs feel like separate worlds, and they spend a LOT of time trying to explain to policy makers how they work together to keep the Internet running ✨

Key discussion points:

  • The use of passive DNS in attack mitigation was described. 🔍
  • RIRs talked about the data they maintain and share, including worldwide BGP update data and root DNS server data. 📊 These datasets can be shared with researchers and could be useful for anyone working on attack response. The current way the data is made available does not scale 💀 so ideas were discussed at the workshop for making it more scalable, in case it becomes a more widely used resource.
  • Some of the global RIRs already actively coordinate with incident responders in their region 🤝 In some cases they help with information sharing and also offer education and training. Data shared out by RIRs is anonymized. 🙈
  • Someone raised a concern about overlapping efforts and asked the IETF and ISOC to pay attention to this and help out 🥺 This workshop was one step toward that, bringing together a really diverse community. The participants wanted this kind of event repeated for future cross-area collaboration, because the different groups usually only meet inside their own silo 🧚
  • Standards for APIs that consistently access data from RIRs, plus scoring methods, were discussed as possible ways to scale trust 🔥 People asked how this could actually be possible. You might receive data about a network that you can't verify. You may be able to verify the source's identity and verify route origins, but you won't be able to verify the provenance of the data 😭

2.4. Trust Privacy and Data Markings Panel 🔐

okay the big question: 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 worries about sharing proprietary data with competitors. that said, most of these reasons got dismissed as bogus by the more operationally focused people at the workshop 💅 lawyers need contextual education on where law and technology intersect. and sensitive data is still a problem, because you can't control what others do with data once it's been shared 💀

Key points from the panel discussion:

  • Operationally focused groups do retain, rate, and re-mark confidence levels based on the submitter's reputation. 🏷️
  • The Traffic Light Protocol (TLP) [TLP] was discussed. TLP is useful to some groups who exchange data, but others find it isn't granular enough for what they need 🚦
  • In many cases, when data is shared, the user never knows where it goes, and there's no way to manage that disclosure. 👀
  • Trust is personal 💖 When sharing circles get too big, trust breaks down. Several people who are actively exchanging data really emphasized the personal relationship side of information sharing communities. This was a very prevalent theme 🫶
  • A comparison was made with consumer goods, and it was noticed that trademarks are a byproduct of the Industrial Revolution. The question came up: does trust need branding? 🤨
  • Observing participants noted that there appear to be cabals running the groups based on current trust notions 😬 Nobody disputed this.
  • Transparency is vital to maintaining trust. ✨
  • People working on automation have found they need to share with organizations of all sizes, and they need to share both synchronously and asynchronously. In an automated model, they must ensure data sources are "authorized" 🤖 These efforts have run into questions about anonymization, and regional regulatory perspectives vary too 🌍
  • Another automation effort found that people have different upper limits for trust group scale. That's sometimes based on individual knowledge of other participants and how comfortable they feel with them 🥹 Social interaction (beer) is a common thread among sharing partners when building trust relationships 🍻 The relationships form between individuals, not necessarily between organizations 💜
  • 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). But in aggregate, non-PII can become PII 🫠
  • There was common agreement that reputation is fundamental 👑

3. Workshop Themes 🌸

okay so during the day, a couple of themes kept coming up in the discussions 💕 First, in order to better scale attack response by improving the efficiency and effectiveness of information exchanges:

  1. Exchanging data should not be just for the purpose of creating blacklists, since that could mean redundant efforts 🚫
  2. Involving service providers and vendors to better coordinate and scale response is key 🔑

Second, information security practitioners are a scarce resource 😩

  1. Training and education was discussed as a way to close this gap, both to train information security professionals and to teach others in IT 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 are really interested in more information about the resources and assistance that RIRs and DNS providers offer. Participants are going to define what is needed 🎯

4.2. Education and Guidance 🎓

Another theme that kept coming up was the community's lack of knowledge about basic security principles, like ingress and egress filtering explained in BCP 38 [RFC2827]. The CSIRTs, operators, and vendors of attack mitigation tools found this especially frustrating 😤 As a result, follow-up activities may include figuring out whether security guidance BCPs need updates, or whether there are opportunities to educate people on these basic principles that the IETF has already documented 📖

4.3. Transport Options 🚚

One of the livelier discussions was about needing better transports for information exchange 🔥 Real-time Inter-network Defense (RID) [RFC6545] was published 5 years ago. The patterns it established still show promise, and there are updated solutions in the works 🙌 One such solution is in the IETF DOTS working group, which has an approach similar to RID but with updated formats and protocols to meet the demands of today's DDoS attacks 💥

Trusted Automated eXchange of Indicator Information (TAXII, another transport option) is just transitioning to the 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 pointed out several interoperability challenges with TAXII during 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 of today's information exchanges, with features like 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 its 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 make it more useful. There was a desire for additional information exchange groups to use it too, creating a living library 📚🧚 It would improve awareness about how to become a member of, benefit from, or contribute to the success of attack response and CSIRT information exchange platforms 🌟

5. Security Considerations 🛡️

okay, the CARIS workshop was all about security and methods to improve the effectiveness and efficiency of attack response so it can scale better 🔐 This report summarizes the workshop discussions and identifies some outcomes to improve security. As such, no additional considerations are provided in this section 💀

6. Informative References 📚✨

okay bestie, this is where the receipts live 💅 every doc the spec leans on is listed here so you can go check it yourself 🔍

[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/>.

[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>.

Appendix A. Workshop Attendees 🎀

In alphabetical order by first name, the 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

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:

  • FIRST provided a room and excellent facilities in partnership with their annual conference in Berlin. 🌸
  • The Internet Society hosted the social event, a boat ride through the canals of Berlin. 🛶
  • 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
📦 where this page comes from