With modern transmitters opting for Internet-based control and monitoring in a graphical user interface (GUI) environment, the protocol employed to enable and secure this operation is critical. A popular non-proprietary, easy, effective protocol is SNMP, or Simple Network Management Protocol.

However, a known weakness of SNMP Versions 1 and 2 is security. Version 3 addresses this, according to Brian Lindemann, vice president for RF engineering at Broadcast Electronics, who will speak on the topic during the NAB Show.

“If the SNMP connection is not properly secured, the ease of access can allow accidental and/or malicious modification of the operating parameters at the transmitter site. For instance, modifiable parameters include power level, operational frequency, audio source, etc.”

SNMP prior to Version 3 uses a “community string” for security, sent in plain text. Anyone can read its value.

In Version 2 of SNMP, if the browser has the “write” community string specified, write access is granted. It is possible for a person who is hoping to just monitor the status may inadvertently modify an operating parameter. In Version 3 of SNMP, it is possible to connect as a user with “read-only” permissions. With read-only permissions, the user cannot modify parameters inadvertently.

“Version 3 of SNMP has been around for a while,” Lindemann said. “In 2004 the Internet Engineering Task Force recognized SNMPv3 (STD0062) as the standard for SNMP, having made the two prior versions obsolete. However, in the broadcast world, the prior versions of SNMP appear to be quite prevalent.

“Some attempts to secure earlier versions include port blocking, community strings and (if possible) the setup on a switch or the device to limit which device IP is allowed to talk to it. SNMP communications does not usually contain secure data, so it is not looked at as needing encryption. That is, the frequency of a particular transmitter is not necessarily something that is to be kept confidential. So there is a tendency not to worry about securing the data.”

Other options

SNMP is a popular protocol. It is easy to use; there are browsers readily available. Because it is a standard, writing custom user interfaces over it is relatively simple. Inexpensive MIB browsers are available.

Other non-proprietary protocols include Common Management Information Protocol, or CMIP. This is also defined in the Request for Comments documents used in computer network engineering, and has been standardized by the International Telecommunication Union. However, it is not commonly used in TCP/IP environments because of the complexity and resource requirements of its agents and management systems.

Other protocols require some amount of proprietary information. For example, a straight HTTP Web-based interface, as can be found on many transmitters, displays a lot of information and has the ability to change various parameters through the interface. However, it doesn’t support breaking out one or two individual items in which a particular engineer is interested. With a custom-developed SNMP browser, the engineer can have a single screen showing alarm status for every piece of equipment at the transmitter site. If the transmitter supports only HTTP, the engineer would need a separate Web browser window opened for that piece of equipment.

A common misconception about SNMP, Lindemann said, is that community strings provide security. “Just because I can’t think of a way to break it doesn’t mean someone else can’t, even without really trying.” In looking toward the future Lindemann expects more equipment to adopt SNMPv3.

The presentation “Securing SNMP for Transmitter Control” is part of the Tuesday session “Network Security for Broadcast.” Lindemann will discuss uses of SNMP as a control protocol and offers techniques and methods for protecting SNMP-enabled equipment from hackers and virus attacks.