Public Forum: DNSO NC report.

Bruce Tonkin: Walking through resolutions. Resolutions re ERC process. Structure of new GNSO. Want three representatives per constituency; review 12 months after the formation of GNSO council. Second resolution: NC underlines principle of equal st…

Bruce Tonkin: Walking through resolutions. Resolutions re ERC process. Structure of new GNSO. Want three representatives per constituency; review 12 months after the formation of GNSO council. Second resolution: NC underlines principle of equal stakeholder representation. Third and fourth: updating of name servers at the root level and DNS data quality issues. NC recommends that ccTLD managers and ICANN committee for security and stability with input from IANA staff develop procedures at interface between IANA and ccTLDs. Fourth resolution re Lynn and Cerf letter on security and stability: Look at data quality; also concerns WHOIS data. Chairs of task forces no longer need to be members of NC. Terms of reference and procedure for deletes task force. Discussions around WHOIS and Transfers: How to actually implement conclusions and recommendations from Task Forces? ICANN is about contracts, not laws which can just be imposed. Even after looking at improvement at policy level, need to figure out how to practically implement these. Complex with multiple registries and hundreds of registrars. Difference between policy decision and detailed implementation information? Need to review output of task force from that point of view; permit for registry and registrar flexibility in implementing. Transfers: What’s the most effective way to assure that registrant has actually authorized transfer? WHOIS: Accuracy is a concern, but can only be accomplished when privacy is properly addressed. WHOIS is very complex. Process will be to prioritize. Like to report that ccTLD constituency has ended involvement in the DNSO as of yesterdaqy. Would like to thank for the contribution of the ccTLDs to DNSO. Cerf: Thoughtful, timely.

ASO report.

Barbara Roseman, chair of address council. Progress with LACNIC and AFRINIC. Establish BoD selection processes; publish by Januaery 2003. Ongoing discussion to review RFC 2050 and replace it by something outside the domain of the IETF. Mailing lis…

Barbara Roseman, chair of address council. Progress with LACNIC and AFRINIC. Establish BoD selection processes; publish by Januaery 2003. Ongoing discussion to review RFC 2050 and replace it by something outside the domain of the IETF. Mailing list. AC working closely with RIRs on ICANN reform process discussions.

Public Forum: IDN committee.

Katoh-san, trying to be brief. Members of the committee, time line, Created in March 2001 by board. Permissible code point issue. Try to limit the number of character sets. Current Unicode over inclusive for purpose of domain names. Carefully stud…

Katoh-san, trying to be brief. Members of the committee, time line, Created in March 2001 by board. Permissible code point issue. Try to limit the number of character sets. Current Unicode over inclusive for purpose of domain names. Carefully study symbols, icons etc. which aren’t necessary for domain names, but may create confusion. On October 24, IETF came out with standard. Client-side approach. Client translates non-ascii to ascii. Punycode, nameprep, … Issues remain: Chinese-Japanses-Korean registration and administrative guidelines. More than 68000 characters in Unicode. Just use all of them is a problem: Similar characters, read the same way, mean the same thing, but are expressed at different code points. Potential for much confusion. When implementing IDN, need administration and registration guidelines. More limited character set instead of entire Unicode. Some companies already operade 2nd level IDNs. […] Discussed about non-ASCII top level domain names. Adopt then? When? Need dialogue and coordination among registries. Actual use is not coming yet. Need user interfaces. Suggestions and recommendations from committee: Not much time before IDN is going to be implemented by businesses. Need awareness and education. IDN committee has limited life. Asks board to consider continuation of committee for undefinite time period.

Public Forum: Security and Stability Advisory Committee.

Steve Crocker reports: Quick overview of pieces of committee; generally what they are doing; some recent events. Strengths of SAC group: Operational experience. Not a policy or politically-oriented group. Originally try to do a fairly comprehensiv…

Steve Crocker reports: Quick overview of pieces of committee; generally what they are doing; some recent events. Strengths of SAC group: Operational experience. Not a policy or politically-oriented group. Originally try to do a fairly comprehensive look at security issues along multiple dimensions. Protocol, system design, registration process, identification, countering threats. Try to quantify, where possible, progress measures and measures of goodness and safety and stability and secfurity so can separate out emotional measures if things are good and bad. Have not finished near term schedule. Need shift to mode of activities. Focus on individual recommendations, put them together. Events of past few weeks have taken focus. DDoS attack to name server system substantial and serious, but minimal damage to end users. Structure of root system is good. Operational staff responded quickly and vigorously. Attack subsided by itself. Response by operators diminished effectg of attack well before it subsided. If attack had proceeded at the same level, world would not have seen much of a change. Academic issue as to how long can sustain under that attack. But answer to the question is “indefinitively”. But unlikely that future attacks will be the same as this one. Servers suffered under load. Some stopped responding, but none actually broke. Improvements: Strengthen communication among operators and with law enforcement and government and oversight committees which want to be informed immediately. Denial of service attacks are not necessarily specific. In this case, root and TLD servers. There are things to be done on the network: Secure the edge. Reduce number of easily captured hosts. Beyond narrow purview of DNS since this affects the entire network. Should lend a hand here. From committee’s point of view, don’t want to put out redundant extra report, but will work with others. Lesson to engage in more operational issues. Open dialogue on generic denial of service attacks.

Asked for comment on zone transfer. It didn’t take long to come to a conclusion on a number of core things: Authenticate requestor to avoid hijacking of zone. Consistency between parent and child. Desirable: Accuracy of glue records; up-to-date software; redundancy, diversity, disaster recovery preparations.

ccTLDs, IANA, SAC have formed a small, sort term working group to resolve procedures. Doesn’t want to make this the entire focus of the committee’s activity.

Have been asked about WHOIS. Last verified date should be added; privacy is needed; standardize format. Make WHOIS servers known publicly.

Question from Vint: Assume small number of sources, but with spoofed sources. Track them down? Traffic was generated by a small number of machines with high bandwidth. Need to trace them back. Crocker: Comments on securing the edges. Would be helpful to eliminate or reduce bogus addresses. One layer of defense. Won’t stop these kinds of attacks, because if you get thousands of machines, you still have a problem. But takes away a layer of protection from bad guys. Karl Auerbach concerned about getting into a bind where things interdepend too strongly.

Marilyn Cade appreciates comments on WHOIS in the name of the task force, would like conference call. Participant at the microphone: Finds position taken by SAC and Touton in public overly complacent. Metaphore: In 1993 WTC was attacked. This was our 1993. In 2001, after 09/11, there was special meeting. Single point of failure pointed out then: IANA. Need to have way to change name servers urgently when TLD comes under attack in this way. Can’t even reach IANA outside business hours. […]

Public Forum: Root Server Advisory Committee

Jun Murai reports. Basic introduction to root servers; locations and global distribution of the servers. Had 13 meetings so far. Mostly meet at IETF meetings. Security and stability issue: Root name servers are a distributed system. Carefully desi…

Jun Murai reports. Basic introduction to root servers; locations and global distribution of the servers. Had 13 meetings so far. Mostly meet at IETF meetings. Security and stability issue: Root name servers are a distributed system. Carefully designed robustness. 7 different hardware platforms, 8 different operating systems (Unix variants), from 5 different vendors (?). There are contingency plans for server outages. Kept in professional facilities with strong physical security. Strong social network. Established encrypted network. Number of out-of-band ways to coordinate. Technical guidelines: RFC 2870 for root server operators.

Incident report on DDoS in october. Presents bits per seconds diagram; presentation disturberd by a number of Nimda virus warnings coming up on the presentation screen. Back to presentation: Attack on Monday 21, 2200 UTC. Coordinated distributed DOS attack. No degradation on three servers. Network congestion caused by this attack made several of the servers effectively unreachable. Enough servers remained reachable and continued the service. No reports about user-visible service errors. Health monitoring worked. In 90 minutes some recovered, in 120 minutes all did. Robust and diverse enough to sustain this particular attack. More capacity should be added to the system in order to resist predicted future attacks. Improve communication channels.

DNSsec, IPv6: Skipping some slides. Carefully studied all this. IDN: No impact on root servers expected. Need test period to deploy technology.

Question from Karl about recovery from attack: Recovery due to active measures or because attack stopped happening? Murai: Both. (Other explanations remain extremely unclear.) Cerf follows up: Can we assume that mechanisms used in defending against denial of service attack against any host would ber useful in defending attack. (Norton Antivirus comes up again; Murai: “I don’t know how to stop that, but I think I know how to stop the root server attack, I hope.”) Primititve way: Identify traffic, remove or filter traffic. Andy MM: Can data be distributed from something else than the A root? Murai: Design new structure of distributing original root zone file to the server. Has been tested in non real-life server basis.

Public Forum: GAC report.

Paul Twomey presents communiqu?? from GAC meeting held here. Representatives from 32 governments etc. Focused on evolution and reform. IPv6, recent WIPO and IETF deliberations, ccTLD management, GAC reform. Affirming Bucharest resolutions, GAC main…

Paul Twomey presents communiqué from GAC meeting held here. Representatives from 32 governments etc. Focused on evolution and reform. IPv6, recent WIPO and IETF deliberations, ccTLD management, GAC reform.

Affirming Bucharest resolutions, GAC maintains strong interest in the deliberations of the ERC. GAC discussed the ERC’s proposed new bylaws. Recommendations for further amendment. GAC requests that ERC and board take recommendations into account. Walk through proposed bylaw changes. GAC will consider and comment on further bylaw text by ERC on ccNSO. Internet is global resource. Supports worldwide economic and social interaction. GAC notes that issues arising from coordination are entrusted to one entity whose activities should appropriately reflect the global interdependency of the resource. GAC calls on all parties concerned, including ICANN, RIRs and ccTLD fconstituency to cooperate in good faith in order to ensure a relationship conductive to efficiency and mutual confidence. Dialogue with ccTLD constituency. Notes comments that simplification of contractual positions and processes might facilitate improvement in interactions between ICANN and ccTLD constituency. IANA should perform updates in a more timely and efficient manner in order to ensure accuracy. GAC prefers its representative on the nominating committee should be non-voting liaison. Strongly support efforts on IPv6. Presentation was made on WIPO decision on issues addressed by 2nd WIPO internet domain name process. GAC will put this issue onto work program. GAC received presentation from Harald Alvestrand on ICANN and the IETF. Appreciated; further dialogue in the future. Internal organization and work plan: Priority areas for future work. Elections for office bearers beginning on November 1. GAC will have a new team of chair and vice chair in place by Mid-January. EU commission takes over secreatariat. Transition from Australia to new secretariat should be done by November 30. Considering diversitiy of the GAC, members agree to continue with outreach efforts. Ensure that GAC’s work reflects interests of all members. Introduce mechanisms through which local internet communities benefit from having their governmental or public administration representatives at GAC. Appreciate briefing on IDN. Would like to recall earlier advice. Exercise great care in introduction of IDNs; consult with all parties affected. GAC continues to monitor and facilitate registration of dot info country names as per board decision of Montevideo meeting. Next face-to-face meeting in Rio de Janeiro.

Suggested bylaw changes: Cerf requests to move this to reform session later. Asks about “interim secretariat” function of EU. Twomey: “Interim” in the sense of being reviewed.