On 10/6/2014 11:19 PM, marcelo bagnulo braun wrote: > El 07/10/14 08:04, John-Mark Gurney escribió: >> > >>> Option 2 - Protect the payload plus some fields of the TCP header >>> For this option we believe there are 3 possible approaches: >>> Option 2.a -- include the MAC (and other relevant information) in a TCP >>> option >>> This option seems to provide lower deployability, higher security and >>> lower complexity >> Can you include information why you believe that this has lower >> deployability? > > see the text on the middleboxes that split and merge segments. > Including the MAC in an option would not work though these middleboxes.
It might be useful to see Section 6.2 of draft-ietf-tcpm-tcp-edo-01.txt. >From that: ...However, the most comprehensive study of these cases indicates that "although middleboxes do split and coalesce segments, none did so while passing unknown options" [Ho11]. Middleboxes that silently remove options they do not implement have been observed [Ho11]. [Ho11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it still possible to extend TCP", Proc. ACM Sigcomm Internet Measurement Conference (IMC), 2011, pp. 181-194. I.e., any option-based solution might not work through a middlebox - including the one that signals the use of TCPINC. At that point, we're back to running TLS, and it seems pointless to discuss this as a TCP variant, IMO. Joe _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
