Hi Stefan
Thanks for writing here about this area of concern.
To fully understand Multicast and its risks as well as possible ways
around narrowing the pipe (so to speak) of the possible threats, this is
a good paper to read
http://www.sans.org/reading_room/whitepapers/networkdevs/ipv4_multicast_security_a_network_perspective_246
Multicast messaging can be hardened to be limited to specific ports,
switches, and routers within a subnet. We use it in clustering for the
obvious advantages of lower network packets and since none of the
cluster instances are expected to be exposed to external networks (as
you would front it with a LB tier in a DMZ), the probability of exposing
the cluster to packet flooding is narrowed significantly - coupled with
network level security to protect against internal attacks (not within
GlassFish security scope but larger system-wide scope), one can in fact
deploy GlassFish clustering in a multicast enabled network. Even with
non-multicast, purely point-to-point networks, one can bring down
systems through SYN flood attacks or other means, so one is not immune
to security risks in internal networks - albeit multicast can
potentially make it a lot easier to attack . GlassFish/Shoal is not the
first clustering technology to employ multicast - take WebLogic,
WebSphere, JBossCache, Coherence, et al
There are significant scaling disadvantages when you use unicast-only
connections for all cluster messaging since you have each instance
maintaining n*(n-1) unidirectional connections with other instances that
each take CPU cycles and add to network I/O in addition to adding more
work to the thread scheduler in the JVM in a high load environment all
of which can result in higher bandwidth consumption and lower overall
performance. i.e unless you are in a high throughput network environment
such as a gigabit or infiniband network coupled with high performance
hardware. If your customer is not deploying in a high load environment,
point-to-point based clustering may work fine.
Notwithstanding the above, we do have an unsupported undocumented
configuration setting in v2.1.1 that allows clustering to go through
non-multicast environments. These do not require a predetermined list of
host addresses but need one of the instances (typically but not
specifically, the DAS server ) to be designated as a virtual multicast
router. Note that this has not been extensively tested, certified for
support, and also poses a single point of failure in that when this
routing instance crashes, we do not yet have support for a failover
virtual routing instance so clustering is lost and and consequently
replication is affected to a certain extent (replication uses
bidirectional point to point connections).
If you are interested in the above configuration, please let us know - I
will contact you offline for instructions. If you or your customer are
a Sun support customer, we may be able to prioritize more to help take
this further in terms of failover virtual router capability. We currentl
plan to have that capability in GlassFish's next v3.1 release.
hth
Shreedhar
Stefan Müller-Wilken wrote:
> Dear all,
>
> a customer of mine has strictly forbidden multicast traffic in their networks for security reasons which breaks Shoal clustering.
>
> Is there a means to still allow Glassfish cluster nodes to find each other? Can I help GMS with a list of well known node IP addresses to circumvent the limitation?
>
> Apart from that: how real is the security threat? It would be a pitty if Glassfish based its clustering solely on a mechanism that companies will switch off sooner or later...
>
> Cheers
> Stefan.
>
> Acando GmbH
> Geschäftsführer: Michael Mörchen
> Amtsgericht Hamburg, HRB 76048
> Ust.Ident-Nr.:DE208833022
>
> Haftungsausschluss: Diese Nachricht ist ausschließlich für die Person oder Einheit bestimmt, an die sie gerichtet ist. Sie enthält unter Umständen Informationen, die unter geltendem Recht vertraulich, gesetzlich geschützt oder von der Offenlegung ausgeschlossen sind. Falls Sie nicht der vorgesehene Empfänger oder verantwortlich für die Weiterleitung dieser Nachricht an den vorgesehenen Empfänger sind, ist es Ihnen strengstens untersagt, diese Nachricht offenzulegen, zu verteilen, zu kopieren oder in irgendeiner Art zu benutzen. Sollten Sie diese Nachricht versehentlich erhalten haben, benachrichtigen Sie bitte den Absender und löschen und vernichten Sie jegliche Kopie davon, die Sie möglicherweise erhalten haben.
>
> Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>