pipenet padding

William Hitzke william at 25thandClement.com
Tue Nov 27 17:13:44 PST 2001


i'm constructing a pipenet application and
one of the biggest headaches is traffic padding.

end-to-end traffic padding is too costly, so its outta the question.

another similar problem to traffic padding is connection establishment
and tear-down. w/o significant enough traffic, you can't
really do it in mixmaster style.

my idea for link padding (between adjacent nodes/switches)
started w/ the idea of a bi-di 14400 bps, to make hosting an
anonnet server (my pipenet implementation) palatable to the
person who cuts the checks for bandwidth (such as myself).

14400 connections would force people to open many connections
for, say, looking at a website (multiple connections for the page,
images, etc). this would help w/ the mixmaster connection requests,
and allow hosters to better control bandwidth.

then i thought about allowing multiple "virtual links" to be connected
at the end node/receiver, so that traffic could be spread
across them. aside from latancy and ordering issues, this could
really up the through-put.

just recently (after reading an attack from wei dai on
the freedom network), i was thinking how these multiple "channels" could
be used to guard against the active attacks that are exposed
absent end-to-end padding.

if the traffic did not fill all the channels, and traffic was
randomly distributed across the channels, wouldn't/couldn't
this make attacks on the system much more difficult. especially
if different nodes randomly sent null packets to the receiver,
and vice-versa (to reduce possible collusion between the end node
and a middle node).

assuming the end node is trustworthy (more so than the set
of nodes used), then an attack on any link between the beginning
and end gives far less information to be used in tracing
a route, because its is unknown what the distributiuon of
traffic is.

it makes things more hairy, having to deal w/ out of
order packets (each single channel is still mac'd and sequenced
properly). but, it widens the security margins, no?

this design seems to me to be a win-win. it makes high[er]-throughput,
beneficial link padding possible, while (per the low
per-channel bandwidth cost) giving the host of a pipenet/anonnet
node more control (finer granularity) over traffic usage
thus making hosting less costly.

any comments, suggestions? i'm really looking for somebody
to tell me whether allowing multiple channels like this
exposts the design to more attacks than have been pointer
out w/ link padding schemes. otherwise, at the very least
it makes the application more practical.





More information about the cypherpunks-legacy mailing list