Mirja Kühlewind <[email protected]> writes:
> To my understanding the reason to not encrypt the header was that some of the
> header information is need to pass middleboxes, such as for sure the ports
> but also some of the flags and maybe even the seq#. However, I think options
> or at least some of the options are less critical.
First, the problem here is as much the authentication as the encryption,
assuming we are using some sort of authenticated encryption. The
original tcpcrypt design actually addressed most of the fields. For
example, even though middleboxes manipulate seq# and ack#, we used
64-bit offsets from the ISN, which is robust to middleboxes. In fact,
tcpcrypt even subsumed timestamp and could potentially save option space
for things like RFC1323 PAWS.
However, the working group was concerned that middleboxes might reorder
options. Hence, any authentication must be robust to such
manipulation. I think that leaves two possible approaches:
1. Encrypt each option separately with authenticated encryption.
2. Stuff all the options into a giant, new "encrypted option option".
Probably this would be the ENO option in non-SYN packets.
#1 is problematic because each individual option is going to require an
authentication tag (say 8 bytes), very likely blowing out the option
space. Moreover, middleboxes attempting to parse the options may flip
out when the options don't match their length.
#2 is I think a better approach, but not perfect. Many options depend
on a SYN exchange to make sure both sides (and all middleboxes) support
the option. So we need to keep that negotiation robust. Of course,
long-term if ENO takes off there may be significant gains in SYN option
space to be had. For example if the encrypted option option enjoyed
widespread use, we could define a new ENO code point that uses a bitmask
in SYN segments to disclose supported options, so a single byte could
negotiate timestamp, SACK, etc. Or later encryption specs could even
subsume some of those options if they are universally supported.
> The main reason is to avoid (easy) leakage of privacy-sensitive information
> that could be used to identify different connections or different IP
> addresses that belong to the same host.
It might help to consider options on a case by case basis. Some
options, such as timestamp, can potentially be handled unilaterally.
For example OpenBSD's NAT code has been modulating timestamps for years.
Another approach here would be to make it easy for other RFC authors to
leverage tcpcrypt to protect the privacy of there options. For any
options that are tied to data, moving them in-band to special TLV frames
might make the most sense.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
