The traffic analysis prevention (TAP) layer is responsible for preventing an observer from determining the volume and timing of data carried by a BTP stream.

What should the interfaces between BTP, TAP and the transport plugin look like? Does the plugin need to be able to ask for a specific stream length, other than setting an upper bound? Are there any transports for which sending data as quickly as possible is preferable (from a TAP point of view) to sending it at a limited rate?

The TAP layer could adjust the transmission rate, increasing it if there's data waiting and decreasing it if not. What could the adversary learn by observing changes in the transmission rate and/or manipulating congestion?

Padding could be handled at the BTP layer by choosing a padding multiplier for each stream. The TAP layer would then sit between BTP and the transport and handle chopping and delaying the stream -- that is, segmenting the encrypted, padded stream according to some segment size distribution, and writing segments to the transport according to some inter-segment delay distribution.

The padding, size and delay distributions can be used to produce a characteristic traffic 'shape' for each device or pair of devices:

http://www.cs.kau.se/philwint/pdf/wpes2013.pdf

We can conceal traffic bursts by throttling the output of the TAP layer so that bursts are smoothed out. However, we should make good use of intermittently available transports -- if we send too slowly, the transport connection may be lost before we finish.