You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/11/07 07:56:26 UTC
Discovery - Denial of Service and DNS-SD
I've been examining the code relating to discovery, feel free to clarify
if I've missed some important detail.
River currently has two discovery protocols,
Discovery V2 and V1.
V1 dates from Jini 1.0, during the discovery process, registrar proxy's
are stored in java.rmi.MarshalledObject and transferred over the network
in serialized form.
Discovery V1 utilised MarshalledObject, I haven't figured out a way
prevent Denial of service attacks during unmarshalling of the registrar
proxy for V1.
It is important to remember there are two occasions when we're
susceptible to DOS attack, firstly during deserialization of
MarshalledObject and secondly when we unmarshal the registrar proxy from
the MarshalledObject.
The question is of course what to do with Discovery V1 going forward?
Should we deprecate it? If so, how should we ensure that V2 is used by
default. DiscoveryConstraints?
Discovery V2 (Unicast), uses MarshalledInstance serial form, there's a
lot more we can do with V2, it can utilise multiple implementations via
DiscoveryFormatProvider.
Discovery V2 supports constraints and has a number of pluggable
implementations. It has SSL and Kerberos implementations.
In LookupDiscovery, Multicast is used first to discover a registrar and
create a MulticastAnnouncement which contains the following fields:
public class MulticastAnnouncement {
/** The announcement sequence number. */
protected long sequenceNumber;
/** The lookup service host. */
protected String host;
/** The lookup service listen port. */
protected int port;
/** The lookup service member groups. */
protected String[] groups;
/** The lookup service ID. */
protected ServiceID serviceID;
The information gathered during Multicasting is then used to for Unicast
to get the Registrar proxy (from a serialized MarshalledInstance).
DNS-SD could be used to provide the same information as
MulticastAnnouncement prior to performing Unicast discovery, this will
allow services to be dynamically discovered over the internet proper.
Multicast uses datagram packets with a recommended limit of 512 bytes, I
can't think of much opportunity for an attack on the client, it's a
different story for the Join protocol and the registrar but since
multicast is only utilised on private networks this shouldn't be a
problem. DNS-SD allows a range of addresses and ports to be utilised
dynamically, multiple registrars for a group might assist to protect
against packet storms, remembering that Multicast packets can't be
utilised in a packet storm over the internet, because of TTL routers etc.
We will have to take DOS into account when designing a DNS-SD equivalent
to Multicast.
Currently Unicast can be subjected to DOS, Notice in the Discovery V2
Unicast implementation methods below, we're reading more than just the
MarshalledInstance. Since Unicast is not limited by packet size, an
attacker can feed an unending stream of bytes (very large group string
arrays etc) to protect against Denial of Service we need to run Unicast
Discovery within an Executor thread that handles StackOverflowError's,
until we can return a UnicastResponse.
Excerpt from com.sun.jini.discovery.internal.PlainText:
/**
* Reads unicast response according to the net.jini.discovery.plaintext
* format.
*/
public static UnicastResponse readUnicastResponse(
InputStream in,
ClassLoader defaultLoader,
boolean verifyCodebaseIntegrity,
ClassLoader verifierLoader,
Collection context)
throws IOException, ClassNotFoundException
{
try {
DataInput din = new DataInputStream(in);
// read LUS host
String host = din.readUTF();
// read LUS port
int port = din.readUnsignedShort();
// read LUS member groups
String[] groups = new String[din.readInt()];
for (int i = 0; i < groups.length; i++) {
groups[i] = din.readUTF();
}
// read LUS proxy
MarshalledInstance mi =
(MarshalledInstance) new ObjectInputStream(in).readObject();
/* We have the opportunity to protect against unmarshalling
* attacks, this is the place to do it.
*/
ServiceRegistrar reg = (ServiceRegistrar) mi.get(
defaultLoader,
verifyCodebaseIntegrity,
verifierLoader,
context);
return new UnicastResponse(host, port, groups, reg);
} catch (RuntimeException e) {
throw new DiscoveryProtocolException(null, e);
}
}
Excerpt from com.sun.jini.discovery.plaintext.Client:
// documentation inherited from UnicastDiscoveryClient
public UnicastResponse doUnicastDiscovery(
Socket socket,
InvocationConstraints constraints,
ClassLoader defaultLoader,
ClassLoader verifierLoader,
Collection context,
ByteBuffer sent,
ByteBuffer received)
throws IOException, ClassNotFoundException
{
Plaintext.checkConstraints(constraints);
return Plaintext.readUnicastResponse(
new BufferedInputStream(socket.getInputStream()),
defaultLoader,
false,
null,
context);
}
Excerpt from com.sun.jini.discovery.internal.EndpointBasedClient:
/**
* Provides an abstract endpoint-based UnicastDiscoveryClient
implementation,
* which serves as a superclass for client-side providers for the
* net.jini.discovery.ssl and net.jini.discovery.kerberos unicast discovery
* formats.
*/
public abstract class EndpointBasedClient
extends EndpointBasedProvider implements UnicastDiscoveryClient
{
/**
* Constructs instance with the given format name and object providing
* access to non-public endpoint operations.
*/
protected EndpointBasedClient(String formatName,
EndpointInternals endpointInternals)
{
super(formatName, endpointInternals);
}
// documentation inherited from UnicastDiscoveryClient
public void checkUnicastDiscoveryConstraints(
InvocationConstraints constraints)
throws UnsupportedConstraintException
{
if (constraints == null) {
constraints = InvocationConstraints.EMPTY;
}
ConnectionInfo ci = getConnectionInfo(null, constraints);
checkIntegrity(endpointInternals.getUnfulfilledConstraints(ci.handle));
}
// documentation inherited from UnicastDiscoveryClient
public UnicastResponse doUnicastDiscovery(
Socket socket,
InvocationConstraints constraints,
ClassLoader defaultLoader,
ClassLoader verifierLoader,
Collection context,
ByteBuffer sent,
ByteBuffer received)
throws IOException, ClassNotFoundException
{
if (socket == null || sent == null || received == null) {
throw new NullPointerException();
}
if (constraints == null) {
constraints = InvocationConstraints.EMPTY;
}
ConnectionInfo ci = getConnectionInfo(socket, constraints);
Connection conn = ci.endpoint.connect(ci.handle);
try {
boolean integrity =
checkIntegrity(conn.getUnfulfilledConstraints(ci.handle));
OutputStream out =
new BufferedOutputStream(conn.getOutputStream());
conn.writeRequestData(ci.handle, out);
out.write(calcHandshakeHash(sent, received));
out.flush();
InputStream in = new BufferedInputStream(conn.getInputStream());
IOException e = conn.readResponseData(ci.handle, in);
if (e != null) {
throw e;
}
return Plaintext.readUnicastResponse(
in, defaultLoader, integrity, verifierLoader, context);
} finally {
conn.close();
}
}
It looks as though Kerberos and SSL Discovery provides guarantees for
integrity and authentication. So is MarshalledInstance really subject
to DOS attacks during unmarshalling in this case? Can we use DNS-SD
with Secure protocols? For the registrar proxy, it would seem that it
isn't subject to DOS attacks if Kerberos or SSL Discovery is used.
However if we're using the Registrar to lookup other services, we might
not have the same trust relationship with them as we do the Registrar,
so in that case it justifies requiring a service authenticate prior to
unmarshalling it's proxy from MarshalledInstance.
There also seems to be a case still for Codebase services, we can
determine codebase service trust prior to downloading a codebase from
it. This wouldn't prevent Maven from being utilised for codebase
provisioning, although we still need to determine a suitable way to
utilise Maven.
If we're using Kerberos and SSL discovery, from the Jini Discovery and
Join Specification:
The net.jini.discovery.ssl Format
The net.jini.discovery.ssl format specifies an encoding in which unicast
response data is sent across a TLS/SSL (Transport Layer Security/Secure
Socket Layer) connection. Encryption, authentication, and/or integrity
protection may be provided by the underlying TLS/SSL connection,
depending on the selected cipher suite. This discovery format does not
apply to multicast requests or announcements. The discovery format ID
for this format is 1816474798606646324. TLS/SSL is specified in /RFC
2246 <http://tools.ietf.org/html/rfc2246>/.
Unicast Responses
In the net.jini.discovery.ssl format, transmission of unicast response
data involves three steps:
1. The discovering entity establishes a TLS/SSL connection between
itself and the lookup service on top of the TCP connection over
which it sent the unicast request.
2. The discovering entity transmits a hash of all of the data it has
sent and received over the connection so far.
3. The lookup service also computes a hash of all of the data it has
received and sent over the connection so far. If this hash value
matches that sent by the discovering entity, then the lookup
service sends the unicast response data encoded as described later
in this section. If the hash does not match, the lookup service
terminates the connection.
The hash sent by the discovering entity to the lookup service is
computed as follows: first, a sequence of bytes is assembled consisting
of the entire unicast request immediately followed by the portion of the
unicast response that is not discovery format data--the initial protocol
version followed by the selected format ID, as specified in Section
DJ.2.6.7, "Protocol Version 2 Response Format"
<http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#Protocol_Version_2_Response_Format>.
This sequence of bytes is then used as input to the SHA-1 hash function;
the 160-bit result is sent in its entirety in big-endian order as the
hash value. The SHA-1 hash function is specified in /Federal Information
Processing Standards Publication (FIPS PUB) 180-1/.
The unicast response data sent by the lookup service, if the hashes
match, consists of the following values encoded (on top of the secured
TLS/SSL connection) according to the net.jini.discovery.plaintext
discovery format for unicast responses, specified in Section DJ.3.1.3
<http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#Unicast_Responses>:
* Unicast discovery host
* Unicast discovery port
* Member groups
* Registrar proxy
The net.jini.discovery.kerberos Format
The net.jini.discovery.kerberos format specifies an encoding in which
unicast response data is sent across a connection secured using the
Kerberos Version 5 GSS-API Mechanism, defined in /RFC 1964
<http://tools.ietf.org/html/rfc1964>/. Kerberos provides authentication;
encryption and integrity protection of the transmitted data may also be
provided depending on the GSS-API context in use for the connection.
This discovery format does not apply to multicast requests or
announcements. The discovery format ID for this format is
5724038453852586603. The Kerberos network authentication protocol is
defined in /RFC 1510 <http://tools.ietf.org/html/rfc1510>/; the GSS-API
is defined in /RFC 2743 <http://tools.ietf.org/html/rfc2743>/.
Unicast Responses
Transmission of unicast response data in the net.jini.discovery.kerberos
discovery format is similar to the net.jini.discovery.ssl format, except
that the underlying connection is secured using the Kerberos Version 5
GSS-API Mechanism instead of TLS/SSL:
1. The discovering entity establishes a GSS-API context for
communicating with the lookup service, whose Kerberos principal it
knows in advance. It then uses GSS-API tokens obtained from the
established context to wrap all subsequent data sent to the lookup
service (over the TCP connection on which the unicast request was
originally transmitted). Also, all data subsequently received over
the connection is unwrapped using the GSS-API.
2. The discovering entity transmits a hash of all of the data it has
sent and received over the connection so far. Multiple GSS-API
tokens may be used to convey the hash. The hash is computed as
specified in Section DJ.3.4.1
<http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#Unicast_Responses_2>
3. The lookup service also computes a hash of all of the data it has
received and sent over the connection so far. If this hash value
matches that sent by the discovering entity, then the lookup
service sends the unicast response data, encoded as specified in
Section DJ.3.4.1
<http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#Unicast_Responses_2>,
over the TCP connection to the discovering entity, using GSS-API
tokens as described in step 1. Multiple GSS-API tokens may be used
to convey the unicast response data.
Cheers,
Peter.
Re: Discovery - DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
For the keen eye:
Any constraints created would be client constraints, so in this case you
would be authenticating the server, this would be the minimum principal.
LookupLocator locator =
llb.host(name).port(port).authenticate(principal).confidentiality(true).build();
Peter Firmstone wrote:
> N.B. The original implementation of LookupLocator only performs
> Unicast Discovery V1, it cannot be changed because of a static final
> field for the protocol version.
>
> We could create a builder, perhaps called LookupLocatorBuilder, which
> returns ConstrainableLookupLocator if security is desired.
>
> This could also build all the necessary constraints.
>
> LookupLocatorBuilder llb = new LookupLocatorBuilder();
> LookupLocator locator =
> llb.host(name).port(4062).authenticate(true).confidentiality(true).build();
>
>
> Cheers,
>
> Peter.
>
> Peter Firmstone wrote:
>> Hi Gregg,
>>
>> You can use an instance of ConstrainableLookupLocator to perform
>> Unicast V2 discovery, it is also an instance of LookupLocator.
>>
>> Discovery V2 also supports Kerberos and SSL, Discovery V1 has no
>> security.
>>
>> Discovery V1 uses MarshalledObject serial form to transfer the
>> Registrar proxy, Discovery V2, uses MarshalledInstance.
>>
>> I'm currently investigating methods of preventing the deserialization
>> and unmarshalling attacks during discovery, Discovery V1 cannot be
>> fixed (MarshalledObject related) however Discovery V2 can be.
>>
>> Regards,
>>
>> Peter.
>>
>> Gregg Wonderly wrote:
>>> I use LookupLocator as a basic form of service end point
>>> description. Many of my deployments are across non broadcast
>>> networks and I must use unicast lookup via LookupLocator.
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 9, 2010, at 1:25 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>>
>>>
>>>> Sim IJskes - QCG wrote:
>>>>
>>>>> On 09-11-10 12:53, Peter Firmstone wrote:
>>>>>
>>>>>> LookupLocator is used by LookupLocatorDiscovery as little more
>>>>>> than a
>>>>>> String URL parser, to store the host and port information.
>>>>>>
>>>>> Could you also have a look at LookupLocator. I was looking for the
>>>>> methods usage for the methods you deprecated, but couldn't find
>>>>> any reference. Is it still a functional part of code?
>>>>>
>>>>> Gr. Sim
>>>>>
>>>>>
>>>> ConstrainableLookupLocator overrides the methods and performs
>>>> Discovery V2, so I decided to simply add some more javadoc and
>>>> relevant references to clear up any confusion instead.
>>>>
>>>
>>>
>>
>>
>
>
Re: Discovery - DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
N.B. The original implementation of LookupLocator only performs Unicast
Discovery V1, it cannot be changed because of a static final field for
the protocol version.
We could create a builder, perhaps called LookupLocatorBuilder, which
returns ConstrainableLookupLocator if security is desired.
This could also build all the necessary constraints.
LookupLocatorBuilder llb = new LookupLocatorBuilder();
LookupLocator locator =
llb.host(name).port(4062).authenticate(true).confidentiality(true).build();
Cheers,
Peter.
Peter Firmstone wrote:
> Hi Gregg,
>
> You can use an instance of ConstrainableLookupLocator to perform
> Unicast V2 discovery, it is also an instance of LookupLocator.
>
> Discovery V2 also supports Kerberos and SSL, Discovery V1 has no
> security.
>
> Discovery V1 uses MarshalledObject serial form to transfer the
> Registrar proxy, Discovery V2, uses MarshalledInstance.
>
> I'm currently investigating methods of preventing the deserialization
> and unmarshalling attacks during discovery, Discovery V1 cannot be
> fixed (MarshalledObject related) however Discovery V2 can be.
>
> Regards,
>
> Peter.
>
> Gregg Wonderly wrote:
>> I use LookupLocator as a basic form of service end point
>> description. Many of my deployments are across non broadcast
>> networks and I must use unicast lookup via LookupLocator.
>>
>> Sent from my iPhone
>>
>> On Nov 9, 2010, at 1:25 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>
>>
>>> Sim IJskes - QCG wrote:
>>>
>>>> On 09-11-10 12:53, Peter Firmstone wrote:
>>>>
>>>>> LookupLocator is used by LookupLocatorDiscovery as little more than a
>>>>> String URL parser, to store the host and port information.
>>>>>
>>>> Could you also have a look at LookupLocator. I was looking for the
>>>> methods usage for the methods you deprecated, but couldn't find any
>>>> reference. Is it still a functional part of code?
>>>>
>>>> Gr. Sim
>>>>
>>>>
>>> ConstrainableLookupLocator overrides the methods and performs
>>> Discovery V2, so I decided to simply add some more javadoc and
>>> relevant references to clear up any confusion instead.
>>>
>>
>>
>
>
Re: Discovery - DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Gregg,
You can use an instance of ConstrainableLookupLocator to perform Unicast
V2 discovery, it is also an instance of LookupLocator.
Discovery V2 also supports Kerberos and SSL, Discovery V1 has no security.
Discovery V1 uses MarshalledObject serial form to transfer the Registrar
proxy, Discovery V2, uses MarshalledInstance.
I'm currently investigating methods of preventing the deserialization
and unmarshalling attacks during discovery, Discovery V1 cannot be fixed
(MarshalledObject related) however Discovery V2 can be.
Regards,
Peter.
Gregg Wonderly wrote:
> I use LookupLocator as a basic form of service end point description. Many of my deployments are across non broadcast networks and I must use unicast lookup via LookupLocator.
>
> Sent from my iPhone
>
> On Nov 9, 2010, at 1:25 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>
>> Sim IJskes - QCG wrote:
>>
>>> On 09-11-10 12:53, Peter Firmstone wrote:
>>>
>>>> LookupLocator is used by LookupLocatorDiscovery as little more than a
>>>> String URL parser, to store the host and port information.
>>>>
>>> Could you also have a look at LookupLocator. I was looking for the methods usage for the methods you deprecated, but couldn't find any reference. Is it still a functional part of code?
>>>
>>> Gr. Sim
>>>
>>>
>> ConstrainableLookupLocator overrides the methods and performs Discovery V2, so I decided to simply add some more javadoc and relevant references to clear up any confusion instead.
>>
>
>
Re: Discovery - DNS-SD
Posted by Gregg Wonderly <gr...@wonderly.org>.
I use LookupLocator as a basic form of service end point description. Many of my deployments are across non broadcast networks and I must use unicast lookup via LookupLocator.
Sent from my iPhone
On Nov 9, 2010, at 1:25 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Sim IJskes - QCG wrote:
>> On 09-11-10 12:53, Peter Firmstone wrote:
>>> LookupLocator is used by LookupLocatorDiscovery as little more than a
>>> String URL parser, to store the host and port information.
>>
>> Could you also have a look at LookupLocator. I was looking for the methods usage for the methods you deprecated, but couldn't find any reference. Is it still a functional part of code?
>>
>> Gr. Sim
>>
> ConstrainableLookupLocator overrides the methods and performs Discovery V2, so I decided to simply add some more javadoc and relevant references to clear up any confusion instead.
Re: Discovery - DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 09-11-10 12:53, Peter Firmstone wrote:
>> LookupLocator is used by LookupLocatorDiscovery as little more than a
>> String URL parser, to store the host and port information.
>
> Could you also have a look at LookupLocator. I was looking for the
> methods usage for the methods you deprecated, but couldn't find any
> reference. Is it still a functional part of code?
>
> Gr. Sim
>
ConstrainableLookupLocator overrides the methods and performs Discovery
V2, so I decided to simply add some more javadoc and relevant references
to clear up any confusion instead.
Re: Discovery - DNS-SD
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09-11-10 12:53, Peter Firmstone wrote:
> LookupLocator is used by LookupLocatorDiscovery as little more than a
> String URL parser, to store the host and port information.
Could you also have a look at LookupLocator. I was looking for the
methods usage for the methods you deprecated, but couldn't find any
reference. Is it still a functional part of code?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Peter Firmstone wrote:
>> Peter Firmstone wrote:
>>> Sim IJskes - QCG wrote:
>>>> On 11/08/2010 12:39 PM, Peter Firmstone wrote:
>>>>
>>>>> Seeing as we're not interested in Multicast DNS, we're probably
>>>>> better
>>>>> off utilising Waiter's source and integrating only the
>>>>> functionality we
>>>>> need into River. I'll ask the original author if he's happy to donate
>>>>> some code.
>>>>
>>>> Or http://www.dnsjava.org/, BSD license, recently updated project.
>>>> Used by james.
>>>>
>>>> Gr. Sim
>>>>
>>>>
>>> Much better, we don't need to maintain it and can distribute it with
>>> river as a library.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>> Rather than use jini as the service type, which has already been
>> defined by Daniel Steinberg for any arbitrary Jini service, do you
>> think we should use jini-discovery as per IANA's service type
>> definition?
>>
>> jini-discovery 4160/tcp Jini Discovery
>> jini-discovery 4160/udp Jini Discovery
>> # Mark Hodapp <mark.hodapp&sun.com>
>>
>>
>> DNS-SRV service type:
>>
>> jini-discovery
>>
>> http://www.dns-sd.org/ServiceTypes.html
>>
> Meaning that in the internet, any port can be used for discovery,
> provided that the "jini-discovery" DNS-SRV service type is used in DNS
> records.
>
> Thoughts?
>
> Peter.
>
LookupLocator is used by LookupLocatorDiscovery as little more than a
String URL parser, to store the host and port information.
ConstrainableLookupLocator extends LookupLocator to support Discovery V2.
For DNS-SRV we could have a utility that searches DNS-SRV records and
creates ConstrainableLookupLocator instances for each record. We'd have
to specify constraints for the utility to set.
Currently the Discovery and Join spec requires a jini://host:port/ or
jini://host/ syntax for URI's, if no port is specified, the default is used.
Cheers,
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Peter Firmstone wrote:
>> Sim IJskes - QCG wrote:
>>> On 11/08/2010 12:39 PM, Peter Firmstone wrote:
>>>
>>>> Seeing as we're not interested in Multicast DNS, we're probably better
>>>> off utilising Waiter's source and integrating only the
>>>> functionality we
>>>> need into River. I'll ask the original author if he's happy to donate
>>>> some code.
>>>
>>> Or http://www.dnsjava.org/, BSD license, recently updated project.
>>> Used by james.
>>>
>>> Gr. Sim
>>>
>>>
>> Much better, we don't need to maintain it and can distribute it with
>> river as a library.
>>
>> Cheers,
>>
>> Peter.
>>
> Rather than use jini as the service type, which has already been
> defined by Daniel Steinberg for any arbitrary Jini service, do you
> think we should use jini-discovery as per IANA's service type definition?
>
> jini-discovery 4160/tcp Jini Discovery
> jini-discovery 4160/udp Jini Discovery
> # Mark Hodapp <mark.hodapp&sun.com>
>
>
>
> DNS-SRV service type:
>
> jini-discovery
>
> http://www.dns-sd.org/ServiceTypes.html
>
Meaning that in the internet, any port can be used for discovery,
provided that the "jini-discovery" DNS-SRV service type is used in DNS
records.
Thoughts?
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Sim IJskes - QCG wrote:
>> On 11/08/2010 12:39 PM, Peter Firmstone wrote:
>>
>>> Seeing as we're not interested in Multicast DNS, we're probably better
>>> off utilising Waiter's source and integrating only the functionality we
>>> need into River. I'll ask the original author if he's happy to donate
>>> some code.
>>
>> Or http://www.dnsjava.org/, BSD license, recently updated project.
>> Used by james.
>>
>> Gr. Sim
>>
>>
> Much better, we don't need to maintain it and can distribute it with
> river as a library.
>
> Cheers,
>
> Peter.
>
Rather than use jini as the service type, which has already been defined
by Daniel Steinberg for any arbitrary Jini service, do you think we
should use jini-discovery as per IANA's service type definition?
jini-discovery 4160/tcp Jini Discovery
jini-discovery 4160/udp Jini Discovery
# Mark Hodapp <mark.hodapp&sun.com>
DNS-SRV service type:
jini-discovery
http://www.dns-sd.org/ServiceTypes.html
Cheers,
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 11/08/2010 12:39 PM, Peter Firmstone wrote:
>
>> Seeing as we're not interested in Multicast DNS, we're probably better
>> off utilising Waiter's source and integrating only the functionality we
>> need into River. I'll ask the original author if he's happy to donate
>> some code.
>
> Or http://www.dnsjava.org/, BSD license, recently updated project.
> Used by james.
>
> Gr. Sim
>
>
Much better, we don't need to maintain it and can distribute it with
river as a library.
Cheers,
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/08/2010 12:39 PM, Peter Firmstone wrote:
> Seeing as we're not interested in Multicast DNS, we're probably better
> off utilising Waiter's source and integrating only the functionality we
> need into River. I'll ask the original author if he's happy to donate
> some code.
Or http://www.dnsjava.org/, BSD license, recently updated project. Used
by james.
Gr. Sim
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 11/08/2010 12:54 AM, Peter Firmstone wrote:
>> TXT keys:
>>
>> txtvers=<8 bit byte version number of the DNS-SD TXT record format>
>> dpv=<8bit byte discovery protocol version number>
>> sid=<128bit hash code service ID>
>> grp=<comma separated list of group names to which the service belongs>
>
> DNS is mostly managed by people other than programmers. DNS managing
> departments are not eager to provide DDNS access to their zone.
>
> So, should we limit the SRV records info to only point at an IP +
> port, similar to the jini: url used in LookupLocator?
>
> You can have the department responsible for the zone maint, create a
> SRV record once, and you can be as dynamic as you like with the
> registries under your own deployment control.
>
> Gr. Sim
>
That's seems a fair assumption, it would make development simpler to
begin with, if we want to, we can add text key's later.
We have a number of choices of existing software, but if we pick from
two Java based software stacks, there is jmdns and waiter.
Jmdns is currently developed but doesn't have much in the way of unit tests.
Waiter hasn't been actively developed in two years, however it has
comprehensive unit tests.
Both are Apache 2 Licensed projects.
Seeing as we're not interested in Multicast DNS, we're probably better
off utilising Waiter's source and integrating only the functionality we
need into River. I'll ask the original author if he's happy to donate
some code.
Regards,
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/08/2010 12:54 AM, Peter Firmstone wrote:
> TXT keys:
>
> txtvers=<8 bit byte version number of the DNS-SD TXT record format>
> dpv=<8bit byte discovery protocol version number>
> sid=<128bit hash code service ID>
> grp=<comma separated list of group names to which the service belongs>
DNS is mostly managed by people other than programmers. DNS managing
departments are not eager to provide DDNS access to their zone.
So, should we limit the SRV records info to only point at an IP + port,
similar to the jini: url used in LookupLocator?
You can have the department responsible for the zone maint, create a SRV
record once, and you can be as dynamic as you like with the registries
under your own deployment control.
Gr. Sim
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 11/07/2010 10:10 PM, Peter Firmstone wrote:
>> The reason to avoid V1, is mostly due to it's unicast implementation, it
>> has no privacy integrity or authentication ability and uses
>> MarshalledObject's serialized form, over which we have no control.
>
> I was talking non-sense. V1 has an array as well. I'm talking about
> the "Protocol Version 1 Announcement Packet Format", if we insert DNS
> data in the same place as this packet, would the discovery stay V1, or
> will it upgrade to V2?
>
> Gr. Sim
>
>
The discovery protocol is relevant to unicast, so perhaps we should
specify it too.
TXT keys:
txtvers=<8 bit byte version number of the DNS-SD TXT record format>
dpv=<8bit byte discovery protocol version number>
sid=<128bit hash code service ID>
grp=<comma separated list of group names to which the service belongs>
Cheers,
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/07/2010 10:10 PM, Peter Firmstone wrote:
> The reason to avoid V1, is mostly due to it's unicast implementation, it
> has no privacy integrity or authentication ability and uses
> MarshalledObject's serialized form, over which we have no control.
I was talking non-sense. V1 has an array as well. I'm talking about the
"Protocol Version 1 Announcement Packet Format", if we insert DNS data
in the same place as this packet, would the discovery stay V1, or will
it upgrade to V2?
Gr. Sim
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 11/07/2010 09:12 PM, Peter Firmstone wrote:
>>> Cutting too much corners here? If not, shall we add this to the wiki?
>> In the same sense as a Discovery V2 datagram packet, I would strongly
>> discourage the use of Discovery V1.
>
> Because you want to phaseout V1 i guess? Can we ever?
>
>> The the DNS-SD registry is only for lookup services, ServiceRegistrar in
>> this case.
>>
>> Yes we do need to document it, perhaps as a draft spec, in the wiki?
>
> http://wiki.apache.org/river/InternetJini ?
>
> V2 countains more data than V1, including an unlimited array. Any idea
> how to format this in SRV records?
>
> Gr. Sim
>
>
TXT keys:
sid=<128bit hash code service ID>
grp=<comma separated list of group names to which the service belongs>
alternative:
grp=<space delimited list of group names to which the service belongs>
We might consider creating a new spec specific to DNS-SD, to account for
it's limitations, with information required to perform Unicast Discovery V2.
Obviously the number of groups a registrar can join is limited by the
TXT fields which, is recommended to be limited between 200 to 400 bytes,
in extreme cases, up to 1,300 bytes is the practical limit, limited by a
1,500 byte Ethernet packet.
The reason to avoid V1, is mostly due to it's unicast implementation, it
has no privacy integrity or authentication ability and uses
MarshalledObject's serialized form, over which we have no control.
We may also consider an additional separate format for implementing a
dynamic addressable Endpoint for services (not used for Discovery),
perhaps with only a single txt key:
TXT keys:
sid=<128bit hash code service ID>
Cheers,
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/07/2010 09:12 PM, Peter Firmstone wrote:
>> Cutting too much corners here? If not, shall we add this to the wiki?
> In the same sense as a Discovery V2 datagram packet, I would strongly
> discourage the use of Discovery V1.
Because you want to phaseout V1 i guess? Can we ever?
> The the DNS-SD registry is only for lookup services, ServiceRegistrar in
> this case.
>
> Yes we do need to document it, perhaps as a draft spec, in the wiki?
http://wiki.apache.org/river/InternetJini ?
V2 countains more data than V1, including an unlimited array. Any idea
how to format this in SRV records?
Gr. Sim
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 11/07/2010 08:47 PM, Peter Firmstone wrote:
>> Now I'm wondering if the same thing can be done for groups using DNS-SD
>> & DDNS?
>>
>> To have several domains participating in a group, a helper utility,
>> searches DNS-SD records for jini with that group, if clients and
>> registrar's can authenticate each other, belonging to that group, then
>> we have a dynamic djinn group that exists on the internet.
>
> So we have a registry implemented with DNS-SD and DDNS.
>
> A starting participant is configured with a URL pointing to the name
> of the SRV record. It queries DNS for this SRV record, and uses the
> result in the same sense as a received V1 discovery packet.
>
> Cutting too much corners here? If not, shall we add this to the wiki?
>
> Gr. Sim
>
In the same sense as a Discovery V2 datagram packet, I would strongly
discourage the use of Discovery V1.
The the DNS-SD registry is only for lookup services, ServiceRegistrar in
this case.
Yes we do need to document it, perhaps as a draft spec, in the wiki?
Cheers,
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/07/2010 08:47 PM, Peter Firmstone wrote:
> Now I'm wondering if the same thing can be done for groups using DNS-SD
> & DDNS?
>
> To have several domains participating in a group, a helper utility,
> searches DNS-SD records for jini with that group, if clients and
> registrar's can authenticate each other, belonging to that group, then
> we have a dynamic djinn group that exists on the internet.
So we have a registry implemented with DNS-SD and DDNS.
A starting participant is configured with a URL pointing to the name of
the SRV record. It queries DNS for this SRV record, and uses the result
in the same sense as a received V1 discovery packet.
Cutting too much corners here? If not, shall we add this to the wiki?
Gr. Sim
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 11/07/2010 12:31 PM, Peter Firmstone wrote:
>> Sim IJskes - QCG wrote:
>>> On 11/07/2010 07:56 AM, Peter Firmstone wrote:
>>>> I've been examining the code relating to discovery, feel free to
>>>> clarify
>>>> if I've missed some important detail.
>>>>
>>>> River currently has two discovery protocols,
>>>
>>> I assuming you talk about internet deployment here. Assuming the
>>> lowest common denominator here, there is no broadcast on the internet.
>>
>> Exactly, which is why DNS-SD is attractive (not to be confused with
>> Multicast DNS), making it possible to discover registrar's in different
>> domains.
>
> Indeed. What your are talking about is a other kind of registry. The
> combination of DDNS & DNS-SD.
Yes that's true.
>
>> DNS-SD can assist us to discover unknown registrars. DNS-SD would be
>> used to first discover the host address, port, groups and Service ID of
>> registrars, then we can use Unicast Discovery to retrieve the lookup
>> service proxy.
>
> Once you know the ip+port (because you have the queried the dns) you
> can construct a proxy of a registrar, can you? No need to do unicast
> discovery anymore. Wrong or right?
Wrong, we still need unicast discovery, we can only store a limited
amount of information with DNS-SD, similar to what can be stored in a
single datagram packet. Unicast is needed to retrieve the proxy.
>
>> Intranet today:
>>
>> 1. Multicast Discovery
>
>>
>> The Internet Tomorrow:
>>
>> 1. DNS-SD
>
> Ok. You did not specify DDNS here, but you meant to include it. Correct?
Correct.
>
>>> So in order to participate in a specific djinn, you need a
>>> pre-specified registry.
>>
>> This is currently the situation.
>
> Are you sure? You can currently discover a registry without specifing
> a hostname (other then localhost) can you?
>
>>>
>>> Do you still need discovery in this situation?
>>
>> No you don't need discovery if you already know your registrar. But it's
>> no longer dynamic either.
Actually this requires a qualification, you no longer require multicast
discovery if you already know where your registrar is, but you still
need unicast discovery to retrieve the proxy, so you still need
discovery, but it lacks the dynamic multicast component. Must have been
tired when I answered it last night.
>
> I'm not fully with you here, the dynamic nature of it, is implemented
> in DDNS isnt it?
>
> My general sense of your proposal is dynamic discovery by the use of
> DNS-SD + DDNS, and after this another step of discovery. I cannot
> place this second step.
The second step is Unicast Discovery (V2) as is currently utilised in River.
DNS-SD + DDNS performs dynamic discovery, to discover the following
information:
/** The lookup service host. */
protected String host;
/** The lookup service listen port. */
protected int port;
/** The lookup service member groups. */
protected String[] groups;
/** The lookup service ID. */
protected ServiceID serviceID;
As currently implemented, Multicast Discovery (V2) is used to discover
this information on an intranet, it is stored in a MulticastAnnouncement
object and used in Unicast discovery to retrieve the registrar proxy.
LookupDiscovery contains DecodeAnnouncementTask, which takes a datagram
packet, creates a MulticastAnnouncement, then uses Unicast to retrieve
the registrar proxy. DecodeAnnouncmentTask's are submitted to a
TaskManager.
From LookupDiscovery's documentation:
* This class is a helper utility class that encapsulates the functionality
* required of an entity that wishes to employ multicast discovery to
* find lookup services located within the entity's "multicast radius"
* (roughly, the number of hops beyond which neither the multicast requests
* from the entity, nor the multicast announcements from the lookup service,
* will propagate). This class helps make the process of acquiring
references
* to lookup services - based on no information other than lookup service
* group membership - much simpler for both services and clients.
Now I'm wondering if the same thing can be done for groups using DNS-SD
& DDNS?
To have several domains participating in a group, a helper utility,
searches DNS-SD records for jini with that group, if clients and
registrar's can authenticate each other, belonging to that group, then
we have a dynamic djinn group that exists on the internet.
An interested user might initially browse groups looking for something
of interest, then dynamically discover all the registrar's in that
group, followed by actual service discovery, filtering by entry, then
performing some more specific local filtering with entry's (with delayed
unmarshalling), followed by unmarshalling a registrar proxy and using it
via a Service UI.
Seems a very powerful concept.
Cheers,
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/07/2010 12:31 PM, Peter Firmstone wrote:
> Sim IJskes - QCG wrote:
>> On 11/07/2010 07:56 AM, Peter Firmstone wrote:
>>> I've been examining the code relating to discovery, feel free to clarify
>>> if I've missed some important detail.
>>>
>>> River currently has two discovery protocols,
>>
>> I assuming you talk about internet deployment here. Assuming the
>> lowest common denominator here, there is no broadcast on the internet.
>
> Exactly, which is why DNS-SD is attractive (not to be confused with
> Multicast DNS), making it possible to discover registrar's in different
> domains.
Indeed. What your are talking about is a other kind of registry. The
combination of DDNS & DNS-SD.
> DNS-SD can assist us to discover unknown registrars. DNS-SD would be
> used to first discover the host address, port, groups and Service ID of
> registrars, then we can use Unicast Discovery to retrieve the lookup
> service proxy.
Once you know the ip+port (because you have the queried the dns) you can
construct a proxy of a registrar, can you? No need to do unicast
discovery anymore. Wrong or right?
> Intranet today:
>
> 1. Multicast Discovery
>
> The Internet Tomorrow:
>
> 1. DNS-SD
Ok. You did not specify DDNS here, but you meant to include it. Correct?
>> So in order to participate in a specific djinn, you need a
>> pre-specified registry.
>
> This is currently the situation.
Are you sure? You can currently discover a registry without specifing a
hostname (other then localhost) can you?
>>
>> Do you still need discovery in this situation?
>
> No you don't need discovery if you already know your registrar. But it's
> no longer dynamic either.
I'm not fully with you here, the dynamic nature of it, is implemented in
DDNS isnt it?
My general sense of your proposal is dynamic discovery by the use of
DNS-SD + DDNS, and after this another step of discovery. I cannot place
this second step.
Gr. Sim
Re: Discovery - Denial of Service and DNS-SD
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 11/07/2010 07:56 AM, Peter Firmstone wrote:
>> I've been examining the code relating to discovery, feel free to clarify
>> if I've missed some important detail.
>>
>> River currently has two discovery protocols,
>
> I assuming you talk about internet deployment here. Assuming the
> lowest common denominator here, there is no broadcast on the internet.
Exactly, which is why DNS-SD is attractive (not to be confused with
Multicast DNS), making it possible to discover registrar's in different
domains.
DNS-SD can assist us to discover unknown registrars. DNS-SD would be
used to first discover the host address, port, groups and Service ID of
registrars, then we can use Unicast Discovery to retrieve the lookup
service proxy.
This would be as dynamic on the internet as Multicast Discovery is on
the Intranet today.
Intranet today:
1. Multicast Discovery
2. Using the result from multicast, use unicast to get the registrar
proxy.
The Internet Tomorrow:
1. DNS-SD
2. Using the result from DNS-SD, use unicast to get the registrar proxy.
DNS-SD is something relatively new, which will require support from Bind
etc.
> So in order to participate in a specific djinn, you need a
> pre-specified registry.
This is currently the situation.
>
> Do you still need discovery in this situation?
No you don't need discovery if you already know your registrar. But
it's no longer dynamic either.
Cheers,
Peter.
Re: Discovery - Denial of Service and DNS-SD
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/07/2010 07:56 AM, Peter Firmstone wrote:
> I've been examining the code relating to discovery, feel free to clarify
> if I've missed some important detail.
>
> River currently has two discovery protocols,
I assuming you talk about internet deployment here. Assuming the lowest
common denominator here, there is no broadcast on the internet. So in
order to participate in a specific djinn, you need a pre-specified registry.
Do you still need discovery in this situation?
Gr. Sim