From Achilles' Heel to Ajax's Shield: Evolution of Security in Traffic Signal Controllers - (1) Basics
Introduction
The National Transportation Communications for Intelligent Transportation Systems Protocol (NTCIP) is a family of standards developed to ensure interoperability among electronic traffic control equipment. NTCIP 1202 stands out as particularly important to traffic engineers and professionals working with actuated traffic signal controllers (ASCs). It defines the data elements, object structures, and conformance requirements specific to the operation and management of traffic signal controllers.
You can find out about the latest (and on-going) development of NTCIP 1202v4 specification from:
👉 https://www.ite.org/ITEORG/assets/File/NTCIP%201202v04_07b_UCD.pdf
The NTCIP 1202 specification is presented as a high-level standard; it doesn’t cover the implementation-level details that matter most to those involved in the implementation or integration of traffic signal controllers. For these audiences, a deeper, binary-level understanding of SNMP —is essential for developing secure and standards-compliant systems.
This article marks the beginning in a multi-part series, offering a technical deep dive into SNMP within the context of NTCIP 1202. The series is intended to help gain practical insight into the lower layers of the NTCIP protocol stack.
In later articles, we will explore the security shortcomings of SNMPv1 and examine how NTCIP 1202 has addressed these issues through its adoption of SNMPv3, bringing improved authentication, encryption, and access control to the world of traffic signal control.
The NTCIP Framework: A Layered Architecture
The NTCIP framework is best understood through its layered architecture, which aligns closely with the OSI model. Figure 1 illustrates how messages are constructed, with lower layers wrapping upper-layer data with additional protocol information for NTCIP 1202. Note, for Dynamic Objects, STMP 2301 may become obsolete with NTCIP 1202v4.
For NTCIP 1202, we’re primarily interested in everything up to the Application Layer—particularly in how SNMP is used as the protocol for management and data exchange.
Anatomy of an SNMP Message
An SNMP message consists of a sequence of binary bytes, each with a specific function in the message structure (See Figure 2). A simplified walkthrough of a typical SNMP message, as shown in Figure 3, is as follows:
Start of Sequence
A message begins with0x30, identifying it as a "Sequence" type message in ASN.1 BER (Basic Encoding Rules).OID Encoding/Decoding
OIDs (Object Identifiers) use a variable-length encoding scheme where:Each byte contains 7 bits for data.
The high bit indicates if another byte follows.
Example:
0x89 0x36represents OID node 1206:1000 1001 (high bit set, look for another byte) 0011 0110 (high bit not set, this is end)
Stripping high bits, we get 000 1001 011 0110
Putting back into two bytes: 0000 0100 1011 0110 =
0x04B6= 1206 decimal
Length Field Encoding
SNMP messages use BER encoding for lengths:If the high bit is 0, the byte represents the length.
If the high bit is 1, the remaining 7 bits indicate the number of bytes that follow to define the actual length.
Example:
0x2C→ 44 bytes follow.0x82 0x01 0xB0→ length is0x01B0= 432 bytes.Full message length: 432 + 4 = 436 bytes.
SNMP Version
Encoded as a Type-Length-Value:
0x02 0x01 0x00→ Integer, 1 byte, value 0 (SNMPv1)
The following lists the common ASN.1 data types, relevant to SNMP:
Why SNMPv1 Is Not Secure
While SNMPv1 is widely deployed, it suffers from serious security flaws that render it inappropriate for many modern applications, especially in critical infrastructure like traffic signal control:
Authentication is weak:
Only a simple community string (like a plaintext password) is used for access control.
These strings are transmitted in cleartext, making them easy to intercept and spoof.
No encryption:
Data, including configuration commands and sensitive system information, is sent in unencrypted binary.
No user-based access control:
Anyone with the correct community string can potentially perform privileged actions.
These vulnerabilities are especially problematic when SNMP is used over IP-based networks, where packet sniffing, spoofing, and replay attacks are all possible.
From SNMPv1 to SNMPv3: A Security Evolution
To address the limitations of SNMPv1 (and SNMPv2c), SNMPv3 was introduced with a robust set of security features:
User-Based Security Model (USM):
Provides authentication, privacy (encryption, e.g., AES), and message integrity.
View-Based Access Control Model (VACM):
Granular access control to MIB objects based on user and context.
Key RFCs for SNMPv3 include:
RFC 3410: Introduction and Applicability Statements
RFC 3411: Architecture
RFC 3412: Message Processing and Dispatching
RFC 3413: Applications
RFC 3414: USM
RFC 3415: VACM
RFC 3416–3418: Protocol Operations and Transport Mappings
Alternatives to SNMPv3 for NTCIP 1202 – Why They Don't Fit
As NTCIP 1202 systems move from SNMPv1 to a more secure messaging framework, several modern alternatives may seem appealing at first glance:
However, SNMPv3 was ultimately selected for its clear advantages as a direct and pragmatic upgrade path:
Compatibility: It maintains compatibility with existing MIBs, preserving prior investments and minimizing migration effort.
Security: It introduces robust security features essential for managing, configuring, and updating today’s advanced traffic signal controllers.
Maturity: SNMPv3 is well-established in the network management domain, enabling a smooth transition with minimal disruption to existing firmware stacks.
Final Thoughts
Understanding SNMP at the binary level is essential for developers and system integrators working with NTCIP 1202-based signal controllers, especially as the industry shifts toward secure implementations.
Stay tuned for upcoming posts in this series, where we’ll decode actual SNMPv3 packets, explore USM configurations, and dive deeper into real-world controller implementations.