Re: TCP segments reordering and covert channels

> 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.