I tend to agree with Dan, there's some cruft we need to dispose of,
however we might be able to make the transition period easier for users,
so I make the following proposal / suggestion:
Currently Discovery is either all v1 or all v2.
From what I can see the migration problem is with multicast.
It looks like (with some minor modifications) we can migrate an existing
Discovery v1 djinn by requiring all registrar nodes to be modified as
follows:
1. Registrars support and respond to both versions of Unicast request
protocols (v1 for migration only).
2. The Registrar only uses Multcast Announcement Protocol v2
3. The Registrar responds to both versions of Multicast Request
Protocol.
Clients and services use only one version, older existing deployments
use Discovery v1, new deployments use discovery v2.
We can branch a transition release for Registrars, including required
functionality.
Our next release can have Discovery v1 removed while the Registrar
transition branch can be maintained until everyone's environments have
been converted.
We might also be able to solve the problem using modular builds, with an
alternate discovery module.
Cheers,
Peter.
Christopher Dolan wrote:
But v2 isn't backward compatible with anything, even itself if you're missing
the META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider file. I've
tried to upgrade my djinn to v2, but it requires a flag day because any
existing v1 clients will never be able to speak to v2 servers if the clients
lack the provider file.
I think a prerequisite for deprecation of v1 would be a pragmatic migration
path to v2. With the current v2 implementation, I don't think such a migration
is possible.
Chris
-----Original Message-----
From: Dan Creswell [mailto:dan.cresw...@gmail.com]
Sent: Friday, June 10, 2011 10:47 AM
To: dev@river.apache.org
Subject: Re: Security & Re: Discovery V2 migration
Controversial position: Why don't we just deprecate the entirety of V1?
That means less work to do, no nasty dark corner workarounds as we try
and retain compatibility, a clear policy on what will work with what
etc. Fact is V2 has been around so long that most people are surely
using it by now?
I just am not a fan of backward compatibility without some very good
reasons, history shows this sort of "holding onto the past" to be a
nightmare for all concerned. One needs to look no further than the JDK
itself which is full of cruft and cut corners for the sake of
compatibility.
On 10 June 2011 08:51, Peter Firmstone <j...@zeus.net.au> wrote:
_Unicast Discovery v2 - Unmarshalling Attack with Registrar proxy._
During unicast discovery, we have the option of using SSL, Kerberos or x500
discovery implementations, unfortunately, if the unicast discovery
implementation being used doesn't comply with constraints for Authentication
and Confidentiality, the constraints are re tried against the unmarshalled
registrar proxy, bypassing the security benefits these implementations
provide.
I believe this was an oversight to allow codebase integrity constraints to
bubble up as Unfulfilled Constraints to the upper layer, where they're
checked against the unmarshalled proxy, unfortunately it appears to be a
mistake to allow Authentication and Confidentiality constraints to bubble up
during discovery.
I think we should change this specifically for Authentication and
Confidentiality constraints, if these are requested but not satisfied during
discovery we should throw an UnsupportedConstraintException.
Doing so avoids the DOS unmarshalling attack which is possible during
unmarshalling of an unauthenticated registrar proxy.
_Unicast Discovery v1_
In light of Unicast Discovery v1's total lack of support for security, I
believe we should deprecate it, for this to happen we also need to provide a
way for existing deployments to migrate.
LookupLocator performs unicast discovery v1. ConstrainableLookupLocator
extends LookupLocator and is used for v2 unicast discovery constraints.
_But what about Multicast Discovery?
_Multicast discovery produces a LookupLocator which is used by Unicast
Discovery to retrieve a registrar proxy.
_Multicast Request Protocol v1
_Please add any security concerns here.
No integrity support - how much of a problem is this?
_Multicast Request Protocol v2
_x500 integrity supported_
__Multicast Announcement Protocol v1
_Please add any security concerns here.
No integrity support, packets can be modified in transit, but this doesn't
seem to be much of a concern for announcement anyway.
_
__Multicast Announcement Protocol v2
_x500 integrity supported.
Note that Multicast v2 supports x500 integrity constraints, in addition to
plain text, while it doesn't prevent someone viewing the contents of the
packet, it ensures the packets contents haven't been tampered with.
I don't see a reason to deprecate Multicast Discovery v1 for existing
deployments, x500 integrity is an obvious advantage, but the real threat to
security occurs during Unicast Discovery, when unmarshalling attacks can
occur.
So we could, in theory at least, use a LookupLocator from Multicast v1
discovery with Unicast v2 discovery in newly deployed clients and
registrars to remain network compatible with existing clients that only
support D v1.
Figuring out how to solve the migration problem?
I think most of the migration problem exists with Multicast, so for legacy
support reasons a djinn could employ Multicast v1 with a combination of
Unicast v1 (for older clients) and v2 for the latter.
Registrar's could have providers for both v1 and v2 discovery and thus reply
to both.
This will require some revisions to discovery utilities (implementing
DiscoveryGroupManagement) for our next release, in order to provide an
upgrade path for existing djinn's.
Any ideas?
Cheers,
Peter.
*
*_
_
Hi Peter.
I don't remember enough about this to know for sure if this problem is as
stated. I thought the resources were defined in the default Jini 2.0 JAR
files, but that could have changed after my time. Mike Warres was the
initial author of this stuff, but others at Sun took over from him before
the effort stopped. I don't know if any of those guys are still following
the conversation.
- Tim
On Dec 12, 2010, at 2:31 PM, Peter Firmstone <j...@zeus.net.au> wrote:
Tim,
Do you know of an alternative plan to Chris' suggestion, for migration
from Discovery V1 to V2?
It probably all happened too long ago to remember now, just wondering if
anything comes to mind?
I'll look into it further too.
Cheers,
Peter.
Since its inception, my project has been using DiscoveryV1 and we've
never dealt with Jini constraints. Peter's comments last week about the
flexibility of DiscoveryV2 inspired me to learn more about it and to
experiment a bit. To my surprised, I found it very difficult to figure
out how to turn V2 on (I ended up reading a lot of source code), and it
looks like it's nearly impossible to migrate in a backward compatible
way, i.e. continuing to fully interact with services that were deployed
with the default preference for V1. I would LOVE to be told that I've
made a mistake or missed something important...
* To switch Reggie to use V2 for multicast announcements:
com.sun.jini.reggie {
discoveryConstraints = new BasicMethodConstraints(new
InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
}
* To switch group discovery to use V2 for multicast requests:
net.jini.discovery.LookupDiscovery {
discoveryConstraints = new BasicMethodConstraints(new
InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
}
* To create a locator that uses V2 for directed unicast discovery:
new ConstrainableLookupLocator(host, port, new
BasicMethodConstraints(new InvocationConstraints(null,
DiscoveryProtocolVersion.TWO)));
* To tell DiscoveryV2 how to encode and decode the messages, create a
file called
"META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider" and
put in lines (for example):
com.sun.jini.discovery.plaintext.Client
com.sun.jini.discovery.plaintext.Server
However (and this is the key problem), any deployed clients or Reggies
which lack the
META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider file
will not be able to decode the incoming messages and will drop them with
an error message about unknown format IDs.
So, the only solution I can see is to start shipping new services with
the DiscoveryFormatProvider file in place, and then wait several
releases until all of my old deployments have been retired, and then
turn on the V2 preference. Am I wrong? Is there a trick to get
already-deployed clients to use a format ID that they don't know about?
Surely other people have had similar problems deploying brand-new
DiscoveryFormatProvider implementations?
Is there a way to make services send out both V1 and V2 multicasts? Is
there a way to tell LookupDiscovery.UnicastDiscoveryTask to try V2 first
and then retry with V1?
I feel like I'm missing some central point...
Chris
