Re: [tcpm] TCP Long Options

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: tcpm-bounces@ietf.org [mailto:itcpm-bounces@ietf.org] On 
> Behalf Of Adam Langley
> Sent: Tuesday, July 01, 2008 9:50 AM
> To: tcpm@ietf.org
> 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.
> 
> 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=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
> 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
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm