On Tue, Jun 27, 2006 at 10:42:19PM +0200, Thomas King wrote: > Hi Matthew, > sorry for my delayed reply. I have been on vacation for a few days. > First of all, I have to say that I am really pissed. I cannot understand what > is going on. A few week ago, I suggested a Sommer of Code project that > proposed STUN and UPnP support for the Free Network Project client. You > bashed my proposal many times and you had lots of arguments why STUN and UPnP > is not needed by the Free Network Project. Now, you are the person who is > promoting STUN and UPnP. In fact, you come up with the same arguments I have > used to underpin the usefulness of STUN and UPnP. > I hope you get me right. I am not pissed because you dismissed my proposal. I > am pissed because you dismissed my proposal at first and now you are using my > ideas. > Any explanation about this incident would be very helpful.
I was wrong. You were right. About STUN, not about UP&P. There are big issues with UP&P. Thanks to your existing code STUN implementation is fairly trivial (as a plugin to circumvent the 1.5 issue). Many thanks for writing it. As I see it the primary advantage of STUN is for newbies. The situation right now is that a newbie behind a NAT must connect to somebody who isn't NATed first, because they don't know their IP address and therefore can't give it to the other NATed node, so UDP hole punching doesn't work. STUN also helps when a node has been offline for a while. Finally it can tell us whether we are NATed; being able to detect this is useful for seednodes, and perhaps for saving bandwidth on handshaking. I changed my mind. It happens. Very frequently within the Freenet project! Part of the reason for my opposition to STUN at the time was the opposition of others in the team, who have now come round to the need for easy IP detection - partly due to practical experience. I'm sorry if I seemed hostile at the time. Maybe one way to deal with these sorts of issues is to more rigorously accredit those whose work we use; I will certainly try to mention you in the announcement resulting from this. I don't at this point expect us to implement UP&P; personally I am undecided, nextgens is very hostile; there are security issues (more than with STUN), and there are practicability issues (a hell of a lot of people are double NATed due to plugging a wifi router into a router modem rather than just plugging a hub in; 50% success rate when UP&P is detected reported by another tool which deployed UP&P; windows issues). > > However, I try to divide between personal disfavor and the benefit for the > Free Network Project. > Of course, you can use my JSTUN code and I offer to maintan a Java 1.4. > compliant version of JSTUN. Another open source project is already using a > Java 1.4 compliant version of JSTUN. So, it will be very easy for me to > extract the relevant code and maintain it. I will work on that in the next > few days. I keep you informed. That would be really excellent. What're your two cents on whether it should be a plugin or built-in? Plainly there are security issues with STUN, and some users won't want to use it, but I expect the majority will... The current plugin implementation is in https://emu.freenetproject.org/svn/trunk/plugins/jSTUN - most of this is just your code, JSTUNPlugin interfaces to the node. Not tested yet. Finally some technical questions: Do we need to bind outgoing packets to our listenPort number? Why does UDP hole punching work at all for us? Half of the domestic NAT boxes always rewrite the port number according to http://www.plugndial.com/draft-jennings-midcom-stun-results-02.txt . We always connect via our nodereference. This includes our detected IP address (which may come from an external node), and our official listenPort number, combined into physical.udp (which can be a list of IPs although right now it isn't). If two nodes are both behind NATs which rewrite the port number, then even if they know each other's IP addresses, they won't be able to connect to one another, because their port numbers are wrong. Correct? Our present on-network IP detection mechanism does not fix this, because a node's reference always uses its real port number. We could provide alternate port numbers or something? UP&P would fix this but UP&P is unreliable as well as having security issues... If one NAT doesn't rewrite the port number, then we can connect, because the node will reply to the detected port rather than the one in the reference. A full-cone NAT is effectively a port forward. But most nats are restricted cone or port restricted cone. As I see it in order to support port restricted cones it is necessary to bind your outgoing packets to your listening port, yes? A node behind a symmetric NAT (possibly run by an evil ISP; we've had a few italians come on with such a predicament) can connect to port forwarded or directly connected nodes, and also to those behind full cone NATs provided that they have accurate information on the new port number. It can't connect to nodes behind anything more restrictive, because it cannot know what port number will be allocated to that specific connection; we have a different port number for each {source IP, source port, dest IP, dest port}. Correct? > > Greetings, > Thomas > > On Wednesday 21 June 2006 22:16, you wrote: > > We are going to use jSTUN in Freenet 0.7. However we have many users who > > use java 1.4. The other java stun library seems unmaintained; we would > > prefer to use yours. This does mean that we will need to backport it to > > 1.4. Would we have to maintain a fork? Using java 1.4 means we won't > > have to cause disruption to our users, and we retain the possibility of > > using it on free javas (GCJ, Kaffe), which has a number of advantages. > > I'm not asking you to port it yourself, I'm asking if you'd take a patch > > to make it compatible with 1.4, or if you'd rather we maintained a fork. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060627/9461f020/attachment.pgp>
