|
November 13, 2001 Marina del Rey, California ICANN Public Meetings I. Welcome (Stuart Lynn) A. Special thanks to all who traveled to come here. Had been concerned about possibility of low attendance, but there are more than 800 preregistrants for this meeting. B. Keep in mind that this meeting is open to the public. C. This meeting reflects one step in ICANN’s continuing work. D. Today’s plenary sessions will be followed by breakout sessions. E. Thanks to program committee. http://www.icann.org/mdr2001/program.htm II. Welcome (Vint Cerf) A. Introduction of Kenji Kosaka, Senior Vice Minister for Public Management, Home Affairs, Posts and Telecommunications of Japan III. Kenji Kosaka A. Keynote delivered – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/KosakaSpeech.html 1. Importance of Internet security and stability in the context of increasingly broad use of the Internet. 2. Importance of autonomous operation of Internet by world Internet community. Support community consensus structure of operation. 3. Increasing use of IP addressing systems by ordinary consumers will make ICANN’s work of interest to a larger group. B. Lynn: Thanks to Kenji Kosaka for the special trip to the US specifically for this meeting. IV. Steve Bellovin (AT&T Fellow) A. Presentation delivered – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/bellovin-keynote.html B. Q&A 1. Donovan: If you have to prioritize, what to fix first? • Easiest attack right now targets customer-registrar communications. Harder: Routing, protecting root servers. 2. Kaijanen: What can ICANN do about Internet viruses? IPv6 might help, but what to do until its wide deployment? How to track down virus authors? • Hard problem. Privacy issues complicate this. 3. Wesson: Say more about the weakness in communications between customers and registrars? Registrars have made great progress here, and media coverage may be misleading. • Some high-profile domains have had their nameservers switched. Design reflects an earlier era in which authentication was unnecessary. Improvement is desirable. 4. Crocker: Thanks for noting the variety of vulnerabilities we face. • Some safety might result from using a greater variety of TLDs. 5. Brown: Concerned about spoofing of IP packets. Much traffic still has spoofed packets, even though straightforward ACLs can fix this. How can ICANN get the message out about fixing this? • Easy and should be done. Some concern about ISP behavior, because no one directly controls the ISPs. 6. Joe Alagna (Centralnic): Passwords and social engineering create vulnerabilities. Educational program to encourage improvements here? • Agree that this is a longtime problem. Not likely to happen overnight. 7. Matthew Hamrick (Declarator): Seek to explain security to insurance companies (so that rates match risks). • If courts apply liability law here, then it will be important to note what steps are necessary. But no clear legal rules in place. 8. Keith Teare (RealNames): DNS can cache records. May allow redirection of a domain name. This is a feature, important for those such as Akamai. • Not sure this is a feature, but it is possible. Certainly cannot keep these problems secret. DNSSEC will help with these problems. 9. John Klensin (AT&T): Real or potential threats on the network have been used to support calls for changes to Internet architecture – less privacy, etc. • Risks of key recovery and key escrow are well-known. Still consider these problems serious. Some recent implementation flaws show the importance of this concern. Not an ICANN issue. C. Lynn: Thanks to Kosaka and Bellovin. V. Root Name Server Security A. Jun Murai - Chair, DNS Root Server System Advisory Committee; Professor, Keio University, Japan; DNS root name server operator; President, JPNIC; Chair, WIDE Project; ICANN Director 1. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/murai.html B. Paul Vixie – Internet Software Consortium 1. Slides - http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/vixie.html C. Mark Kosters – Verisign 1. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/kosters.html D. Lars-Johan Liman - Senior Systems Specialist, Autonomica AB; Co-Chair, IETF Domain Name Server Operations Working Group 1. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/liman.html E. Q&A 1. Cerf: Slides public? • Yes. 2. Dowman: Volunteer nature is potentially problematic. • Vixie: Has never been a problem. The people doing this work have never asked to be paid. It works well for a variety of organizations to support this work. If there were a single central organization doing this work, a problem with that organization, the service might be interrupted. • Liman: If one server went down, others would still be in place. 3. Trumpy: Panel expresses optimism about reliability of the root server system. But security still a concern. Following the RFC? A need for formal contracts here? • Liman: RFC provides guidelines. No one is perfectly compliant, but it is a goal. Working towards removing other domain names from the root servers. • Vixie: Have a MoU. Some name server operators might agree to a strong contract. But existing approach is sufficient and preferable. 4. Auerbach: Security differences between hints files and root servers themselves? • Vixie: Hints files take years to propagate. But nameserver implementations ordinarily use hints files only for startup, so this is not so serious. • Liman: Hints file is updated infrequently. 5. Paul-jean Jouve (Brinx Corp): What if master root becomes corrupted? How to check for worms and trojans? • Liman: Audits by various organizations. No guarantee possible, but alarms and monitors in place. Also have contact information for each root. 6. Daniel Karrenberg (k.root-servers.net): “Volunteer” concept is not fully accurate because operators have resources available. For example, RIPE NCC funds the operation of a root server. Funding is distributed but definitely does exist. Variety in operating procedures across root servers provides security benefit. Making contracts too specific may make the system more brittle. 7. Howard Eland (Afilias): Monitoring for distribute denial of service attacks? • Vixie: Monitor for the problem. Contact source of the attacks when they occur. The root servers are visible and well-monitored, both by root server operators and by others. Monitoring also tracks changes in master zone. 8. Elisabeth Porteneuve (.FR): For Kosters: A dedicated WHOIS service for TLDs? • Kosters: Yes. See http://whois.internic.net 9. Karen Rose: Caching improvements helpful? • Vixie: Caching already in place. Those who are not caching their requests must be going out of their way to avoid caching. (The default behavior is to cache.) ISPs cache to save bandwidth, to improve speed, etc. So it is surprising that there are so many non-cached inquiries. 10. Steadman: When will DNSSEC be implemented? Consider a proprietary solution to enhance security? • Kosters: Later panel will discuss problems with DNSSEC. Root server operators are conservative and will only deploy services they feel confident in. • Vixie: Tradeoffs. Commercial software has paid support. But free software allows audits of quality. 11. Bill Manning: Concerned about perception that root server operators are conservative and slow. But in fact the operators vary widely. We are flexible and adaptive. It is important to recognize this. VI. McLaughlin: Breakout Groups this afternoon A. 3:45-5:30 B. Variety of languages C. Mix & mingle VII. Lynn: Lunch – box lunches in courtyard and Bay View Room VIII. Remarks - Cerf A. Discussion of security is serious and important. B. Recommendations to policy makers: 1. Do no harm. 2. Do not let policy go beyond technology. No unimplementable policy. 3. Seek input from technical community re technical feasibility and maturity. 4. Do not decrease security. 5. Look for operational practices to improve security. ICANN should develop policy, but not invent technical solutions. IX. Introduction of Panel - Pisanty X. DNS Security: Present and Future A. Edward Lewis 1. Evangelist, DNS Security technology; Researcher, NAI Labs; Co-chair, IETF; Provisioning Registry Protocol Working Group 2. Slides: http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/lewis.html B. Olaf Kolkman 1. Scientific Programmer on the RIPE NCC's Deployment of Internet Security Infrastructures (DISI) project 2. Slides - http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/kolkman.html C. David Conrad 1. CTO, Nominum 2. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/conrad.html D. Allison Mankin (IETF): Working to encourage code tests. Need to balance insecurity against unavailability (resulting from excessive emphasis on security). Must keep systems simple enough to use. Need to move forward with security of DNS now that issues are understood. E. Q&A 1. Paul Vixie: Concern that panel is “too kind” to Bind 4 and 8 (which I wrote). 2. Randy Bush (YMBK): ICANN is considering a variety of possible approaches. But adding complexity will only make things worse. Problems are DDOS and routing attacks, and these are what should be fixed. Current methods break protocols and add complexity. Vendors should implement the DDOS defensive systems that engineers have designed. Schedule should be conservative. Engineers should focus on designing software and protocols, not briefing ICANN. DNSSEC is weak. ICANN should not be having this meeting today. • Cerf: Giving information to ICANN may prevent other problems or mistakes. Other work can proceed here. 3. Steadman: Microsoft has pushed protocols via their new products. Could they help get DNSSEC moving forward? • Conrad: Microsoft is aware of DNSSEC, and DNSSEC engineers will be in touch. 4. Mockapetris: Engineers now have an obligation to be in touch with ICANN and others. DNSSEC will enable the future by adding security and authentication to data communications. 5. Crocker: Agree with Mockapetris re engineers’ obligation to help with policy. Despite its other successes, IETF has repeatedly failed to deliver security. Perhaps because market did not previously demand security. Now, market demands security and IETF must catch up. • Mankin: Why not more security in DNS in the 70s and 80s? • Crocker’s comment can be misunderstood. True that little of IETF security work has been deployed, but this may not be because their designs were bad. Could be because deploying security software is hard (due to procedures, etc.). 6. Conrad: “Chicken and egg” problems of network effects. No benefit to deploying a technology until others have deployed it too. 7. Crocker: “Why not just start over [to improve security]?” An important question. But replacing systems is harder than fixing or adding on. Attempts to replace the DNS may be unsuccessful given the number of installed users. Especially difficult when a system is not amenable to refinement on the edges of the network. 8. Vixie: DNSSEC is not a complete replacement because engineers thought that would be too long and hard. But operational stability of the Internet faces more serious risks than the absence of DNSSEC. Need to prevent users from sending IP addresses into the network that bear forged IP addresses. ICANN needs to think through how it can prevent this – perhaps somehow penalize ISPs that allow forged IP packets to come from their networks. 9. Bush (AT&T): DDOS is not source-spoofed. Only way to prevent DDOS is pushback. Lack of encryption in network connectivity (especially on wireless networks) is problematic and causes risks. 10. Buchanan (register.com): How to move keys between registrant and registry via registrar? Tricky relationships here. ICANN needs to think about this because this problem results from the multi-registrar model. • Verisign has been thinking about this. See http://www.verisignlabs.com XI. Lunch Break XII. Introduction of the Panel (Lynn) A. Ken Silva (Verisign) 1. Director of Technical Services and Network Security, VeriSign Inc.; Board member, Information Technology Information Sharing and Analysis Center (IT-ISAC) 2. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/silva.html B. Sabine Dolderer 1. Executive Director, DENIC 2. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/dolderer.html C. Federico Neves 1. CTO/Software Engineer, Registro.br 2. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/neves.html 3. Statistics – http://registro.br/estatisticas.html D. Geir Rasmussen 1. CTO and Executive Director, Global Name Registry 2. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/rasmussen.html E. Martin Lindner 1. Team Leader for Incident Handling, CERT Coordination Center 2. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/cert.pdf F. Q&A 1. Donovan: For ccTLDs with problems as identified, should ICANN be concerned? Do these problems affect everyone, or just those with registrations within those country codes? • Dolderer: All ccTLD operators should follow best practices. ICANN need not insist that operators run the service in a certain way, but the community should monitor who follows what procedures. • Lindner: Cache poisoning could result from certain ccTLD errors. This could affect resolution of domains in other TLDs. 2. Wesson: Concern about CEO quote saying that Verisign could take down the Internet. • Silva: Quote may have been taken out of context. Verisign’s servers are well-protected and reside in high quality data centers. No one person within Verisign could cause catastrophic failure. Verisign data resides at multiple locations. 3. Gomes (Verisign): Don’t believe everything you read. 4. Jouve Paul-jean (Brinx): Shouldn’t there be checks and balances in which another company replicates Verisign’s functions? Then Internet could continue even if Verisign ceased to function. • Silva: Functioning nameservers will continue to work even if Verisign ceased to function. Registration (of new TLDs) might be disrupted, but resolution would continue. • Rasmussen: New TLDs have extensive and frequent escrow procedures, as required by contracts with ICANN. Data is well replicated. XIII. Reminder to register for breakout groups - McLaughlin XIV. Registries and Registrars: Recovery & Restoration A. Elliot Noss – President & CEO, Tucows - Moderator 1. Introduction of the panelists B. Chanki Park 1. Technical Manager, Korea Network Information Center (KRNIC) 2. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/park.html C. Calvin Browne 1. Director, UniForum SA (the .co.za registry); Committee member, ISOC-ZA; Member of the Linux Professionals Association; Internet and Open Source software consultant 2. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/browne.html D. Bruce Tonkin 1. CTO, Melbourne IT 2. Slides – http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/tonkin.html E. Rick Wesson 1. CEO, Alice’s Registry; CTO, Registrars Constituency 2. http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/wesson.html F. Q&A 1. Noss: How to switch to backup registry database if needed? Would failover be transparent, or would changes by each ISP be necessary? • Park: It would take a bit of time to recover. • Tonkin: Backup is at a different location. But change could be transparent. 2. Paul Twomey (Governmental Advisory Committee): What data can be verified where? • Wesson: Postal service has periodic updates of street addresses that are likely to be possible. Telephone network numbers can also be tested. Of course, no way to know whether there is actually a telephone handset on the other end of a line. • Cerf: Can tell “this is a well-formed telephone number which might belong to an individual.” Reverse lookups also possible. • Tonkin: Some databases available (including from government) in Australia. 3. Joanna Lane (#1380, remote): Concerned that ICAN-accredited registrars are doing business with members of terrorist organizations. • Noss: FBI may be interested to know who self-identifies as being affiliated with a terrorist organization. ICANN staff will have to answer questions re ICANN’s interpretation of contracts. 4. Jordyn Buchanan: Concern about lack of security in Whois as well as at other steps of communication between registrant and registrar, registrar and registry. • Tonkin: The more security is put in place, the more difficult and costly it becomes to deal with customers. (Certificates, etc. are costly in terms of customer support.) • Noss: Best security is knowing who you are dealing with. Distributed design helps. 5. Eric Brunner-Williams (wampumpeag): EPP has an asymmetric event model – in which registrars are not continuously receiving information from registries. Protocol design affects recovery and restoration possibilities as well as security. • Tonkin: Agreed. Registry-registrar protocols should include some sort of token to facilitate registrant authorization. Otherwise, possibility of interference by one registrant in domains of another registrant. 6. Howard Eland (Afilias): Wesson said longer TTLs might help. Maybe really it’s expiration times that matter? • Wesson: Right. 7. Anand Pradhan (URL Consulting): How to secure domains that have suffered from cybersquatting? Work with DOJ? • Noss: Unsure. • Lynn: No plans. • Cerf: Don’t understand. Don’t know that DOJ has jurisdiction here. Litigation can always be used if either party is unhappy with result of UDRP. 8. Ram Mohan (Afilias): What to do when a government orders a change to DNS records (due to national emergency)? • Browne: Depends on national laws and constitutions. Must abide by law. • Tonkin: Governments have tried to shut down the Internet, but it is hard to do that when networks use satellite links. Also, some difficulties re regulation of what kind of information can be sent to what countries – hard to comply, since it is difficult to know which users (submitting WHOIS requests) are submitting which requests. • Cerf: This is complicated, and we cannot solve this here or today. 9. Patrick Mevzek (Gandi): Backup systems need to be tested frequently so as to verify that everything works properly. Registrars should participate in registry backup procedures. • Park: It’s difficult to test a live system. But before we implement a new system, we test thoroughly to make sure that the backup works properly. • Tonkin: Melbourne IT uses its backup locations for administrative tasks on an ongoing basis. Have to reach a reasonable compromise between testing and simplicity and stability. (Can’t test fire extinguishing systems by setting your building on fire!) • Noss: Registrar responsibility is to identify those with problems. • Wesson: Registrars can fix certain problems and can encourage customers to do better. 10. ICANN should provide backup services since it collects a fee from domain name registrars and registries. XV. Lynn: Thanks to panel, closing of plenary sessions. XVI. McLaughlin: Breakout rooms are posted. CONTACT INFORMATION For additional technical information, please contact: Ben Edelman and Rebecca Nesson |