Adam Roach wrote: > On 11/9/17 08:16, Kyle Rose wrote: > > On Thu, Nov 9, 2017 at 10:11 AM, Adam Roach <a...@nostrum.com> wrote: > > > On 11/8/17 19:45, Mirja Kuehlewind (IETF) wrote: > > > > 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. > > Mirja's is my interpretation, as well. > > > > Off-path attackers wouldn't be able to sent segments with the right > > sequence number with high probability, so it's unlikely that this is a > > DoS vector; but giving implementations the option of simply dropping > > segments for which the authenticity check fails is not likely to cause > > recurring timeout problems for correct implementations. > > Yes, and you're giving implementors options here without really explaining > why -- which means they're probably just going to pick one randomly. Adding > text that gives some notion about why one might choose one option over the > other would allow them to make an informed choice rather than a random one.
That makes sense. How about the following text instead? (It is very similar to how we treat spurious FIN in the following section, 3.7.) [...] The output of this operation is either a plaintext value `P` or the special symbol FAIL. In the latter case, the implementation SHOULD abort the connection and raise an error condition distinct from the end-of-file condition. But if none of the TCP segment(s) containing the frame have been acknowledged and retransmission could potentially result in a valid frame, an implementation MAY instead drop these segments. This doesn't speculate on how the corruption came about (I agree it's difficult to find a reasonable case), but it gives a reasonable default via SHOULD and also leaves a little room for implementations with some sort of clever anti-DOS mitigation. daniel > > Again, this remains a suggestion and not a blocking comment. You can feel > free to proceed with the document as-is. > > /a _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
