Re: [tcpm] TCP Long Options

["Anantha Ramaiah (ananth)" <ananth at cisco.com>]

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