TPACT: the Transparent Proxy Agent Control proTocol

1
TPACT theTransparent Proxy AgentControl
proTocol

• Presented to CS558
• May 7, 1999
• Alberto Cerpa Jeremy Elson

2
outline of our talk

• Motivations
• Related Work
• Design Standardization Effort
• Implementation Details
• Future Work

3
Motivations for TPACT
4
transparent caches
Clients
Transparent Caches Reduce traffic without client
configuration
5
typical cache setup
Critical observation Cache usually knows what
should be intercepted, but the Switch is the
interceptor
Router
L4 Switch
6
the role of TPACT
Proxy Caches (or any other type of transparent
proxy)
L4 Switch
TPACT allows the cache and switch to exchange
control traffic
7
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 (and switches) can say Im busy -- stop
  sending work to me.
• Caches can tell switches to allow direct
  connections for clients (e.g., on auth failure)

8
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

9
Related Work
10
wpadweb proxy autodiscovery

• Lets clients automatically discover proxies
• Wed prefer clients use proxies this way
• Transparent Proxies are just a hack until
  clients that understand proxies are deployed
• Once proxy-aware clients are around, using WPAD
  (or similar), transparent proxies -- and TPACT --
  will be obsolete
• Until then, TPACT and WPAD will probably both be
  used on network elements

11
snmp why not use it?

• Initially, it seemed perfect to us -- its a
  generic way for net devices to interoperate
• But, we found ourselves redesigning things that
  were already in TCP. We use TCPs
• stream demultiplexing
• retransmission policy
• segmentation reassembly of large messages
• flow control
• congestion control
• Like ICP designers Is SNMP too heavy?

12
other related protocols

• ICP (Internet Cache Protocol)
• Used by caches to create hierarchies
• Complementary to TPACT will run in parallel
• Proxied app-level protocols HTTP, RTSP, etc.
• Big influence on design of a proxy, of course
• But, not directly related to TPACT

13
Design and Standardization
14
the basic design

• Turns out that many design parameters come from
  switch implementation details.
• TCP
• Hard state
• Our own data format (very simple)

15
redirection semantics

• If you ask the switch to allow a client through,
  do existing flows break?
• We assume that all switches keep per-flow state,
  and can redirect new connections without breaking
  old ones.
• Multiple services -- Redirection occurs per
  service.

16
NAT and GRE

• Earlier versions of the protocol include complex
  NAT queries in case the original IP dest addr was
  lost.
• Why not encapsulate?
• Generic Routing Encapsulation to tunnel
  application packets from proxy to cache
• Now - no NAT problems reduces complexity of
  design and implementation

17
authentication

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

18
current status

• Internet-Draft done
• Major issues decided
• Lots of details have been sorted out.
• Skeleton reference implementation of the TPACT
  library done.
• Draft will be reviewed by people at NetApp and
  will be submitted to IETF soon (hopefully)

19
Implementation of TPACT
20
library design issues

• Who is charge of checking for ready fds?
• give all fds to the application, which will call
  the appropriate msg handle library routines.
• Or, we can do all the fd processing as long as
  the application calls us periodically.
• Or, fork another thread from the library to do
  the work. (RTOS in the switches may not have a
  multithreaded model)
• We chose periodic call best tradeoff between
  ease-of-use and OS overheat

21
library functions

• All functionality built into the library.
• read, write
• message parsing
• SHA-1 operations
• keepalive messages
• initialization procedure (with exponential
  backoff)

22
issues, issues..

• Library is non-blocking (following squid design)
• multiple callbacks functions to pass
  tpact-pre-digested info to the application.
• Implementation is not thread safe. If used in
  such environment, we need to add synchronization
  to it.
• Message-Chaining API Incremental Hash

23
Future Work
24
our best laid plans

• Submit draft to IETF and shepherd it through the
  standardization process
• Use our library to build a working prototype
  system based around TPACT
• Modify Squid to use the client side
• Modify FreeBSD to use the server side
• Possibly work with vendors to help
  implementation, or revise the standard

25
squid implementation

• I am here upon Squid initialization.
• New Event in charge of sending KEEPALIVEs and
  flow control (based on fds opened).
• Direct this client to the Internet.
• Send HTTP redirect after ACK from NE.

26
FreeBSD switch

• Use same library
• Use the IP filter package to turn FreeBSD into an
  L4 switch
• Use the server-side piece of the TPACT library to
  have it listen, modify its filter lists
  appropriately
• Slow but useful

27
thats all, folks!
Thank you!