Subject: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 9 Dec 2009 14:03:00 -0600

TCPM has been discussing draft-knutsen-tcpm-middlebox-discovery
for some time now, and the latest copy:
http://tools.ietf.org/html/draft-knutsen-tcpm-middlebox-discovery-03
includes many revisions based on feedback from the working group.

At this point, the authors have asked if it can become a TCPM
working group item, targeted for Experimental (although the
draft currently says "Informational"; intended-status can be
discussed further).

Please respond to this email whether you think:

(1) the Middlebox Discovery Option SHOULD become a TCPM working
   group document, and you would support work on it

or

(2) the Middlebox Discovery Option SHOULD NOT become a TCPM working
    group document

If possible, responses in the next two weeks, by 12/23, will be
appreciated.

--
Wes Eddy
MTI Systems

---

From: rick jones <[email-masked]>
Date: Wed, 09 Dec 2009 19:11:00 -0800

How many angelic options are we going to try to get to dance at once  
on the header of a TCP SYN segment?

> There may be situations where other options are required in the SYN  
> packet which do not leave enough room for all of the target data  
> necessary for the desired device capability to be advertised. In  
> these cases, a shorter alternate device capability may be defined  
> which signals the request to further negotiate the capability after  
> the handshake completes. This will impact performance by introducing  
> an extra round-trip during connection set-up, but this may be the  
> only way to perform the negotiation within the limited TCP option  
> space available.
An additional round-trip??

Not being at all certain I've been around the list/wg long enough to  
cast a vote, I'll simply say it sounds dodgy to me.

rick jones
Wisdom teeth are impacted, people are affected by the effects of events

---

From: Andrew Knutsen <[email-masked]>
Date: Wed, 09 Dec 2009 21:01:17 -0800

I'll just say again that this solution has been deployed by several 
vendors for several years (using several invalid option kinds). The only 
way to avoid the problems mentioned below (and others, elsewhere) is to 
force them (us) all to change, probably at the cost of competitive 
advantage, and possibly by making more fundamental changes in TCP 
itself. We agree that standardization in this area is a worthwhile goal, 
however it is most likely to be accomplished incrementally.  The current 
proposal represents a first step in that direction.

Andrew

rick jones wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Thu, 10 Dec 2009 09:19:13 -0600

Speaking as an individual (not a WG co-chair), it was an eye-opener
for me to discover that there are N vendors, each of which is doing
something similar to this, and they're picking their own TCP option
numbers (not getting them properly allocated and documented).

That's "really bad".  It basically turns the space of what we think
are unused options numbers into a minefield of somewhat-used options
numbers.  In the sense that this proposal is a possible step towards
fixing that in the long term, I can support it.

It's possible that there are other approaches to fixing the situation;
if so, maybe we should be talking about those too.  Does anyone else
feel like there's a potential for the options space to be poisoned
by the current middlebox discovery practices?

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: Andrew Knutsen [mailto:[email-masked]]
>Sent: Thursday, December 10, 2009 12:01 AM
>To: rick jones
>Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; [email-masked]
>Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a
>TCPM WG item
>
>

---

From: rick jones <[email-masked]>
Date: Thu, 10 Dec 2009 08:41:46 -0800

On Dec 9, 2009, at 9:01 PM, Andrew Knutsen wrote:
>   I'll just say again that this solution has been deployed by  
> several vendors for several years (using several invalid option  
> kinds). The only way to avoid the problems mentioned below (and  
> others, elsewhere) is to force them (us) all to change, probably at  
> the cost of competitive advantage, and possibly by making more  
> fundamental changes in TCP itself. We agree that standardization in  
> this area is a worthwhile goal, however it is most likely to be  
> accomplished incrementally.  The current proposal represents a first  
> step in that direction.

Have any end-system/client TCP stacks actually adopted these several  
vendors' invalid option kinds thusfar?

Getting more fundamental, and perhaps initiating one of my "Emily  
Litella" moments, it sounds like transparent middlebox discovery is  
trying to allow such boxes to be "Shimmer" - is it supposed to be  
*transparent* ? Then it would seem that this is making it visible.  Is  
it supposed to be a proxy? Then it should be done explicitly by the  
application(s). It sounds like this is an attempt to make it a little  
of both.

rick jones

http://snltranscripts.jt.org/75/75ishimmer.phtml  or for the more  
audiovisually oriented:
http://www.hulu.com/watch/61320/saturday-night-live-shimmer-floor-wax

---

From: "Knutsen, Andrew" <[email-masked]>
Date: Thu, 10 Dec 2009 09:40:01 -0800

This technology is generally implemented in proxies, although some proxies are co-located on client systems.
 
   There are two kinds of proxies: explicit and transparent.  Clients only need to be configured for explicit proxies.
 
   The current use of this option is generally to make tunnels, as described in the draft and also the middlebox rfc referenced.  In this case, there are four devices involved, and two "proxy discoveries". Each discovery can be either explicit or transparent.  The option is used by the tunnel endpoint near the client ("edge") to find the endpoint near the server ("core"). Discovery of the edge by the client is a seperate issue, and generally does not use a TCP option.
 
Andrew

________________________________

From: rick jones [mailto:[email-masked]]
Sent: Thu 12/10/2009 8:41 AM
To: Knutsen, Andrew
Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; [email-masked]
Subject: Re: [tcpm] poll for consensus on Middlebox Discover draft as a TCPM WG item

rick jones

---

From: Matt Mathis <[email-masked]>
Date: Fri, 11 Dec 2009 13:48:10 -0500

Can we get some of the vendors to 'fess up to this?  (Or is anybody willing
to point fingers?) If there is more than one, I think we (tcpm) had better
not stand in the way of an attempt at standardisation, and should perhaps
take the opposite stance: the guilty parties MUST attempt to standardise
what they are doing, and get the proper IANA option codes.

It would be much better to have this done out in the open, in tcpm and the
IETF.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://staff.psc.edu/mathis
Work:412.268.3319   Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Thu, Dec 10, 2009 at 10:19 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE

---

From: Andrew Knutsen <[email-masked]>
Date: Fri, 11 Dec 2009 11:14:26 -0800

I've attached a email from August with this info.

Andrew

Matt Mathis wrote:
> Can we get some of the vendors to 'fess up to this?  (Or is anybody 
> willing to point fingers?) If there is more than one, I think we 
> (tcpm) had better not stand in the way of an attempt at 
> standardisation, and should perhaps take the opposite stance: the 
> guilty parties MUST attempt to standardise what they are doing, and 
> get the proper IANA option codes.
>
> It would be much better to have this done out in the open, in tcpm and 
> the IETF.
>
> Thanks,
> --MM--
> On Thu, Dec 10, 2009 at 10:19 AM, Eddy, Wesley M. (GRC-MS00)[ASRC 
> AEROSPACE CORP] <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     >From: Andrew Knutsen [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP];
>     [email-masked] <mailto:[email-masked]>
>     several
>     >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery
From: Andrew Knutsen <[email-masked]>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Cc: Jamshid Mahdavi <[email-masked]>, Ron Frederick <[email-masked]>, Qing Li <[email-masked]>, "[email-masked]" <[email-masked]>, Wei Jen Yeh <[email-masked]>
Date: Thu, 13 Aug 2009 15:51:56 -0700
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>

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

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> Ok; just a couple easy follow-up questions:
>
>   
>> 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: (216) 433-6682
> ---------------------------
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Dec 2009 12:13:25 -0800

Hi, Wes (et al.),

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> That's "really bad".  

I agree. It's hard to understand why TCPM should take this on as a WG
item if the assumption is that the vendors won't follow the specs.

So far, what I've seen in the discussion seems to blow the size of the
options out of the water. It doesn't appear compatible with existing use
of the option space.

Taking this on as a WG item appears to both endorse the current method
and to assume that we can find a way to develop it as a useful standard.
It seems like we have a ways to go before reaching that conclusion.

Joe

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 22 Dec 2009 12:38:28 -0800

I'll try to be nice here, but this is getting repetitious.  However 
as Dr. SNMP says, "Repetition is the key to learning...  I'll say it 
again... Repetition is the key to learning".

    Vendors cannot follow specs that do not exist.  The spec will not 
exist until we adopt it.  Saying we shouldn't adopt it because it hasn't 
been adopted does not seem like a reasonable argument to me.

    Perhaps it seems odd, or heretical, but this option, or similar, is 
in fact "existing use of the option space".  This is because the fact 
that a spec does not exist does not preclude implementation and 
widespread deployment if a need (ie market) exists.

    The area we are dealing with here, middleboxes, is a very real part 
of the Internet which is not well dealt with using the formal model of a 
layered, end-to-end TCP protocol.  Lets remember the scientific method: 
rather than keeping faith in a model which does not match experience 
(and denying the incongruities), its more effective to change the model 
to fit experience.

   If its the consensus of the group, the IETF can continue to deny this 
aspect of reality.  All that will happen is that reality will continue 
to diverge from the IETF model (and the option space will become more 
chaotic).  I don't think that would be a desirable outcome.

Andrew

PS Happy Holidays!
AK

Joe Touch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, Wes (et al.),
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAksxKGUACgkQE5f5cImnZrv62gCfdLpu44cdJQCJC0VT+L1VCSPs
> jgIAoKQcQCCMgHW8+KVDlj4T4/ACHrXN
> =PZ5g
> -----END PGP SIGNATURE-----
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Dec 2009 13:17:59 -0800

> been adopted does not seem like a reasonable argument to me.

FWIW, what I was saying was closer to:

	Vendors are violating the existing specs. It is not clear
	why we should expect them to follow new specs.

There are allowances in the spec for experimental options. The claim is
that these are not the option numbers being used.

> widespread deployment if a need (ie market) exists.

The TCP roadmap describes the use of existing options. It's not clear
that there is space for the option this proposal describes. I've raised
that on this list before.

> (and denying the incongruities), its more effective to change the model

FWIW, I wasn't saying we should never change TCP, or that this change
would never happen. I am saying that we don't seem to have a viable
change that is consistent with the whole of how TCP is used in the
Internet. That doesn't mean it doesn't already work in specific places.

I was implying that taking this on as a WG *document* was premature. We
can certainly take it on as an issue and see whether we have consensus
on how to proceed, but I didn't see that yet.

Joe

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 22 Dec 2009 13:33:11 -0800

> 	why we should expect them to follow new specs.

    Which spec is being violated, other than the implicit directive to 
not do anything thats already in a spec?

> that these are not the option numbers being used.

    In fact, one vendor (us ;-), is using the experimental kind.  
Unfortunately, that kind is not intended for deployment.

    WAN Optimization is not an experiment.  I'll say it again.  WAN 
Optimization is not an experiment.  Its a billion dollar industry.

> that on this list before.

    This option is already in wide use, with very few (if any) space 
problems.  I'll say it again.  This option is already in wide use, with 
very few (if any) space problems.

> Internet. That doesn't mean it doesn't already work in specific places.

    I'll say it again.  This is in fact how TCP is used in the Internet.

> on how to proceed, but I didn't see that yet.

    At some point I'm going to get tired of repeating myself.  At that 
point, if this proposal dies, we may try for "Informational" status.   
However, that may not be sufficient to compel our organization to change 
over to the new kind, much less providing motivation for other 
organizations to do the same.

Andrew

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Dec 2009 13:46:37 -0800

> not do anything thats already in a spec?

The use of TCP option numbers other than experimental.
RFC4727 defines those numbers.

> Unfortunately, that kind is not intended for deployment.

Right - that's why this is the correct next step. I'm not disagreeing
with that part.

> Optimization is not an experiment.  Its a billion dollar industry.

Please see the Tao of the IETF. Experimental also means there are
unanswered questions to a protocol that has not yet been approved for
standards track, so yes, this is an experiment.

> very few (if any) space problems.

You can say it a third time - it won't make it any more relevant.
Simultaneous open is never seen on some nodes, but that doesn't mean
it's any less relevant in the standard, or that we should remove those
protocol states.

What we see in the wild *today* is only a subset of what we design a
protocol for.

>    I'll say it again.  This is in fact how TCP is used in the Internet.

See above.

> organizations to do the same.

Informational is not an end-run around a WG, either. If the WG thinks
that this option is a bad idea (e.g., not compatible with other uses of
the option space, etc.), then it may not be documented as a spec - it
could as easily be documented in a future "TCP implementation issues" RFC.

Just plopping something out there is not justification for the IETF to
standardize it.

Joe

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 22 Dec 2009 14:02:15 -0800

Well, I think our positions are clear, and I doubt they're going to 
change.  Its up to the rest of the group, as far as I'm concerned.  I've 
invested a lot of time trying to do the right thing here, but at some 
point one just has to rely on the wisdom of the collective.

Andrew

Joe Touch wrote:
> iEYEARECAAYFAksxPj0ACgkQE5f5cImnZrtWfwCg2rN8wijy0jKy3gyq/hclC7QI
> iOEAoNr+1DlXrqy7BdpVGc0g1WLbMGCY
> =Ogon

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 22 Dec 2009 16:16:58 -0600

Speaking for myself, I think this is probably the right thing to do,
and would support the work in TCPM if adopted.

That said, whether it will actually help to fix the present situation
seems uncertain.  However, what does it cost us if we spec this out
as Experimental and it ends up not getting used?  Some years down the
line, it can be classed as Historic and the option number can be
reaped.  I don't see a problem with that.

The concern expressed about options space is interesting to me, having
grappled with that problem myself in the past.  For the purposes of
this option, which is being used by middleboxes rather than end-hosts,
it seems to me like as long as it fails safe and disables either this
portion of the discovery process or the optimization it permits, when
there's not enough space, then it seems acceptable to me.  It's not
ideal, but seems to be a step better than allowing chaos to reign, as
Andrew tells us it is, and I think that's fitting with the spirit of
the draft.

--
Wes Eddy
MTI Systems

>Sent: Tuesday, December 22, 2009 5:02 PM
>To: Joe Touch
>Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; rick jones;
>[email-masked]

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 22 Dec 2009 14:41:58 -0800

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> seems uncertain. 

    There is a very good chance that Blue Coat will in fact use the new 
option kind if it is allocated. As our software in the field is updated, 
use of the experimental kind for this no-longer-experimental purpose 
will go down. Our competitors use techniques that are similar enough to 
ours to use this option as well.

Andrew