Subject: [tcpm] TCP Long Options

From: "Adam Langley" <[email-masked]>
Date: Tue, 1 Jul 2008 09:49:57 -0700

I've revived an old draft, with the original author's permission: TCP
Long Options[1]

For a SYN packet with window scale, MSS, TS, SACK permitted and MD5
options (and the associated word alignment padding) we have already
filled the 40 byte option space. Not to mention that SACK permitted is
a waste in such a packet since no SACK blocks can fit in the following
frames.

TCP-AO will probably truncate the MAC by 4 bytes to add space for a
single SACK block, but even packets without authentication options
have only 20 bytes of option space left in a typical SYN [2]. This is
hampering experimentation, esp in the cryptographic space because you
can't fit even a reasonable elliptic curve key in the remaining
space[4]. Even with the current feature set, extra SACK blocks are
known to be helpful in certain situations[3].

I suggest to the working group that reaching consensus on a long
options standard would be positive for TCP.

http://www.ietf.org/internet-drafts/draft-eddy-tcp-loo-04.txt

Experimental, Linux implementation:

http://marc.info/?l=linux-netdev&m=121435555619591&w=2

Changes since 03

   1.  Change the option numbers specified to placeholders:
       "TBD-IANA-KIND1" and "TBD-IANA-KIND2".

   2.  Change the requirement that all segments include the LO option,
       if negotiated, to a SHOULD NOT unless the options require it.
       The reasoning behind the initial requirement was for
       implementation ease but, having implemented it myself, the
       ability to use the fast path processing for LO connections
       outweighs that.

   3.  Change the units of the LO option from bytes to words.  This was
       ambiguous in the 03 draft and, since padding to four bytes was
       required anyway, it seemed best to remove one extra way that the
       option could be invalid.

[1] http://www.ietf.org/internet-drafts/draft-eddy-tcp-loo-04.txt
[2] SYN options take 20 bytes in modern Linux kernels with default
sysctl settings
[3] http://portal.acm.org/citation.cfm?id=1259591.1260102&coll=GUIDE&dl=GUIDE
[4] Assuming this it isn't to be the last option ever, we leave 4
bytes of space. With the 2 byte option header, we have 14 bytes, or
112 bits for a key. Using Pollard's Rho algorithm we need 14*3 = 42
bytes to store a point. Granting the attacker only 1 PB of space
(approx cost < €200K) they can store 2**44 points, so one in 2**12
points are distinguished. So the attacker can break such a key almost
instantly: 2**12 operations on average.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Jul 2008 10:20:55 -0700

It might be worth reviewing the discussion on the TCP-LO when it was 
previously presented, and provide a summary to the group as to whether 
anything has changed.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 1 Jul 2008 10:46:31 -0700

It is good call to revive this draft. Needless to mention, the TCP option space is exhausted and something needs to be done to fix it. When the discussions last came up, I voted in favor of taking this item up, and my viewpoint remains the same :-)

I will give this new version, a read later.

Thanks,
-Anantha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Adam Langley
> Sent: Tuesday, July 01, 2008 9:50 AM
> To: [email-masked]
> Subject: [tcpm] TCP Long Options
> 
> I've revived an old draft, with the original author's 
> permission: TCP Long Options[1]
> 
> For a SYN packet with window scale, MSS, TS, SACK permitted 
> and MD5 options (and the associated word alignment padding) 
> we have already filled the 40 byte option space. Not to 
> mention that SACK permitted is a waste in such a packet since 
> no SACK blocks can fit in the following frames.
> 
> TCP-AO will probably truncate the MAC by 4 bytes to add space 
> for a single SACK block, but even packets without 
> authentication options have only 20 bytes of option space 
> left in a typical SYN [2]. This is hampering experimentation, 
> esp in the cryptographic space because you can't fit even a 
> reasonable elliptic curve key in the remaining space[4]. Even 
> with the current feature set, extra SACK blocks are known to 
> be helpful in certain situations[3].
> 
> I suggest to the working group that reaching consensus on a 
> long options standard would be positive for TCP.
> 
> [2] SYN options take 20 bytes in modern Linux kernels with 
> default sysctl settings [3] 
> http://portal.acm.org/citation.cfm?id=1259591.1260102&coll=GUI
> DE&dl=GUIDE
> [4] Assuming this it isn't to be the last option ever, we 
> leave 4 bytes of space. With the 2 byte option header, we 
> have 14 bytes, or
> 112 bits for a key. Using Pollard's Rho algorithm we need 
> 14*3 = 42 bytes to store a point. Granting the attacker only 
> 1 PB of space (approx cost < €200K) they can store 2**44 
> points, so one in 2**12 points are distinguished. So the 
> attacker can break such a key almost

---

From: "Adam Langley" <[email-masked]>
Date: Tue, 1 Jul 2008 11:28:04 -0700

> previously presented, and provide a summary to the group as to whether

Good point, although I am probably omitting salient points which I
missed when reviewing the archives:

1. It's a "non-optional option" / it's another 4 bytes of bloat

Referring to the requirement that the LO option be included in every
packet. This requirement has been removed for implementation reasons
(it's very good to have a single fast path), but that also addresses
this. (However, the LO option is still required to be the first
option, if present and DO is required to be set to 6 in this case. I
reasoned that it was still best to remove extra degrees of freedom
about where to put it / how to set DO)

2. Some options can't be included in SLO

This is still correct. There's no good way to negotiate some options,
like MSS, if not included in the SYN packet so they cannot be moved to
the SLO option. The draft doesn't discuss this, and possibly it
should. Thinking about it, I might suggest that only options
explicitly defined to be SLO compatible should be included in the SLO
space. At the moment, that list might include just timestamps.

(Consider a SYN with MD5: LO (4 bytes) + WScale (4 bytes) + MSS (4
bytes) + SACK perm + TS (12 bytes) + MD5 (20 bytes) > 40 bytes - so we
can't even advertise LO in this case if we include TS in the SYN)

3. Three SACK blocks is sufficient

This is probably true for the vast majority of the time. However, auth
options esp reduce the number of possible SACK blocks when timestamps
are included as well. So, although extra SACK space is probably a
waste in packets with just a timestamp option, it can have it's uses

4. We could squeeze the options better

Several suggestions concerning making better use of the options space
were suggested like a binary flags option where timestamp permitted
and SACK permitted could live, or making the timestamp option smaller
in SYN packets. This would have been a great idea before these options
were deployed, but there's really no good way to transition now that
they have wide acceptance in their current form.

However, possibly we should change that by defining that binary flags
option right now and make LO the first user. If there's general
acceptance of this, I'll happily write the drafts.

5. Other methods of extending the option space

For example, making DO 5-bits wide or defining a scaling options for
DO. None seemed to gather widespread acceptance.

6. There's no need / we're not running out of space

Fundamentally, this objection is unaddressable by a long options draft
:) I suggest that there is a need in the case of TCP-AO/MD5 to include
SACK blocks. Additionally, the lack on long options hampers
experimentation. Personally, I'm pushing this because I want to
include an ECDH key exchange and need the extra options space. Others
have certainly needed the same thing and by specifying it we can aid
experimentation and encourage future TCP work which might not have
happened otherwise.

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Mon, 7 Jul 2008 13:58:42 -0500

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Adam Langley
>Sent: Tuesday, July 01, 2008 2:28 PM
>
> ...

Based on my memory, Adam's summary is pretty accurate.  In 2005, the
reason that Bob Braden cited to me for not publishing the previous
version of this draft as Experimental was:

> Basically, the critical fact here is that TCP is a core protocol for
> the Internet, so any changes to it should go through the IETF process.
> We understand that there are competing proposals, and TCP does not
seem
> to be an area where competition is desirable.  Experimental
> implementations of your proposal would probably not be a good idea.

I guess the real problem was that the TCPM group didn't ever get
consensus that working on any long options mechanism was important,
so it never got done as a WG item, and it couldn't be done as an
independent submission RFC because TCP is a core protocol.  Thus,
4 years later, it is still not done, and I still get email every
few months from people that stumble upon the draft and want to use
it to enable some other experimental modification that requires a
really long option or two.  I think this is what happened with Adam.
He was working on another project, ran across the previous version
of the TCP Long Options draft, and discovered it was what he had been
reinventing.

In my personal opinion, it's a good idea to have some way to do
long options (any way, not necessarily even this draft) that's
at least published Experimental (off by default), simply because
different groups of people keep thinking they need long options.  I
think that's the point that the WG didn't have consensus on in the
past, and may or may not still lack.

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 7 Jul 2008 15:45:27 -0400

> past, and may or may not still lack.

The functionality sought with TCP "long options" are already provided
with SCTP. The only valid reason cited for not using SCTP for these
type of new applications is lack of support from middle-boxes.

Any TCP enhancement that does not preserve transparency to existing
software and hardware will face all of the problems of SCTP, and
probably with fewer benefits.

In addition to the middle-box issue that is always cited, there is
a special issue with changing the syntax of TCP options that is in
the hosts themselves - any form of header/data separation done in
existing software or hardware could be broken. This is especially
true for LRO/LSO (Large Receive/Send Offload).

I strongly suspect that any encoding that provided more option space
would prove inherently incompatible with one or more existing middle
boxes, host stacks and/or NICs. If such a feature merely provides
SOCK_STREAM service between two enhancement-aware endpoints, then
why not simply map SOCK_STREAM to SCTP at both ends and leave TCP
alone?

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 7 Jul 2008 13:29:48 -0700

> > 
> 
> The functionality sought with TCP "long options" are already 
> provided with SCTP. The only valid reason cited for not using 
> SCTP for these type of new applications is lack of support 
> from middle-boxes.

I have to dis-agree here. There are planty of TCP applications that
wouldn't simply migrate to SCTP for many reasons. This is somewhat
similar to the "IPv4 to IPv6 transition, NAT's" etc., Hence I would be
very careful to use this sort of reasoning.

> 
> Any TCP enhancement that does not preserve transparency to 
> existing software and hardware will face all of the problems 
> of SCTP, and probably with fewer benefits.

Well, are you saying that the proposed enhancements wouldn't work well
with middleboxes? Again, that shouldn't stop from having enhancements
made to TCP. IMO.

<snip>

> I strongly suspect that any encoding that provided more 
> option space would prove inherently incompatible with one or 
> more existing middle boxes, host stacks and/or NICs. If such 
> a feature merely provides SOCK_STREAM service between two 
> enhancement-aware endpoints, then why not simply map 
> SOCK_STREAM to SCTP at both ends and leave TCP alone?

Easier said than done. The issue here is that the existing TCP
applications need support for long TCP options, so asking them to
migrate to SCTP may be ok, but doesn't sound practical.

$0.02,
-Anantha

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jul 2008 14:07:14 -0700

...
> independent submission RFC because TCP is a core protocol....

I'm recalling that no mechanism was ever developed that was backward 
compatible with legacy TCP implementations, i.e., that "did the right 
thing" for SYNs with long options. Doing well for other segments is 
somewhat moot if SYNs cannot be extended, because space is most critical 
for them.

Joe

---

From: "Adam Langley" <[email-masked]>
Date: Mon, 7 Jul 2008 14:27:05 -0700

On Mon, Jul 7, 2008 at 2:07 PM, Joe Touch <[email-masked]> wrote:
> compatible with legacy TCP implementations, i.e., that "did the right thing"
> for SYNs with long options. Doing well for other segments is somewhat moot
> if SYNs cannot be extended, because space is most critical for them.

I don't believe that such a system is actually possible; if anyone has
an idea about this please speak up. One could imagine assuming that
the remote end supports long options and backing off when
retransmitting the SYN frame, but I don't believe such behaviour is
actually reasonable because of the additional latency.

AGL

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jul 2008 14:52:09 -0700

Adam Langley wrote:
> I don't believe that such a system is actually possible...

I believe that was the sticking point the last time we talked. If we 
give up on backward compatibility, the variants become overwhelming, 
including Mark Allman's "let's double all the fields" proposal, as I 
recall, and none is sufficiently motivated at this time AFAICT. I.e., it 
is when we give up on backward compatibility that Braden's observation, 
I believe, applies.

Joe