TPACT: the Transparent Proxy Agent Control proTocol

1
TPACT theTransparent Proxy AgentControl
proTocol

• Presented to CS558
• March 26, 1999
• Alberto Cerpa Jeremy Elson

2
outline of our talk

• History and Motivations
• What is TPACT? Why is it needed?
• Design Standardization Effort
• Complex, even before implementation
• Implementation Details
• Whos doing what current status

3
part one
a brief history of the web, and the stories of
those prophets who have come before
4
the book of genesis(c. 1993)
Genesis of the WWW Few clients, few servers, no
problem.
5
the book of numbers(c. 1995)
Cheap, Overloaded Server
Clients
Increasing numbers of clients Network Server
loads grow.
6
the book of numbers(c. 1996)
Server Farms (Fabios Territory)
Clients
Increasing numbers of clients So, add more
server capacity.
7
the book of exodus(c. 1997)
Clients
Exodus of clients From backbone providers to
small ISPs
8
the book of peter(c. 1998)
Clients
Transparent Caches Reduce traffic without client
configuration
9
the book of peter(c. 1998)
Critical observation Cache usually knows what
should be intercepted, but the Switch is the
interceptor
Router
L4 Switch
10
the book of jeremiahand alberto (558)
Proxy Caches (or any other type of transparent
proxy)
L4 Switch
TPACT allows the cache and switch to exchange
control traffic
11
what control traffic?

• When caches come up, they can tell the switch
  add me to your cache group
• Switches immediately stop sending work to dead
  caches using periodic KEEPALIVEs
• Caches can tell switches to allow direct
  connections for clients (e.g., on auth failure)
• When caches are not on same LAN as switch, dest
  IP is lost cache can get it from switch

12
part two
writing the next book, and convincing the
world that they should read it
13
why write a standard?

• There are many switch vendors and many cache
  vendors -- no one makes both (but Cisco)
• An open standard with a good, open-source
  reference implementation promotes use
• Standards are subject to peer review
• Doing it right, once, will (hopefully) prevent
  others from needing to reinvent the wheel

14
why not snmp?

• Initially, it seemed perfect to us -- its a
  generic way for net devices to interoperate
• But
• retransmission policy?
• hard state vs. soft state?
• authentication?
• too heavyweight for wire speed?
• can we do it in 2 months? -- straw that broke the
  camels back

15
the new camel

• TCP
• Hard state
• Our own data format (very simple)
• Possible to map easily to SNMP in the future, if
  necessary

16
redirection semantics

• If you ask the switch to allow a client through,
  do existing flows break?
• Do we add a redirect client except for the
  following ethereal ports command?
• Do we assume that all switches keep per-flow
  state, and can redirect new connections without
  breaking old ones?
• Ostrich Algorithm let the connections break?
• Multiple services -- only some redirected?

17
nat buzz

• Switches actually do 2 types of forwarding
• Forward the actual, unchanged IP datagram to a
  LAN where the cache is promiscuously listening
• Change the IP destination to the cache and route
  the modified datagram normally
• If we overwrite the IP destination, we still need
  to know where the client wanted to go
• Some application-level protocols tell us
• If not, use TPACT to ask switch
• Even with app headers, seems like we still need
  IP dest so we can forge the reply to the client!

18
authentication

• Both sides share a secret (say, a password)
• Sender
• appends the secret to its message
• calculates an MD5 hash
• replaces the secret with the MD5
• Receiver
• Saves the MD5
• Replaces the MD5 with the secret
• Calculates the MD5 (should match)
• Sequence numbers to prevent replay attacks
• Note this is authentication, not encryption

19
details, details(or, writing a standard is
harder than it looks)

• Byte ordering
• Which 1 byte do you use in a 4-byte int?
• Authentication specified for operations, or for
  connections?
• Sequence number space exhaustion problems
• etc., etc.

20
current status

• Internet-Draft just about done
• Major issues decided
• Some details not filled in yet
• Some details and semantics will probably change
  as we get implementation experience
• Its being reviewed by people at NetApp and will
  be submitted to IETF soon (hopefully)

21
part three
turning an idea into reality, and trying to avoid
learning lessons the hard way
22
division of labor

• Library of common functions (Alberto Jer)
• Server-Side (Jer)
• FreeBSD with IP Filter package
• Client-Side (Alberto)
• Squid

23
freebsd implementation

• Adding support to, say, an Alteon switch might be
  better do you have the code?
• We think we can emulate the behavior of a (slow)
  switch using FreeBSD IP Filter
• Having a FreeBSD-L4 switch may be useful
• FreeBSD public reference implementation

24
experimental topology
Roqueta (router)
L4 Emulator ( IP Filter)
Squid 1 ( IP Filter)
Squid 2 ( IP Filter)
Client
25
ip filter limitations?

• A real switch (e.g., the Alteon) can decide
  where a connection goes when it starts
• With the IP filter package, we have to install
  rules beforehand
• Will changing this mapping break existing
  connections?
• Maybe not per-connection state may be persistent
  even when rules change
• If so, use stable hash function ala multicast
  rendezvous point selection from set

26
what you get is notwhat you see

• IP Filters packet generation circumvents
  tcpdump need a hub and another machine
• The switches are having a confounding effect
  they may be preventing delivery of spoofed
  packets
• Trying to combine multiple services into one
  machine can be very confusing

27
squid implementation

• Helper vs. Library.
• Advantage of a helper
• Nice way of plugging in TPACT into Squid.
• Disadvantage
• Wed have to implement TPACT twice, or invent a
  2nd protocol from helper to squid
• Library has standard API that can be used by any
  cache or switch implementation

28
operation in squid

• I am here upon Squid initialization.
• New Event in charge of sending KEEPALIVEs and
  flow control.
• What servers IP if no Host info.
• Other cases?
• Direct this client to the Internet.
• Send HTTP redirect after ACK from NE.

29
direct/redirect example
L4 Emulator ( IP Filter)
Squid 1 ( IP Filter)
Client
30
anti-calamari(or, how to keep squid from getting
fried)

• Flow control based on no. of fds open
• Start/Stop with some hysteresis.
• Performance metrics
• Load same as before.
• Average response time statistics?
• Recovery from crashes
• process nicely handled by the OS (TCP reset)
• machine KEEPALIVE timeout.

31
thats all, folks!
Thank you!