- Gnso-ssr - lists.icann.org

an announcement from Mikey -- i'm retiring from ICANN
by Mike O'Connor April 7, 2014

April 7, 2014

dear all, just a quick note to let you know that i am retiring from ICANN. right now. how about that? it’s spring here at the farm and i’ve realized that it’s time for me to redirect my attention to things closer to home and heart. as you can see by the number of mailing lists this note is addressed to, i’ve spread myself too thin. somewhere along the line i burned myself out. i never was very good at seeing this “burnout" thing coming. oops... as to the “immediately” timeframe — well, i’m burned out. which means that the prospect of ICANN-related work just leaves me cold. so rather than drag myself (and you) through some half-baked transition period where i do an even worse job than i’ve been doing lately, i’m just making a clean break of it. it will turn out fine. you’ll see. as of this note i’m setting down all the trappings. GNSO Councillor, ISPCP support, the working groups, all the leadership-development and newcomer-orientation projects. i’m not throwing them down, just placing them gently there for somebody else to pick up and run with. this is the place where i’m supposed to write about how i’ll miss you all. but i’m not going to do that. through the miracle of this Internet thing, i plan to stay connected to you and maintain all those friendships that have developed over the years. i’m just stopping the work, not the relationships. maybe some day i’ll even dip my toe back into a working group or two. but not right away. right now that goes on the Too Hard pile. here’s a link to a pictorial tour of the farm. http://www.aprairiehaven.com/?page_id=23369 see that bench? that’s where i’ll be sitting, thinking of you. come visit. Marcie and i will show you around. onward, mikey PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

1 0

Update on the SSR Review Team recommendations tracking
by Patrick Jones March 26, 2014

March 26, 2014

A status report on the implementation of the Security, Stability and Resiliency Review Team recommendations can be viewed on the ICANN Accountability and Transparency page (http://www.icann.org/en/news/in-focus/accountability) The current report is at the top of the page, http://www.icann.org/en/about/aoc-review/ssr/implementation-status-18mar14-e n.pdf. This is part of more regular updates on the SSR RT implementation. Patrick -- Patrick L. Jones Senior Director, Global Stakeholder Engagement Internet Corporation for Assigned Names & Numbers 801 17th Street, NW, Suite 400 Washington, DC 20006 Tel: +1-202-570-7115 patrick.jones(a)icann.org

1 0

Broken TMCH?
by Mike O'Connor March 4, 2014

March 4, 2014

hi all, here’s a snip from the chat transcript of the recent CEO/Community-Leaders webinar. i’m curious about the “broken TMCH” comment that Patrik made. Patrik (or others) would you like to expand on that? i’m curious whether that would be an SSR topic that one/all of the GNSO constituencies might want to request a review by the SSAC. here’s the chat transcript: Patrik Fältström: I would like to remind everyone that regarding the issues SSAC have seen on broken TMCH has not been acted on, at all. And I urge people to not rely on TMCH yet. In any process. Patrik Fältström: https://www.myicann.org/board-advice#advice-to-board_f=tmch&advice-to-board… Michele Neylon: Security + stability issues should be core Michele Neylon: I thought they were core to ICANN’s mission Patrik Fältström: I also want to point out that we do have new gTLDs that are so broken technically that I think various clauses that say EBERO could be invoked has matched. Michele Neylon: Patrik - already? Michele Neylon: wow Patrik Fältström: Part from me supporting the issue that Michele mentioned, that the fact people in some legislations cannot sign contracts with ICANN due to US-centric clauses is something that MUST be addresses, or else our enemies might be able to say that "the internal ICANN change processes does not work" PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

4 15

SAC060 - User Experience Implications of Active Variant TLDs -- Procedure to Develop and Maintain Label Generation Rules for the Root Zone w/respect to IDN Labels
by Mike O'Connor March 4, 2014

March 4, 2014

hi all, this is a two-for-one deal — another SSAC-report thread AND a procedure. SAC060 came out in July, this Label Generation Rules procedure implementation report was just released for comment yesterday. it would be helpful to me to have a discussion about both at the same time, since SSAC seems to be making recommendations that bear, at least in part, on this procedure. i’m happy to split this topic in two if they really AREN’T about the same thing. :-) i will be the first to admit that i’m coming from behind on this issue. Chris Wright was kind enough to take me through the baby steps i needed to get a really basic introduction to the IDN Variant topic. we made a short series of videos from that conversation and you can view them on the ISPCP site. Chris did all the heavy lifting, i just listened and learned (a lot). here’s the link for those of you who’d like to get that briefing on the basics. http://www.ispcp.info/policy-resources/idns-a-brief-whirlwind-tour/ i’ve included the Executive Summary of SAC060 and a link to the newly-released procedure below. here’s my little list of questions: - how does the new procedure align with the SSAC findings? - are there gaps, overlaps, conflicts between the two? - is this even possible? reading both reports, i am struck by how nuanced this conversation is, especially in the “Procedure” document, and wonder if it will be possible to implement something like this. - are there things that the GNSO (community or PDP) can do to help at this time? mikey here’s a link to SAC060 — https://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf here’s the Executive Summary from SAC060, including brief summaries of the recommendations (sorry, once again there’s a little trouble with the formatting) Executive Summary At the request of the Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN), the ICANN Security and Stability Advisory Committee (SSAC) provides comments and advice regarding ICANN’s Report on Examining the User Experience Implications of Active Variant TLDs.1 With respect to that Report the SSAC makes the following recommendations: Recommendation 1: The root zone must use one and only one set of Label Generation Rules (LGR). Recommendation 2: ICANN must maintain a secure, stable, and objective process to resolve cases in which some members of the community (e.g., an applicant for a TLD) do not agree with the result of the LGR calculations. Recommendation 3: ICANN should concentrate foremost on the rules for the root zone. Recommendation 4: ICANN should coordinate and encourage adoption of these rules at the second and higher levels as a starting point by: Updating the IDN Implementation Guidelines and recognizing that a modified version of these rules or a review or appeals process must be required to address special cases for the first and second levels; Maintaining and publishing a central repository of rules for second- level domain labels (2LDs) for all Top Level Domains (TLDs), encouraging TLD operators to publish their LGRs publicly in the repository maintained by ICANN; and Conducting specific training and outreach sessions in cooperation with generic TLD (gTLD) and country code TLD (ccTLD) operators who intend to launch Internationalized Domain Name (IDN) 2LDs or IDN TLDs, with a focus on consistency of user experience. The outreach should include among others registrants, end users, and application developers. Recommendation 5: Be very conservative with respect to the code points that are permitted in root zone labels. Recommendation 6: Because the removal of a delegation from the root zone can have significant non-local impact, new rules added to a LGR must, as far as possible, be backward compatible so that new versions of the LGR do not produce results that are incompatible with historical (existent) activations. Recommendation 7: Should ICANN decide to implement safeguards, it should distinguish two types of failure modes when a user expects a variant to work, but it is not implemented: denial of service versus misconnection. Recommendation 8: A process should be developed to activate variants from allocatable variants in LGR. Recommendation 9: ICANN must ensure that Emergency Back-End Registry Operator (EBERO) providers support variant TLDs, and that parity exists for variant support in all relevant systems and functions associated with new TLD components. Recommendation 10: The current rights protection regime associated with the Trademark Clearinghouse (TMCH) process is susceptible to homographic attacks. The roles of the involved parties, specifically registrars, registries, and TMCH, related to matching must be made clear. Recommendation 11: When registries calculate variant sets for use in validation during registration, such calculations must be done against all of the implemented LGRs covering the script in which the label is applied for. Recommendation 12: The matching algorithm for TMCH must be improved. Recommendation 13: The TMCH must add support for IDN variant TLDs. Particularly during the TM Claims service, a name registered under a TLD that has allocated variant TLDs should trigger trademark holder notifications for the registration of the name in all of its allocated variant TLDs. Recommendation 14: ICANN should ensure that the number of strings that are activated is as small as possible. > > > > News Alert > > http://www.icann.org/en/news/announcements/announcement-2-03mar14-en.htm > > IDN Variant TLDs – LGR Procedure Implementation – Maximal Starting Repertoire Version 1 is Now Open for Public Comment > 3 March 2014 > > Forum Announcement: Comment Period Opens on Date: 3 March 2014 > Categories/Tags: > Internationalized Domain Names > IDN > IDN Variant TLD > new gTLD > Purpose (Brief): > As first deliverable under the "Procedure to Develop and Maintain Label Generation Rules for the Root Zone With Respect to IDN Labels" [PDF, 772 KB] (the Procedure), ICANN is releasing for public comment version 1 of the Maximal Starting Repertoire (MSR-1). The contents of MSR-1 and the detailed rationale behind its development are described in "Maximal Starting Repertoire – MSR-1-Overview and Rationale" [PDF, 393 KB]. > > Public Comment Box Link: http://www.icann.org/en/news/public-comment/msr-03mar14-en.htm > > > This message was sent to mike(a)haven2.com from: > ICANN | 12025 Waterfront Drive Suite 300 | Los Angeles, CA 90094-2536 > Email Marketing by > > Manage Your Subscription > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

1 0

Re: [Gnso-ssr] SAC065 - DDoS Attacks Leveraging DNS
by Michele Neylon - Blacknight March 3, 2014

March 3, 2014

Mikey I'd have to disagree with you about the hosting providers A LOT of them are not registrars And a LOT of them do not qualify for ISPCP membership This is something that people like Elliot Noss have raised in the past .. M -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: Mike O'Connor [mailto:mike@haven2.com] Sent: Monday, March 3, 2014 1:01 PM To: Michele Neylon - Blacknight Cc: GNSO SSR List Subject: Re: [Gnso-ssr] SAC065 - DDoS Attacks Leveraging DNS hi Michele, hm. a couple points. SAC65 isn't just talking about ISPs and hosting providers - it's really talking about network operators. all the way from individuals running their home networks up to content distribution networks, corporate networks, ISPs, hosting providers, the works. i'd love to see a strengthening of the relationships between the ICANN community and that broadly-defined network-operator community - this last series of SSAC reports just reminds me of that. the ISPCP is definitely in the game here. we actually has a very broad worldwide reach, which we've been refining as some of the more "operational" issues associated with the new gTLD program have come up. Name Collisions really got us going - we now publish a weekly email of the newly-delegated TLDs, aimed at non-members of the ISPCP (you can subscribe by going here - http://ispcp.info/mailman/listinfo/gtld-delegations ). i'm planning to post all these SSAC reports to our next "issue" at the end of the week. so fersure, the ISPCP is willing and able to help - but we're probably not the best group to *lead* a worldwide communications campaign. i will gently push back on the "truly representative" comment. most of our members are either from very large ISPs or represent regional ISP associations - so while our number is relatively small, we speak to a pretty large international audience (that is actually quite biased towards regions outside North America). we could always use help with outreach and recruiting, since most of us are focused more on policy-making than sales and marketing the ISPCP. but i would contend that we *are* pretty representative. and i'll also push back a bit on the lack of a home for hosting providers. it seems to me that they have three choices. if they are registrars (like you are), they can hang out in the Registrar SG. i would bet that just about every registrar has more money coming in from hosting than they do from sponsoring domain names. if they're ISPs, they are welcome in the ISPCP. some of Christian Dawson's members fall in this category and that's why he's representing those folks in our gang. if neither of those pertain, the Business Constituency could be the place to go. there's a pretty strong "operations oriented, large corporate network operator" subgroup in the BC (Jeff Brueggeman and Bill Smith come to mind as an examples). so back to the main point that i think we agree on - there's a real need to provide a clear channel for recommendations like the ones in this report and all the others to find an audience in the larger community of people who operate networks, yes? i'd love to help with that. mikey On Mar 3, 2014, at 3:38 AM, Michele Neylon - Blacknight <michele(a)blacknight.com<mailto:michele@blacknight.com>> wrote: Mikey Well there's a couple of things .. First off, if the ISPs were truly representative of ISPs around the globe, wouldn't that group be the one to share this kind of information far and wide within their member organisations? Though, as others have mentioned in the past, there's no real "home" for hosting providers etc., within ICANN at the moment and maybe they're the real audience for this .. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: gnso-ssr-bounces(a)icann.org<mailto:gnso-ssr-bounces@icann.org> [mailto:gnso-ssr-bounces@icann.org] On Behalf Of Mike O'Connor Sent: Monday, March 3, 2014 12:31 AM To: GNSO SSR List Subject: [Gnso-ssr] SAC065 - DDoS Attacks Leveraging DNS hi all, here's the second new SSAC report - SAC065 - DDoS Attacks Leveraging DNS http://www.icann.org/en/groups/ssac/documents/sac-065-en.pdf please read the report in it's original form and don't rely on this extract - the detailed recommendations are great. i'd have included them, but my cut/paste skills resulted in a format-mess. so i've just included the one-line summary recommendations in the Executive Summary. this report is another call to action - in this case, as an ISP, i feel that i'm included directly in this. i'm wondering how the ISP Constituency can join the effort that is being called for in this report, and would like to be put on the "interested in helping out list" if one is ever created. again, the question. who does what? where do the resources come from? John Crain's Security gang is hopelessly and woefully underfunded as it is. the ISP constituency raised the underfunding issue last year in our comments on the budget - and got roundly ignored, along with all the rest of the community input i saw. do we just shout again? shout louder? shout at somebody else? it's ridiculous to think that his tiny gang can do much about this without more support from above. meanwhile ICANN has multiple millions of dollars aimed at "Outreach" - shouldn't a big slice of that be aimed at topics like this one, towards the network-operator and DNS-operator audiences described in this report? <rant ends> thoughts? mikey Executive Summary This document is intended for the Internet technical community, particularly authoritative and recursive Domain Name System (DNS) operators, network operators, the Internet Corporation for Assigned Names and Numbers (ICANN), and policy makers. It explores several unresolved critical design and deployment issues that have enabled increasingly large and severe Distributed Denial of Service (DDoS) attacks using the DNS. While DDoS attacks can exploit multiple characteristics of network infrastructure and operations, the prevalence and criticality of the DNS means that securing it is both challenging and urgent. These unresolved DNS issues and related DDoS attacks pose a real and present danger to the security and stability of the Internet. The first recommendation below is made to ICANN, while others are made to operators of Internet infrastructure and manufacturers. While in many instances they reflect actions not under ICANN's control and actors not necessarily within ICANN's usual community, they are meant to address the overall responsibilities of the multi-stakeholder community and encourage ICANN to take action where it is relevant to do so. In particular, this means ICANN should be looking for ways to increase the effectiveness of steps already being taken against DNS abuse and promoting the participation of others as well as pursuing the measures suggested here. The Security and Stability Advisory Committee (SSAC) strongly recommends that all types of DNS operators and network operators take immediate steps to mitigate the design and deployment issues that make large scale DDoS attacks possible. Specifically, the SSAC strongly recommends that: 1. ICANN should help facilitate an Internet-wide community effort to reduce the number of open resolvers and networks that allow network spoofing. This effort should involve measurement efforts and outreach. 2. All network operators should take immediate steps to prevent network address spoofing. 3. Recursive DNS server operators should take immediate steps to secure open recursive DNS servers. 4. Authoritative DNS server operators should support efforts to investigate authoritative response rate limiting. 5. DNS server operators should put in place operational processes to ensure that their DNS software is regularly updated and communicate with their software vendors to keep abreast of the latest developments. 6. Manufacturers and/or configurators of customer premise networking equipment, including home networking equipment, should take immediate steps to secure these devices and ensure that they are field upgradable when new software is available to fix security vulnerabilities, and aggressively replace the installed base of non-upgradeable devices with upgradeable devices. 2. Why Is This Important? Critically, basic controls for network access and DNS security have not been as widely implemented as is necessary to maintain and grow a resilient Internet. When increasingly higher-speed Internet connections are combined with the growing power of individual end user devices, an unintended result is an extraordinary and growing capacity for conducting extremely large scale and highly disruptive DDoS attacks using unsecured DNS infrastructure. Paradoxically, the networks that fail to implement the best current security practices are the sources, not the destinations, of attack data flows. Defenders are powerless to influence the design and implementation of the attackers' preferred networks. It takes only a relatively modest number of end-user devices, for example, to build or rent as a botnet for an attacker to generate significant attack traffic using only a very few, generally well-managed DNS authoritative servers operated by entirely innocent third parties. These attacks have been growing in size over time, and are disrupting individual businesses;3 entire networks, critical applications and services;4 and entire countries.5 The scale of attacks will continue to grow if the Internet community takes no further action. PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com/>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

2 1

Re: [Gnso-ssr] SAC065 - DDoS Attacks Leveraging DNS
by Michele Neylon - Blacknight March 3, 2014

March 3, 2014

Mikey Well there's a couple of things .. First off, if the ISPs were truly representative of ISPs around the globe, wouldn't that group be the one to share this kind of information far and wide within their member organisations? Though, as others have mentioned in the past, there's no real "home" for hosting providers etc., within ICANN at the moment and maybe they're the real audience for this .. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: gnso-ssr-bounces(a)icann.org [mailto:gnso-ssr-bounces@icann.org] On Behalf Of Mike O'Connor Sent: Monday, March 3, 2014 12:31 AM To: GNSO SSR List Subject: [Gnso-ssr] SAC065 - DDoS Attacks Leveraging DNS hi all, here's the second new SSAC report - SAC065 - DDoS Attacks Leveraging DNS http://www.icann.org/en/groups/ssac/documents/sac-065-en.pdf please read the report in it's original form and don't rely on this extract - the detailed recommendations are great. i'd have included them, but my cut/paste skills resulted in a format-mess. so i've just included the one-line summary recommendations in the Executive Summary. this report is another call to action - in this case, as an ISP, i feel that i'm included directly in this. i'm wondering how the ISP Constituency can join the effort that is being called for in this report, and would like to be put on the "interested in helping out list" if one is ever created. again, the question. who does what? where do the resources come from? John Crain's Security gang is hopelessly and woefully underfunded as it is. the ISP constituency raised the underfunding issue last year in our comments on the budget - and got roundly ignored, along with all the rest of the community input i saw. do we just shout again? shout louder? shout at somebody else? it's ridiculous to think that his tiny gang can do much about this without more support from above. meanwhile ICANN has multiple millions of dollars aimed at "Outreach" - shouldn't a big slice of that be aimed at topics like this one, towards the network-operator and DNS-operator audiences described in this report? <rant ends> thoughts? mikey Executive Summary This document is intended for the Internet technical community, particularly authoritative and recursive Domain Name System (DNS) operators, network operators, the Internet Corporation for Assigned Names and Numbers (ICANN), and policy makers. It explores several unresolved critical design and deployment issues that have enabled increasingly large and severe Distributed Denial of Service (DDoS) attacks using the DNS. While DDoS attacks can exploit multiple characteristics of network infrastructure and operations, the prevalence and criticality of the DNS means that securing it is both challenging and urgent. These unresolved DNS issues and related DDoS attacks pose a real and present danger to the security and stability of the Internet. The first recommendation below is made to ICANN, while others are made to operators of Internet infrastructure and manufacturers. While in many instances they reflect actions not under ICANN's control and actors not necessarily within ICANN's usual community, they are meant to address the overall responsibilities of the multi-stakeholder community and encourage ICANN to take action where it is relevant to do so. In particular, this means ICANN should be looking for ways to increase the effectiveness of steps already being taken against DNS abuse and promoting the participation of others as well as pursuing the measures suggested here. The Security and Stability Advisory Committee (SSAC) strongly recommends that all types of DNS operators and network operators take immediate steps to mitigate the design and deployment issues that make large scale DDoS attacks possible. Specifically, the SSAC strongly recommends that: 1. ICANN should help facilitate an Internet-wide community effort to reduce the number of open resolvers and networks that allow network spoofing. This effort should involve measurement efforts and outreach. 2. All network operators should take immediate steps to prevent network address spoofing. 3. Recursive DNS server operators should take immediate steps to secure open recursive DNS servers. 4. Authoritative DNS server operators should support efforts to investigate authoritative response rate limiting. 5. DNS server operators should put in place operational processes to ensure that their DNS software is regularly updated and communicate with their software vendors to keep abreast of the latest developments. 6. Manufacturers and/or configurators of customer premise networking equipment, including home networking equipment, should take immediate steps to secure these devices and ensure that they are field upgradable when new software is available to fix security vulnerabilities, and aggressively replace the installed base of non-upgradeable devices with upgradeable devices. 2. Why Is This Important? Critically, basic controls for network access and DNS security have not been as widely implemented as is necessary to maintain and grow a resilient Internet. When increasingly higher-speed Internet connections are combined with the growing power of individual end user devices, an unintended result is an extraordinary and growing capacity for conducting extremely large scale and highly disruptive DDoS attacks using unsecured DNS infrastructure. Paradoxically, the networks that fail to implement the best current security practices are the sources, not the destinations, of attack data flows. Defenders are powerless to influence the design and implementation of the attackers' preferred networks. It takes only a relatively modest number of end-user devices, for example, to build or rent as a botnet for an attacker to generate significant attack traffic using only a very few, generally well-managed DNS authoritative servers operated by entirely innocent third parties. These attacks have been growing in size over time, and are disrupting individual businesses;3 entire networks, critical applications and services;4 and entire countries.5 The scale of attacks will continue to grow if the Internet community takes no further action. PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

2 1

SAC065 - DDoS Attacks Leveraging DNS
by Mike O'Connor March 3, 2014

March 3, 2014

hi all, here’s the second new SSAC report — SAC065 - DDoS Attacks Leveraging DNS http://www.icann.org/en/groups/ssac/documents/sac-065-en.pdf please read the report in it’s original form and don’t rely on this extract — the detailed recommendations are great. i’d have included them, but my cut/paste skills resulted in a format-mess. so i’ve just included the one-line summary recommendations in the Executive Summary. this report is another call to action — in this case, as an ISP, i feel that i’m included directly in this. i’m wondering how the ISP Constituency can join the effort that is being called for in this report, and would like to be put on the “interested in helping out list” if one is ever created. again, the question. who does what? where do the resources come from? John Crain’s Security gang is hopelessly and woefully underfunded as it is. the ISP constituency raised the underfunding issue last year in our comments on the budget — and got roundly ignored, along with all the rest of the community input i saw. do we just shout again? shout louder? shout at somebody else? it’s ridiculous to think that his tiny gang can do much about this without more support from above. meanwhile ICANN has multiple millions of dollars aimed at “Outreach” — shouldn’t a big slice of that be aimed at topics like this one, towards the network-operator and DNS-operator audiences described in this report? <rant ends> thoughts? mikey Executive Summary This document is intended for the Internet technical community, particularly authoritative and recursive Domain Name System (DNS) operators, network operators, the Internet Corporation for Assigned Names and Numbers (ICANN), and policy makers. It explores several unresolved critical design and deployment issues that have enabled increasingly large and severe Distributed Denial of Service (DDoS) attacks using the DNS. While DDoS attacks can exploit multiple characteristics of network infrastructure and operations, the prevalence and criticality of the DNS means that securing it is both challenging and urgent. These unresolved DNS issues and related DDoS attacks pose a real and present danger to the security and stability of the Internet. The first recommendation below is made to ICANN, while others are made to operators of Internet infrastructure and manufacturers. While in many instances they reflect actions not under ICANN’s control and actors not necessarily within ICANN’s usual community, they are meant to address the overall responsibilities of the multi-stakeholder community and encourage ICANN to take action where it is relevant to do so. In particular, this means ICANN should be looking for ways to increase the effectiveness of steps already being taken against DNS abuse and promoting the participation of others as well as pursuing the measures suggested here. The Security and Stability Advisory Committee (SSAC) strongly recommends that all types of DNS operators and network operators take immediate steps to mitigate the design and deployment issues that make large scale DDoS attacks possible. Specifically, the SSAC strongly recommends that: ICANN should help facilitate an Internet-wide community effort to reduce the number of open resolvers and networks that allow network spoofing. This effort should involve measurement efforts and outreach. All network operators should take immediate steps to prevent network address spoofing. Recursive DNS server operators should take immediate steps to secure open recursive DNS servers. Authoritative DNS server operators should support efforts to investigate authoritative response rate limiting. DNS server operators should put in place operational processes to ensure that their DNS software is regularly updated and communicate with their software vendors to keep abreast of the latest developments. Manufacturers and/or configurators of customer premise networking equipment, including home networking equipment, should take immediate steps to secure these devices and ensure that they are field upgradable when new software is available to fix security vulnerabilities, and aggressively replace the installed base of non-upgradeable devices with upgradeable devices. 2. Why Is This Important? Critically, basic controls for network access and DNS security have not been as widely implemented as is necessary to maintain and grow a resilient Internet. When increasingly higher-speed Internet connections are combined with the growing power of individual end user devices, an unintended result is an extraordinary and growing capacity for conducting extremely large scale and highly disruptive DDoS attacks using unsecured DNS infrastructure. Paradoxically, the networks that fail to implement the best current security practices are the sources, not the destinations, of attack data flows. Defenders are powerless to influence the design and implementation of the attackers’ preferred networks. It takes only a relatively modest number of end-user devices, for example, to build or rent as a botnet for an attacker to generate significant attack traffic using only a very few, generally well-managed DNS authoritative servers operated by entirely innocent third parties. These attacks have been growing in size over time, and are disrupting individual businesses;3 entire networks, critical applications and services;4 and entire countries.5 The scale of attacks will continue to grow if the Internet community takes no further action. PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

2 1

SAC064 - Search List Processing
by Mike O'Connor March 2, 2014

March 2, 2014

hi all, here’s one of (at least) two new SSAC reports that have come out in time for Singapore — SAC064 - Search List Processing http://www.icann.org/en/groups/ssac/documents/sac-064-en.pdf i’ve extracted some of the report below, mostly with the intent of providing enough of it to give you a sense of what’s there. this report seems closely related to another of my favorite topics, Name Collision (i’ll give that thread a kick in a moment, the JAS report is out for comment). to start off the conversation, here’s an inflammatory question. we seem to be piling up an impressive group of recommendations that we should do more research, work with the IETF to come up with standards and communicate these issues to the worldwide operator community. but then what? let’s assume for a moment that the Board says “yes, thanks, we agree.” who does what after that? how do we evaluate success? who is accountable? this isn’t a problem just with SSR related stuff, i’m running into this broadly across the “implement GNSO policy” spectrum. it seems like a gap to me. this report could be another one we look back 5 years out and say “why didn’t anybody do anything way back in 2014?” is there something the GNSO (either the Council, by launching a PDP, or the broader GNSO stakeholder community) could do to help avoid that situation? mikey Executive Summary A Domain Name System (DNS) “search list” (hereafter, simply “search list”) is conceptually implemented as an ordered list of domain names. When the user enters a name, the domain names in the search list are used as suffixes to the user-supplied name, one by one, until a domain name with the desired associated data is found or the search list is exhausted. Processing search lists was weakly standardized in early Requests For Comments (RFCs) and implemented in most operating systems. However, as the Internet has grown, search list behavior has diversified. Applications (e.g., web browsers and mail clients) and DNS resolvers process search lists differently. In addition, some of these behaviors present security and privacy issues to end systems, can lead to performance problems for the Internet, and might cause collision with names provisioned under the newly delegated top-level domains. This advisory examines how current operating systems and applications process search lists. It outlines the issues related to the current search list behavior, and proposes both a strawman to improve search list processing in the long term and mitigation options for the Internet Corporation for Assigned Names and Numbers (ICANN) and the Internet community to consider in the short term. The purpose of these proposals is to help introduce new generic Top Level Domains (gTLDs) in a secure and stable manner with minimum disruptions to currently deployed systems. Specifically, the Security and Stability Advisory Committee (SSAC): Invites ICANN Supporting Organizations and Advisory Committees, and the DNS operations community to consider the proposed long term behavior for search list processing outlined in this advisory and comment on its correctness, completeness, utility and feasibility; Recommends ICANN to work with the DNS community to encourage the standardization of search list processing behavior; and Recommends ICANN, in the context of mitigating name collisions, to consider additional steps to address search list processing behavior. 6. Findings Finding 1: There is variance on how search lists are processed. The variation is large between applications and operating systems. Finding 2: RFC 1535 is ambiguous in how search list processing should take place. How to process a (specifically unqualified) domain name can be interpreted in multiple ways. Finding 3: Deployed operating systems and applications violate RFC 1535 today. Application developers and providers of operating systems today already have started to implement search list algorithms that differ from RFC 1535. This leads to incompatibilities and might contribute to a degraded user experience. Finding 4: Some search list algorithms deployed today will create problems when new TLDs are delegated. Search list processing according to RFC 1535 can today result in local resolution of a name if a TLD is not delegated. However after that TLD is delegated, global resolution will occur (see SAC06214). Given the variance in implementation of search lists, the use of shortened domain names is non-deterministic and, as a result, can result in negative consequences regardless of whether TLDs are delegated. Thus, the SSAC makes the following recommendations: 7. Recommendations Recommendation 1: The SSAC invites all ICANN Supporting Organizations and Advisory Committees, the Internet Engineering Task Force (IETF), and the DNS operations community to consider the following proposed behavior for search list processing and comment on its correctness, completeness, utility and feasibility. Administrators (including DHCP server administrators) should configure the search list explicitly, and must not rely on or use implicit search lists; Where DNS parameters such as the domain search list have been manually configured, these parameters should not be overridden by DHCP. When a user enters a single label name, that name may be subject to search list processing if a search list is specified, but must never be queried in the DNS in its original single-label form. c. When a user queries a hostname that contains two or more labels separated by dots, such as www.server, applications and resolvers must query the DNS directly. Search lists must not be applied even if such names do not resolve to an address (A/AAAA). Therefore www.server is always a FQDN. Recommendation 2: The SSAC recommends ICANN staff to work with the DNS community and the IETF to encourage the standardization of search list processing behavior. Such an effort should begin with ICANN staff submitting an Internet-Draft to the IETF, and advocating for its standardization within the IETF process. The effort should update RFC 1535 and other applicable RFCs to address the Findings and Recommendations in this document. Recommendation 3: In the context of mitigating name collisions, ICANN should consider the following steps to address search list processing behavior. a. Commission additional research studies to further understand the cause of invalid queries to the root zone and the significance of search list processing as a contributor to those queries. b. Communicate to system administrators that search list behaviors currently implemented in some operating systems will cause collision with names provisioned under the newly delegated top-level domains. Such communication should complement the current ICANN effort in this area with findings and recommendations from this report.15 PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

1 0

discussion -- SAC061 -- SSAC Comment on ICANN’s Initial Report from the Expert Working Group on gTLD Directory Services
by Mike O'Connor Feb. 17, 2014

Feb. 17, 2014

hi all, here’s a thread to talk about the SSAC comment on EWG initial report. here are a few questions. view them as a starting-point, not a rigid requirement. if you have a comment that falls outside of these questions, please go ahead and make your post. i’m just posting these to start conversation, not restrict it. - what’s the current status of the EWG work? - where are we in the process of establishing a registration data policy? - who, if anybody, has taken these SSAC recommendations on board? - is there anything that the GNSO, and/or the GNSO Council, should be doing in Singapore to help move this along? - are there any other questions people would like to raise about this comment? SAC061: SSAC Comment on ICANN’s Initial Report from the Expert Working Group on gTLD Directory Services http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf Recommendation 1: SSAC reiterates its recommendation from SAC055: The ICANN Board should explicitly defer any other activity (within ICANN’s remit) directed at finding a ‘solution’ to ‘the WHOIS problem’ until the registration data policy has been developed and accepted in the community. The EWG should clearly state its proposal for the purpose of registration data, and focus on policy issues over specific implementations. Recommendation 2: The ICANN Board should ensure that a formal security risk assessment of the registration data policy be conducted as an input into the Policy Development Process. Recommendation 3: SSAC recommends that the EWG state more clearly its positions on the following questions of data availability: A. Why is a change to public access justified? This explanation should describe the potential impact upon ordinary Internet users and casual or occasional users of the directory service. B. Does the EWG believe that access to data currently accessible in generic Top Level Domain (gTLD) WHOIS output should become restricted? If so, what fields and to what extent exactly? Under the EWG proposal, queries from non- authenticated requestors would return only “public data available to anyone, for C. Should all gTLD registries be required to provision their contact data into the Aggregated Registration Data Service (ARDS)? There may be jurisdictions that prohibit by law the export of personally identifiable information outside the jurisdiction. If so, the ARDS may not be a viable way to deliver data accuracy and compliance across all gTLDs. D. Does the EWG propose more types of sensitive registration data be provisioned into ARDS than are found in current gTLD WHOIS output? Recommendation 4: The SSAC suggests that the EWG address this recommendation from SAC058: “SSAC Report on Domain Name Registration Data Validation”3: As the ICANN community discusses validating contact information, the SSAC recommends that the following meta-questions regarding the costs and benefits of registration data validation should be answered: • What data elements need to be added or validated to comply with requirements or expectations of different stakeholders? • Is additional registration processing overhead and delay an acceptable cost for improving accuracy and quality of registration data? • Is higher cost an acceptable outcome for improving accuracy and quality? • Would accuracy improve if the registration process were to provide natural persons with privacy protection upon completion of multi-factored validation?

3 8

Re: [Gnso-ssr] discussion -- SAC061 -- SSAC Comment on ICANN's Initial Report from the Expert Working Group on gTLD Directory Services
by Michele Neylon - Blacknight Feb. 17, 2014

Feb. 17, 2014

Mikey The lack of uniform Whois display means we all have crazy regex rules on our systems to make sense of what we run into in the wild ... M ------------------------ Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 16 Feb 2014, at 19:36, "Mike O'Connor" <mike(a)haven2.com<mailto:mike@haven2.com>> wrote: hi Greg, you raise a couple of interesting questions. 1) in the case of a thin registry, how does the gaining registrar do that 2013 RAA verification and validation? it’s my understanding that job is easier if both registrars are under the 2013 RAA, because then they are both obligated to provide uniform Whois display. so a script could be written to pull that data from the losing registrar and that script could count on success. but what if the losing registrar isn’t a signatory to 2013 RAA yet? that looks like another in that pile of dependencies, no? 2) what about all the European registrars (like Michele) who <stirring up a hornet’s nest> haven’t signed the 2013 RAA yet because of the conflict with European privacy law? yet another dependency, i bet. OK. what i’ve learned from this topic so far is; - EWG still has substantial work to do, which certainly won’t be finished by Singapore — but maybe London - we should wait to see how SAC061 advice is incorporated into that EWG report before trying to decide what the next step is for the GNSO - so again, maybe London fair summary? is there anything in SAC061 the GNSO should look at in Singapore? mikey On Feb 16, 2014, at 3:30 PM, Greg Aaron <greg(a)illumintel.com<mailto:greg@illumintel.com>> wrote: The 2013 RAA says that when a domain is transferred between registrars, OR when a domain is transferred between registrants, “both Whois information and the corresponding customer account holder contact information related to such Registered Name” must be verified and validated. So it must happen with inter-registrar AND inter-registrant transfers. http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun1… Registrars who have signed the 2013 RAA sponsor most of the gTLD domains that exist. The community must understand what the current policies are, see if proposed new policies are superior, what the implications of any new proposals are, etc. If the EWG final report doesn’t lay out all of that, then the GSNO will have to make sure it’s done, because it’s tasked with making/approving the policies that come out of the EWG work. I suspect that there are dependencies that have not been documented and discussed yet. And I note that the “ central repository” of WHOIS policies is not complete. http://whois.icann.org All best, --Greg From: gnso-ssr-bounces(a)icann.org<mailto:gnso-ssr-bounces@icann.org> [mailto:gnso-ssr-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Sunday, February 16, 2014 8:57 AM To: Mike O'Connor Cc: GNSO SSR List Subject: Re: [Gnso-ssr] discussion -- SAC061 -- SSAC Comment on ICANN’s Initial Report from the Expert Working Group on gTLD Directory Services Sorry forgot to answer your key question....as you pointed out in Buenos Aires from the mike, some people are doing all the work in the working groups. Absent that connective tissue, I have not seen any other mechanism. There is a lot of material to cover....hard to catch everything, if you are just sitting around reading all the minutes and notices etc. Transparency is not enough.... cheers Stephanie On 2014-02-16, at 8:42 AM, Stephanie Perrin wrote: That does raise interesting questions. First one I have, is do all registrars get to look at all data, or do they only get to look at a particular transaction? I would hope the latter, because that would be compliant with data protection law, if they get to look at all data that would not, in my view, be compliant. It would have been easy to engineer a consent mechanism in there to get around this problem, which would be normal in other commercial transactions, and would also perform a security function. The second question of course, remains begging in my view, with respect to the EWG work. How on earth are we going to accredit actors to look at the ARDS? Do all registrars get to look at all data all the time, if not how is it going to be policed? How many miscreant registrars are there out there? AS always, pardon the naivete of my questions. Stephanie On 2014-02-16, at 8:29 AM, Mike O'Connor wrote: thanks Stephanie and Greg for kicking this thread off so well. let me add another dimension to the discussion — i’m going to combine a couple of fuzzy terms to coin a new one and see if it sticks. “Policy Architecture” i’m involved in several WG’s that touch (or depend on) Whois, or its replacement. the most interesting puzzler is the IRTP-C PDP, which introduced the notion of “inter REGISTRANT transfer” to the existing inter REGISTRAR transfer policy. IRTP-C is now in the implementation process and there are turning out to be a lot of dependencies in there. one of the fundamental notions that IRTP-C introduced was the idea that registrars need determine whether the transfer is just inter-registrar, or whether it’s also inter-registrant. the question is, how will registrars determine whether the registrant is changing or not? one answer, which works in thick Whois environments, is to go look at whois data at the registry and see if registrant data is changing. if it is, then it’s an inter-REGISTRANT transfer and new safeguards apply. if not, it’s just an inter-registrar transfer. when we wrote that section of the report, we knew that it was hard to do that — but we were (correctly) counting on some things changing fairly soon. sure enough, the Thick Whois PDP has just been approved by the Board, which means that “go look at registry data” option will exist for all TLDs. the puzzler for me is who looks after these meta-level dependencies? what if Thick Whois had gone the other way? what if the EWG process concludes that registrars can’t look at that data? who minds that “architectural” framework in the policy-making process? mikey PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com/>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) _______________________________________________ Gnso-ssr mailing list Gnso-ssr(a)icann.org<mailto:Gnso-ssr@icann.org> https://mm.icann.org/mailman/listinfo/gnso-ssr _______________________________________________ Gnso-ssr mailing list Gnso-ssr(a)icann.org<mailto:Gnso-ssr@icann.org> https://mm.icann.org/mailman/listinfo/gnso-ssr PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) _______________________________________________ Gnso-ssr mailing list Gnso-ssr(a)icann.org<mailto:Gnso-ssr@icann.org> https://mm.icann.org/mailman/listinfo/gnso-ssr

2 1