On Tuesday 08 Jan 2013 16:37:58 Arne Babenhauserheide wrote: > Am Samstag, 5. Januar 2013, 23:41:33 schrieb Matthew Toseland: > > > Ah, OK. I’m also interested in the case where we have exactly *one* > > > darknet > > > friend: The one who introduced us into freenet. If we now introduce > > > someone > > > else, FOAF does not help, because we also only know one person. But we can > > > spread opennet noderefs. > > > > Hmmm. True... If we are invited by somebody with darknet peers, we will have > > FOAFs. > > > > Is this a case we want to optimise? I suppose it's fairly important? > > I think it is important. > > > A related question is is our whole "use opennet until you have 40 darknet > > peers/FOAFs" strategy acceptable, given you can get disconnected pockets? > > Should we keep the limits for darknet vs opennet completely separate and > > have some mechanism to detect when your darknet is "mature" enough to turn > > off opennet? > > We could check, if we can access the latest freenet update in pure darknet > mode. > > If we can get that, we likely can access the global keyspace.
Possibly. It gets passed across unroutable links and reinserted, so it's not so certain. Maybe the source or something. Or the bookmarks even. Maybe do a random-route-then-fetch probe. But we'd want to be able to distinguish between "in our darknet pocket" and "on opennet via another node". We might have a cluster of 39 darknet nodes, all with opennet enabled, all connected to each other. We add one more node, they lose their remaining opennet connections and become orphaned. So we want a flag for requests to only pass over darknet links IMHO. We can use this for testing the local darknet. But we could also use it for trying to fetch data from the local darknet before we ask opennet, on a whole-request level. IMHO that would be useful. > > > Your argument is then that we need to be able to announce from any darknet > > peer? > > I thought we could already do that… We can right now. But some of my plotting re opennet changes might not be compatible with initiating your own announcements without involving seednodes. Without involving the seednodes it is much harder to throttle announcements - either for a DoS or for creating lots of nodes or for MAST. > > Yes, I think it is necessary. So we need to think about this when designing any future opennet architecture. > > > No, we need to actually communicate with the downstream nodes: we exchange > > noderefs internally via an announcement. That means there needs to be > > two-way FNP traffic. It's necessary for UDP hole punching to work. Of > > course it doesn't always work... > > Argl, yes. > > But that would still not be too hard in a lightweight script, I think. I don't see how it can be a script. > > > > So even though the current implementation of Opennet is centralized, the > > > concept behind it is not. It’s just based around having some really long > > > lived points of contact. > > > > Hmmm, maybe. I'm not sure I follow or agree. > > I think that this is actually not centralized on the protocol level, because > all it needs are servers which have stable addresses. > > GWebCaches for example exchange lists of other GWebCaches - by having the > clients tell them about the other GWebCaches they know. Due to that there is > no additional required upper layer: To get a new cache known, you just have > to > give its address to a client. For example via a freesite. And the clients can > decide which cache-list to follow. Seednodes could keep track of other seednodes. But you would still need to know a seednode in order to get onto the network. Hence it is a centralised network. Even worse, in principle a malicious seednode can ensure you only receive references he controls; there are ways to prevent this involving other seednodes, of course. I stand by my original statement: Opennet Freenet is already a federated, two-level, supernode network. > > > > They might join after hearing a talk about Freenet. (I might be dreaming > > > here, though :) ) > > > > Local publicity is *possible*. I don't think it would give an *instant* > > response. And like I said, there would be some darknet hopefully as a > > result. > > Do you have an idea where the rising number of users since sunday 2012-12-30 > comes from? > > http://127.0.0.1:8888/freenet:USK@pxtehd- > TmfJwyNUAW2Clk4pwv7Nshyg21NNfXcqzFv4,LTjcTWqvsq3ju6pMGe9Cqb3scvQgECG81hRdgj5WO4s,AQACAAE/statistics/129/ > > That’s a rise which would not trigger that problem. Hmmm, interesting. Guess there was some publicity? If there is a problem we would see a spike on only one AS. If there is local publicity (e.g. obscure language) we'd see a spike on a subset of AS's. > > > That would likely have the same effect as any other publicity: Lots of new > > nodes across lots of AS's. No? > > I think at first, all might log in over the CCC WLAN. Like I said, an AS is a lot bigger. Getting more fine-grained data will be harder. > > > > The given location would for example be a range from 0.11 to 0.12, If that > > > gets significantly more new connections than before, the node would only > > > accept some of them. Maybe 50% more than the hour before. > > > > No, we can't do this. We want most of our connections to be close to our > > location. We do throttle new connections through various heuristics, but > > it's not really adequate protection, if creating a new node and announcing > > is free. > > How about just segmenting the connections we have right now into 10 segments > - > and just throttling the ratio of changes in the number of new nodes in these > segments? I would be worried about routing consequences; it would be too similar to normal traffic, and ... > > > And it wouldn't help AFAICS: The attacker doing MAST only needs one peer. > > So we cannot stop that with node-based throttling… > > > The attacker trying to surround a node just abuses path folding. > > :( > > > We can > > make surrounding a little more expensive by checking the AS's of peers > > though; that doesn't need much central support. > > That might be a good step, yes. > > > > So throttling must not stop regular nodes, because there is no fallback. > > > > There are two separate cases: > > > > Creating an identity: There is no fallback, except waiting - but the limits > > are probably strict enough that they may have to wait quite some time. > > Users are expecting an immediate response. However, we CAN tell them that > > there is a DoS attack going on on their ISP. > > That would be nice, yes. > > > > (reminds me of my old idea of having two locations, than any attack would > > > very likely only affect one of your locations but not the other…) > > > > You'd need separate sets of peers. You'd be running two nodes. What's the > > benefit? > > The benefit would be that an attack on part of the keyspace would be very > unlikely to block you completely. And your node could correlate the > performance of your two locations to find out about attacks. We now would > have > 2 datapoints we can trust. Hmmm, maybe. > > > IMHO we could deploy the fix, or at least write our own simulator to test it > > ourselves. The main difficulty with that is I could never get my head > > around exactly what the Pitch Black attack was algorithmically. I'm sure I > > could deal with it now given enough time though... > > That would be really nice, I think. The Pitch Black Attack is the sword > hanging above our head at the moment. It says “freenet cannot prevent > censorship, even with Darknet”. > > And fixing that would make the fundamental usecase of freenet real again: > “Just use Darknet. It’s some work and needs spreading freenet, but it avoids > censorship at once.” Yes, we should fix Pitch Black.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
