Partager via

  • Article

Working with Multicast

Microsoft Silverlight will reach end of support after October 2021. Learn more.

The System.Net.Sockets namespace in Silverlight 4 has added support for UDP multicast clients. A component of the core IP protocols, IP multicast provides a support for one-to-many communication over an IP infrastructure. IP multicast has the ability to scale to a larger population of receivers. It is an efficient way for forwarding IP datagrams to a group of interested listeners or receivers. Multicast uses network infrastructure efficiently by requiring the source to send a packet only once, even if it needs to be delivered to a large number of receivers. The nodes in the network take care of replicating the packet to reach multiple receivers only when necessary. The most common low-level protocol used for IP multicast is User Datagram Protocol (UDP).

There are certain applications where the use of IP multicast provides a more efficient use of network resources. A common scenario is a server application that needs to distribute the same identical data to the large number of clients. IP multicasting allows a server application to send a single set of data out each network interface and the IP routing infrastructure distributes the data to client applications at multiple IP addresses that have joined the multicast group.

The routers between the server IP address and the multiple client IP addresses that any packets traverse must support IP multicast for the above scenario to work. Most modern routers and network equipment used to route traffic to and from corporate networks supports IP multicasting. IP multicasting may need to be enabled on the router when it is supported. Small consumer wireless access points and routers commonly used in small businesses and residences often lack support for IP multicasting.

IP multicasting is not a new technology. IP multicasting was used since the early 1990s to broadcast some of the Internet Engineering Task Force (IETF) quarterly meeting presentations to interested parties unable to attend in person. The use of IP multicast has been limited by a lack of IP infrastructure to supports it (end-to-end router support). This issue does not normally exist within the Intranet for a corporation or other large organizations (educational institutions and government agencies, for example). Most mainstream commercial-grade routers now support IP multicasting. As a result, the market and demand for IP multicast applications is now expanding. A common scenario is the need to stream live video or data to a large number of clients (receivers or listeners) on a network efficiently so it can scale.

Multicast Protocol Support

The System.Net.Sockets namespace in Silverlight 4 has added support for two new multicast client classes. The new classes support the use of IPv4 or IPv6 multicast as long as networking on the local computer has support enabled for IPv4 and IPv6. These new classes include the following:

  • UdpAnySourceMulticastClient - A client receiver for multicast traffic from any source, also known as Any Source Multicast (ASM) or Internet Standard Multicast (ISM).

  • UdpSingleSourceMulticastClient - A client receiver for multicast traffic from a single source, also known as Source Specific Multicast (SSM).

These classes allow a client application to do the following:

  • Join a multicast group (subscribe to a group address).

  • Receive datagrams sent to the group, including multiple or unknown in advance sources.

  • Specify a sender that should be blocked or unblocked so that multicast packets originating from it are no longer received (applicable to the UdpAnySourceMulticastClient class).

  • Send unicast or multicast datagrams back to senders. This feature is often used for flow control, error correction with protocols such as RTCP, and other similar purposes.

  • Set the send and receive buffer sizes used by the underlying sockets.

  • Dispose of the class instance to leave (unjoin) the multicast group and free associated resources.

Security Restrictions on Connecting to Multicast Groups in Silverlight

There is a need to provide security and prevent Silverlight applications using multicast from initiating unauthorized connections. Potential networking threats to be mitigated include:

  • Denial of Service (DoS) attacks – A large number of remote hosts are used to attack a target site so that the target is unable to service valid requests.

  • DNS Rebinding attacks – Use DNS to force a remote host to rebind a trusted host name (site of origin) to a victim’s IP address, thus allowing access to a host other than site of origin.

  • Reverse tunnel attack – Use a remote client’s outgoing connection as a back tunnel to the client’s private network.

lThe security policy checks incorporated in the Silverlight runtime are designed to prevent these networking threats.

The IP multicast protocols do not include any security mechanisms. So they can be used for malicious purposes. IP multicast uses UDP which by its nature does not implement reliable sessions and is vulnerable to spoofing attacks. As are result, there are additional security requirements added in Silverlight that must be met to use the new multicast classes.

  • Connectivity to remote ports less than 1,024 (reserved system ports) is not allowed as a defense in depth measure.

  • Before a multicast client is allowed to join a group, the Silverlight runtime implements a protocol check to verify that the client has been granted permission to join the group and receive datagrams.

Ports below 1,024 were traditionally considered system ports and reserved primarily by core network services. These system ports that listen on UDP are used by important network services (DNS, SNMP, and system logging, for example). The first requirement in Silverlight for multicast prevents applications from sending packets to these system ports to prevent multicast Silverlight applications from being used in denial of service attacks against important network services. 

To implement the second requirement, the Silverlight runtime uses two slightly different policy mechanisms based on whether the client is requesting to listen to a single-source multicast group or requesting to participate in an any-source multicast group.

In a single-source multicast group, the source of traffic is determined ahead of time (hard-coded into the application or provided by some out-of-band mechanism). So responsibility for control of policy can be assigned to this single sender. The sender must authorize a Silverlight client to access the data which the client is sending, and to return data to the sender via unicast.

When a Silverlight application attempts to join a single-source multicast group, the Silverlight runtime sends an announcement via unicast to the source on UDP port 9430 notifying the source that a the Silverlight client is attempting to join. The announcement includes an indentifying random number, the Uri the application was downloaded from as well as the multicast group address and remote port it is attempting to join. If the source wishes to authorize the client, it responds by sending a matching authorization packet back to the client via unicast to the source address from where the announcement originated. When the Silverlight runtime receives this authorization, the Silverlight runtime allows the Silverlight application to join the group. If no authorization is received within a timeout period, the client is not allowed access and a SocketException is thrown with SocketError.AccessDenied. If the client is authorized to join the multicast group (remote address and remote port), the application is also authorized to send unicast packets to the single source on the any port number equal to 1,024 or greater.

In an any-source multicast group, the source of traffic is not determined ahead of time. In fact, there may be many sources of traffic (including other Silverlight applications). It is impractical to have each sender validate each client that joins the multicast group. Instead, there are a separate set of responders that are responsible for controlling policy for the entire group. The guiding principle of this design is that Silverlight applications should conceptually have the same level of access to network resources as their site of origin does. If an application server on the local network has the ability to interact with a multicast group on the local network, then it is safe to give a Silverlight application from this server access to the multicast group. A Silverlight application could achieve the same thing by using an HTTP connection to the server as a proxy. If a server on the Internet is prevented from interacting with a multicast group on a local network (either implicitly by Internet routers that do not support multicast or explicitly by a corporate firewall blocking the interaction), then a Silverlight application from that server should not be given access to the group even if the computer it is running on does have access to the group.

The any-source multicast design performs a straightforward check to determine whether an application’s source has access to the multicast group to which the application wishes to connect. The Silverlight runtime sends an announcement to the multicast group on port 9430 indicating that a Silverlight application would like to join the group. The Silverlight runtime then waits for a response authorizing the access on this same multicast group and remote port. If the application’s origin server (or some other responder who trusts the application’s origin server) has access to the multicast group on the network where the application is running, the origin server or responder receives the announcement and sends a response authorizing the client application to access the multicast group. If not, the attempt to join the group will time out and the client is not allowed access to the multicast group. A SocketException is thrown with SocketError.AccessDenied.

Basics of the Multicast Security Policy Protocol

The Silverlight runtime use two messages sent as UDP datagrams to implement the multicast security policy protocol:

  • Announcement - The initial message sent by the Silverlight runtime when a client attempts to join a multicast group.

  • Authorization - A response to the announcement sent by a responder or service to authorize the client access to the multicast group.

When a Silverlight application attempts to join a multicast group, the Silverlight runtime sends an announcement message of this intent in a UDP packet to port 9430 (as IP unicast to the single source for the UdpSingleSourceMulticastClient or as IP multicast to the multicast group for the UdpAnySourceMulticastClient class). The Silverlight runtime then waits for a response to this announcement on port 9430 (received as IP unicast from the single source for the UdpSingleSourceMulticastClient or received as IP multicast to the multicast group that the application is trying to join for the UdpAnySourceMulticastClient.

The format of the announcement and authentication messages are as follows:

struct SilverlightPolicyMessage

{

byte[3] header = "SL\0";

byte version = 1;

byte messageType = {Announcement: 0, Authorization: 1};

byte[4] messageId;

byte[2] port;

byte[2] applicationOriginUriLength;

byte groupAddressLength;

byte[applicationOriginUriLength] applicationOriginUri;

byte[groupAddressLength] groupAddress;

}

The header member allows easy identification of announcement and authorization messages from Silverlight applications. The version member is currently defined as 1. Future versions of the protocol can increase the number to indicate the presence of extensions after the end of the v1 message which a v1 client should ignore. The messageType member determines whether this packet is an announcement or an authorization message. The messageId is four bytes of random data inserted by the Silverlight runtime and sent with each announcement. The messageId must be copied into any correlated authorization messages to confirm that the sender of the authorization message actually received the announcement message.

The applicationOriginUri member specifies the Uri from which the requesting Silverlight application was downloaded by the Silverlight runtime. Responders should only respond to announcements from Silverlight applications which a network administrator has inspected and authorized to access multicast groups on the network.

The groupAddress and port members specify the multicast group address and remote port the Silverlight application is attempting to join. This allows a single-source responder to limit the exposure of network resources by only responding to announcements of attempts to join certain multicast groups, and ignoring requests to join other groups.

Before sending the announcement message, the Silverlight runtime joins the multicast group the application is requesting access to. After sending the announcement, the Silverlight runtime waits for a matching authorization message on the multicast group. Any packets which are not a matching authorization message are silently discarded. A packet is considered a matching authorization message if all of the following conditions are met:

  • The header is correct (this filters out packets that could not possibly be Silverlight policy protocol packets).

  • The messageType is Authorization.

  • The messageId in the received authorization message matches the messageId sent in the announcement message.

  • The applicationOriginUri member in the received authorization message matches the applicationOriginUri sent in the announcement message.

  • The groupAddress and port members in the received authorization message match the groupAddress and port members sent in the announcement message.

If the Silverlight runtime does not receive a matching authorization message within 3 seconds, the Silverlight runtime assumes the announcement was dropped and resends a new announcement. The same resend is repeated after 6 seconds if no matching authorization is received. If a matching authorization message has not been received by 12 seconds after the third resend, the policy check is considered to have failed and the application receives a SocketException with SocketError.AccessDenied. If at any point before the timeout a matching authorization message is received, the policy check succeeds and the application is allowed to access the multicast group.

Any other attempts to join a multicast group which the application initiates during the policy check process will wait until the policy check is complete before beginning. If a policy check fails, another attempt to join a multicast group within the next 60 seconds will wait until the 60-second backoff period is over before starting the policy check. This prevents a malicious or poorly written application from using repeated policy checks to create excess traffic on a network.

Source code and binaries for a responder application that implements the multicast security policy protocol are being made available on the Code Gallery site. This sample source code implements a responder application that uses an XML configuration file to authorize any-source and single-source multicast clients. Developers can use and modify this sample for use with Silverlight multicast applications. The sample code and binaries are available for download from Code Gallery.

A sample configuration file for the sample source code is included below for the configuration of a simple responder.

<?xml version="1.0" encoding="utf-8" ?>

<multicast-policy-responder>

<ssm-responder>

<!-- authorize all applications from this server to listen to our transmissions, regardless of group/port -->

<respond-to application ="http://slapps/">

<allowed-resource group="*" port="*" />

</respond-to>

</ssm-responder>

<asm-responder>

<!-- also authorize a trusted video player from contoso.com to access the multicast group containing live training videos on out network on 234.23.23.23:1234 (but not the restricted video feed of certain meetings on port 5678!) -->

<respond-to application="https://www.contoso.com/silverlight/videoplayer.xap">

<allowed-resource group="234.23.23.23" port="1234" />

</respond-to>

</asm-responder>

</multicast-policy-responder>

Developers may create their own custom responders if this sample responder does not fulfill all of their requirements.