Last modified 11 years ago Last modified on 08/06/2008 11:35:59 AM

Event Messaging Subsystem


The Events subsystem functions as a nervous system for the LSST infrastructure. It is a general-purpose publish-subscribe message system based on ActiveMQ. Some of its primary uses are expected to be:

  • Logging
  • VOEvent alerts
  • Internal status notifications
  • Error & exception alerts

Each LSST system has a single "Event Broker", which is the sole source and sink of messages within that system. Broker policies determine which events are routed inter-system, and which remain local.

Design Choices

Signed messages or unsigned? That is the main decision to make.

  • Signed messages
    • Are more resource-intensive to create and consume
    • Guarantee integrity regardless of communication channel
  • Unsigned messages
    • Are simple to create and consume
    • Depend on transport security to guarantee integrity

We currently plan to use unsigned messages with transport-layer security, and carefully control how messages are created and transported.

1. Responsibilities

To be determined: who manages Event Brokers? Discussion:

  • Central management:
    • ensure uniform enforcement & management
    • ensure compatibility coordination
    • break autonomy of local systems
  • Local management:
    • delegate responsibility of policy enforcement
    • allow local variations for internal events
    • propagation policies should limit potential damage, but lack of signing is a vulnerability in case of a rogue Broker

Individual Event Brokers and event sub-networks may be managed centrally or by the administrators of the Systems where they reside. Either way, they will be expected to adhere to LSST policies, and LSST will provide software and guidelines for maintaining them.

2. Physical Operating Environment

The components of the Event subsystem will share the physical environment of each system where they reside. It is likely that Event Brokers will be virtual machines.

3. System Descriptions

3.1. Event Brokers

The core of the Event subsystem is a tight confederation of autonomous brokers. Each broker has its own policies that determine:

  • Which events are propagated
    • Import: from outside the local System (from other brokers) into the broker's system
    • Export: exposing events from inside the local System to external brokers
    • Local: events that originate locally and are not offered to external brokers

3.1.1. Broker Authentication

Brokers authenticate to each other using centrally-issued host certificates that are revocable and which expire and must be re-issued after a set time (probably a year). If a broker presents a revoked certificate, other brokers will refuse to connect to it. A recently expired (or soon-to-expire) certificate should at least provoke a warning, if not outright rejection. For example, they could use TLS.

Brokers authenticate with their local clients (event consumers) using a host certificate as well. It may be the same host certificate used to connect with other brokers or a locally issued one.

3.2. Event Producers

Event Brokers are responsible for verifying and propagating events that originate within their local systems. To export events to other Brokers, they should adhere to the policies described here or risk having their host certificates revoked.

3.1.2. Producer Authentication

Event producers should authenticate with their local broker using a host certificate. If the events are to be exported outside of the local system, the host certificate has the same requirements as event brokers' certs.

3.1.3. Consumer Authentication

Any application in the system is permitted to subscribe to events.

Event consumers will subscribe to events from their local broker, but they may not be required to present host certificates. They may still be expected to connect via a secure channel and authenticate their broker's identity based on its host certificate. (Question: should we require secure connections for all clients?)

Whether or not all clients use secure channels, brokers should at least make available a secure channel backed by their centrally-issued host certificate.

4. Management, Operational, and Technical Controls Descriptions

4.1. Access Control

4.2. Awareness and Training

4.3. Audit and Accountability

4.4. Configuration Management

4.5. Contingency Planning

4.7. Maintenance

4.8. Media Protection

4.9. Physical and Environmental Protection

4.10. Security Planning

4.11. Personnel Security

4.12. Risk Assessment

False Message Injection

False events could cause real problems, especially if they propagate to sensitive Systems, or if there are large numbers of them.

  • Extraneous logging
  • False VOEvent alerts
  • Erroneous status notifications ("telescope preparing for exposure", "nightly data transfer complete")
  • False exceptions ("the camera is malfunctioning", "error during nightly processing", "DAC X has lost Y raw data")

False events could originate from:

  • Injection into a Broker by a rogue client
  • A rogue Broker sending to clients or other Brokers


Event messages, like all LSST network traffic, are vulnerable to network disruptions. That subject is expected to be covered elsewhere, especially in network design and fault-tolerance.

4.13. Systems and Services Acquisition

4.14. System and Communications Policy

4.15. System and Information Integrity