Transcript presentation source

TPACT: the
Transparent Proxy Agent
Control proTocol
Presented to CS558
March 26, 1999
Alberto Cerpa & Jeremy Elson
outline of our talk
• History and Motivations
– What is TPACT? Why is it needed?
• Design & Standardization Effort
– Complex, even before implementation
• Implementation Details
– Who’s doing what; current status
part one
a brief history of the web,
and the stories of those
prophets who have come before
the book of genesis
(c. 1993)
Internet
Backbone
Client
Server
(with monitor; i.e. cheap)
Genesis of the WWW: Few clients, few servers, no problem.
the book of numbers
(c. 1995)
Internet
Backbone
Clients
Cheap, Overloaded Server
Increasing numbers of clients: Network & Server loads grow.
the book of numbers
(c. 1996)
Internet
Backbone
Clients
Server Farms
(Fabio’s Territory)
Increasing numbers of clients: So, add more server capacity.
the book of exodus
(c. 1997)
To Server
Farms
ISP Network
Internet
(Large Backbone ISP)
Clients
Congested,
Slow, and/or
Expensive
Exodus of clients: From backbone providers to small ISPs
the book of peter
(c. 1998)
$
To Server
Farms
ISP Network
Internet
(Large Backbone ISP)
Clients
Congested,
Slow, and/or
Expensive
Transparent Caches: Reduce traffic without client configuration
the book of peter
(c. 1998)
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 book of jeremiah
and alberto (5:58)
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 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
part two
writing the next book,
and convincing the world
that they should read it
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
why not snmp?
• Initially, it seemed perfect to us -- it’s 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 camel’s back
the new camel
• TCP
• Hard state
• Our own data format (very simple)
• Possible to map easily to SNMP in the
future, if necessary
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?
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!
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
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….
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
• It’s being reviewed by people at NetApp and
will be submitted to IETF soon (hopefully)
part three
turning an idea into reality,
and trying to avoid learning
lessons the hard way
division of labor
• Library of common functions (Alberto & Jer)
• Server-Side (Jer)
– FreeBSD with IP Filter package
• Client-Side (Alberto)
– Squid
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
experimental topology
Roqueta
(router)
Squid 1
(+ IP Filter)
L4 Emulator
(+ IP Filter)
Client
Squid 2
(+ IP Filter)
Internet
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
what you get is not
what you see
• IP Filter’s 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
squid implementation
• “Helper” vs. Library.
• Advantage of a helper:
– Nice way of plugging in TPACT into Squid.
• Disadvantage:
– We’d 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
operation in squid
• “I am here” upon Squid initialization.
• New Event in charge of sending
KEEPALIVEs and flow control.
• “What server’s IP” if no “Host:” info.
– Other cases?
• “Direct” this client to the Internet.
• Send HTTP redirect after ACK from NE.
direct/redirect example
Squid 1
(+ IP Filter)
L4 Emulator
(+ IP Filter)
Internet
Client
Step
Step 4:
1: Cache
2:
3:
5:
6:
7:
Server sends
Switch
Cache
Client
request
tells
tells
rejects
ACKs
switch
client
same
request
client’s
the
to Internet
to
updated
request;
toretry
to
direct
request
Internet
gets
(by
redirection
this
that
sending
(IP
intercepted;
time
client’s
addr
not
list
HTTP
not
requests
intercepted
authenticated)
sent
redirect)
totocache
Internet
anti-calamari
(or, how to keep squid from getting fried)
• Flow control: based on no. of fd’s 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.
that’s all, folks!
Thank you!