On 07/30/2014 01:55 PM, David Mazieres wrote: > The good news is that whether or not to require RST protection is a > purely local decision made by the recipient. Senders should always > protect RST bits when possible, and obviously not protect them when not > possible. The best solution (modulo complexity to the overall tcpinc > protocol) is therefore to make RST protection optional at the recipient. > However, this is not something that needs to be negotiated with the > other side. Moreover, such a local, receiver-driven option leaves the > door open to better policies--e.g., there have been suggestions to treat > active and inactive connections differently, and that can be implemented > unilaterally at endhosts without changing the tcpinc wire format.
I like this analysis. Is there any reason we can't apply it to the
items in category 2 as well as RST?
I note that we won't be able to fold these headers into a standard AEAD
construction with this approach, since stuffing RST and category 2
headers into the AD spot will mean that any munging of the protected
header info would cause the payload to fail to decrypt, which removes
the ability of the receiver to decide whether it cares about these
protections. (This is an argument against Martin Thomson's TLS-based
proposal, as i understand it)
I think this approach also implies a further expansion of the payload
(and maybe the TCP connection state) to include some additional MAC
information over the protected headers.
ekr, of the proposals presented in Toronto, i think yours was the only
one that provided no protection for any of the TCP header info. Do you
see a way to include header protection in your proposal, or is it only
for consideration if we decide no TCP header protection is warranted?
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
