Xtrace: a Crosslayer network trace tool

1
Xtracea Cross-layer network trace tool

• Rodrigo Fonseca and George Porter
• R. Katz, S. Shenker, I. Stoica

2
Introduction

• Xtrace a network diagnostic tool for tracing
  requests at multiple layers
• Higher and lower levels
• Recursive connections (DNS, web services)
• E.g., overlays, proxies, p2p, recursive DNS,
  email through multiple servers
• Why?
• Applications increasingly use middleware,
  proxies, overlays, and network appliances
• Network layer tools (i.e., traceroute) work at a
  single layer for a given source/destination pair
• We dont want each app to develop its own tracing
  tool

3
Outline

• Two motivating examples
• Our approach XTrace
• Research problems
• Supporting cross-layer metadata
• A secure notification architecture
• Revisiting the example
• Current status and future work

4
Example 1 HTTP Proxy
HTTP
TCP
IP
Client
Proxy
Server

• The client, proxy, and server know about HTTP
  proxies, but not intermediate routers
• So even if an IP router were dropping a packet,
  any ICMP notification would be sent to the proxy,
  not the client

5
Example 2 OCALA

• Network infrastructure services like I3 are out
  there and are going to be used if theyre useful
  to people
• Stovepipe tracing and debugging a bad idea
• Replicating work, cant share tools
• The users need end-to-end tracing, not just of
  sub-components such as I3

6
Alternative approaches

• In-band tracing
• Shares fate with faults in the connection
• Limited space receiver must send trace data back
  to sender

• Network layer
• Traceroute
• Per-protocol
• I3 traceroute in development
• Cross-layer as a service (Rexford, et al)
• Focus on control-path information

7
XTrace Approach

• Put metadata into packets that reaches the
  endpoint
• Even for requests that are made up of multiple
  connections

• Have devices use that metadata to notify the
  sender of what theyve seen
• Out of band
• Using a transport of the senders choosing

Client
Proxy
Server
8
Research problem 1Supporting cross-layer
metadataResearch problem 2 Designing a
notification architecture
9
Research problem 1Supporting cross-layer
metadata
10
Cross-Layer Metadata

• Key problem
• Propagating lower level annotations in new
  connections
• Requirements
• Has to be in the uppermost layer to get to the
  final destination
• Devices shouldnt look in layers they dont
  support
• Incrementally deployable
• What about the Annotation Layer?
• Vision a scratchpad for adding/removing metadata
  by devices along the path
• Sufficient, but still in development
• Thus, we have implemented a subset of AL
  functionality for well known protocolss

11
Cross-layer metadata approach

• Put the metadata in each layer
• Imposes overhead, but now devices only look at
  their layer
• Encode metadata in option fields or extension
  headers
• Incrementally deployable
• As new connections are opened (i.e., by the
  proxy), copy the data into the new connection
• via libxtrpropagate

• Protocols this approach can support
• Has an option field or extension header
• This header propagated to the destination
• Protocol support
• HTTP, TCP, IP, I3, NAT, Firewall
• Soon SMTP, DNS
• Desired Ethernet/wireless

12
Client
Proxy
Server
GET / HTTP/1.1 Host berkeley.edu X-Layer
123456
HTTP
dport 8080 sport 17658 seq_num
6253 tcp_option XTR123456
TCP
dst_ip proxy src_ip client ttl 58 ip_option
XTR123456
IP
13
Libxtrpropagate Example
libxtrpropagate
Squid Proxy
xtr_connect(d, anno)
Web Server
Kernel
Annotated request

• Squid reads the XTR annotation out of the web
  request
• xtr_connect() sets up state in kernel so that
  when the SYN packet goes out, it is properly
  annotated

14
Research problem 2Designing a notification
architecture
15
Notification example
report.net
r4.router.net
r1.router.net
r3.router.net
me.client.org
p1.proxy.net
Annotation (type I3 data i3_trigger)
www.berkeley.edu
16
Secure Notification Architecture

• Requirements
• Metadata dictates how and where notifications are
  sent
• Completely stateless for each device
• Incrementally deployable
• The device/AS controls who gets notified
• Fine-grained access control of internal
  information

• Challenges
• Visibility
• Preventing abuse
• Against the device itself
• Against the receiver of notifications

17
Notification Approach

• Flexibility of transports
• UDP over IP, I3, Locally kept logs
• Visibility
• Shared secret / capability
• Trust relationships between ISPs (capability
  switching)
• Multiple layers
• E.g., unauthenticated just the border routers
  authenticated detailed topology information
• Preventing abuse
• I3s DoS protections

18
Network diagnosis with XTrace
Bro Process stopped
IP ISP 3
I3 Overlay

• Notification from BRO server
• IP saddr server2.i3.com daddr
  server.bro.com
• TCP sport 3212 dport 80 (no listening
  socket)

19
Current Status

• Initial implementation
• Built on Apache runtime (APR)
• Linux, Mac, Windows
• Libxtrreport
• I3, UDP
• Local logging (soon)
• Libxtrpropagate
• Complex design using IPC message queues

• To be done
• Controlled visibility solution
• DoS prevention
• Tools

20
Thank you

• Weve got a poster on Xtrace
• Feedback/suggestions/discussion welcome