[arch-d] minimal wire image [was <draft-trammell-wire-image-04>]T

[Brian E Carpenter <[e-mail]>]

Trimmed the Cc's and the text...

On 2018-09-12 00:39, Stephen Farrell wrote:
> 

...
>> As a technical comment, I'd like to mention an extreme version of
>> wire image. The only thing needed to deliver an IP packet to its
>> destination is the destination address. So the minimal wire image of
>> a packet is the destination address followed by some number of
>> encrypted bits. [Not my invention: Jon Crowcroft's unpublished
>> article on Sourceless Network Architecture points out that the IP
>> source address is redundant for the delivery of packets.]
>>
>> Now this has some minor disadvantages (no diffserv field, no flow
>> label, no intermediate ICMP replies, etc.) but from the privacy point
>> of view, it's hard to do better at the single packet level. You can
>> still do some temporal analysis, but most of the normal clues are
>> missing since you have no tuple to track, so it will be extremely
>> hard to assign packets to flows.
>>
>> Also, with the message body being pseudorandom, you cannot deduce
>> anything about the protocol, ports, or payload size, or even whether
>> the packet is just noise to confuse temporal analysis.
>>
>> I think this sets a baseline for discussion of wire images: you can't
>> have *less* of an image than this.
> 
> Not sure I quite agree that this is the minimal wire image. ISTM
> that e.g. running Tor over MPTCP with a observer that can't see
> all paths seems like it results in a less complete wire image.

Yes, which is why I qualified it as "at the single packet level".
Maybe what you are seeing is one packet on one path in a multipath
Tor session. Or maybe it's pure noise intended as distraction. Or
maybe it's a perfectly normal SYN packet.

> But as I argued above, I think that's down to needing a better
> definition of wire image for it to be a more generally useful
> concept.

Yes, I agree with that.

    Brian