>> but not bulletproof? tcp checksum is weak and can't detect all corrupt packet; and bit flip can happen anywhere within the stack, and can be caused by malfunction of ram, or say, cosmic rays. Statistically a corrupt packet survives all layers of check is low, and even a packet is corrupted, app layer behavior might still be ok.
>> wire encryption probably resolves it for free. This would be my recommendation here as well to ensure data integrity during transmission. Checksum itself (even cryptographic checksum) can't guarantee data integrity as packet in flight can be altered along with the new checksum. On Tue, Apr 7, 2020 at 1:37 AM Andor Molnar <an...@apache.org> wrote: > Hi Zk community, > > I’ve been looking at the following ticket for a while and made me thinking: > ZOOKEEPER-2175 Checksum validation for malformed packets needs to handle. > https://issues.apache.org/jira/browse/ZOOKEEPER-2175 > > It has been found in 3.4.6 originally and not resolved since then saying > that wire encryption probably resolves it for free. I have doubts against > the issue could actually happen at all, but the evidence in the jira is > quite convincing. > > 1) But what if somebody don’t want the overhead of using encryption? > 2) How often this issue could ever happen given that TCP packets have > their own checksum which also protects the payload, but not bulletproof? > 3) Found a suggestion in a comment to send session id in the payload of > Ping packets, but malformed packets could happen in any other > communication, not just session ids. > 4) Does GRPC have a built-in mechanism to protect the communication? Maybe > this would be the best way forward. > > What do you think? > > Andor > > >
