Can Read Receipts Implemented at the IPv4/TCP Layer Detect Data Harvesting on a Server?

[vkosuri]

I'm working on a project where I'm planning to implement custom read receipts at the IPv4/TCP layer by modifying the BSD networking stack.
My goal is to detect if someone is harvesting data from my server by tracking whether packets are being properly received and acknowledged.

What I've Done So Far:

I’ve researched how to add custom headers to IPv4/TCP packets and modify the BSD source code to implement this functionality.
The read receipts will be embedded in the packet headers to confirm that a packet has been received and presumably processed by the intended recipient.

What I Need to Understand:

Detection Capabilities:

Can this method of using custom-read receipts help in detecting if someone is harvesting data from my server? For instance, would it be able to identify unauthorized data interception or forwarding by a malicious actor?

Limitations and Workarounds:

Are there specific limitations to this approach, and what additional measures (e.g., encryption, intrusion detection) should I consider to complement this technique?

Real-World Effectiveness:

Has anyone successfully used a similar approach in a real-world scenario, and what were the outcomes?

Why I'm Concerned:
I’m aware that this method might only confirm that packets reach their destination, but I’m unsure if it can detect more sophisticated data harvesting techniques, especially at the application layer or through man-in-the-middle attacks.

Any insights, alternative approaches, or examples would be greatly appreciated!

 

[SirDice]

Can this method of using custom-read receipts help in detecting if someone is harvesting data from my server?

No. Because you will not be able to detect a passive capture of the packet stream.

For instance, would it be able to identify unauthorized data interception or forwarding by a malicious actor?

Forwarding maybe, if those custom headers are dropped before being forwarded.

Your solution reads like a modified version of RFC-3514 (take note of the publishing date!)

I’m aware that this method might only confirm that packets reach their destination

Which is what TCP already does (ACK + sequence number).

especially at the application layer or through man-in-the-middle attacks.

This is what SSL/TLS already provides. You can still passively capture the packet stream though.

 

[vkosuri]

No. Because you will not be able to detect a passive capture of the packet stream.


Forwarding maybe, if those custom headers are dropped before being forwarded.

Your solution reads like a modified version of RFC-3514 (take note of the publishing date!)


Which is what TCP already does (ACK + sequence number).


This is what SSL/TLS already provides. You can still passively capture the packet stream though.

Thanks for pointing out the limitation of passive capture. can this be detectable through any other approach?

Good catch on detecting forwarding if headers are dropped. I'll also look into RFC-3514 as you suggested

 

[SirDice]

Thanks for pointing out the limitation of passive capture. can this be detectable through any other approach?

No.