Re: [tcpm] TCP Long Options

[Joe Touch <[e-mail]>]

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

Adam Langley wrote:
> 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
> 

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm