|
November 15, 2001 Marina del Rey, California ICANN Public Meetings I. Welcome - Cerf II. Reports A. Regional Internet Registries – Mirjam Kuehne 1. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/rir.html 2. Presenting on behalf of all three RIRs 3. Overview of RIR infrastructure and procedures for security • Failure of a single RIR would not cause Internet failure. • RIR services include reverse mapping, WHOIS. Operations much like any other organization. • No major recent issues. Procedures in place. 4. What to protect • Servers (DNS, Whois, Web, internal) • Network • Facility • Data • Reverse DNS 5. Responsibilities lie within RIRs. DNS responsibility shared with IANA. 6. Security and reliability procedures • Configuration control • Time synchronization • Authentication, authorization, accountability • Backup (on-site and off-site) • Network security zones • Filters & firewalls • Facility (access control, fire, power, temperature) • Confidentiality of data 7. Lynn: RIRs backing up each other? Testing plans? • Failures have never happened, so this is untested. But this is straightforward in principle. Testing planned for the future. 8. Auerbach: Transactions per second on in-addr.arpa? Size of zone file? • Defer. They fit on a CD-ROM. 9. Cerf: Can you de-assign a block of addresses? • OK if delegee knows and can avoid using the revoked addresses. B. DNSO – Sheppard 1. gTLD Registries - Rodin • http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/rodin.html • Constituency formed a task force to address registry failure (expanded to include security). Outlined best practices. Membership expanded to include technical representatives. • Seek to assure reliability and performance, to preserve consumer and user confidence. • Best practices to include physical security, data security, disaster recovery, network security, availability. • Intend to consider cost and user inconvenience when evaluating security policies. • Welcome input from others who are interested. • Cerf: Report to the Board the sense of the gTLD Registries of their own reliability and security. • Lynn: Reporting is important and helpful. 2. gTLD Registrars - Palage • Discussed best practices for DNS security, escrow and data recovery. • ICANN Escrow document posted - http://www.icann.org/escrow/registrar-escrow-08nov01.htm . Moving towards implementation. • Auerbach: Escrow has been delayed for years. When will this be working and tested? - Agree that this is overdue. Talk of weeks or months to completion. Testbed to start with a few small registrars. Escrow plans need to consider distinction between thin and thick registries; escrow may be out of date. • Auerbach: Concerned to hear about choices in data formats. Backup should follow a single format for simplicity in restoration. - Focus on big picture. Details pending. • Auerbach: Concerned about treatment of international registrations and non-ASCII character sets. - Issues are pending. • Abril i Abril: Issues re security, management. - No disputes about contractual interpretation here. Escrow is clearly included in existing contracts. • Lynn: Interaction between registrars and registries is a concern? - Have to figure out which data is authentic – that at registry or at registrars. New TLD registries think that their data is authoritative. • Mueller-Maguhn: Concerned about security/privacy issues. - Will check with GAC. 3. Non-Commercial Constituency - Mueller • Non-Commercial Constituency is a user of DNS. Support efforts to address security-related problems. Ask technically advanced members to assist ICANN with assessing and resolving threats. Offer our assistance to ICANN. • Discussion of security should be sensitive to civil liberties. Discussion should focus on technical concerns, not policy concerns. Security concerns should not curtail public participation in ICANN. • Archives are difficult to access from developing countries or for non-English speakers. Suggest concise text archives. • Ask that ICANN lead by example in securing its own network. 4. ccTLD Constituency – de Blanc • Report presented – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/cctld.html • Three days of meetings held, including sessions specifically about security. • Changes to ccTLD DNS records currently take approximately one week. Accelerated procedure needed to respond to catastrophic failure. 24x7x365 live support needed. • Best Practices document under development. Working group formed to address security questions. • Developing a shared ccTLD backup-up secondary server system. • Auerbach: Heard that IANA update procedure may take longer than a couple weeks. Speculate that delays in making changes are being used to encourage signing contracts. - Not here to talk about that. Contract negotiations are ongoing. - Lynn: Delays may result from verification with ccTLD itself, or from approval by DoC. Need to focus on concrete and official data, as previously shared between ICANN and ccTLDs; these data show that a routine nameserver change takes 30 days, of which 12 are under ICANN control, and the rest are used by waiting for information from ccTLDs (most of the 18 days) or on approval by DoC.s • Quaynor: Internal backup procedures? - ccTLD managers know each other and can rely on each other for backup. This could allow geographic separation of a ccTLD’s name servers. • Mueller-Maguhn: Security seems to be a weak link here? - Working on it, both internally and with IANA. 5. Business, IP and ISP Constituencies – Sheppard – joint report • Report – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/sheppard.html • Applaud discussion of security. Issues to be considered include establishing new policies, revising existing policies, and implementing incentives and guidelines to encourage security certification. C. Governmental Advisory Committee - Twomey 1. Will note GAC’s concerns and priorities rather than provide recommendations. 2. GAC is diverse, and members have some different priorities. 3. Need risk analysis, testing, best practices, improved information flow to users (including governments). 4. Concern about complacency. Concern about “trust me, I’m an engineer” which leaves many uncomfortable. 5. Need to consider effects of certain failures on certain communities of users. Some failures may affect some users disproportionately. 6. Wong: GAC discussed security of DNS and is concerned about security of root servers. Planning needs to take account of rising Internet communities, especially in Asia (China). May need to reevaluate placement of root servers. Existing placement may have outlived its historical origins. Risk assessment should be conducted to determine how to proceed. Look forward to additional review of operations here and to elaboration of best practices. 7. Trumpy: Understand complexity of problem. Internet is critical infrastructure, and must be operated in the interest of the community. Meeting yesterday between users, constituencies, and governments to discuss managerial aspects of security of the Internet. Network operators tend to find existing security acceptable and to prefer to be left without government or other involvement. Question of who will enforce best practices. Problem is complex, and more people need to get involved. 8. Twomey: Note that this is not a communiqué. Nor is it a formal position of any individual government. Primarily seek to discuss issues with the community and to improve the quality of service. GAC seeks improvement for everyone’s good, not just based on government authority. 9. Cerf: In a session earlier this week, root server operators discussed their backup systems. Murai will shortly present Root Server Advisory Committee report. Note that root server changes must be slow due to delay in updating root server IP addresses (in default name server zone files). 10. Elliot Noss (Tucows): Appreciate the concern at operators’ position (of wanting autonomy). But operators concerned that standards will be overwhelming. Market already does a good of enforcing quality. 11. Twomey: Understand. But governments seek transparency. For example, root server operators should more frequently and publicly discuss their backup procedures. Re best practices, GAC seeks to make this easy (via a single standard), but seeks progress. D. Root Name Server Operators - Murai 1. Presentation – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/rssac.html 2. Distributed System • Diversified variants of Unix. 3. Discussion of locations. 4. Root Name Servers. Controlled physical access, environment, and diverse connections. Backup and hardware redundancy, including hot and live spares. 5. Administrative Services. Secure communication technologies. 6. Zone File. Defined procedure for modifications. 7. Operators. Diverse base, strong social network, secure communications. 8. ICANN’s role: transition plan, MoU process, backup IANA function. Trust engineers. 9. Auerbach : What’s the current status of studies re more optimal placement of root servers? • Report available in February or March, 2002. 10. Mueller – Maguhn: What if the weak link is the DOC? • Cerf: This is an example of a threat scenario that we should be concerned about. 11. Cerf: Rumor that root server operated by PSINet might become unavailable if PSINet goes bankrupt? • Murai: From a technical and operational point of view, server is running as well as the others. • Touton: In contact with PSINet. Assurances from them suggest that no change is needed at this time. Will use extreme caution in making changes. 12. Milton Mueller (Syracuse University): Persistence of hints file causes a lack of flexibility in moving root servers. Need diversity of software? Separate hints from software (so that hints are received in some other way)? • Murai: Hints (initialization) file is fixed. Changing this is hard at this point. Not considered urgent at this time. • Single software base is of some concern. Hints file is separate from the software itself, but it is part of the design of DNS. Changing this requires changing the entire DNS protocol. 13. Wong: Like to trust engineers and operators. But it’s still the case that root servers are potentially the weakest link. Contractual regimes in place elsewhere, but root servers operate on a voluntary basis, preventing claims if there were security or operational shortcomings. Praise DNS reliability to date, but improvement needed. Thinking practically, a special effort is needed to move root servers in the face of threats to US east coast. • Cerf: That all makes sense. But it is not so easy on a technical level. Would like to move name servers and/or add more. But engineering effort is required. 14. Auerbach: Parts of DNS are easier targets than the roots. Biggest concern is distributed denial of service attacks. How to address and resolve these attacks? • Murai: Root servers face the same threats as the rest of the Internet. • Auerbach: But root servers have well-known addresses, and we cannot move root servers. Also problematic that some ISPs are unwilling to investigate DDoS. III. Break IV. Notes from Klensin technical track roundtable - McLaughlin A. What ICANN should consider doing: 1. Internal procedures to authenticate communications from ccTLD managers, especially during a crisis. 2. Mirroring IANA. Web site already mirrored to Sweden by Royal Institute of Technology. Need to be prepared to mirror the staff and procedures. 3. Improvement in contacts for IP delegation. 4. Testing crisis procedures. 5. Detailed and public threat analysis. 6. Analyze how long services can be down, and conduct escrow and backup routines correspondingly frequently. 7. Security between registrants and registrars. Question of minimum standards (set by ICANN) versus market competition. Education and discussion of the problem may encourage improvement. B. Seem sensible. Work ongoing on some, possible on others. V. Open Microphone Period on DNS Security/Stability A. Sean Donelan: Meeting this week has set the right tone in terms of level of transparency. Need running code to improve security. Programmers with extra time on their hands could rewrite BIND. 1. Blokzijl: Karrenberg is writing a new DNS server especially for root servers, without any BIND code. B. Dave Crocker: DNS is complicated. “Security” may be an overstatement. “Safe and reliable” is the right standard. IETF produces the specifications here, but stays out of market testing of software. Often, a market “kick” needed to inspire security improvement. But even when improvements are desired, can be difficult. Beware of risks other than the root. ICANN could help with facilitating security improvements, not by dictating policy but by setting standards, providing “certificates of quality,” etc. C. Eric Dierker: Need to emphasize to users that Internet is safe and secure. Discussion this week has focused on weaknesses, but we should reiterate that Internet works as expected and should be used at this time. 1. Auerbach: Automobile industry has been working on security for decades. But drivers should not be encouraged to forego seatbelts, etc. Should not provide reassurances that we cannot live up to. 2. Mueller-Maguhn: Keep in mind ICANN’s limited scope. 3. Cerf: Internet continues to function, despite a number of challenges. Trying to make it better. But no one (ICANN, nor anyone else) can say that there are no weaknesses or no problems. Plenty of problems, but system is resilient. We will try to make it better. D. Russ Mundy: Commend the meeting focus on security. Recent interest in security for name system is important progress. Need to consider security awa whole rather than in peices and establish priorities. The sum of critical infrastructure pieces is greater than the individual pieces. E. Paul-jean Jouve (Brinx): Others say that this meeting may be a knee-jerk reaction. Serious concern. F. Daniel Karrenberg (on Personal Title): Placement of root name servers on east coast of US should be reevaluated. Work is ongoing on improving this. Report forthcoming, Murai says. But this is a hard problem. Need to think through the kind of people necessary to work on these decisions – independence, diversity. Trust a diverse bunch of engineers. 1. Auerbach: Security involves a balance of equities, including social costs, so it can’t be left entirely to engineers. G. Lars-Johan Liman (Autonomica): Surprised that people are still interested in protecting the servers; the service should be focus of protection. Diversity will facilitate security. Stability of DNS as a whole. A single security specification for all root servers may itself be a security risk. Security on rest of Internet must be demand-driven. Must recognize friction between engineers and non-engineers in fitting Internet into society. H. Chuck Gomes: A former security director of Verisign made negative comments about this meeting. But he had not been with Verisign for more than a year. I. Harold Feld (Media Access Project): Need more voices and perspectives in this discussion to assure that all views taken into account (including the possibility that excessive security might suppress discussion or scrutiny). Security and stability should not be used to restrict public discussion or debate. J. Sean Donelan: Delegations to hostile nations need to be reviewed. K. Dave Crocker: Higgs draft was distributed as an Internet Draft. But note that it contradicts a published RFC from IAB. 1. Auerbach: Should accept and value all points of view. Should consider possibility of replicated roots. Should not rule out any possible approaches. L. Mouhamet Diop: DNS misconfiguration is a serious problem. May result in part from linguistic barriers. Simultaneous translation and document translation can help. ICANN should consider improvements here. 1. Cerf: Will discuss translation efforts shortly. VI. ICANN Board Meeting on DNS Security & Stability A. Cerf: Formulate specific resolutions in this afternoon’s sessions. B. Lynn: Thanks to all who helped. Shows that ICANN community takes security seriously. Cannot fix security problems only through tough legal agreements. Where possible, ICANN should seek to encourage improvement via positive suggestions, not tough contracts. Setting priorities between prevention and detection should be thought through carefully. Should not just leave this meeting feeling good, but need to take actual actions towards improvements in security. Perhaps a standing committee on security. C. Auerbach: Security is hard. When communities and networks are small, rebuilding is relatively easier, but this requires widespread deployment of tools and skills. ICANN should adopt a similar approach – encouraging users to be self-reliant in case of serious disruptions. Free availability of zone files is one way to help with this. 1. Cerf: If absolutely nothing is left, Auerbach’s approach makes sense. Certainly planning is needed. It is helpful to think through what tools (and skills) should be in our (DNS) “emergency kit.” We can’t make many people do much, but we can disseminate information. D. Cerf: What should we do? IANA procedures to grade the amount of verification necessary? Different amounts of verification for different kinds of requests? 1. Blokzijl: Next-generation DDoS attacks are worrisome. Engineers are thinking about protection systems. But serious challenges since new computers with standard operating systems come with vulnerabilities. Software makers should consider themselves obliged to make progress here. 2. Cerf: Costs both in money and in convenience. Want the security, but do not want to forego convenience. 3. Cerf: We could highlight our interest in DDoS and other related research. E. Katoh: Have learned about security. Strongly support Lynn’s proposal to continue focus on security (via a standing committee on security). F. Auerbach: DDoS is difficult to trace. ISPs are not always cooperative. Maybe a bad idea: Can we use our authority over IP address allocation to induce ISPs to be more helpful? 1. Cerf: Feel conflicted about this. Some ISPs are very cooperative. G. Blokzijl: ICANN could issue a statement pointing out that current consumer-oriented software has potential security holes, and that ICANN thinks software makers have a responsibility to do better. 1. Cerf: DDoS, viruses, worms, and other problems. H. Cerf: But what about ICANN’s area of direct responsibility? I. Kraaijenbrink: Learned a lot. Impressed by knowledge shared and awareness raised. Word “security” is not the best choice, because real security is very hard. Should analyze (and specifically acknowledge) the risks we face. Could audit the estimated security risks. Information sharing is and has been valuable, and we should continue this. Support standing committee on security if we can focus on facilitating risk analysis (rather than directly improving security). J. Quaynor: Human beings are a part of the potential security problem here. ICANN should facilitate communication to reduce this problem. K. Pisanty: Board should promote risk analysis and facilitate outreach to concerned Internet users. L. Auerbach: Internationalization will be tricky because many Internet users may be unable to read addresses used by others. An should layer new code on top of DNS rather than replace it. M. Lynn: Will prepare a resolution thanking those who helped plan this week’s meetings. N. Pisanty: This week has also provided valuable training. Should include information-sharing in future sessions whenever relevant. This will also ease travel funding for some. O. Kyong: Support Lynn’s standing committee. P. Cerf: Adjourn. CONTACT INFORMATION For additional technical information, please contact: Ben Edelman and Rebecca Nesson |