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

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 agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm