On Mon, Jun 18, 2001 at 03:52:48PM -0700, Ian Clarke wrote:
> On Mon, Jun 18, 2001 at 06:28:10PM -0400, Tavin Cole wrote:
> > Thanks for doing the legwork on this, Bad. However, I think requiring
> > users to restart the node once a day to get new inform.php addresses,
> > or requiring them to ma
I've been giving this a bit more thought and I think that nodes having a
large percentage of ther requests satisfied by a small number of nodes isn't
nescesarily a bad thing.
In fact in a mature freenet it is pretty likely that nodes would mostly talk
to a few nodes that are close to themselves ke
Ian Clarke schrieb:
> > IC> It seems that there are a small number of nodes which are
> > IC> receiving a disproportionate amount of traffic.
> > How can you possibly know this, Ian? What makes you think this is true
> > at all?
> Because people are reporting that their datastores tend to
> I think it'd be fun if we made up a bunch of costumes like in a
> medieval morality play, so that when someone has to take a personify
> an aspect in a design trade-off, we can all know who they are supposed
> to be.
Ah, Mr. Bad, what would I do without you.
_
> "IC" == Ian Clarke <[EMAIL PROTECTED]> writes:
IC> That would certainly be nice, I guess I have become
IC> hyper-sensitive to potential issues such as this.
Of course! It's important, after all.
I think it'd be fun if we made up a bunch of costumes like in a
medieval morality play
> "IC" == Ian Clarke <[EMAIL PROTECTED]> writes:
IC> Because it is unhealthy for a node to almost exclusively rely
IC> on one other node in the network.
I agree, but I also think this is a problem that corrects itself.
IC> Secondly, if you are the poor bastard that is operating
> "m" == moritz <[EMAIL PROTECTED]> writes:
m> you can't force a node to limit the references/IP
Me> Why not? Please elaborate.
m> well, YOU can force YOUR node, but freenet-nodes can't be
m> forced in general.
Right, well, that's something of a good point. I -don't- thin
On Tue, Jun 19, 2001 at 09:33:45AM -0700, Mr. Bad wrote:
> OK, you lost me there. If not to preserve security, why do we want to
> prevent the formation of ubernodes? Where I assume you mean by
> "ubernode" the natural build-up of a lot of references to a single
> address within a single node's da
On Mon, Jun 18, 2001 at 11:43:07AM -0700, Ian Clarke wrote:
> It seems that there are a small number of nodes which are receiving a
> disproportionate amount of traffic.
>
> How can this be addressed? There are several options:
>
> Only one reference to each node is permitted in the datastore.
Mr.Bad (Tue, Jun 19, 2001 at 10:06:19AM -0700):
> m> you can't force a node to limit the references/IP
> Why not? Please elaborate.
well, YOU can force YOUR node, but freenet-nodes can't be forced in
general. just remove the part of code. (if added, there most probable
will be a option for
> "m" == moritz <[EMAIL PROTECTED]> writes:
m> you can't force a node to limit the references/IP
Why not? Please elaborate.
>> If a node has TWO good peers, equally distributed, which one do
>> we reduce?
m> two peers are not very much... i wouldn't consider freenet
m
Mr.Bad (Tue, Jun 19, 2001 at 08:11:41AM -0700):
> I have 3 transient nodes behind a firewall. They all have a single
> address to use in nodes.config -- the firewall machine's node. Do THEY
> now have to have 9 other addresses (which BTW they can't connect to)?
you can't force a node to limit the
Mr.Bad (Mon, Jun 18, 2001 at 02:44:49PM -0700):
> m> since you know which keyspace the undernode is ``responsible
> m> for'', you should be able to recognize if the undernode is the
> m> initial requestor (routing-key different from ``keyspace'')
> That's assuming that your idea of wha
> "IC" == Ian Clarke <[EMAIL PROTECTED]> writes:
IC> This may not stop a determined attacker, as you point out, but
IC> it will make such an attack more difficult. Either way, this
IC> was a secondary goal, the most important thing is that it will
IC> prevent the natural form
On Tue, Jun 19, 2001 at 04:29:18PM +0200, Oskar Sandberg wrote:
> On Mon, Jun 18, 2001 at 08:58:56PM -0700, Ian Clarke wrote:
> > On Tue, Jun 19, 2001 at 05:33:21AM +0200, Oskar Sandberg wrote:
> > > And how the fuck does "one reference per node" help against a malicious
> > > attacker? Nothing st
> "NB" == Neil Barsema <[EMAIL PROTECTED]> writes:
NB> I still think limiting the number of references to a specific
NB> node is a nescesary feature.
OK, let's say that we limit the number. Are we going to limit it to an
absolute # (1000), or to a percentage of what's in the data sto
On Mon, Jun 18, 2001 at 08:58:56PM -0700, Ian Clarke wrote:
> On Tue, Jun 19, 2001 at 05:33:21AM +0200, Oskar Sandberg wrote:
> > And how the fuck does "one reference per node" help against a malicious
> > attacker? Nothing stops them from making up a new node identity with
> > every reply.
>
> A
Ian wrote:
>Having said that, and after some IRC discussion, I have realised that
>another solution which should fix the problem as a side-effect is to
>periodically split DataRequests and take the DataSource in the first to
>return. The main reason for doing this is to make the network optimise
On Mon, Jun 18, 2001 at 08:58:56PM -0700, Ian Clarke wrote:
> On Tue, Jun 19, 2001 at 05:33:21AM +0200, Oskar Sandberg wrote:
> > And how the fuck does "one reference per node" help against a malicious
> > attacker? Nothing stops them from making up a new node identity with
> > every reply.
>
> A
On Tue, Jun 19, 2001 at 05:33:21AM +0200, Oskar Sandberg wrote:
> And how the fuck does "one reference per node" help against a malicious
> attacker? Nothing stops them from making up a new node identity with
> every reply.
A new IP address every time? Not impossible, but rather difficult.
Ian.
On Mon, Jun 18, 2001 at 01:03:21PM -0700, Ian Clarke wrote:
> On Mon, Jun 18, 2001 at 12:10:15PM -0700, Scott Miller wrote:
> > Or wait until we have load balancing sometime in 0.4.
>
> Yes, but that is voluntary, you need to trust other nodes to do it, a
> malicious attacker could simply remove
> "IC" == Ian Clarke <[EMAIL PROTECTED]> writes:
>> b) It's not a network issue, it's a per-node (Pernod?)
>> issue. Mature nodes settle.
IC> I don't see how inform.php is relevant? These addresses are
IC> only "seeds", the node should quickly find out about more
IC> nod
On Mon, Jun 18, 2001 at 06:34:07PM -0700, Mr. Bad wrote:
> IC> It is ugly to require a flow of out-of-band addresses for a
> IC> node to "settle", and IMHO it is unnecessary.
>
> Well, I think that at some point you have to have
> o.o.b. addressing.
Of course, but only when the node fi
> "IC" == Ian Clarke <[EMAIL PROTECTED]> writes:
IC> It is ugly to require a flow of out-of-band addresses for a
IC> node to "settle", and IMHO it is unnecessary.
Well, I think that at some point you have to have
o.o.b. addressing.
>> This is only really a problem if a) you'r
On Mon, Jun 18, 2001 at 04:35:08PM -0700, Scott Miller wrote:
> Sure there is. Each reference gives more information about the keyspace of
> that node. As has been said, it doesnt matter how many references there are
> to a node, its how (or whether) that influences how often that node is
> cont
On Mon, Jun 18, 2001 at 03:52:48PM -0700, Ian Clarke wrote:
> On Mon, Jun 18, 2001 at 06:28:10PM -0400, Tavin Cole wrote:
> > Thanks for doing the legwork on this, Bad. However, I think requiring
> > users to restart the node once a day to get new inform.php addresses,
> > or requiring them to ma
On Mon, Jun 18, 2001 at 06:28:10PM -0400, Tavin Cole wrote:
> Thanks for doing the legwork on this, Bad. However, I think requiring
> users to restart the node once a day to get new inform.php addresses,
> or requiring them to maintain the nodes.config file, isn't what we
> want in the long run.
On Mon, Jun 18, 2001 at 02:58:43PM -0700, Mr. Bad wrote:
> As long as you keep introducing new addresses in (preferably through
> an out-of-band mechanism), and let the node run for a while, the
> routing table will eventually "settle." Adding in a number of good
> addresses of permanent nodes to
On Mon, Jun 18, 2001 at 02:58:43PM -0700, Mr. Bad wrote:
> As long as you keep introducing new addresses in (preferably through
> an out-of-band mechanism), and let the node run for a while, the
> routing table will eventually "settle." Adding in a number of good
> addresses of permanent nodes to
> "IC" == Ian Clarke <[EMAIL PROTECTED]> writes:
IC> Because people are reporting that their datastores tend to
IC> have one or two nodes to which almost all references are
IC> pointing to.
Me> See my explanation on chat.
IC> Thanks, I am familiar with how Freenet works.
On Mon, 18 Jun 2001, Peter Todd wrote:
> On Mon, Jun 18, 2001 at 01:10:51PM -0700, Mr. Bad wrote:
>
> This is no defense against such an attack, as I just
> pointed out you can run an unlimited number of virtual servers on
> different ports/ip addresses.
>
> Still I think nodes should be setup
On Mon, Jun 18, 2001 at 01:10:51PM -0700, Mr. Bad wrote:
> IC> Because people are reporting that their datastores tend to
> IC> have one or two nodes to which almost all references are
> IC> pointing to.
> See my explanation on chat.
Thanks, I am familiar with how Freenet works.
> An
> "m" == moritz <[EMAIL PROTECTED]> writes:
m> since you know which keyspace the undernode is ``responsible
m> for'', you should be able to recognize if the undernode is the
m> initial requestor (routing-key different from ``keyspace'')
That's assuming that your idea of what the
Mr.Bad (Mon, Jun 18, 2001 at 01:10:51PM -0700):
> > "IC" == Ian Clarke <[EMAIL PROTECTED]> writes:
>
> >> How can you possibly know this, Ian? What makes you think this
> >> is true at all?
>
> IC> Because people are reporting that their datastores tend to
> IC> have one or
On Mon, Jun 18, 2001 at 01:10:51PM -0700, Mr. Bad wrote:
> IC> This is even a viable attack, since a
> IC> node could always set itself as the datasource on all
> IC> messages, creating a positive feedback loop (more references
> IC> in the datastore lead to still more references i
On Mon, Jun 18, 2001 at 01:10:51PM -0700, Mr. Bad wrote:
> IC> This is even a viable attack, since a
> IC> node could always set itself as the datasource on all
> IC> messages, creating a positive feedback loop (more references
> IC> in the datastore lead to still more references i
On Mon, Jun 18, 2001 at 11:43:07AM -0700, Ian Clarke wrote:
> Only one reference to each node is permitted in the datastore.
This would be, ah, interresting. Think about it
AGL
--
When will people realise that we don't care for their damm stupid laws? We can handle
ourselves, thank you very m
Or wait until we have load balancing sometime in 0.4.
On Mon, Jun 18, 2001 at 11:43:07AM -0700, Ian Clarke wrote:
> It seems that there are a small number of nodes which are receiving a
> disproportionate amount of traffic.
>
> How can this be addressed? There are several options:
>
> Only one
> "IC" == Ian Clarke <[EMAIL PROTECTED]> writes:
IC> It seems that there are a small number of nodes which are
IC> receiving a disproportionate amount of traffic.
How can you possibly know this, Ian? What makes you think this is true
at all?
IC> Only one reference to each node i
> It seems that there are a small number of nodes which are receiving a
> disproportionate amount of traffic.
>
> How can this be addressed? There are several options:
>
> Only one reference to each node is permitted in the datastore.
I'd be surprised if that worked in practice. Wouldn't it jus
40 matches
Mail list logo
