March 2014 - Gnso-ssr - lists.icann.org

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