On 11/8/17 19:45, Mirja Kuehlewind (IETF) wrote:
In one interpretation, the TCP stack acts as if those packets were never
received, and so they are never acknowledged. Since retransmissions will
contain the same contents and also fail to decrypt, this is basically just
going to cause a connection failure upon expiration of the retransmission timer
-- in which case an immediate failure is clearly preferable.
That’s not true. This is to cover the case where the packet got corrupted on
the path, thus hopefully the retransmission will decrypt correctly.
So, to be clear, you're talking about packet corruption that happens to
produce a valid checksum, right? If that's the reasoning here, the
authors probably want to include that rationale in the document.
The other interpretation is that the TCP packet is processed as received, but
that all of the data that could not be decrypted is elided from the stream of
bytes provided to the receiving application. This is also a problem, since many
applications rely on the in-order delivery aspects of TCP. The prospect that a
sender could provide "Message A", "Message B", and then"Message C" to its TCP
socket and the receiver only get "Message A" followed immediately by "Message
C" is not something that applications will generally be capable of handling. As
before, a connection reset would be preferable to violating the in-order
delivery guarantees of TCP.
This can never happen with TCP.
Right. That's exactly my point.
/a
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
