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

From: Andrew Knutsen <[email-masked]>
Date: Mon, 03 Aug 2009 14:53:36 -0700

We've just posted 
<http://www.ietf.org/internet-drafts/draft-knutsen-tcpm-middlebox-discovery-00.txt>.  
The intended category is Informational.

    Current technology uses several experimental and unassigned option 
kinds for this function, by different vendors. This draft represents an 
effort to allow use of a single, standard, flexible option.  We 
appreciate your attention, so we can begin moving toward an assigned 
option kind.

Abstract

This document describes a TCP option intended to facilitate
transparent detection of middleboxes (or services playing that role)
along the path of a TCP connection as the connection is made. The
option has no effect if an appropriate middlebox is not on the path.

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 13 Aug 2009 11:51:42 -0700

Are there any comments on this draft?  We'd like to proceed ASAP, so 
we can begin working the new option assignments into our protocols.

Andrew

Andrew Knutsen wrote:
> kinds for this function, by different vendors. This draft represents 
> an effort to allow use of a single, standard, flexible option.  We

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Thu, 13 Aug 2009 14:40:31 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Andrew Knutsen
>Sent: Thursday, August 13, 2009 2:52 PM
>To: [email-masked]
>

Here are some comments ...

First, it's definitely good to see this kind of thing being brought for a
proper number assignment rather than simply silently poaching one.

Just from the abstract, I wasn't sure what "transparent detection" meant ...
or if it should've been "detection of transparent middleboxes".  To me,
"transparent detection" sounds like the detection itself is undetectable :).

In terminology, should client and server really be described in terms of
request/response or should it be based on TCP concepts like sending a SYN
or being in LISTEN?

Requests MUST have the "R" bit set to 0, and Responses MUST have the "R" bit
set to 1 ... but Requests MUST be in a SYN packet ... so I guess I don't see
what the R-bit is accomplishing that the ACK bit doesn't already.  If SYN-ACK
is set, it's a response, and if SYN (but not ACK), then it's a request, right,
or am I missing something?

Does this need to think about simultaneous open at all ... it's probably a
non-issue, but worth mentioning just to make sure the bases are covered.

The security considerations isn't quite right specifically, as it doesn't
distinguish between different modes or ESP/AH in IPsec that affect the
option's visibility and protection.

My biggest question, simply because I'm totally naive about these things is
who will use it, and if they already have something like it that this is just
formalizing and standardizing on.  Further, I'm guessing that there's some
way that the data from this option gets shared outside the TCP implementation
with the app, but I don't totally understand what the app is going to do with
this knowledge.  I guess maybe section 7 (empty, currently) will discuss that?
Sorry if everyone else knows this already and I'm just late to the party :).

My overall take-away from a quick read is that it seems a bit like this is
hacking something into TCP to assist applications in creating layer violations,
and I don't quite understand the driving requirement or the benefits that can
be gained by having it.  Maybe there are some references or further discussion
to be included to motivate the mechanism?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 13 Aug 2009 12:58:08 -0700

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.

    "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.

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

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

    I can't comment on the security aspects right now because its not my 
area, but I'm sure we can add more info there. Perhaps one of my 
colleagues will answer ;-).

    We can add some information to section 7 if desired, but middleboxes 
typically run proprietary operating systems and thus the APIs are not 
standard...  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...

Andrew

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Thu, 13 Aug 2009 15:23:38 -0500

Ok; just a couple easy follow-up questions:

>From: Andrew Knutsen [mailto:[email-masked]]
>Sent: Thursday, August 13, 2009 3:58 PM
>

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.

>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"?

>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.

>client/server technology. We can make this explicit.

It seems reasonable to do so.

>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?

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?

>  And yes, WAN Optimization can be considered a layering

Fully understood and I don't disagree :).

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 13 Aug 2009 15:51:56 -0700

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

> I guess that's all just background information that's needed to put the
    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.
> 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.

> 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.

> It seems reasonable to do so.
    Will do.
> 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.

> 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

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Fri, 14 Aug 2009 09:13:22 -0700

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: [email-masked]; Mahdavi, Jamshid; Frederick, Ron; Li, Qing; Yeh, Wei
Jen
Subject: Re: [tcpm] New ID available: TCP Option for Transparent
Middlebox Discovery

		-----Original Message-----
		From: Andrew Knutsen
[mailto:[email-masked]]
		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.

	

		   "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"?

imply that the connection works if the middlebox is not present, does
it?

	

		   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.

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

	

    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?

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?

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...