Skip to main content

Status of Session Traversal Utilities for NAT (STUN) in JXTA

17 replies [Last post]
merlante
Offline
Joined: 2010-08-18
Points: 0

Hi there,

I have been googling and going through forum/email archives trying to determine the status of STUN in JXTA. As far as I can make out, STUN is earmarked for the next release. Is this true? Is there somewhere I can find the roadmap for upcoming JXTA/JXSE versions?

mark

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
merlante
Offline
Joined: 2010-08-18
Points: 0

Hi AdamMan71,

Cheers for your informative post. Plenty of food for thought!

I think that the most important thing at this stage is for JXTA/JXSE to get a consistent web presence. From a cursory web search, it looks like JXTA development has pretty much ceased from the Sun/Oracle pages.

Great to see interesting work going on.

mark

galato
Offline
Joined: 2007-07-06
Points: 0

Hi John and Mark,

does the STUN technique solve the symmetric NAT issue? I know it works
well with most NAT configurations but I am not sure about the symmetric case.

Thanks

boylejohnr
Offline
Joined: 2008-10-27
Points: 0

Hi,

Extract from http://www.brynosaurus.com/pub/net/p2pnat/

"Many symmetric NATs allocate port numbers for successive sessions in a fairly predictable way. Exploiting this fact, variants of hole punching algorithms [9,1] can be made to work “much of the time” even over symmetric NATs by first probing the NAT's behavior using a protocol such as STUN [19], and using the resulting information to “predict” the public port number the NAT will assign to a new session. Such prediction techniques amount to chasing a moving target, however, and many things can go wrong along the way. The predicted port number might already be in use causing the NAT to jump to another port number, for example, or another client behind the same NAT might initiate an unrelated session at the wrong time so as to allocate the predicted port number. While port number prediction can be a useful trick for achieving maximum compatibility with badly-behaved existing NATs, it does not represent a robust long-term solution. Since symmetric NAT provides no greater security than a cone NAT with per-session traffic filtering, symmetric NAT is becoming less common as NAT vendors adapt their algorithms to support P2P protocols."

galato
Offline
Joined: 2007-07-06
Points: 0

RIght - I know that paper, I think it's from 2005. Not sure how things have changed for S-NAT in 2010 but I did find recent journal papers that mention that S-NATs are still
in use and that STUN servers are not suitable solutions for them - thus my question.
In any case, I am not too concerned about S-NATs anyway, it was a side question, and I will very much welcome STUN capability in JXTA.

Thanks again John

adamman71
Offline
Joined: 2007-01-31
Points: 0

Terminology in NAT behavior has evolved. In general, you can find out how your outmost NAT behaves by probing two STUN servers. If your NAT has an independent mapping behavior (that is, the mapping between private IP-port and public-port is 'unpredictible'), then your only option is to use a TURN method (which is the Relay solution we have in JXTA).

Symmetric/unpredictible/independant mapping NAT config are not recommended anymore. There are RFC standards providing guidance on configuration and design recommendations for proper P2P behavior.

boylejohnr
Offline
Joined: 2008-10-27
Points: 0

Jerome,

thanks for the detailed response on time lines. Makes sense.

To confirm the work to date on this by student. He has implemented an tested TCP NAT hole punching, through linksys and blekin routers with windows firewall on. Will not work with symmetric NATs It works. The code is using the Netty IO libs used in JXTA now. The code at present is not in a state to be integrated. I have not made any commitment in time line but would like to see in before year end. And happy if someone wants to pick up the work.

Why TCP and not UDP:
Pro: For reliable comms TCP is better, since we are transferring files. Unlike video and voice which can be lossy. Therefore, avoid writing reliability code.
Con: (to be proven as major concern) UDP is less heavy on resources on the server, since only require one UDP port for all clients. We already have relay overhead anyway.

So logical fist step is to go TCP. I think the evolution after this may be to use UDP more for Route discovery in JXTA as a whole - but this would be way off.

Regards,
John.

merlante
Offline
Joined: 2010-08-18
Points: 0

Hi Demetris,

I know your question was for John, but just to clarify one thing. NAT traversal is indeed already in JXTA, via relays. In other words, A can send data to B via a relay C. Any traffic sent between A and B must be relayed through C. What STUN, hole punching, etc., accomplish is allowing data to be sent between A and B, without having to send it through C. Instead C does some handshaking tricks between A and B so that after the connection is established by C, A and B send data directly to one another through both firewalls. C is required to get things going, but does not need to have the transmitted data relayed through it. The advantage is a huge gain in the scalability of the P2P network when data is transmitted between peers, many of whom are behind firewalls.

I believe that John's student is attempting to accomplish this using TCP.

mark

galato
Offline
Joined: 2007-07-06
Points: 0

Hi Mark,

can you elaborate as to what the TCP tunneling that your student is working on is offering to the JXTA stack? Isn't NAT traversal already achieved with what JXTA has? I am just curious as to what the particular goal is since we are also working around the same area. Using both tcp and http transports we were able to get peers behind NAT/Firewall settings ot use a super peer (RDV/RLY) to enable pipe connectivity and exchange messages. I cannot comment much on performance (yet) as our goals were first to get the connectivity going but I am very interested in the work you and others are doing in this area.

Thanks and regards
Demetris

galato
Offline
Joined: 2007-07-06
Points: 0

Correction: the questions was directed for John and not Mark. Apologies :)

adamman71
Offline
Joined: 2007-01-31
Points: 0

Hi Merlante,

To answer some of your questions/remarks:

> As far as I can make out, STUN is earmarked for the next release. Is this true?

I don't think anyone has committed STUN for the next release. There is a lot of interest in this feature from many members of the community, and this will surely end up in JXSE.

IMHO, there is still pretty much core refactoring, clarifying and simplifying to be performed before we can smoothly integrate any STUN implementation. A lot has been achieved in 2.6. More patches are ready and still need to be applied.

Regarding STUN, I would bet on n+2, rather than n+1.

> Is there somewhere I can find the roadmap for upcoming JXTA/JXSE versions?

No. There is no official page so far. Since we are a small (but dedicated) community of developers, we discuss this on dev email list. Feel free to join.

For n+1 (Cheeseburger), we'll most probably have:
- New HTTP transport
- Messenger opitmization/rewritting
- Further code refactoring and optimization
- Long term performance and memory bug/issue correction
- Stop supporting Java 5.0 code.

May be we'll also have:
- Multiple peers in same JVM
- Equinox Bundle

This is nothing official, just a highlight.

> I am trying to figure out is if JXTA is as efficient as it can be.

And so does everyone. There has been significant improvement in 2.6 (thread & resource consumption, generation of files on file systems). There is still more to be done.

> I would like to read an up to date performance and comparison survey paper in the area. There are a few papers, but many of them are 4/5+ years old and rarely do they benchmark against alternatives.

Volunteers to perform benchmark analysis are welcome.

> The JXTA/JXSE stuff seems to be spread between a lot of different sites at the moment, and there are a lot of links to forums, mailing lists, news, etc., that go nowhere on these various sites.

This is also something we focussed on. We have decided to move to Kenai (centralize). There has been a lot of red tape and slow down during Sun's Oracle acquisition. There has been a lot of rescheduling on their part too.

The JXTA board of directors has not been really pulling their weight. The elections should have been organized in July and they have not. No emails about it, no nothing. I have asked for info about Oracle's intention and never got an answer. I see no difference with a case of abandonment. This is a general issue the JXTA community will have to deal with sooner or later. Split? No Split? Whereto? Apache? A life on our own?

As far as we are concerned, the transition to Kenai could have been finished off at the beginning of the year. We have been ready for a long time.

> With hindsight, I'd try to work a lot more with the PSEMembershipService, and solve the trust side of things by manipulated the certificate chains, which wouldn't necessarily be hierarchical, and there would be no one root.

Someone has apparently implemented something operational for 2.5, but it has not been integrated in 2.6 (lack of resource and other priorities). If you want more details, check:

https://jxta-jxse.dev.java.net/issues/show_bug.cgi?id=103
https://jxta-jxse.dev.java.net/issues/show_bug.cgi?id=105
https://jxta-jxse.dev.java.net/issues/show_bug.cgi?id=107

> What sort of DOS attacks is JXTA currently susceptible to?

Any, BUT, you can implement filters in the endpoint service to help tackling those issues.

> I believe that John's student is attempting to accomplish this using TCP.

We have focussed on TCP, because we don't use UDP. If we have a solution for TCP, then we don't really need one for UDP.

Hope this clarifies.

AdamMan71

galato
Offline
Joined: 2007-07-06
Points: 0

Gotcha - I didn't read thoroughly to ensure what John was responding to - makes sense now. We did use STUN servers before JXTA on some of our testing so I am familiar with them and I do agree with you on the performance considerations.

Thanks for the clarification

boylejohnr
Offline
Joined: 2008-10-27
Points: 0

Hi Mark,

we had an MSc Student working on a TCP tunnelling solution which we would plan to integrate to JXTA in the future. Unfortunately can not commit to a time line at present, but he has an implementation based on the TCP libraries used in JXTA.

What is your interest, requirement? Is this something you can help with?

Regards,
John.

merlante
Offline
Joined: 2010-08-18
Points: 0

Hi John,

Thanks for your reply. I am trying to appraise JXTA's ability to send large amounts of data between two peers at either side of a relay (i.e. both behind firewalls), without the data actually passing through the relay itself. In the case of STUN, I guess the relay would coordinate the appropriate handshaking required for the two peers to get the connection going and then both peers send the data to each other directly via UDP. I assume you are talking about the same thing, except over TCP?

Basically, I am periodically involved in P2P research projects, and I am trying to get a feel for whether JXTA is still the best/most mature/most efficient/full featured, etc. of the P2P platforms -- not that there are all that many of them. So I do not have a specific need for STUN, etc., right now, but am curious to see if and when this kind of functionality will be added. I am interested though. :)

Regards,
mark

boylejohnr
Offline
Joined: 2008-10-27
Points: 0

Hi Mark,

timing is everything. Zeyad, the Msc student doing the investigation into NAT traversal demoed his app yesterday and it works. I believe it will be straightforward to integrate to the JXTA API's and leverage the existing relay in JXTA. Will post to community and see when we can integrate.

As FYI we have made significant improvements to the JXTA network stack of late. Performance is definitely up for us. And we have much more efficient HTTP hole punching, implementing an HTTP protocol handler in the JXTA stack, enabling scalability since not using any of the J2EE stack as was with the JETTY stack.

Watch this space....

Out of interest, what has your further search showed up in Java libs that could be an alternate to JXTA.

Regards,
John.

merlante
Offline
Joined: 2010-08-18
Points: 0

I haven't actually found an alternative to JXTA in java. In fact I haven't found any straight replacement for JXTA in any language. Other technologies that claim to be comparable are either just DHT implementations, grid computing or file sharing/content distribution technologies. In other words, specific problems are tackled, but a general P2P platform is generally not considered an end in its own right.

I think that due to the complexity of JXTA, adoption has been relatively poor, which is a pity. However JXTA (JXSE at least) has in the past required a lot of memory and processing power, and took a long time to load. Many of these problems have resolved themselves since, and I have yet to put 2.6 through its paces. One of the things I am trying to figure out is if JXTA is as efficient as it can be, or whether there are some collection of libraries that could be stitched together to provide a much lighter weight platform with 80% of the functionality.

I would like to read an up to date performance and comparison survey paper in the area. There are a few papers, but many of them are 4/5+ years old and rarely do they benchmark against alternatives.

My own work with JXTA has centered around identity (IdentityFlow sourceforge project) and trying to do something sensible with the MembershipService/Credentials setup, which at the moment is insufficient because the PSEMemebershipService (only mature implementation) is effectively centralised by relying on a hierarchical certificate chain.

boylejohnr
Offline
Joined: 2008-10-27
Points: 0

Well good to hear no other alternatives to date.

Of the past year we have made significant improvements to JXTA, from our perspective we have improved, thread and resource consumption. And there have been contributions to make the SRDi data caches faster. So all in a positive direction.

I very much view JXTA as interfaces now that we have momentum behind and we will progressively bring in the best third party libs to make those interfaces work as well as possible. Since the down side of doing something your self is that you lose the support of the community.

Identity flow is something of a challenge I agree, and we have implemented on top of JXTA at present a web of trust. And used our distributed convergent data structures to support things like revocation and key lists. we have not solved DOS attacks, but we hope as we continue to improve the efficiency of the Comms layers we will be able to handle far better.

No one has done a performance benchmark on 2.6, but form experience it is much faster and more predictable.

merlante
Offline
Joined: 2010-08-18
Points: 0

Hi John,

I will take a look at the new identity work in JXTA ASAP. Is the web of trust stuff new in 2.6? Also, is there a roadmap, and/or list of changes I can find anywhere? The JXTA/JXSE stuff seems to be spread between a lot of different sites at the moment, and there are a lot of links to forums, mailing lists, news, etc., that go nowhere on these various sites.

As to my identity work on JXTA, firstly, it's quite easy to miss the work that is being done since the 2.5 release, so I felt more inclined to go it alone. I wanted to create username-password based membership service, where users log into an IdP of choice, obtain a credential, and use trust between IdPs and SAML assertions to determine the scope of identity on the network. This work is more general than JXTA so I just did what I had to do to make something work on JXTA.

With hindsight, I'd try to work a lot more with the PSEMembershipService, and solve the trust side of things by manipulated the certificate chains, which wouldn't necessarily be hierarchical, and there would be no one root. I am of the opinion that the concept of the PeerGroup offers very little in a P2P environment, and only encourages deceptive centralised thinking. However, Credentials and authentication, etc., will always be useful. I also discovered along the way, that if you use the PSEMembershipService, PKI signing and verification kicks in automatically when messages are sent.

What sort of DOS attacks is JXTA currently susceptible to? I guess the web of trust could be use here. Or even just have superpeers refuse to propagate the advertisements of bad peers. This is happening at the advertisement level, I take it?

mark