DNP3
From SCADApedia
DNP3 is a master/slave control system protocol widely used in the North American electric sector for power transmission and distribution SCADA systems and for power generation DCS. Use today has migrated to other vertical markets such as water /wastewater, transportation and the oil and gas pipeline sectors.
Contents |
History
The Distributed Networking Protocol (DNP) was first developed in 1990 by Westronic, Inc., which after a few acquisitions is now known as GE Harris. In 1993, DNP 3.0 ownership was transferred to the DNP Users Group, and the DNP 3.0 specification was released to the public.
DNP3 began as a serial protocol and was extended to work over IP, encapsulated in TCP or UDP packets, in 1998 with the publication of Volume 7: IP Networking.
DNP3 was specifically developed for use in electric utility control system applications. It is now a dominant protocol in North American electric utility control systems, and is gaining popularity in other industries, including oil & gas, water, and wastewater.
Relation to IEC 60870-5
The DNP3 protocol was based on the IEC 60870-5 protocol as it was specified in 1992, and the protocols remain very similar to this day. For example, DNP3 uses one of the data link layer options specified in IEC 60870-5-1 and -2. However, Westronic was concerned that the number of options in IEC 60870-5 would hamper interoperability and a small number of features were missing that Westronic felt were required for the North American market.
Protocol Description
DNP3 is a client / server protocol stack, but in DNP3 parlance the client is called the master and the server is called the outstation. A master is typically an HMI, realtime server or other higher level PLC. The outstation is a PLC, RTU, IED or other type of controller that communicates with actuators, sensors and other instruments.
The DNP3 protocol stack is depicted below.
- The User Layer is the vendor’s application code that inputs and outputs data at the master and outstation. This code, whether it be an HMI application, a PLC application, or any other system with a DNP3 protocol stack, inputs and receives output from the DNP3 application layer. It is not part of the DNP3 protocol stack.
- The Application Layer is where the control and monitoring functions take place in DNP3. DNP3 request and responses are constructed using function codes and objects defined in the DNP3 standard.
- The DNP3 specification uses the term transport function rather than transport layer because it lacks the addressing or acknowledgments a transport layer typically provides. The transport function actually can be considered an addition to the Application Layer. The transport function splits the application message into segments no longer than 250 bytes, hence it is unnecessary unless application data is present. On the receiving side the transport function reassembles the packets into the application layer message.
- The Data Link Layer adds the addressing and error detection and correction prior to sending the frame over the physical layer. The error detection and correction are relatively robust compared to other control system protocols. A 16-bit CRC is sent for the header and every 16 data bytes. Frames can be as long as 292 bytes. The DNP3 Data Link layer also sends acknowledgements for certain data link layer frame types and can detect lost or duplicate frames.
The diagram above represents the serial communication stack which places the DNP3 Data Link Layer Frame directly on the physical layer. When DNP3 is sent over an IP network the DNP3 Data Link Frame is encapsulated in either a TCP or UDP packet. TCP is recommended except for broadcast packets and instances with strict communication overhead requirements.
Application Layer
The DNP3 application layer formats the request and response messages. DNP3 relies on function codes to specify the purpose of a request and response message. The function codes include reads, writes, administrative and diagnostic purposes. Many function codes can have significant security impacts such as false writes (0x02), stop application (0x12), and disable unsolicited (0x15).
The application control byte provides message control information such as dealing with fragments that occur in very large responses that exceed buffer size.
The internal indications (IIN’s) are two bytes with each bit having a function. Some IIN’s can have security implications, most often in detecting attacks. For example, HSB bit 0 is “function code not supported” that could occur during function code scans in an attack reconnaissance phase. Digital Bond’s DNP3 IDS signatures include detecting IIN attack related events.
The object requests or responses are sent after the application header. DNP3 supports a large number of object types and there are separate specification documents just to deal with object definition.
Unsolicited Response
DNP3 is a request/response protocol, but it also supports unsolicited response. An unsolicited response occurs when an object value at an outstation exceeds a set threshold, and the outstation sends a response to the master station without receiving a request (unsolicited). This can be very important when communication costs are high or the number of points is so large it is not feasible to poll them often enough.
Secure DNP3
In February 2007 the DNP3 User Group released the Secure DNP3 specification. This specification added five new security related function codes to the protocol and offered data and source authentication. The authentication can take place on all requests/responses, periodically, or selectively based on function code type.
Secure DNP3 can be used on either serial DNP3 or DNP3 encapsulated in TCP because the security takes place at the application layer.
Secure DNP3 currently lacks a companion key management standard, so the top-level, pre-shared key is manually loaded and changed. This is likely to be an administrative burden for all but the smallest networks.
This protocol is almost identical to IEC 62351-5.
DNP3 IDS Signatures
Digital Bond has developed a set of DNP3 IDS Signatures for the Snort IDS. Most commercial IDS sensors have integrated these signatures into their systems.
DNP3 Implementations
The DNP3 stack developed and sold by Triangle Microworks is widely used by vendors rather than developing their own stack. While exact numbers are not available, Triangle Microworks has at least a 50% market share, and there market share might be as high as 80%.
Internet Activity on DNP3 Port
There has been activity noted at the Internet Storm Center on the DNP3 Port, TCP and UDP 20000. This traffic has been analyzed in a variety of packet captures and was not DNP3 communication. It was determined to be traffic related to the Usermin application. There was an arbitrary file disclosure bug, CVE-2006-3392, that affected Usermin, and it is likely the traffic was caused by attacks on Usermin installations.
