Transcript Document 7844091

TPACT: the
Transparent Proxy Agent
Control proTocol
Presented to CS558
May 7, 1999
Alberto Cerpa & Jeremy Elson
outline of our talk
• Motivations
• Related Work
• Design & Standardization Effort
• Implementation Details
• Future Work
Motivations
for
TPACT
transparent caches
$
To Server
Farms
ISP Network
Internet
(Large Backbone ISP)
Clients
Congested,
Slow, and/or
Expensive
Transparent Caches: Reduce traffic without client configuration
typical cache setup
Critical observation: Cache usually
knows what should be intercepted,
but the Switch is the interceptor
Internet
(Large Backbone ISP)
Router
L4 Switch
Proxy Caches
ISP User
Network
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
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 “I’m busy -stop sending work to me.”
• Caches can tell switches to allow direct
connections for clients (e.g., on auth failure)
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
Related
Work
wpad:
web proxy autodiscovery
• Lets clients automatically discover proxies
• We’d 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
snmp: why not use it?
• Initially, it seemed perfect to us -- it’s a
generic way for net devices to interoperate
• But, we found ourselves redesigning things
that were already in TCP. We use TCP’s:
–
–
–
–
–
stream demultiplexing
retransmission policy
segmentation & reassembly of large messages
flow control
congestion control
• Like ICP designers: “Is SNMP too heavy?”
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
Design
and
Standardization
the basic design
• Turns out that many design parameters
come from switch implementation details.
• TCP
• Hard state
• Our own data format (very simple)
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.
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
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
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)
Implementation
of
TPACT
library design issues
• Who is charge of checking for ready fd’s?
– give all fd’s 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
library functions
• All functionality built into the library.
– read, write
– message parsing
– SHA-1 operations
– keepalive messages
– initialization procedure (with exponential
backoff)
issues, issues..
• Library is non-blocking (following squid
design)
• multiple callbacks functions to pass tpactpre-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
Future
Work
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
squid implementation
• “I am here” upon Squid initialization.
• New Event in charge of sending
KEEPALIVEs and flow control (based on #
fd’s opened).
• “Direct” this client to the Internet.
• Send HTTP redirect after ACK from NE.
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
that’s all, folks!
Thank you!