On 7/28/2014 5:27 PM, Mark Handley wrote:
I think there are three common (legit) uses of RST:
1. In response to a SYN to indicate no-one is listening.
2. In mid connection, commonly used to avoid having to hold time-wait
state.
3. After a reboot, to optimize timing out an old connection.
Of these, 1 isn't an issue for TCPINC - it's pre-handshake, so we
wouldn't change anything.
2 is OK - these RSTs could be authenticated.
That depends on whether you think it's OK for a middlebox to generate
the RST. I don't, so I'm OK with this position.
3 is problematic, but I suspect it isn't actually anyway near as common
as 1 and 2, and ignoring such RSTs wouldn't really be a big deal. In
the end, this is a tradeoff, and we can argue which side of that
tradeoff we'd prefer to be on: hardened against DoS vs optimize an
uncommon case.
I don't know why you think this isn't a big deal. TCP doesn't retry a
connection with different parameters if it times-out, and if keepalives
aren't used, the server TCP state would never be cleaned up. You'd end
up having a garbage collection problem.
Yes, the OS could take care of that by reclaiming idle connection state,
but I don't know that any OS out there already does this.
As Dave says though, this is a local choice, and even if the protocol
supports it, not all hosts and/or apps need to enforce RST protection.
I disagree with this. IMO, all apps that use TCP-level security should
have RST protection while the connection is active. Once a connection is
idle, it can be the app/host decision to continue to ignore unprotected
RSTs, but the default IMO should be to allow them (so the app/host that
decides otherwise has the context to know to have an alternate garbage
collection mechanism).
Joe
Mark
On Mon, Jul 28, 2014, at 08:57 AM, David Mazieres wrote:
marcelo bagnulo braun <[email protected]> writes:
Hi,
As we discussed in the meeting, we should try to make some design
decisions for TCPINC.
One of them is whether to protect or not the TCP header.
I would like to start the discussion on this topic. Arguments on one way
or the other?
Can we rephrase the question slightly and ask: "Which TCP header fields
are worth protecting?" Obviously one way forward is to protect nothing
in the headers. But I don't think anyone is advocating protecting the
whole header. (After all, the charter talks about NAT traversal.)
At the meeting, I also sensed widespread agreement that people
(including me) consider always protecting the RST bit somewhat
problematic, particularly in the short term. That's why, for instance,
tcpcrypt says implementations SHOULD disable RST validation by default.
On the other hand, there are some very good use cases where you do want
protection against RST, as evidenced by multiple previous ways to do so.
If we are going to protect any header bits at all, I argue it makes
sense to have a per-connection option to protect against RST, because
the benefit/cost ratio is very high. It's trivial to condition the
header integrity check on RST being clear or some socket option being
set. Conversely, for proposals that aren't designed to protect any
other header bits, adding RST protection could be a big burden.
A common-sense guideline would be to say once we converge on a
high-level tcpinc design, we shouldn't leave any low-hanging fruit.
(This is the same logic by which the charter requires authentication
hooks, even though our anticipated use case is to protect unmodified
legacy applications against passive eavesdroppers. If we go through all
the trouble of standardizing increased TCP security, it's silly not to
let people authenticate connections.)
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
