RSSAC Meeting, Atlanta, GA
RSSAC
meeting 14
Atlanta, Georgia, USA
Q: Are NTIA and White House folks regular attendees or invited guests?
A: Guests for now; status to be discussed.
Agenda
* Mechanism for report/disclosure of root-ops (Daniel)
Discussed, but mechanism not yet decided.
Does that mean there will be no reports?
A: Reports from individual root operators, but will never be a report
from the "community" of root operators, some of whom are constrained
by contracts from confirming or denying information.
Cmt: Status of report disclosure.
---
* Mechanism for Comments (Louis)
Got a mail list set up for public comments to be made to the rssac list.
Have 4 volunteers to monitor the list. Have rec'd 3 substantative comments
so far.
- one on topic
- one not on topic
- one saying that the list was not a sufficient forum for communication
with the root-ops
Louis suggests that the volunteer committee monitoring the list should
be able to provide an answer if straight-forward. (Common sense) If there
are more complex questions, they should formulate---
Answers should be sent with the return reply of <rssac-questions>.
Probably need an FAQ to answer common q's such as spam, whois questions,
etc.
ICANN committee, so ICANN should draft. That met with approval.
Put standard answers together, post to rssac list for 7-day comment period.
---
* .arpa and in-addr.arpa (PV)
Proposal to add .arpa and in-addr.arpa to 4 root name servers that currently
do not run them in order to get those zones hosted internationally quickly.
3 of the 4 are willing to serve the zones.
Request will go through normal channels to make the additional delegations.
Q: Has IAB been notified of the proposal?
A: Yes. Their only response was that the requirement that the servers
be sufficiently robust.
Cmt: A/J is the only one to dissent. Willing to put in, but does not believe
it should be put on roots.
---
* Crada report (Louis)
Current plans call for 2 reports: Nov 30 and Dec 31
Nov 30 report is a questionnaire for each root server operator. Some common
questions.
Dec report is a different type of report; it is intended to include enhanced
architecture discussion, etc.
Cmt: Enhanced architecture is something that has already been implemented.
(SNS/TSIG) Discussion now is to write up what was done since already completed?
Explain: "enhanced architecture" is short-hand. The current
agreement says "...report for..." What does contract language
mean?
TSIG and Distribution Master plus Editorial control
Q: Should the report now be interpreted to mean this new stuff, not the
original reference which has already been done?
<Discussion>
Q: What does DoC say?
A: Could just write up what was done and explain how it was accomplished.
Bill will summarize the existing report of what was done, pull out dates,
and submit to RSSAC for review.
Q: Is the report something that was helpful and would be worth doing again?
A: Resounding no.
---
Report from CAIDA (Kim Claffy)
Three main points:
1 - Root server attacks from October 21
3 measurement locations only; would like more observations points
UCSD
SanJose
Boulder
There were practice runs in two weeks before the real attack
2 - Dwayne's NANOG talk
analysis of 24 hours of tcpdump from f.root-servers.net shows that only
2% of all root server traffic is legit.
Q: Could some of this be due to IDN traffic?
A: Not IETF-standards IDN traffic.
http://www.caida.org/tools/measurement/dnstop/
/dnsstat/
3 - RFC1918 analysis
Analysis of the rfc1918 dynamic updates requests identified in #2
traffic requests
- show packets at midnight local time (in region)
(clocks out of sync so slightly off)
A spike in detail
Who is trying to update the roots?
Identify source of patterns, track source AS
Found that they are mostly from DSL and Cable Modem providers
Possible to fingerprint the OS?
Win 2000 or Win XP (default vendor behaviour)
How to fix...
Q: Has MS been told?
A: Not yet
CAIDA's DNS projects:
- continuous performance monitoring or root/gtld servers
- analysis of bogus queries and broken name server configurations
- investigation and modeling of bind algorithm behaviour
- evaluation and optimization of root server placement
---
Looking at ccTLD server behaviour (Neville Brownlee)
http://www.caida.org/~neville/
Using 2 sites: UCSD, San Jose
"multi" dns servers: Several servers host multiple cc TLDs;
they are getting 30% of the traffic
Surprising that Surinam is second.
rtts = both request and reply
trans = either request or reply
San Jose - proportions are different, but Surinam still 2nd
Summary: ccTLD servers generally do not perform as well as root and gtld
servers.
Proposal: Delay release of data to discourage script kiddies
---
Report from WIDE (kjc)
Summary sent to the list; please look at and provide feedback.
---
IPv6 Update (Kato)
Discussion among root-ops about v6 proposal from Suzanne.
Only 3 or 4 roots able to provide native v6 service at this point
if can get IPs from registry folks. (Apply to local RIR under micro-allocation
policy.)
Kato's revised report is not ready.
Suzanne – need a draft re: how to handle AAAA with dnssec.
Request to IANA for AAAA glue. Any opinions?
That is the recommendation that depends on these documents.
ICANN would like document saying that's an okay thing to do.
---
IDN
Is there anything for which rssac should provide feedback?
Has the situation changed at all?
Some motion; as CAIDA/Dwayne's slides show will see more bogus queries,
but not sure what RSSAC can do to test for this.
Difference is that answers will be longer, so that is why the issue came
up.
"Truncation in the additional data section is not truncation."
– ML
It may increase server load.
How know that it won't overflow into auth section? (orange/red zone dichotomy)
Probably need to look at again.
---
Joined by members of SECSAC:
Russ Mundy
Steve Crocker - chair ICANN's DNS Security & Stability Advisory Committee
- All people are folks with real jobs (no attorneys)
- Drawn from operational component (ISPs, registry, registrar, etc) including several folks in the room
Would like to know more about
what happened during the Oct attack; focused on long term issues so that
can facilitate what procedures will be developed.
Root servers are one aspect; other are TLDs and some high profile sTLDs.
Is the aggregate strength of the root servers structure better than even
a robust TLD, e.g., .com?
As a committee, not looking for more work, but would like to be cooperative
and anything that they do be a product of a joint effort.
Q: Why do two different ICANN committees need to talk?
A: Is there a need for two? root security vs. dns security. Should talk
so that decide if there is a necessity for a
second committee. (Assumed that this group knew what was going on since
so many of DNSSEC committee also on RSSAC)
The other principle of the committee is that whatever work is produced
is for the good of the internet. The output
should be outwardly focused and seek input, not just to provide advice
to ICANN.
RE: public reporting of events, would like to be joint and hold out a
common message about what happened or dispelling myths.
Trying to gather information about the various roots.
Suggestion: have independent party get the info.
Did questions get formulated?
Cmt: Just saying what you want to know would help.
Whatever asked and answered should be helpful for a specific purpose,
not just bureaucratic administrivia. Meeting soon.
Q: Is the meeting open?
A: No. Question of whether the committee should have some
open meetings is still tbd.
Q: Broad group: how many?
A: About 18.
---
TSIG and other
Plan drafted; proposed; agreed on. All root servers agreed and moved to
using TSIG. Therefore, could now use distribution master model instead
of xfer from a-root.
Now, would like to provide more robustness, are considering going to a
multiple-distribution master which can pull the zones from a couple of
different locations.
Now, can start discussing protecting the data, not just the distribution
path.
---
Anycast Plan (PV)
Sent copy of press release that ISC is deploying mirrors of root server
with APNIC.
K also has a plan; see ripe's website. Have already had offers to host.
DRC: Would like members of the group to comment on rfc3258 revisions
(T. Hardie document)
This addresses DDOS threat, not distributing bad data. That problem requires
dnssec; this is solved with anycast.
But still would like to sign the root zone, especially for these anycasted
machines.
Issue of route poisoning and re-direction is a concern, but is not something
roots could resolve. DDOS is. Implementing dnssec is made somewhat more
difficult with the anycasted servers, but not impossible. (Can solve with
locking the IP to AS.)
---
Attack/security Report (PV)
Should the group produce a report of what actually happened?
Should probably be two documents:
- Generic report about what happened
- Vulnerabilities shown; what could be done? what timeframe?
What is the target audience
for each? Should it be made public?
Comment: We should do the first, and it should be made public.
Really two attacks: one against roots, one against TLDs, so should the
report come from RSSAC or SECSAC committee?
The report about the attack against the roots should come from the RSSAC.
Q: Is anyone concerned about the possibility that a report of the attack
would be an invitation to further attacks?
A: Yes it is a concern. Depends on whose concerns are being considered.
Different groups (users, law enforcement, roots) will have different opinions.
Time line for a draft? By Tues, Nov 19.
---
Next meeting: Does this date/time work? Yes. Should the scheduled meeting
be longer? No.