Agenda

 Agenda Bashing
 Name Service Daemon and DISTEL (D. Karrenberg)
 RIR presentation (R. PLzak)
 Routing Beacons and other things (H. Uijterwaa)
 GEANT Deployment of Premium IP (S Leinen)
 Looking at ccTLD server behaviour (N. Brownlee)
 Dial-By-ASN (B. Woodcock)
 Sources of ongoing damage to DNS System (K Claffy)

1. A Name Service Daemon

Daniel Karrenberg

distel2.pdf (ppt)(Also at http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-dnr-nsd)

nsd.pdf (ppt) (Also at http://www.ripe.net/ripe/meetings/archive/ripe-43/presentations/ripe43-dnr-distel)

a Name Service Daemon Why?

• code diversity
• at the end of 2001 there was increasing awarness of the common code base of the root servers. SOme diversity was seen as positive
• this allows a simple server-only implementation, increased performance in terms of server capacity, and the release of an open source implementation

What is nsd? Authoratitive only DNS name server

• no recursion
• no caching
• no dynamic update
• no zone transfer

Performance Outcomes

• code diversity has been achieved, including bug diversity
• simplicity - 6,000 C lines with the daemon 1,000 code lines
• performance
• open source

Who could use nsd?

• publish of auth zone information
• tld servers
• .. anyone who has to publish auth xone info

NOT

• recursive
• dynamic updates

Questions:

Q: Do you have wrappers around it?
A; half done - for simple uses you can use named-xfer. Some ideas include simple perl with an operator's interface with info on time of last fetch, oldest loaded zones, server status.

Q: more than authoritative servers?
A: no - this is not a follow of Bind which attempts to do a far broader set of functions.

Testing

Why?

regression testing of nsd - reasonable confidence that nsd is working
performance evaluation of code and hardware platforms
simulation and analysis of abnormal query loads

present a reproducible load to the server

not finished as yet

None of the difference encountered will be noticed by resolvers conforming to the Internet standards. Issues of reproduction of timing of replay of load with anomalies of microsleep function in FreeBSD was resolved with the use of a busy wait to correct microsleep anomalies.

Talk to Daniel if intersted in the test lab - there is no manual and nothing other than best efforts of support.

Q: are you interested in volunteer assistance?
A: what someone to take the tarball and log their experience and turn the log into installation instructions

A: suggestions for synthetic loads would appreciated

Q: you you have any sampled loads from the root server dos attacks?
A: no

Q: have you measured the speed to reload for nsd for a large zone file
A: you don't need to load it, as the database provides the answers for queries. You don't notice reload time normally

Q: how big?
A: .nl (750K delegations, 200M compiled size) .de (couple of million, takes a 4G drive on a 32 bit machione - a 64 bit machine would be prefereable for such a zone size)

Q: you have tried all kinds of different zones?
A: yes

People interested in real sizes of compiled zones should contact Daniel. Also those interested to run this, see Daniel and the nl lab people.

2. Joint RIR Presentation

Ray Plzak

rir.pdf (ppt)

Welcome to LACNIC as the most recently chartered RIR

Review V4 allocation

• 17 /8 (6.6%) attempting to return to the pool
• 44% still available at this stage
• historic allocations- 35.5%
• RIRallocations- 14%
• ExperimantalReserved - 6.3%
• Multicast 6.3%

  higher utilization rates in the RIR allocation blocks is a reasonable supposition

ASN assignments

57% available

V6 allocation review

/35 & /32 allocations

Joint Activities

aso SUPPORT - arin TO apnic (2003)
Outreach - East Africa Forum and IPv6 Forum
Coordination - IPv6 common policy, ERX Early Registration Exchange project, Sgtaff exchange, RIR blueprint

Comment: PLease have non-overlapping meeting dates for RIR meeings.

Routing Beacons and other things

H. Uijterwaal

beacons.pdf (ppt)

Look at route flapping, flap dampening, BGP under stress. Use a test rig that announces and withdraws a know prefix at known intervals. There are usually 2 or 3 beacons active at any particular time.

Request to set up more beacons - RIPE NCC to set up more at their route collector sites (9). Uses a /19 for this as an experimental effort. Announcements are at 0, 4, 8, ... GNT witgh withdrawals at 2, 6, ... GMT. The beaconing prefix is 195.80.224.0/24, 195.80.225.0/24, ... 195.80.232.0/24 at each route collector point.

What do you see?

• list all the BGPupdates following an announce or withdraw time
• withdraws may trake up to 24 updates before the withdrawal is complete
• latency for event and first response - appears to have a median of some 30 seconds with a tail of up to 140 seconds
• last message is lingering - announcements tail off after 200 secs - withdraaws tail off after 500 seconds
• time that a prefix is unstable - withdrawals - time of last message
• time of first message - note a staggering of 30 second clumps of min route advert update interval
• note also the lengthening paths for withdrawals

Latency roughly consistent with previous studies same effect of expanding paths as per previous studies questions and work remain

Update on RIR - IPv6

Update on Test Traffic - CDMA clocks for the synchronized measurement - IPv6 also available - Contact Henk for details

Q: Are beacons similar to the IPMA fault injector?
A: This was an experiment some time ago and no longer active.

3. GEANT Deployment of Premium IP

Simon Leinen

geant.pdf

Environment of a Backbone network, with heterogenous national networks with campus networks. GEANT has been active for around 12 months, using a 10G STM-64 POS core. Heavily overprovisioned network.

SEQUIN Project of DIffServ deployment. Objective to find a replacement for a managed bandwidth virtual circuit service that based on ATM in a previous incarnation of the pan-European network.

A need for two elevated services: premium low jitter rate limited service, and some form of "IP+" using some kind of assurred rate model (e.g. min dandwidth guarantee - couldn't build). Note this is multi-domain in cores plus national feeder networks.

Implementaiton of low jitter service within a domain - this is "classical" EF-based implementation use different policing granularity - core does AS pairs, edges may do network pairs. BUT routers do not have easy way to specify policing with respect to origin AS. not implemented.

There is a desire to be "lenient" with respect to bursts. Bursts were just let through. No egress shaping. Not worth the effort. INgress policing was assumed close to the source, and the backbone simply policed between domains in an approximate fashion.

Implementation through over-provisioning was an option for the feeder networks.

Hard to draw conclusions with this effort so far as the core is extensively over-provisioned.

Room discussion of trial using long latency 64K lines. Lab tests of recent hardware found line rate sustained with QoS features turned on.

Tests using H.323 packet traces across the backbone. Capture a stream and replay it using different paramters and compare the new capture ot the original. Noted packet recordering on packets of different sizes with 300Kbit bit rate. Noted with variation of packet sizes. reordering packet size traceroute shows this. Also use a modified traceroute to see a modified DSCP.

Lessons - its a lot of work, it requires comprehensive edge policing, overlay networks are difficult, user satisfaction and performance are not related, provisioning needs to be streamlimned.

Focus now shifting the SLAs and an end-to-end performance problem.

Q: Distributed denial of service attack with EF traffic flooding.

Looking at ccTLD server behaviour

Nevil Brownlee

http://www.caida.org/~nevil/leiden/iepg200211.html

Look at round trip tip time of cctld name servers using NetTraMet.

Data collection at two points, collecting the request and matching response packet pairs and looking at RTT.

Initial investigation revealks higher variation of RTT as compared to the roots and gTLDs on the whole, althought this is a highly approximate observation.

Dial-By-ASN

Bill Woodcock

www.pch.net/inoc-dba A Phone system that will contact of the NOC associated with an AS. Uses SIP as the base. The phone boot DHCPs an address and registers with a SIP registry. The problems so far are with NAT traversal (of course). But it can be done with static configuration. STUN is also relevant to the NAT issue.

QoS is completely unnecessary!

Sound quality exceeds the PSTN even under the worst conditions.

This works on any SIP phone, including various soft phones and 802.11 phones

Sources of ongoing damage to DNS System

K Claffy

Monitoring dns root server performance. The DOS attack on the root servers is noticable in terms of monitoring root server response time. It was noted that this has happened in the previous week(s) as well.

Reference Duane Wessell's presentation at NANOG October 2002 noting that some 2% of F root queries were valid and the other 98% were not! This tallioes with an earlier CAIDA study. Two tools are available.

One of the categories of root traffic are RFC1918 updates being sent to the root nameserver system. This traffic is being measured and analysed. Stroing diurnal pattern evident. Largely DSL and cablemodem providers appear to be leaking these updates to the roots. Predominant OS is Windows-based. This can be fixed, at 6 menus deep in the OS. The default software design and its configuration of these Microsoft OS platforms is evidently causing a massive amount of traffic sent to the root name server system.