river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Lookup Service Discovery using DNS? (revised)
Date Wed, 13 Jan 2010 03:31:04 GMT
Sim IJskes - QCG wrote:
> Peter Firmstone wrote:
>> Anyone got any opinions about Lookup Service Discovery?
>>
>> How could lookup service discovery be extended to encompass the 
>> internet?   Could we utilise DNS to return locations of Lookup Services?
>>
>> For world wide lookup services, our current lookup service might 
>> return a massive array with too many service matches. Queries present 
>> the opportunity to reduce the size of returned results, however 
>> security issues from code execution on the lookup service present 
>> problems.
>
> I haven't seen any world wide deployments yet, at least not on my bench.
> :-) And i would like to reserve my definite judgement before i have had
> an actual production deployment of such a service.
>
> When we have several reggies running on the internet, it would be
> handy to find them via DNS SRV records. It would only create an extra 
> layer of indirection. With DDNS zone updates one could build some kind 
> of super registry, but i would prefer just to code it in java.
>
> About MDNS (Bonjour) SRV records. MDNS is a multicast protocol
> so it has the same pattern as the multicast discovery as currently
> implemented. In a broad sense one could suggest that this might suffer
> from the same deployment issues as een MDNS discovery would suffer.
> Except that MDNS is more mainstream and on more sites there might be a
> working infrastructure(substrate?) for it. (like MDNS holes in personal
> firewalls). But still MDNS does not work in the internet.
>
> But anyhow, would this solve the problem. In order for a 
> world-wide-registry to work, wouldn't we need to have clearly defined 
> services? I wouldn't connect to a registry which i cannot verify for 
> source and meaning. To be honest, i can only look as far as using jini 
> scoped for projects under my control, and wouldn't dare to connect to 
> outside services, unless there are clear agreements.
>
> Running Jini on a LAN, creates no problems, as the LAN is under 
> central authority. But to venture out on the internet, which services 
> would i like to expose? I guess we have to define internet-jini. Is 
> the internet a global anonymous crowd, or is the internet a way to 
> connect isolated LAN's? Or just a happy few, romaing the internet, 
> having the right certificate chain to identify them.
>
Internet-Jini:  My thoughts are that it is a Global anonymous crowd, 
where trust relationships are used to allow collaboration to occur in 
proportion to the degree of trust established.

A Global Registry Service, provided it's interface only uses built in 
Java or core River types, will never require remote code to be executed.

For Jini services to be distributed over the internet, they will require 
signed bundles provided by codebase services and trust agreements.  
Bundle signing creates an identity on which a level of trust is based, 
predefined by agreement between parties.  A service client can use, 
signed, trusted bytecode, that doesn't originate from the untrusted 
service (all services are initially untrusted until identified), then 
the client can be assured that the bytecode used for unmarshalling is 
trustworthy within the bounds of predefined trust agreement.  Although 
for full security we need to check Serialized objects defensively copy 
and verify unmarshalled data (we need a source code auditing process for 
serialization). 

The client of a codebase service would have a trust relationship with 
that codebase service ( A company might run their own codebase service ) 
and the codebase service would itself have trust relationships with 
signers who upload code.  A company might require a source code pass an 
audit process for client code of service implementations prior to use.  
The codebase service would itself sign the bundles if they are already 
signed by fully trusted parties and have the correct message digest.  
The trust relationships are based on the OSGi model of trust agreements.

Using bundles for client service code (currently provided in a single 
jar file), might mean better code reuse, additional bundles can be 
downloaded based on dependency requirements and package imports.  
General purpose components could be vetted for security, performing 
common functions for untrusted client code, enough to make code useable 
without breaching security.

Clear trust agreements can be made between parties, companies etc, the 
bundles downloaded can contain required permissions.  Untrusted bundles 
would be sandboxed and all downloaded bytecode would have to pass the 
JVM verification process.

Once bytecode is verified, other verification processes can be used, 
such as user authentication certificates, if required.

For this to succeed, Type must become divorced from originating codebase 
URL's, hence the requirement for a codebase service.  Marshalled Object 
Type must be compared based on fully qualified class names and 
originating bundles, based on OSGi's versioning system.  Therefore, if 
bundle version is compatible and the fully qualified class name equal, 
then two marshalled objects have the same type.

Perhaps upon establishing the Software infrastructure, we could create a 
staging area for submission of client bundle source code, for vetting 
and signing by multiple parties?

Cheers,

Peter.



Mime
View raw message