Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery

["Mahdavi, Jamshid" <[e-mail]>]

I'd like to add one thing to Andrew's last point regarding
interoperability.
 
We tried to design the option specification to allow for companies with
proprietary protocols to do discovery via the OUI ("Private") mechanism.
In this case the expectation is that the option is largely used in a
"Private" fashion -- in our case, one Blue Coat device finding another
Blue Coat device.
 
For cases where there is a desire for real interoperability between
multiple products from different vendors and/or open source packages,
our hope is that such applications would define a non-private "device
type" and have this allocated by IANA.  A suitable RFC would have to be
provided specifying how discovery for that device type is supposed to
work and that is really where things would open up for anyone to be able
to use this option in an interoperable fashion.
 
I can try to give one hypothetical example of what this might look like.
In HTTP, browsers provide slightly different formatting for the URL
depending on whether they are using a proxy or speaking directly to a
server.  When companies write transparent HTTP proxies, they must deal
with the server format of the URL.
 
One could imagine a transparent middlebox discovery option defined for
the purpose of discovering transparent HTTP proxies.  If present, the
application (the web browser) could adjust the HTTP header to be more
suitable for an HTTP proxy.
 
This is somewhat of a contrived example since no one really needs this
today, but we've defined the option formatting to allow for
standardization of such mechanisms that would allow applications to
discover and cooperate with middleboxes in the path (if they are present
and if they are interested in such cooperation).
 
--J
 

________________________________

From: Knutsen, Andrew 
Sent: Thursday, August 13, 2009 3:52 PM
To: Eddy, Wesley M. (GRC-MS00)[Verizon]
Cc: [e-mail]; Mahdavi, Jamshid; Frederick, Ron; Li, Qing; Yeh, Wei
Jen
Subject: Re: [tcpm] New ID available: TCP Option for Transparent
Middlebox Discovery



    I'll put my responses inline this time...  

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: 

	Ok; just a couple easy follow-up questions:
	
	  

		-----Original Message-----
		From: Andrew Knutsen
[mailto:[e-mail]]
		Sent: Thursday, August 13, 2009 3:58 PM
		
		   To answer your fundamental question, yes this is
existing
		technology, implemented by at least three companies for
several years.
		You can check our website (www.bluecoat.com) for one
example. This
		assignment will not change the basic operation of these
WAN Optimization
		products.
		    

	
	
	Ok; so what option number do they use?  Do they all use the same
one,
	or does each company pick its own?  How was the option format
arrived
	at (is it just Bluecoat's or do all the vendors use their own
variation)?
	I guess that's all just background information that's needed to
put the
	effort in context.
	
	
	  

    We use one of the "experimental" numbers, 0xFD.  Cisco uses 0x21,
and Riverbed uses both 0x4C and 0x4E. You can draw your own conclusions
on how they were picked ;-). Although this info can be easily "sniffed",
its probably not appropriate to put it in the draft. In fact, I'm not
making any promises or representations about BlueCoats, or anyone
else's, use or non-use of any of these or any other numbers in the
future or the past.  I hope that keeps the lawyers happy.


	

		   "Transparent detection" refers to the fact that there
is no explicit
		detection protocol; instead the detection is piggybacked
on the TCP
		connection transaction, which goes through to the OCS
(as we say;
		Original Content Server, the host explicitly addresses
by the SYN
		packet) if the connection is not intercepted.  Again,
this is existing
		multivendor practice, used for the reasons mentioned in
the draft.
		    

	
	
	Ah; so there's terminology confusion between calling a middlebox
	transparent (meaning without end-application/transport
knowledge) and calling
	the detection transparent (meaning no extra packets sent).  I
guess it would
	be more clear as "in-band detection"?
	
	
	  

    Well, our implementation is transparent in both ways..  although
another vendor uses a slightly different transparent exchange, where
extra packets are sent if a peer is detected.  The current proposal
could be used for many of these mechanisms.  "In-band" doesn't really
imply that the connection works if the middlebox is not present, does
it?

    The word "transparent" is used fairly widely in the sense of no
explicit configuration, although it can also refer to use of the same
addresses on a tunnel connection as on the client and server connections
(see below).

    Also, the "no extra packets" isn't a common use of the word,
although one might consider it "transparent in time" ;-). Its just a
real-world requirement.



	

		   The "R" bit is to detect hosts which misbehave, and
reflect options
		back to the sender.  This does happen.
		    

	
	
	Ick!  That makes sense, but it should be explicitly stated in
the discussion
	of the R-bit if that's its full reason for existing, rather than
only mentioned
	in passing in the interoperability issues section.
	
	  

    We felt that it is an interoperability issue, and discussing it
earlier would detract from the discussion of the primary purpose.



		   Simultaneous opens have never been an issue because
this is
		client/server technology. We can make this explicit.
		    

	
	
	It seems reasonable to do so.
	  

    Will do.


	
	  

		   We can add some information to section 7 if desired,
but middleboxes
		typically run proprietary operating systems and thus the
APIs are not
		standard...
		    

	
	
	Right, but (correct this if I'm wrong ...) you have to also
modify the
	TCP and application on the endpoints that initiate
communications, right?
	Or will this only be intended for middlebox-to-middlebox?  I'm
still
	trying to understand what an application does now that it knows
something
	about the middlebox(es), what changes about its behavior?
	  

    Our use for this, which I think is the most common, if not the only
use at present, is to set up "tunnels" as described in section 1. Since
this draft is not a protocol spec, we didn't add detail about how these
work.  However for the purpose of this discussion:

     There are usually four "boxes" involved when a tunnel (as described
here) is used: the client and the server, which don't know anything
about this option, and two middleboxes, which we may call the "edge"
(near the client) and the "core" (near the server). However, it is
possible for the edge function to be implemented in the client box. It
is also possible to have multiple tunnels along a path, so one box is
both edge and core. Server and core are less likely to be combined
because that would add load to the server.

    Both the client and the edge can use either explicit or transparent
connection methods. The simplest, and currently most common, use of this
option is transparent detection of the core by the edge (ie to see if
the server is fronted by a core box), for the purpose of setting up a
tunnel between two middleboxes.

    Note that there are other kinds of "tunnels" which are really more
like relays, in that there is only one middebox.  There are also tunnels
where transparency is not appropriate, such as VPN tunnels. The tunnels
I'm talking about are most often used for compression (aka WAN
Optimization).

    I could add a lot of pictures to this, but at this level they're
just series of boxes with lines between them ;-).

    Again, we didn't feel this level of background was appropriate for
the draft, partly because we don't want to prejudice any future efforts
towards protocol-level interoperability in this area, and partly for
legal reasons (I haven't compromised myself here, I don't think, but if
I went into more detail I might). However perhaps we could add a
sentence saying "tunnels", as defined in the draft, are a primary use
case.



	The draft is pretty good in explaining the format of the option
itself,
	but doesn't really speak to how the knowledge the option conveys
gets
	used productively.  As the application-writer, now that a know
	company X's gizmo 123 is in my path, how does that affect me
versus
	not knowing it, or knowing that company Y's doohickey 456 is on
the path?
	  

    In order to request interception by company X, you'd want to find
out how they registered their option (OUI or IANA), and what particular
info they want in the option. Then you'd need to know what to do if they
responded. Also, you wouldn't really need this if you knew what was in
the path (you'd likely use an explicit arrangement).

    However, if you were writing a server-side app and looking at all
the options received, you'd at least know to ignore this option. Or, if
you were writing a network monitoring tool, you could keep track of
interception requests and responses. If you were writing a firewall, you
could do policy on it.  Etc...

Andrew



	
	  

		 And yes, WAN Optimization can be considered a layering
		violation, along with most other security and
load-balancing
		middleboxes, but that won't make them go away...
		    

	
	
	Fully understood and I don't disagree :).
	
	
	---------------------------
	Wes Eddy
	Network & Systems Architect
	Verizon FNS / NASA GRC
	Office: [phone]
	---------------------------