In message <bb5ebe66-1cd7-41b8-8740-1e1bd052d...@mac.com>, Charles Swiger <cswi...@mac.com> wrote:
>On Apr 27, 2015, at 3:12 PM, Ronald F. Guilmette <r...@tristatelogic.com> >wrote: >> As I understand it, (verbatim) duplicate packets can sometimes arrive at >> an endpoint due simply to network anomalies. However as I understand it, >> those will typically have identical lengths and payloads. > >Typically. But you can also have multipath transit where one path has a >different >MTU than the other: a packet can get dup'ed and have one copy then get >fragmented >when flowing through that different route. So, the question becomes: How common is THAT scenario, in practice? And if it is reasonably uncommon, then might it still be worthwhile to at least _log_ cases where two back-to-back TCP packets arrive in succession, where both have an identical squence number, but where they have different lengths and/or checksums (thus indicating possible or perhaps even probably funny business)? Also, although I don't even pretend to be a expert with respect to either TCP or the software stacks that implement it, I must nontheless ask if the exact kind of check I proposed could perhaps be implemented at some level of the protocol stack which is subsequent to fragmented packet reassembly (thereby eliminating as a problem the specific scenario you raised). >>If I read that news article correctly, then the spoofed packets at issue >>will have the >>same sequence numbers as legit ones, but different lengths and/or >>payloads. >Yes. One can also go to town with mechanisms like having the inner protocol >checksum be invalid-- I'm sorry, but I do not grasp what it is that you are driving at, exactly. May I ask you, with respect, if you could state the issue in a different way that I might understand? >> It seems simple enough to detect instances when two packets with the >> exact same sequence number but different lengths arrive at a given >> endpoint in immediate proximity (in time). > >It's much harder to tell whether that happens legitimately, is due to a bug >with the network stack, TSO, etc or is someone playing games with a covert >channel. While I am quite certainly not nearly enough of an expert to be able to in any way take issue with what you've just said, I ceratinly would like to ask you to elaborate further on these scenarios... and whether they atre likely to be at all common, in practice... if you wouldn't mind. >>> For that matter, an attacker could try to spoof >>> legit connections and your countermeasure would presumably zap the >>> legit connection. We seem to be in agreement that the possibility of a nefarious attacker, with evil intent, being able to successfully pull off exactly such spoofing is predicated upon his having direct access to the wire... in which case I personally feel and believe that the victim may have vastly more serious problems to worry about than just abruptly dropped TCP connections. Regards, rfg _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
