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

From: Andrew Knutsen <[email-masked]>
Date: Mon, 26 Oct 2009 19:01:07 -0700

A new version of the Transparent Middlebox Discovery option draft is 
available at 
<http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-02.txt>.

The following changes have been made:

- The security section has been updated.

- An API section has been added.

- Simultaneous open is addressed.

- The "device type" field has been renamed "device capability",
    since a single device may respond to several kinds of discovery 
requests.

- Miscellaneous cleanup and clarifications.

Several changes were not made:

- Specific uses of the option, such as discovery for management
    purposes, are not addressed.  This information belongs in
    the specs for the individual device capabilities.

- This does need to be a TCP option, since it must follow the
    same path as the TCP connection handshake. This is already
    addressed in the draft.

- Performance is a requirement for this option.  If an extra roundtrip is
    required, the option will not be used. This is also already addressed in
    the draft.

In addition, we made a couple more changes which I wasn't able to post 
before the
pre-meeting deadline. They include:

- Options with length < 4 are addressed. The following text is included:

   Options with length less than 4 MUST be ignored.

- The issue of limited option space is addressed. The following text is 
included:

   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.

    Unfortunately, none of the authors will be attending Hiroshima.

Andrew

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Oct 2009 22:43:38 -0700

> The following changes have been made:
...
> - Simultaneous open is addressed.

Simply stating that simultaneous open isn't supported is insufficient.
The document needs to explain what happens when a SYN is received with
the option when in the SYN-SENT state - i.e., what happens in response
to the SYN received, and what happens if the other end responds to the
option in the SYN that has been sent.

...
>   only way to perform the negotiation within the limited TCP option

FWIW, the text in the security considerations needs to take space into
account as well, e.g., when asserting that this option can be protected
with either TCP MD5 (18 bytes total) or TCP-AO (16 bytes total under
both MACs defined in ao-crypto). Given the current ubiquity of the
following:

   o  SACK permitted (2 bytes) [RFC2018][RFC3517]

   o  Timestamps (10 bytes) [RFC1323]

   o  Window scale (3 bytes) [RFC1323]

The result is 9 bytes remaining with TCP-AO, and 7 with TCP-MD5. That
means this option basically has at best trivial target data (at most 3
bytes); if the P-bit is set, there is no room for target data at all. It
would be useful to address whether this option is expected to be useful
with such little (or no) target data - i.e., is this the typical case,
or a useful case? If not, then it would not be appropriate to claim that
protection from either of the TCP mechanisms is expected.

One additional question - is this option really meaningful only when the
SYN bit is set? What happens if you receive it in the SYN-ACK - you
won't be able to send a response back in the ACK (i.e., the last step of
the three-way handshake).

Joe

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 27 Oct 2009 12:25:31 -0700

> option in the SYN that has been sent.

    Thats why the following text is there:

5.2. Initiating Discovery Request

   Requests are only valid in SYN packets. They MUST NOT appear in other
   segments and MUST be ignored when found outside of a SYN.

5.3. Responding to Discovery Request

   Requests received in any state except SYN-SENT MUST be ignored.

   Responses are only valid in valid SYN-ACK packets. They MUST NOT
   appear in other segments and MUST be ignored when found outside of a
   SYN-ACK.

> account as well

    Since the context of the connection impacts the space constraints, 
and that context depends on the device capability and changes over time, 
we feel these issues should be addressed in the specific capability 
specs.  Several vendors are using various forms of this option (with 
invalid kind codes) without problems. If space problems arise, we will 
all have to change our formats, as mentioned in the spec.  Perhaps if we 
adopt this draft, we can move away from the invalid codes at the same time.

Andrew

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Oct 2009 13:26:19 -0700

>   segments and MUST be ignored when found outside of a SYN.

Does that mean that the option is ignored, or the segment?

>   appear in other segments and MUST be ignored when found outside of a

AOK - so only the initiator of a connection can initiate this mechanism.

> adopt this draft, we can move away from the invalid codes at the same time.

Space is less of an issue for connections not authenticated with TCP MD5
or TCP-AO. I agree that the details would be in the service capability
specs. However, it's useful in the security considerations to explain
the security impacts of the approach, i.e., basically:

	- use without TCP MD5 or TCP-AO
	which means it would require IPsec to be protected
or

	- use when the extra information is basically null
	if this isn't expected to be the common case, then
	that's worth noting

I.e., the security considerations should talk about what's expected, and
what the limitations are in those cases.

Joe

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 27 Oct 2009 14:09:40 -0700

> Does that mean that the option is ignored, or the segment?

        I think the concept of ignoring options is pretty well 
understood, but perhaps we can add a reference. This situation is 
slightly unusual, since TCP options, in the "classic" Internet model, 
are always ignored by intermediate nodes (no "deep inspection"). This is 
no longer the case though, so the semantics of "ignoring" IP options 
apply to TCP options (pass them along intact at intermediates), as well 
as the usual interpretation of ignoring a TCP option (skip over them at 
the endpoint). This is well established "art", so we didn't see the 
necessity of explanation...

> what the limitations are in those cases.

    First, I'll note again that protection would not require MD5, AO or 
IPSec, if a hash is included in the target data.

    Regarding uses, whats expected is that the option will be used 
primarily for its current use (although if it has other uses thats 
great).  In this case, which is a compression tunnel, the only time we'd 
have to deal with both options is if the client sent the MD5/AO, and 
policy said we should pass it to the server. This is the case described 
in the "Interoperability" section, since it applies to other large 
client-originated options as well.

    In the "slow path", if the connection is in fact intercepted, there 
is a bit more handshake during tunnel setup to use for auth -- so MD5/AO 
is not necessary between the tunnel endpoints. Again, these details 
would depend on the specific device capability.

Andrew

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Oct 2009 15:58:07 -0700

> necessity of explanation...

It's not at all clear to me that the text makes it clear that this
protocol involves the participation of intermediate nodes. You're going
to need a lot more explanation of how that is expected to be handled,
esp. since intermediate nodes don't keep TCP states.

E.g.: you need to explain what intermediate nodes do for each message,
and whether they need to keep state (and if so, how it is established
and maintained). You also need clear indication about what the endpoints
do with these messages if they ever see them (are they stripped off, or
still there?).

Joe