> OK.. let's say we encode a '0' as "2 segments in order A B" and a '1' as
> "2 segments out of order B A". How do you distinguish between these cases:
>
> 1) packets intentionally crafted with out-of-order numbers (this raises its
> own set of issues - namely you need enough access to craft and manage a TCP
> connection, including sequence numbers).
>
Yes sure, you need some good administrative privileges to modify/patch
the kernel or insert modules/drivers.
> 2) If the destination is off the local subnet, a glitch (lost packet, routing
> flap, load-balanced multiple links, etc) causes packet B to be received before
> packet A (which shows up on retransmit, or a longer transmission path)? Keep
> in mind that the TCP spec was specifically *designed* so that out-of-order
> delivery is a "can happen" situation.
>
Yes I agree.
> Between the fact that the covert data is encoded on something that's
> not an invariant (namely, the order that packets arrive), and the fact that
> you can only transmit 1 bit per packet, this doesn't look like a very practical
> scheme.
>
This can be mitigated with redundancies, CRC or error-correcting codes.
For the bandwidth problem the thesis schema doesn't work with only two
packets! You can do permutation of n packets and encode more information
(your encoding alphabet is not a binary one in this case ).
I don't really care if the technique is a good one or not, I was just
surprised that the author of the thesis considered it was not possible
in TCP but only in IPsec.
Received on May 07 2007
Intro
