Scamper Development Matthew Luckie mjl@wand.net.nz Last years - - PowerPoint PPT Presentation

▶
scamper development
SMART_READER_LITE
LIVE PREVIEW

Scamper Development Matthew Luckie mjl@wand.net.nz Last years - - PowerPoint PPT Presentation

Dec 15, 2023 14 likes •136 views

Scamper Development Matthew Luckie mjl@wand.net.nz Last years scamper work Inferring and Debugging PMTUD Failures Paper at IMC 2005 Datalink access Bypass IP stack for writing some packets Avoid IP stack fragmentation

slide-1
SLIDE 1

Scamper Development

Matthew Luckie mjl@wand.net.nz

slide-2
SLIDE 2

Last year’s scamper work

  • Inferring and Debugging PMTUD Failures

– Paper at IMC 2005

  • Datalink access

– Bypass IP stack for writing some packets

  • Avoid IP stack fragmentation
  • Precise control over what appears on wire

– Fixed bug in FreeBSD for writing to DLT_NULL BPF devices (6.0-RELEASE): PR kern/82157 – Did away with any code that manipulated the routing table

slide-3
SLIDE 3

Last year’s scamper work

  • TCP Traceroute (IPv4)
  • Darryl Veitch’s TSC clock
  • File Format Work
  • SSL version of skdatad
slide-4
SLIDE 4

Future Development

  • SSL version of skcollectd
  • Implement Doubletree Algorithm
  • BGP
  • Annotate data files with IP to DNS name at

the time of capture

  • Rocketfuel
  • Pin-pointing Routing Changes
slide-5
SLIDE 5

SSL version of skcollectd

  • Currently, skitter uses kerberos 4.
  • FreeBSD 5 onwards ships with kerberos 5.
  • Replace authentication / encryption with

SSL which is more widely deployed and understood.

– Some of this work has been done

slide-6
SLIDE 6

The Doubletree Algorithm

  • Donnet / Raoult / Friedman / Crovella

– (sigmetrics 2005)

  • Goal is to reduce the number of times an interface

is visited during large-scale topology discovery

  • Intra-monitor redundancy

– Many interfaces are visited repetitively from the same source

  • Inter-monitor redundancy

– Many interfaces are visited repetitively from the distributed monitors

slide-7
SLIDE 7

The Doubletree Algorithm

  • Avoid probing the destination and working

backwards (as in Mercator)

– a mesh of hosts probing the same address simultaneously might appear as a DDoS

  • Challenge then becomes determining where (h) to

begin probing

– Selecting an appropriate value of h – Current suggestion is to determine the hop distance where most new interfaces are discovered

slide-8
SLIDE 8

BGP

  • Obtain routing table and updates by peering

with a local router.

  • Annotate data files with BGP data at the

time of capture

  • Re-probe path changes signaled by BGP

update

  • Use AS path to guide Doubletree, discussed

as future work in sigmetrics 2005 paper.

slide-9
SLIDE 9

DNS

  • Annotate data files with IP to Name

information

  • Not really a focus until Doubletree is used,

since goal is to reduce network load

  • Leads to Rocketfuel…
slide-10
SLIDE 10

Rocketfuel

  • Spring, Mahajan, Wetherall (SIGCOMM 2002)
  • Detailed ISP maps

– They used 300 traceroute web servers… – … don’t have required skitter monitor deployment for this (20 or so monitors) but it is worth thinking about – there are other contributions to use

  • BGP to reduce probe count (RouteViews)
  • DNS data to determine purpose, location of routers
  • Alias resolution
slide-11
SLIDE 11

Pin-pointing Routing Changes

  • Teixeria, Rexford. SIGCOMM NetTs 2004
  • Straw-man proposal for inter-ISP

cooperation through an “Omni”

  • Use BGP + Local AS policy + IGP
  • Not sure this fits with other proposed work,

but it is something I’m interested in.

slide-12
SLIDE 12

Feedback Invited