ICANN participation

1
August 2004

RSSAC - 19th Meeting



San Diego, CA, USA

Present:

Daniel K not here,
was not within telecoms reach, decided not to patch in by phone so no
conf. call

Agenda:

15:00-17:00

1. Anycast update
   (vixie)
2. v6 glue update
   (manning)
3. Security (crocker)
4. ICANN meeting
   report and administrations (woolf)
5. Measurement activities
   (kc, cho)
6. Future (jun)

1 - Anycast update
(vixie)

Successful and wide
deployment by about 1/2 servers, no longer controversial.

"everything seems to be ok" is the message.

List as found on www.root-servers.org

J in 15 sites

M live in Seoul.

I-root some global,
some not, depends on local environment 5 new sites about to go live, in
various stages of activation. Ones on web taking queries. Tokyo, Bucharest,
Ankara coming up. Chicago in installation, Washington, DC later. Also
KL/Malaysia.

B-root going to research
and education nets.

M-root work in planning.
couple of other locations

K-root, plan to deploy
3-4 global nodes during 04-05. 6-10 local nodes

One issue is unique
server identification. still issue of dealing with 'which server served
me' message info for when things go wrong. server id requirements being
perused by Woolf and Austien in IETF DNSEXT wg. Work stalled, restarting.

We need to do dnssec
soon, gives ability to track data. attack vector on anycast, "assert
I's IP # in odd place, can pretend another instance of I. having signed
zone to be published would help"

One can also stand
up machine for heavily multi-homed I root, same effect. possible even
AS-path checks won't detect. F had 145 BGP peers, before adding 2nd city.
from exterior Point of View, multihoming or anycast are not distinguishable.
not a new problem. we should use DNSSEC

2 - v6 glue update (manning)

ICANN received approval
to add v6 glue for TLDs - added v6 glue for KR,/JP,/FR zones last week.
Graph of v6 load from JP from Kato. V6 glue was in the authoritative section
of JP. base is 2-5 q/sec, but peak rises to higher end once deployed.
from 2 to 4 (!) so still at low end.

V6 glue update, in
the last MPLS meeting, talked about separating V6 glue for TLD from glue
for roots. The issues are slightly different. Since that meeting, there
has been some activity on developing matrix of what will/may occur when
we add v6 glue to root servers. We hope we will have fairly detailed matrix
available soon, if all else works properly, ought to be able to have it
done, do analysis afterward, timed for Nov IETF DC. more to report then.
Issues. Packet size, aiming for deployment in 2005

Working on Matrix,
report in Nov, something for the next ICANN in Cape Town There may be
disparity issues (who's running what server) shooting for 2005 implementation
not technically difficult but thoroughness is key!

SSAC - (crocker)

Joint participation between SSAC & RSSAC - lots of overlap.

Can talk about wildcard

Want to talk about DNSSEC

DNSSEC - the slide
pack from Verisign?

The dnssec-rm evolution

Deployment - once
DNSSEC specs are done.

Discussing what do we do to get from "here" to "there"

Verisign had a similar meeting yesterday

Jim Reid / ISC is running MOTA

ISSUES - a list of
unknown length.

Root Keys

Trust Anchors

Privacy

When? - for stability
- 9-18 months.

This is partly due to the need to coordinate between 12 orgs

Therefore it is likely to see TLDs go first

SSAC slides from
ICANN/KL

SSAC rotation & replenish

Need a writer...

The Wildcard Report ....

Spec cleanup will
he hard.

Does the report describe the "worst" ? KC.

Nope - Crocker.

3 - Security (crocker)

Spent a lot of time
on the wildcard problem

Spent a lot of time on dnssec

DNSSEC Deployment
(based on his slides)



Spent a lot of time wondering how to deploy dnssec and what the issues
are. A separate project has emerged. Long suffering and has taken quite
a while, over 10 years. Looking at the future, it's relatively easier
to manage the beginning and end than the middle.

Communities - IANA, Root Servers, gTLDs, ccTLDs, DNS Vendors

Complicated to deploy
dnssec at root due to the variety of demands for transparency and stability.
Root server operators are cautionary before announcing that they're dnssec
compliant. They are waiting for RFCs to be finalized and stable code available
before announcing a real deployment timetable. It is reasonable to wait
until 2nd half of 2005 to speculate more on implementation plans.

Sitefinder report

1 Verisign changed the registry; caused harm

2 the change violated engineering principles, blurred architectural layers

3 Verisigns change put itself in the loop for all current and future proto
changes

4 the change was abrupt despite long internal dev

5 quick reactions yielded more changes and counter patches

6 email senders and receivers were ingested into Verisign servers

7 web redirection page collected information associated with users

8 the collective events reduced trust overall

Recommendations:

1 no new wildcards
in TLDs

2 roll back wildcards in existing TLDs

3 Clean up specs

4 enforce proper discipline, including open notice and consensus, for

registry changes

taken up other subjects

- TLD failures (i.e.,
LY)

4 - ICANN meeting
report and administrations (woolf)

RSSAC updated to the
board publicly

- working on a separate recommendation re: v6 for the root

didn't have to talk much about anycast (not controversial)

TLDs are interested in deploying something like anycast

- 1 gnso

- 2 ccnso

- 3 at large

Issues getting candidates and nomcom have extended the deadline

New deadline is Aug 25

ICANN has invited
RSSAC liaison to the board

good time to identify (nominate) liaison from RSSAC

annual appointment via the ICANN bylaws

Suzanne, Bill, & Johan attend meetings pretty often (Matt Larson as
well)

Liman brought up that the current RSSAC participants are currently funded
by their respective organization. ICANN covering travel costs will mean
a loss.

General agreement
to put call on list, wait for replies for a week, then Jun selects.

5 - Measurement

KC - two sigcom papers.

Projects - (vixie demos DSC - software from D.Wessls)

Cho - a caida/wide
WS after the IETF. Need input from RSSAC

Presents interesting measurement graphs. 19 sites, has many of the same

Features as the RIPE/DNSMON tool

With anycast - RTT
may get worse - Kato

Clock resolution is problematic - if drift exceeds 10ms, it is hard to
tell - Vixie

AOB -

Barton invited to talk about v6 glue issues

Working on adding new glue - ICANN is getting v6 transport.

Delegation procedure docs well received.

Wants to see v6glue for root.

Use existing procedures
to get NS glue updated.

6 - Futures
- Next meeting date is 06nov - Sunday 15:00-17:00 - WDC IETF-61

Notes taken by: Bill
Manning, Steve Conte, George Michaelson, Andrei Robachevsky