river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject River Musings
Date Sun, 30 Aug 2015 11:09:36 GMT
I finally had the chance to look through the org.apache.river name 
change work Dennis Reedy has done, it all looks very impressive, he's 
even taken the time to tidy up the qa suite. I haven't had time to run 
any tests or look at the jtreg test suite, I promise I'll make some time 
in the near future. Before we release this code there is an opportunity 
to tidy up the org.apache.river name space even further. In the Jini 
days, com.sun.jini.* was implementation code, it wasn't part of the Jini 
public API, should we now use org.apache.river.* for this purpose? There 
is some new public api, in org.apache.river.api.* and at the time new 
implementation code was being placed into org.apache.river.impl.* and 
now the com.sun.jini.* namespace has been moved to org.apache.river.*. 
Should we consider placing the new api in the net.jini.* namespace? It's 
worth looking at the javadoc as most of the new classes are package 
private. There are also discovery constraints in the implementation 
namespace that should be moved into the public api in my opinion, thoughts?

IPv6, for River, this is big, IPv6 has auto network configuration, 
powerful multicast abilities, IPSec and no need for NAT. IPv6 is going 
to allow our existing discovery protocols to work over the internet.

The examples project looks promising, I like how Greg Trasuk has 
structured the examples into api, server and clients, Greg has done a 
lot of work to tidy this up. Our existing example code is relatively 
old, I did notice some bad practices by current standards as a 
consequence. If we want to reduce our support burden, we should 
encourage new users to use best practise.

The issue that stuck out the most was letting 'this' escape during 
construction. All River service implementations now implement the 
Starter interface to avoid letting 'this' escape during construction, 
however since there are a number of downstream “Container” projects and 
there was controversy surrounding the start method; if someone wants to 
propose something less controversial for user examples, please do so, 
hopefully it won't upset anybody still clinging to unsafe publication.

On the topic of “Letting 'this' escape”, because readObject methods 
behave like constructors, the jvm performs a final freeze after the 
readObject method completes, however there are a number of places where 
River lets 'this' escape during deserialization, I did have some 
solution options for this, including a better way to deserialize...

I try not to discuss River security after another developer raised 
concerns it was scaring off new developers. I'm going to take the 
liberty to discuss security and performance briefly.

Some points:

    *

      IPv6 will enable River to traverse the internet, easily.

    *

      IPv6 is plug and play – autoconfiguration of network devices.

    *

      River is well positioned for the internet of things, but needs IPv6.

    *

      IPv4 NAT is pretty much what killed the Jini iot tech 20 years
      ago, as Jini was distributed, not centralised, web services have
      grown up around this centralised model.

    *

      River security isn't ready, our crypto protocols need updating and
      proxy trust is currently flawed.


The issue with proxy trust:

    *

      We can discover a lookup service securely.

    *

      We can't connect to services securely, service proxy's are
      downloaded and deserialized before trust is established.


Don't despair, the security issues are easily fixed.

Back in the early days, Jini used RMI and RMI used skeletons and stubs. 
The stubs had to be downloaded, so you always had codebase downloads. 
Now, codebase downloads aren't always required, but the lookup service 
implementation, is still designed around codebase downloads.

When security was enhanced in Jini 2.0, we were given the concept of a 
bootstrap proxy, which is just a reflective proxy that doesn't require a 
codebase download. So what does River do, it downloads a codebase, 
deserializes a service proxy and then requests a bootstrap proxy from 
it. At this point in time the river client authenticates the service, 
then River asks the bootstrap proxy for a TrustVerifier instance to 
check the service proxy, permissions are dynamically granted (but how do 
we know what permissions are required?) and method constraints are 
applied. This is called proxy preparation and it's a configuration 
concern, as are the exporters. Yep this is a complex processs.

How could this flaw be fixed without impacting the client?

Easy, the lookup service shouldn't contain the service proxy, only the 
bootstrap proxy. Guess what, big performance increase, just like delayed 
codebase downloads, thank you Gregg Wonderly, for identifying and 
trailblazing that path at least a decade ago.

During proxy preparation (a process determined by configuration), 
instead of asking the service proxy for a bootstrap proxy, the lookup 
service should only contain the bootstrap proxy and clients obtain the 
service proxy from it, after authentication, constraints are applied, 
permissions granted to the proxy and the process is complete. This is 
much simpler than our current proxy trust establishment. Less 
serialization overhead, less network traffic, more performance. A 
configuration flag could restore the old behaviour of course.

The client is none the wiser, it still receives a fully prepared and 
constrained proxy. All River services already implement 
ServiceProxyAccessor, although part of the start package, it's an 
interface that provides access to the service proxy.

We only need a new Exporter (easy) that creates the bootstrap proxy and 
ensures it doesn't implement any interfaces that would require a 
codebase download.

Then when a service is registered with a lookup service, Reggie obtains 
the bootstrap proxy from the exported service proxy in the client jvm.

It also means the entire process is simpler, developers no longer need 
to learn the complex TrustVerifier process as it becomes an Endpoint and 
system concern.

Thoughts?

Regards,

Peter.



Mime
View raw message