Okay, so what is a pragmatic migration then? That tells us something about potential solutions. Although there probably isn't one if we're saying we can't ever disrupt clients....
On 10 June 2011 18:28, Christopher Dolan <christopher.do...@avid.com> 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 >> >> >> >
