ICANN participation

RSSAC-24 19 march 2006 Dallas

Attendees:

Bill Manning

Rob Austein

Yuji Sekia

George Michelson

Cathy Handley

Brett Carr

Joao Damas

Jim Cassell

Matt Larson

Gerry Sneeringer

Suzanne Woolf

Lars Liman

Akira Kato

Fredrico Neves

Andrei Robachevsky

Ginny Listman

John Crain

Steve Conte

Guests:

Russ Mundy

Steve Crocker

David Conrad

Absent:

Paul Vixie

Daniel Karrenburg

Jun Murai

Johan Ihren

Agenda:

Anycast Update - Kato-san

IPv6 - Joao Damas

Measurement - Yuji Sekia

Liaison Reports

BoT - Suzanne Woolf

SSAC - Johan Ihren / Steve Crocker

ISOC - Joao Damas

Other Interactions

DoC RFI - Bill Manning

US-GAO - John Crain

CWIN - Paul Vixie / Bill Manning

OECD - KC

Security Issues

DNSSEC - Steve Crocker

IDN - John Crain

IANA Glue policy - David Conrad

RSSAC logistics - Bill Manning

AOB

Note takers: Russ Mundy, Steve Conte, Brett Carr, Bill Manning, and Suzanne Woolf

Anycast: Kato-san

There are now more than 100+ instances globally. There are no metrics on if these deployments are really being effective to reduce roundtrip time, which has been one argument for anycast deployment. Is there real technical benefit to anycast? Are there any studies planned on the use of TCP queries? TCP transactions will sometimes fail in anycast deployments. Can sites that do anycast measure TCP activity/failures?

Bill: What is the status of the NISD draft and software compliance?

IPv6 Glue: Joao Damas

There is now generally agreed on text about draft recommendation for adding v6 glue to the root zone. RSSAC would like to have the report from Bill Manning on his analysis of resolver beahviour before proceeding. Expected draft report after 31march2006.

Measurement: Yuji Sekia

Neville reports from CAIDA. Dwayne Wessles did a presentation at NANOG and is continuing to work on getting data on open recursive resolvers. Query origin study has shown that about 98% of the packets collected seem to come from machines running Microsoft OS variants. Additional work is being done to collect and report the size of request/response pairs over time and over topology, with an emphasis on EDNS(0) capable servers/clients. CAIDA now has newer information about responsiveness of the various roots from selected locations. Neville is now looking at the sizes of packets and how much TCP traffic is appearing on port 53. This has particular applicability for anycast nodes.

CAIDA statistics may be found here:
http://www.caida.org/cgi-bin/dns_perf/main.pl

George Michelson (APNIC) reports on some DNS analysis done on their servers.

Where do V6 queries come from? His data shows that most of the queries are coming from true v6 address origins. Most questions are v6 addresses asking for v4 addresses - probably result of hard binding of v6 resolver to particular v6 address. The total usage is below one tenth of one per cent of total dns usage.

APNIC is providing authoritative service for the RIPE NCC signed zones. He is seeing instances of DS & DNSKEY records in his logs. DNSSEC support requires a significant increase in on-disk, network, memory and CPU cost. It was about 30% bigger than expected at least as measured in user space. Looking at on the wire data, there is a noticeable shift of larger packet sizes showing up in the real world. Georges slides may be found here:

http://www.caida.org/workshops/wide/0603/slides/gmichaelson.pdf

Yuji presented his active measurement work from sites in the asian region. The method was to dial into ISP sites in a number of countries and measure RTT responses. A breakdown listing of anycast nodes of F, I, J, K, and M instances were presented, where specific nodes did or did not respond from a given probe. The curves with CDF vs. RTT from the various ISPs in various countries were presented. The curves for China may not actually be the 'real' roots since China may be answering with their own instantiations of root servers. Question from Bill: Would it be possible to get the actual instance that they were querying/answering for anycast instances, e.g. what is the status of the NSID draft?

A copy of Yuji's material is available here:
http://www.rssac.org/notes_papers/sekiya-DNS-active-measurement.pdf

Liaison Work: Suzanne Woolf

ICANN Board- Suzanne Woolf

ICANN has several people here; staff members are, John Crain, Steve Conte, David Conrad, myself as RSSAC liaison, and Steve Crocker as SSAC chair and ICANN Board member.

The dot.com agreement with Verisign has taken ICANN Board time. It hasn't touched RSSAC very much. Several RSSAC members commented in their individual capacities. The agreement was ratified by ICANN on 28 feb 2006. Of interest in the agreement is the statement to move root zone editing from Verisign to ICANN.

There is much more discussion with IANA since David arrived. ICANN published a document with a plan for IDN in the root. We're being asked for more input from ICANN which (in general) is a good thing.

SSAC- Steve Crocker

Points to be reviewed here: Amplified DDoS attacks on DNS servers, Root Zone update process, Alternate Roots and IDN's, and WHOIS analysis.

Amplified DDoS Attacks can be mitigated by pushing back on the attack by refusing traffic. This "near field" effort should also be matched with a longer term focus on closing down open recursive resolvers, (but this is treating the symptom) as well as encouraging ISPs and equipment vendors to implement BCP 38 - source address ingress checking.

Alternate Roots exist for several reasons. Currently, IDN questions seem to be driving Alternate Root system expansion in the absence of a common capability for IDN question exploration. ICANN recognizes a need to support IDN capability in the DNS.

Root Update Process was examined by SSAC and found several instances in the 2004/2005 timeframe where "glitches" occurred in zone data processing. Some of these were corrected by procedural fixes and some fixes are still pending. A closer examination of the technical issues surrounding update needs to be done. Glue record processing is still an open area as is the creation and implementation of policy for glue management. Both these areas are getting ICANN/IANA attention. There appear to be database "side effects" with the current system.

Whois Analysis - The questions about whois relevance, accuracy and availability have exposed a range of contentious factions that include network operators, domain speculators, law enforcement, and intellectual property lawyers. One possible way to address all these expressed needs is to provide different access for different communities.

Steve SSAC slides may be found here:
http://www.rssac.org/notes_papers/rssac-ssac-mar2006.pdf

ISOC- Joao Damas

RSSAC has no liaison to the ISOC board, but does participate on the internet collaboration mailing list, which was created primarily for the UN-WSIS process. Since the WSIS process in winding down, so has the list. There is a request that the RSSAC members who participated make mailing list archives available to the rest of the RSSAC.

Other Interactions: Bill Manning

RFI- Bill Manning

Published by USG about the IANA task. It's a USG formality of contract law. There may or may not be any follow up requests from the USG.

US-GAO Queries- John Crain

No new data from the US-GAO. Individuals sent some info after the initial request but nothing 'formal' was sent back. Broader question is If RSSAC is asked a question, how should it be answered?" Answer: take it to the list.

CWIN-Bill Manning

CWIN is a US Homeland Security initiative to provide key operations organizations with an out of bound communication medium to enable coordination in the event of a major disaster or outage. The weakness is that the root server operators and their nodes are global in scope. Does RSSAC think that a better plan for continuity of operations can be implemented?

Is it worthwhile to put together a paper to document procedures to ensure operational continuity? Should the existing CWIN participants continue to support that service? Some of the participants have expressed doubts about CWIN's usefulness or viability in the event of disruption.

Initial discussion exposed the following ideas: Any such plans should be specific to the operator, with a framework for communications between the operators and perhaps select others. "Out of Band" communications should be in place. Any plans that are created should be written down and the existence of such plans be made public. Concerns about the exposure of such information were expressed. A system which is used regularly and people know how to use is better than one that is never used except in an emergency.

OECD Impacts- kc

No one was present to report. Copies of presentations by Jun Murai and kc are available here:

http://www.oecd.org/document/5/0,2340,en_2649_201185_36169989_1_1_1_1,00.html

DNSSEC- Steve Crocker

Does it make sense to publish DS records for signed children before the parent is signed? Discussion seemed to reach a consensus was that this would not really serve any useful purpose and would just confuse. Zone update periodicity was raised, Steve wanted to know how long it took a zone update to make it from the edit database out to the last anycast zone. It turns out this is usually a matter of seconds but could be up to 48 hours, so range is 7 seconds to 48 hours.

Steve's slides may be found here:
http://www.rssac.org/notes_papers/rssac-dnssec-mar2006.pdf

IDN - Suzanne Woolf

ICANN published a document from the presidents advisory committee (PAC) on IDN including a tentative timeline for insertion into the root. Most ICANN staff and board received first notice in an IDN article printing in the Chinese Press. John Crain does not think RSSAC has had an official request to contribute. The ICANN notice states ICANN will conduct an experiment and RSSAC are being asked to provide technical input on this experiment. The sooner we provide this input the better. Suzanne and Bill will create a draft recommendation after soliciting comments from the list.

IANA Glue Policy: David Conrad

A discussion then took place on glue policy in the root. When a request for a change in glue in the root zone comes in, it requires all affected TLDs to respond in the affirmative before the change is made. This process may sometimes leave a change request pending for many months. The current process is convoluted and broken. Two questions arise; one, how should the policy be changed, and two, what should the new policy be?

Previously, policy has been taken through the IETF process, as documented in RFC 1591. It was suggested that it might be very helpful to get separation of the technical components from the justification components of change requests. David presented three possible alternatives and a lively debate ensued. NO consensus was reached on any of the given possibilities, but there did seem to be consensus about developing an answer to the current glue policy without developing a general policy solution. David suggests that it would be helpful if an initial recommendation were to emerge from RSAC.

David's slides are here: <to be provided by David Conrad>

Logistics: Bill Manning

RSSAC25 in Montreal (IETF66)