marcelo bagnulo braun wrote this message on Tue, Oct 07, 2014 at 08:19 +0200:
> 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.
>
> David has made the argument that it would be possible to include some
> redundancy, so thjat if 1 of n MAcs actually make it to the destiantion
> it is the possible to verify the integrity. This however would break if
> the options get deleted too frequently. Overall, the deployability is
> lower that including the MAC in the payload (protecting of nor the TCP
> fields). Is this a big problem? well, that is the question we are posing
> to the WG...
Per my reading of the research, it is such a minor problem that it
isn't one... Most of the middleboxes that broke are broken in other
ways that they'll just revert to old normal TCP...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
