Daniel Kahn Gillmor <[email protected]> writes:
>> I think that *optional* protection against further attacks is desirable
>> (allowing applications to request further protection, which will
>> potentially be detrimental to interoperability -- but won't hinder
>> widespread deployment of default encryption, because it only applies when
>> applications opt in).
>
> It sounds like several people have made this suggestion (or similar ones).
>
> As a clarification, do you think that one side should be able to
> unilaterally opt in to this protection, or should both sides need to
> explicitly negotiate it? at what granularity? are they opting into
> protection of their own traffic, or of their peer's traffic?
I think you have to consider the specifics. No one is proposing a large
menu of mix-and-match header protection options. We are basically
talking about three categories of data in the (conceptual) TCP header:
1. The RST bit,
2. Values (such as sequence number offset from the ISN) that will not
be munged by middleboxes, and
3. Values (such as port number, timestamp, etc.) that will commonly be
munged by middleboxes.
We can argue about which fields go into 2 and which go into 3, but I
suspect we can reach consensus on that, particularly if we are
conservative about what we put into category 2. Once you have this
taxonomy, it boils down to a cost-benefit analysis. If we get
protection of 2 for free, then it is worth it. If it requires protocols
to go through contortions, then the sentiment seems to be it isn't worth
it.
The RST bit is special for two reasons. First, RST forgeries are an
actual documented attack by ISPs like Comcast, so there are existing
situations where people would really like an easy way to ignore RST
forgeries. On the other hand, there are other situations in which an
endhost is not in a position to authenticate an RST, yet without an RST
applications risk hanging until the TCP connection times out.
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.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
