Instead we could communicate over ordinary public networks without
any special network admin intervention.
I'm with you!
This does raise privacy issues though for serialization or message
streams, however secure JERI has mechanisms to handle those.
Exactly, you cannot provide proxies in the wild without some kind of
verification. Thats why i keep returning to things analogous to
tunnels/VPNs etc. Because i want a TLS session end to end.
IPSec (VPN) packets cannot be mangled, it breaks the checksum, so the
IPSec packet is wrapped in another packet that gets mangled, this
provides the encryption end to end, unfortunately it requires low level
Kernel support as it's below the TCP/IP Layer, so it isn't available
without network admin intervention.
We have to be careful to avoid a man in the middle with our Relay, see
below I have some more thoughts.
That is of course if Serialization is used for communication.
Compressed Serialized binary data is the fastest way to communicate
over bandwidth restricted and high latency networks.
BTW pluggable marshallers, this could provide us for a place to put an
auto-exporter in. We could with annotations/interfaces signal verify
the intent. (i'm sure i'm not the first one thinking that).
For smart proxy implementations we would want the client to be able
to download the marshalled smart proxy from a lookup service and
download the bytecode from a codebase service (it would be easier if
the code base is public), where the smart proxy itself uses its
internal reflective proxy (RMI JERI) to communicate with the private
service via the listening post. The listening post would just be
relaying the methods / messages while keeping the communication lines
(NAT gateway ports) open between it, the smart proxy and its server.
Perhaps JERI itself could utilise some sort of Relay listening post
service?
Exactly, i was only talking about a proxy in terms of JERI. I think we
now have the proper name for it. Jeri Relay Service (JRS)?
We can also create a standard codebase service, which can (off-course)
also be exported over the JRS.
Gr. Sim
JRS, I like that name. Maybe Just JR? Even though it's a service, the
semantics become difficult to distinguish it from the private service.
Perhaps JR can provide these functions:
1. Be verified by a TrustVerifier from the private Service node as
well as the Client node, to verify the piece of code that handles
the Socket Channels is the genuine JERI Relay.
2. Keeps a line of communication open to the private Service
utilising a heartbeat
3. Read's ByteBuffer's from a Socket Channel, and write it's content
to another Socket Channel without decrypting it. If it isn't
visible to the Relay and the Server and client can verify the JRS
code, then there is potential there to trust the Relay.
4. SSL Handshake: Not sure about how the handshake process from
actual client to private service will handle the redirect.
Before a Relay can provide those functions between a client and service
it must register the private Service proxy with a publicly visible
registrar.
Perhaps the BasicJeriExporter can inspect the IP Address, and if it lies
within a private range, check a system property to determine if JR
Services are to be utilised?
JR could be looked up just like any other service, it only executes
local code, doesn't need to know the details but can be trusted enough
by the Service and client not to peek at the details. JR probably needs
to be identified by a public domain certificate, although this is a weak
defence (DNS cache poisoning), it adds another layer.
Cheers,
Peter.
