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

From: Andrew Knutsen <[email-masked]>
Date: Wed, 23 Sep 2009 19:12:37 -0700

This version addresses Wesley's comments and questions, and also has 
a re-organized "Operation" section addressing off-list comments. This 
version should not have any substantive changes to the option. It is 
available at 
<http://www.ietf.org/internet-drafts/draft-knutsen-tcpm-middlebox-discovery-01.txt>.

   Again, your time reviewing this document is appreciated.

Andrew

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 24 Sep 2009 11:02:42 -0700

On Sep 23, 2009, at 7:12 PM, Andrew Knutsen wrote:

>
>  This version addresses Wesley's comments and questions, and also  
> has a re-organized "Operation" section addressing off-list comments.  
> This version should not have any substantive changes to the option.  
> It is available at <http://www.ietf.org/internet-drafts/draft-knutsen-tcpm-middlebox-discovery-01.txt 
> >.
>

The applicability of this proposed option needs more explanation and  
justification.

The part that makes perfect sense is the desire to have a middle-box  
discovery probe that follows
the same path that a TCP packet would.

What is not clear is why the probe is based on OUI-specific secret  
handshakes.

1) Why not simply probe for "first middlebox that sees this once the  
TTL is less than or equal to X"?
      That would enable discovering all middleboxes that understood  
this option, no matter who
      made them. Once identified SNMP can be used to obtain vendor  
specific information.
2) If vendor X has *two* middleboxes on the path from A to B, is there  
any way to control
      who answers?

One further question, what is the correct handling of redundant SYN- 
ACKs from different
sources? This could happen if a middle-box takes longer than the  
initiator anticipates
and the retransmission follows a different path due to intermittent  
failures and/or
load balancing.

--
Caitlin Bestler
[email-masked]
http://www.asomi.com/CaitlinBestlerResume.html

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 Sep 2009 11:07:11 -0800

> the same path that a TCP packet would.

I think there's a case to be made for in-band
discovery options, which is no something we've
seen previously.  We've had out-of-band path-
coupled and out-of-band path-decoupled, but not
this.  (Next up - in-band path-decoupled ... )

However, I agree about the OUI question, and I
think the stuff discussing problems along a path
could be considered either extremely clear or
extremely muddled, since it doesn't exist.  There
are not just problems around two devices from
the same vendor, but also problems about multiple
types of devices from the same vendor, etc.
Presumably you could infer some stuff about
ordering and topology from TTL data if it were
written into the response.  I'd argue rather
strongly that you'd want an ordered list of as
many of the middleboxes as were discoverable -
this is not that much like tunnel endpoint discovery.

I like the idea of having some sort of in-band
discovery mechanism but I'm not sure about tying
it to TCP (although there's an implied requirement
for a response, which you can't guarantee with, say,
UDP or some other transports) and I'm really not
sure about v4.

Melinda

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 24 Sep 2009 13:11:20 -0700

> UDP or some other transports) and I'm really not

Doing the discovery in a TCP packet is the only way to
ensure that the packet will be routed/forwarded on the
same path as the actual TCP traffic.

Consider that A is sending a connection request into
cloud B for IP X, TCP Port Y.

Now suppose there is a middle-box guarding cloud B
which will divert connection requests for IP X:Port Y
to IP Z. Even without knowing of this special discovery
option, the B-entry middle-box will still divert the SYN
packet to IP Z. If either the endpoint or a later middle-box
understands the option there will be a Response.

But if you tried doing a non-TCP probe then the packet
will just continue on to the probably non-existent IP X,
or perhaps be diverted to a different catchall internal box.

This is actually true for *each* transport that wants to do
middle-box discovery, since the set of middle-boxes can
be different for each transport. Of course TCP middle-boxes
are far more worthy of discovery because historically they
tend to do more mischief/provide more services. By contrast,
if middle-boxes do anything with SCTP packets it is typically
to drop them or forward all of them to a default DMZ machine.

I think the key issue here is whether a mechanism can be
defined that will allow for discovery of any and all middle-boxes
that have support for the newly defined probe, even if there
are other forwarding nodes along the way that do not understand
the new option.

The OUI approach seems optimized for individual middle-box
vendors to do custom probing for their boxes. I do not think that
is a suitable strategy to be adopted as an RFC.

---

From: Andrew Knutsen <[email-masked]>
Date: Thu, 24 Sep 2009 18:19:21 -0700

I'll try to respond to all the issues raised today in this message:

> What is not clear is why the probe is based on OUI-specific secret 

    This draft represents an effort to move technology which is 
currently shipping from at least three vendors toward standardization. 
The handshakes are currently not only "secret", but use invalid option 
kinds.  This draft allows movement away from the invalid kinds; getting 
all vendors to disclose and agree on the rest is future effort, which 
would result in the OUI-less IANA-registered types.  We could have put 
this "history" in the draft, but it didn't seem appropriate.  I did 
include it in the last announcement.

>      made them. Once identified SNMP can be used to obtain vendor 

    - Generally, you want to probe for a specific type of device, which 
will pair with the originator.

    - Performance is a very important factor here.  SNMP adds delay, 
just like the other existing alternates mentioned in the draft.

> 2) If vendor X has *two* middleboxes on the path from A to B, is there 

    This would be specific to the device type, presumably based on the 
target data, although other info like the TTL could of course be used. I 
don't think there is anything in the draft saying a node cannot both 
respond to the probe and send it farther along, or even modify the 
target data and send it along. These actions would be defined with the 
device type registration.

>
> One further question, what is the correct handling of redundant 
> SYN-ACKs from different

    This is a good question, however I think its best considered an 
endpoint issue, ie, not one requiring more protocol. All existing 
implementations (from the three or more vendors I mentioned above) 
should be prepared to handle this. Without saying anything specific, I 
will say we've never had a bug reported because of this situation ;-).

Andrew

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 25 Sep 2009 11:15:17 -0700

On Sep 24, 2009, at 6:19 PM, Andrew Knutsen wrote:

> currently shipping from at least three vendors toward  
> standardization. The handshakes are currently not only "secret", but  
> use invalid option kinds.  This draft allows movement away from the  
> invalid kinds; getting all vendors to disclose and agree on the rest  
> is future effort, which would result in the OUI-less IANA-registered  
> types.  We could have put this "history" in the draft, but it didn't  
> seem appropriate.  I did include it in the last announcement.

TCP options are a limited resource. There is a strong rationale for  
their use here, because there is no other mechanism
that ensures that the probe packet will follow the same path as the  
TCP flow. But limiting the standardization to only the
basic wrapper makes no sense.

Why not also define a "common" OUI which would have standard vendor- 
independent queries, such as a basic TTL
dependent probe that can at least enumerate what all of the option- 
aware middle boxes are?

>
>>
>> 1) Why not simply probe for "first middlebox that sees this once  
>> the TTL is less than or equal to X"?
>   - Generally, you want to probe for a specific type of device,  
> which will pair with the originator.

That may be your usage, but I think a more common usage would be to  
probe what if any middle-boxes are involved on a path
to help diagnose a probleem or perform a security audit.

> just like the other existing alternates mentioned in the draft.

Exactly how can discovery of a middle-box be time critical? How many  
times a second does a path change?

In any event, once a middle-box is discovered, is there any need to  
continue to use the TCP-piggy-back to
communicate with it?

---

From: Andrew Knutsen <[email-masked]>
Date: Fri, 25 Sep 2009 11:51:36 -0700

Caitlin Bestler wrote:
> Why not also define a "common" OUI which would have standard 
> vendor-independent queries, such as a basic TTL
> dependent probe that can at least enumerate what all of the 
> option-aware middle boxes are?

    Thats the purpose of the form with the P (Private) bit set to 0, 
where the device type is IANA registered and there is no OUI.  Or am I 
missing something here?

> to help diagnose a probleem or perform a security audit.

    Then perhaps that would be a good first "standard" device type, 
basically "any device", with an action to both respond and forward.  No 
"target data" would be required in the request, and the response might 
contain an SNMP public community string or whatever.

> times a second does a path change?

    The usual, current case is when you're trying to set up a 
compression tunnel.  In this topology, you have four devices: client, 
edge, core and server (the middle two are middleboxes). The edge 
intercepts a connection from the client, and wants to see if there is a 
core box in the path to the server.  However, if there isn't, the 
connection should not be delayed.

   This is described in the "terminology" section, and referenced later. 
We didn't want to go too far into use cases, but if the consensus is 
that the draft needs more in this area we'll add it.

> continue to use the TCP-piggy-back to

   I'm not sure what your question is here.  After discovery the option 
is no longer used -- just regular connections.

Andrew

---

From: Andrew Knutsen <[email-masked]>
Date: Mon, 28 Sep 2009 12:05:32 -0700

Andrew Knutsen wrote:
> basically "any device", with an action to both respond and forward.  
> No "target data" would be required in the request, and the response 
> might contain an SNMP public community string or whatever.
>

    The point was made off-list that "responding and forwarding" doesn't 
work, since the response is on the SYN-AK.  However, the action defined 
for the device-type could be to send a UDP datagram back to the 
originator, and forward the SYN (with option intact) (unless you're the 
destination).

Andrew

---

From: Melinda Shore <[email-masked]>
Date: Mon, 28 Sep 2009 11:19:54 -0800

On Sep 28, 2009, at 11:05 AM, Andrew Knutsen wrote:
>   The point was made off-list that "responding and forwarding"  
> doesn't work, since the response is on the SYN-AK.  However, the  
> action defined for the device-type could be to send a UDP datagram  
> back to the originator, and forward the SYN (with option intact)  
> (unless you're the destination).

That's going to fail if one of the middleboxes is a NAT.

Melinda

---

From: Andrew Knutsen <[email-masked]>
Date: Mon, 28 Sep 2009 12:41:55 -0700

> That's going to fail if one of the middleboxes is a NAT.

    True in many cases...  Perhaps to implement the trace with this 
option, from a non-static source IP, a static destination IP would have 
to be included in the target data.  It seems to me this might be 
reasonable, since the use case I see for this trace is management, where 
you'd want the response datagrams to go to a management station which 
would follow up with SNMP or some such.

   Note that this use is not the motivation for this option, even though 
the name may seem to imply it. If it works that great though.

Andrew

---

From: Melinda Shore <[email-masked]>
Date: Mon, 28 Sep 2009 12:29:14 -0800

On Sep 28, 2009, at 11:41 AM, Andrew Knutsen wrote:
> option, from a non-static source IP, a static destination IP would  
> have to be included in the target data.  It seems to me this might  
> be reasonable, since the use case I see for this trace is  
> management, where you'd want the response datagrams to go to a  
> management station which would follow up with SNMP or some such.

And we're back to out-of-band solutions to the problem.
I actually don't think this is reasonable - I think
it's based on too many assumptions that don't hold
in a sufficiently large number of cases, or it forces
an architecture that's not widely used.  Either way,
I'm not comfortable with it.

Melinda

---

From: Andrew Knutsen <[email-masked]>
Date: Mon, 28 Sep 2009 13:41:44 -0700

The particular solution to the particular problem we're talking 
about here is an in-band / out-of-band hybrid, which actually makes 
sense for a management probe of the path a SYN takes between arbitrary 
endpoints.

    However this is not the particular problem the option was designed, 
and is needed, for. If it solves other problems, such as management 
probes, thats great.

Andrew

Melinda Shore wrote:
>> have to be included in the target data.  It seems to me this might be 
>> reasonable, since the use case I see for this trace is management, 
>> where you'd want the response datagrams to go to a management station 
>> which would follow up with SNMP or some such.
>

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 28 Sep 2009 22:54:22 +0200

* Andrew Knutsen | 2009-09-25 11:51:36 [-0700]:

>intercepts a connection from the client, and wants to see if there is
>a core box in the path to the server.  However, if there isn't, the
>  This is described in the "terminology" section, and referenced
>later. We didn't want to go too far into use cases, but if the
>consensus is that the draft needs more in this area we'll add it.

No use cases, but a more detailed high level description would be helpful. I
missed that too.

HGN

-- 
Hagen Paul Pfeifer <[email-masked]>  ||  http://jauu.net/
Telephone: +49 174 5455209           ||  Key Id: 0x98350C22
Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
Always in motion, the future is.

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Sep 2009 11:05:12 -0700

Some comments:

1) use of the TCP option is OK, but the option needs some additional
caveats:

	- undefined if length < 4 (i.e., receiver should send a RST)

	- there ought to be a max suggested length
	see, e.g., draft-ietf-tcpm-tcp-auth-opt-05 section-9.6

	with TCP-AO, a typical SYN would have 7-9 bytes available
	for this option, e.g. IMO, the option should never be more than
	7 bytes; there is never a reason for the SYN to carry the full
	weight of arbitrary "target data", and I don't see why it needs
	to carry a full IEEE OUI. IMO, there ought to be enough bits
	that IANA assigns to make this work in a *known, fixed* length,
	and I don't see a good reason to ever have this option exceed 4
	bytes

2) the security considerations needs to be revised

	- IPsec encryption would prevent detection of the option;
	IPsec encryption *or* authentication would prevent response.

	- TLS allows both detection and response

	- TCP-AO allows detection in all cases.
	when options are included in the MAC, TCP-AO would
	prevent response

	- the "target data" should not appear in the option space,
	as noted above, but if it did it's not clear how it could
	possibly be protected separately unless *this doc* describes
	how to include a signature within the option

	(and there is no room for that, IMO)

3) Section 5.3 needs to be specific about other uses of this option

	i.e., it MUST NOT appear in segments other than SYN and
	the response

	what happens in simultaneous open?

4) the document is missing some key elements of any TCP option
description; in this case:

	what is the API extension that allows this value to be
	set or detected?

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Sep 2009 11:25:44 -0700

Two other observations:

- 'transparent' (that don't want to be seen) middleboxes will just  
ignore this too

- this option is (IMO) as likely to result in a dropped or RST  
connection at firewalls, nats, or enpoints that incorrectly implement  
options (i.e., that treat unkown options as errors rather than  
ignoring them) as it may be to actually work

Joe

Sent from my iPhone

On Sep 30, 2009, at 11:05 AM, Joe Touch <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Some comments:
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAkrDndgACgkQE5f5cImnZrtXaACgpV/WeMDTv74XynK9pYbG5dOR
> L6kAoJesr0uh2HGAWhFUSzGquWwbgEKD
> =6O04
> -----END PGP SIGNATURE-----

---

From: Andrew Knutsen <[email-masked]>
Date: Wed, 30 Sep 2009 11:51:59 -0700

I'll take a first shot at this.  My colleagues may also want to chip 
in...

> 	- undefined if length < 4 (i.e., receiver should send a RST)
    We'll add this.

> 	and I don't see a good reason to ever have this option exceed 4

    In current practice, we don't use the authentication option, but we 
do use scaling and timestamps. We end up just about filling the extended 
header, and wishing we had more room. This is without the OUI, using our 
present invalid kind (as do the other vendors in this market).

    What happens is a space vs time tradeoff. Leaving info out of the 
option can imply another roundtrip when setting up a tunnel. Forcing 
this would likely preclude use of the option for its primary (ie 
current) purpose.

> 	when options are included in the MAC, TCP-AO would

    We can add this additional detail.  Which MAC options alter the 
behavior of AO?

> 	(and there is no room for that, IMO)

    As noted above and in the draft, removing the "target data" from the 
option would render it useless.

    Also note that the draft says that the format of the "target data" 
is dependent on the "device type". Thus the intent is that any desired 
protection would be defined in the spec for that type. Since different 
situations would require different protection, I think specifying it 
here might be overkill.

> 	i.e., it MUST NOT appear in segments other than SYN and

    I suppose this is clearer than saying it MUST be in the SYN/SYN-ACK 
packets...  Mostly because the current wording might be construed to 
imply the option must be present in all SYN packets, which is unlikely 
since its an "option", but...

> 	what happens in simultaneous open?

    Wesley brought this up, and we added the last paragraph of section 
5.  It never happens in current use, so we haven't addressed it.  
Perhaps we should add some suggestions, but since its not expected or 
implemented, they would be vague.

> 	what is the API extension that allows this value to be

    Its my understanding, and observation, that RFCs are protocol 
documents and do not generally specify APIs. Also, since all current 
implementations are proprietary, any APIs added to the draft would be 
speculative.

Andrew

---

From: Andrew Knutsen <[email-masked]>
Date: Wed, 30 Sep 2009 12:00:02 -0700

> - 'transparent' (that don't want to be seen) middleboxes will just 

    True. Lets just say they are not of any of the defined "device types"...

> ignoring them) as it may be to actually work

    But the situation will be better than the present one...  and this 
problem is actually surprisingly rare with the current invalid kinds 
used by all vendors in the WAN optimization market. I suppose this is 
partly because people don't deploy equipment that breaks their network.

Andrew

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Sep 2009 12:57:27 -0700

Hi, Andrew,

>    I'll take a first shot at this.  My colleagues may also want to chip
...
> present invalid kind (as do the other vendors in this market).

You don't use TCP-AO, but the endpoints might. It's intended to be more
generally useful than was TCP MD5 (which is used typically only for BGP).

It's unrealistic to fill the option space with this one extension. It
would basically preclude any other options from being included. The
option space is severely limited, especially in SYNs.

I would object to this going forward using more than a highly
constrained amount of space. If additional space is needed for extended
information, that can be exchanged in option fields after the initial
negotiation- the info in the SYN is supposed to just be "do you speak X".

> this would likely preclude use of the option for its primary (ie

Using this much space in the option would kill all other future uses of
the option space. If it's between an extra RTT and shutting down future
use of options, we need to take the RTT hit.

>    We can add this additional detail.  Which MAC options alter the

TCP-AO allows endpoints to either include all the TCP options in the MAC
or exclude them. This information is not visible on the wire. If you
modify any of the options en-route and the options are included in the
MAC, the packet will be silently dropped by the receiver.

TCP is an endpoint protocol. It is not particularly intended for
intermediate parties to modify its contents.

Since you brought that up, I have to then consider whether it's
appropriate to even have a TCP option whose primary purpose is NOT to
communicate to the receiving endpoint, and I have to say that on that
basis, this should not be a TCP option at all.

I appreciate the desire to have a signal on the path with the TCP SYN,
and to embed it in the that segment. Have you considered putting this in
the IP option space?

I.e., it would still fate-share with the TCP SYN, but it would be in a
place it ought to be to be examined and/or modified by intermediate
parties. That would also give you a bit more room to play in...

>    Also note that the draft says that the format of the "target data" is
> dependent on the "device type". Thus the intent is that any desired

Where you say it is protected separately, you should also indicate
"inside the target data area, as specified by the target data format"

> since its an "option", but...

It MAY appear in SYNs, or in ACKs to a SYN.

It MUST NOT appear in other segments.

> implemented, they would be vague.

You need to say *exactly* how it should be handled *when* it comes up.
It may be a corner case, but addressing it is required for all TCP
modifications.

> implementations are proprietary, any APIs added to the draft would be

RFC 793 includes an API. You're extending that RFC, and by inclusion,
its API. You need to state that, in an abstract way, the OPEN and STATUS
calls are modified to include parameters that set and read the status of
this option.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Sep 2009 12:58:19 -0700

> partly because people don't deploy equipment that breaks their network.

I'm also asking whether they deploy equipment that breaks anything for
the end user (and sure, vendors do this all the time - they're called
NAT boxes ;-)

Joe

---

From: Andrew Knutsen <[email-masked]>
Date: Wed, 30 Sep 2009 13:21:38 -0700

> the end user (and sure, vendors do this all the time - they're called

    In the terminology I'm used to, vendors sell, end users deploy.

    Many end users deploy both WAN Op and NAT; they just need to be 
configured correctly (and not do anything stupid ;-).

Andrew

---

From: Andrew Knutsen <[email-masked]>
Date: Wed, 30 Sep 2009 13:25:29 -0700

I don't have time right now to address all of your points, but I 
will note one thing:

Joe Touch wrote:
> You don't use TCP-AO, but the endpoints might. 
>   

    It sounds like you're thinking of a situation where an intermediate 
node adds the option to the SYN packet.  This is not the intent. Do 
other options RFC's call this out explicitly?  If so we will.

Andrew

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Sep 2009 13:28:43 -0700

Andrew Knutsen wrote:
> 
>    I don't have time right now to address all of your points, but I will
> note one thing:
> 
> Joe Touch wrote:
> node adds the option to the SYN packet.  

Or modifies the contents of an existing option. Maybe I'm missing
something. Is this ONLY examined and modified at the destination? (i.e.,
the SYN dest IP address)?

Joe