[118451] in Cypherpunks
Re: The Baton Protocol
daemon@ATHENA.MIT.EDU (RProcess)
Tue Sep 28 16:10:27 1999
Date: 28 Sep 1999 15:00:25 -0000
Message-ID: <19990928150025.24779.qmail@nym.alias.net>
From: RProcess <rprocess@nym.alias.net>
To: cypherpunks@cyberpass.net
Reply-To: RProcess <rprocess@nym.alias.net>
On Mon, 27 Sep 1999 20:46:21 -0500 , Sean Roach <roach_s@mail.intplsrv.net>
wrote
>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.
A simple DoS is nearly always achievable. You're right there's a
vulnerability there which would need to be addressed. Any system which
stores and delivers mail (including SMTP servers) can be flooded. The
difference is that the remailers which currently rely on SMTP servers for
this type of pending storage would have to store it themselves. That is the
cost of bypassing the SMTP server.
> 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.
Getting gigabytes into the system would requiring sending gigabytes to the
system (because the system would filter replicated duplicates). That takes
time, makes the sender visible, and the input connections could be throttled
to prevent one sender dominating the carrier.
>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.
I think authusers would not like to have their IP addresses stored. That's
one of the added benefits of the BDC pickup is that it doesn't require the
final carrier to store information about the authuser, unlike the current nym
account system. Further, many (most) would be dynamic, so for the carrier to
BDC them would be impractical. The idea of an optional BEC (what you called
a BDC2Mail) in the event of the mail not being picked up in a given amount of
time, instead of it merely being deleted might be a good idea.
> 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.
Not sure I follow you there, but sending email is not a security problem -
it's just that mail can be more easily deleted en route without the recipient
knowing it was sent. However the BEC signed acknowledgement system does
accomodate this somewhat.
Carriers with limited resources could choose to accept BDCs from only other
carriers, and handle input and output to/from users via only BEC (email).
That is part of th design. The larger carriers, such as those more likely to
support authusers (nym accounts) could provide BDC to users.
>
>...
>>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.
Yes, that is actually a part of the chaining and command spec, which this
document didn't get into. A user (or his software) could send messages
through multiple chains as Mixmaster does. In addition, it can fork. But
that requires tricky encryption to multiple remailers, which is a security
threat. Also, like current rhop remailers, he can indicate that random hops
be chosen with certain criteria. In addition, he could ask the remailer to
reroute messages around down remailers. However the latter would require a
layer of pk encryption to be foregone.
> 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.
That defeats the anonymity at the second stage.
>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.
Thanks for your feedback.
