some spec questions

I would like to add a comment about the router/DoS issues.

An idea would be to have a "knock Knock" protocol that would state
protocol types with a challenge response and possibly hash cash, else it
will not allow the port to be open for the tunnel.

Lance/0x90

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of auto97841-revL73yDgGBWk0Htik3J/[email protected]
Sent: Tuesday, July 29, 2003 12:01 AM
To: [email protected]
Subject: [iip-dev] some spec questions


The user 'co' on irc, who's shown interest in getting involved in the
java and network side of things, bounced me a few questions wrt the
spec.

For simplicity (with their permission of course) I'm answering them here

so the info gets more widely dispursed.

> 1. What happens when the assumption of the trusted local computer is

> violated? Suppose there is a key logger that captures a password used

> to authenticate a user on the network. If it is captured, the user
can 
> be impersonated by others. How do you propose to deal with that?

If the local machine is compromised, that public/private key can be 
considered useless.  I2P doesn't have any key revocation mechanisms,
so 
applications running on top of it could either periodically cycle 
Destinations (which is a good thing for perfect forward security) or

provide a revocation/verification service.  As with credit cards,
though,

before you cycle or revoke your Destination (and hence public/private

keys), you're still liable for whats done in your name.  

That however isn't too damaging, as we assume all users are evil anyway.
 
That they usually aren't very evil is just a perk.

> 2. In the "Network Topology" section, the following statement is 
> initially confusing: "destinations move between routers, instructing

> routers to rebuild, extend, or tear down old tunnels." I think that
to 
> decrease the confusion, you should rename destinations to clients.

> After all, a router can be a destination for some of the traffic it

> routes. It then becomes clear that clients set up outgoing and
incoming
> tunnels through various routers, and can change those tunnels 
eriodically.

Hmm.  You're right, a router can be a location where a message is sent,
 
though from a black box perspective, the I2P system provides a way of

transparently shoveling data from one end point (destination) to another

(applications using the client API can consider the other end point
local
to their router).  I'm hesitant to use 'client' as a term, as a single

client app can have multiple destinations associated with it (plus MOMs

use the destination terminology), though I do see what you're saying
and 
understand the cause of confusion.  Do you have any suggestions that

could clarify things further?

> 3. Also, I see that after a new tunnel is created (let's say, an 
> incoming tunnel for a client), the old one should remain in operation

> until the routers update the tables to list the new one. Only then
it 
> should be deleted, to avoid loss of messages by routers not knowning

> about the new tunnel.

Definitely.  The tunnel throw up / tear down part of the spec isn't
clear
on this (plus a few other things I've got jotted in my notebook), but

you're 100% right.  

> 4. In the Lease structure, you say that "tunnel" is the "name of the

> tunnel on the gatewayRouter." It may be better to have it be a tunnel

> ID on the gateway, otherwise two clients could connect to the same

> gateway and have it create tunnels with the same name. Of course, the

> gateway could be the entity managing the tunnel names to avoid such

> name collisions.

Right, I need to clarify that name is just a pseudo-unique identifier
(4 
byte positive integer per data structure spec).  During the tunnel 
creation its uniqueness across all tunnel participants must be verified

to avoid exactly the scenario you mention, perhaps even with a two phase

commit if we're feeling ambitious.

> 5. With all the encryption, will the network be fast enough for IRC
or
> instant messages to pass through it? The network will need testing
to
> answer this question and possibly improve the routing algorithm to
> make it faster.

Exactly.  I'm fairly confident our latency will scale at log(n), but
the 
constant overhead I'm not sure about.  I'm not sure how the routing
could
be improved though - we use the shortest outbound and inbound tunnels

that the source and target destinations can use to meet their anonymity

goals, and then we make a direct connection across the fastest transport

available between the outbound tunnel's endpoint and the inbound
tunnel's
gateway.

But you're right - there is a lot of opportunity to use really 
intelligent algorithms when creating the tunnels so that they perform

adequately.  I haven't put too much thought into the specific router

implementation algorithm to do that, though I've been listening intently

to the discussions on freenet's devl wrt their homebrew algorithm 
(ngrouting w/ a Routing Time Estimator) as compared to an alternate 
machine learning based algorithm
(http://hawk.freenetproject.org:8080/pipermail/devl/2003-
July/007454.html).  

> 6. After reading the "Router location" section of the spec, I see that

> it is possible that a router leaves the network yet other routers 
> continue to search for it. For instance, this could happen while a

> tunnel is being created. You need to have the router take this 
> possibility into account when creating a tunnel for routing messages,
 
> and adjust the tunnel if this happens.

Hmm.  Tunnel participants failing before their tunnel 'contract' is up
is 
a problem.  Tunnel creators and gateways should probe the tunnel 
periodically to detect that by sending messages down the tunnel, 
rebuilding the tunnel if/when it fails.  And, getting back to the 
previous question, the algorithm used to choose routers to participate
in
tunnels should take into consideration the fact that some routers are

frequently bad and avoid them.

> 7. To prevent denial of service attacks, clients should accept
incoming
> messages only from the router with which they have set up an incoming
> tunnel. Otherwise, a malicious router could enter the network, find
> a destination from the hash table, then send it many messages
directly.
> Does hashing a destination in the Lease structure prevent this 
> possibility?

We can't really have routers accept messages only from routers it has
a 
lease, as that way both the DHT would fail and we could never contact
a 
router to establish a lease in the first place.

Thankfully, destinations can have multiple concurrent Leases, and hence,
 
multiple inbound tunnels, each of which only promise to deliver a
certain

number of messages or bytes per time period (or unlimited).  If they
are 
under attack, they can notify their controlling router (which will be
the 
destination's router) and that router can either destroy that tunnel
(by 
revoking the lease) or build more tunnels.  This makes it arbitrarily
expensive for an attacker to mount a complete DoS against a particular
destination, as they must flood the gateways to those tunnels with 
messages, while the destination needs merely to create more tunnels.

That does, however, mean DoS attacks can make a destination less 
responsive.  If an attacker floods a particular inbound tunnel with
messages,
 if another person wants to send that destination a valid 
message and unfortunately chooses to use that tunnel, the message could

be lost (depending on their SessionConfig - user can choose to have I2P

guarantee delivery, make a best effort delivery, or make a simplest 
effort delivery.  simplest effort would drop the message, the other two

would try again with a different lease).

If a tunnel is under persistent attack, the router can instead revoke
the 
Lease pointing at that tunnel and build a new one, rather than build
an
additional one and keep the old.

> 8. What are the router's contact addresses? Are these the IP addresses

> it uses?  If not, what are they?

Yes, basically.  The contact addresses can be IP/portnum pairs for the

TCP and UDP based transports.  They can be email addresses for email

based transports. They can be sets of URLs for HTTP based transports.
 
etc.

> 9. During an administrative session, the client sends the trusted 
> router a hash of the administrative password. When is this password

> set? When the router is initially configured? You did not specify
this.

Correct - the admin password is set in a router implementation specific

way (e.g. the Java router may store it in a properties file, while the

Python may store it encrypted in a file, and the C one may load it from

the command line).  I'm hesitant to specify how thats set for all of

them, unless you see a way that doing so could meet a need I haven't

seen?

Thanks for the questions - you're prodding at just the right places and
I
appreciate the time you've spent on this.  Feel free to post up any more
questions either here or privately and we can discuss further.

-jrandom
(its almost 10am and I haven't slept yet, so please forgive me if i'm
not 
quite coherent)



Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427