[118432] in Cypherpunks
Re: The Baton Protocol
daemon@ATHENA.MIT.EDU (Sean Roach)
Mon Sep 27 22:13:38 1999
Message-Id: <3.0.6.32.19990927204621.0082cba0@mail.intplsrv.net>
Date: Mon, 27 Sep 1999 20:46:21 -0500
To: cypherpunks@algebra.com
From: Sean Roach <roach_s@mail.intplsrv.net>
Cc: RProcess <rprocess@nym.alias.net>
In-Reply-To: <19990927214034.29123.qmail@nym.alias.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: Sean Roach <roach_s@mail.intplsrv.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 09:40 PM 9/27/99 -0000, RProcess wrote: >
...
> 4. BDCs are established by a client when it has data to be sent
> to
> a server, or by a server when it has data to be sent to or
> retrieved
> from a server. If a server has data belonging to an authuser,
> it
> must wait for the authuser to connect and collect the data. If
> a
> server has data belonging to a carrier, it may request a BDC to
> send
> the data. Unsent data may expire.
It looks like a successfull DoS attack could be achieved by flooding
the server with messages to safeguard until some future date that
will never come. As most operators will probably be working with
very finite resources, not making money off the project and therefore
being limited to the standard budget of any other hobby, a couple
gigabytes of data to hold until it expires could tye up the system.
This would have two effects. Upstream servers would backlog messages
queued for that server, resulting in no traffic getting through that
used that server. That server would "see the light", and decide that
it isn't worth it to run a server, resulting in the server folding.
Might be better to allow the server to request a connection with an
end user, if the next hop is an end user, or route it through a
BDC2Mail gateway to get it to the end users account early after a
reasonable delay. If the message is encrypted anyway, then getting
it early shouldn't hurt. What error correcting systems exist on
regular e-mail? BDC2Mail gateways could be built to randomly pop up
on their servers with reasonable sounding addresses to avoid keyword
sniffers. Something similar to what spammers are doing with hotmail
to avoid people deleting messages before opening them.
...
>Problems:
> 4. If someone runs an evil carrier (one which selectively
> deletes
> mail, etc.), what would the effects be on the system?
I see two possibilities. Possibility 1 is to fork every message at
every node, and have duplicates weeded out at the hop after the next.
Possibility 2 would be to send it to 1 and get confirmation of its
receipt from both 1 and 2 before deleting and forgetting the whole
thing.
In possibility 1, a string of servers A through E might be chosen. A
is the originating program, perhaps the client. E is the target
system, perhaps another client. A sends a message to B1 and B2. B1
and B2 both send that message to C1 and C2, C1 and C2 now have two
copies apiece. They check to make sure they match before proceeding
with deleting the extra. IF there was a B3 and a C3, they could self
heal by ignoring the different message. In either case they note the
discrepancy and go on, sending duplicate messages to D1, D2, and
perhaps D3. D servers, then, send thier messages on to E, which, if
it is a client, would get a lesser vote on rating the services. If a
server, say B2 is found to consistantly alter or erase messages, it
looses credibility with all connecting servers through experience,
this experience is then taught to the clients when they connect, as
to who's reliable.
In possibility 2, proceed as a normal chain, but double the
authentication if possible, and make the chains 2X-1 longer to get
the same amount of separation from the end address.
Personally, I'd prefer possibility 1 as it means that the identities
of each server in the chain could be kept separate from each member
except those directly involved in the transfer. It would also be
easier to implement as concessions would not have to be made to
assure that servers once removed from each other would not need to be
able to get each others addresses. In both cases, 2 or 3 servers
would know the final address. Also, 2 or 3 servers would know the
originating address.
Sean Roach
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQA/AwUBN/Ad7ZHDoiHtqFDZEQLh9wCfSIs6fVKIPJxP9TTa834d5eI6hFwAnjro
IOLkz4eF3uaPHZemkJTBAlpA
=TUyS
-----END PGP SIGNATURE-----
