Japanese Control System Protocols
There are a number of Japanese manufacturers who develop control system applications and devices. This is not news to people who attend control system events because they are quite active around the world. What was new to me was the protocols developed in Japan, dominant in Japan, widely used in Asia and beginning to get some traction outside the region. Here are two examples from what is a larger list.
CC-Link is a protocol developed by Mitsubishi Electric and spun out to industry, like RA spun our CIP/DeviceNet/EtherNetIP, through the CC-Link Partner Association [CLPA]. The CLPA has offices around the world. Over 900 products support CC-Link and over 4.5 devices have been deployed, and most have the Mitsubishi chipset. Not the biggest, but still sizable. It is used primarily in Manufacturing and comes in a few different flavors depending on performance and safety requirements. The latest is CC-Link IE which is designed for controller-to-controller or control center-to-controller communications over Gigabit Ethernet.
FL-net is developed and maintained by the Japan Electrical Manufacturers’ Association [JEMA]. It includes OPCN-1 for device level communications and OPCN-2 for controller level communications. FL-net is used to connect a small number, usually less than one hundred, devices. The IP subnet is specified in the standard so the idea of routing is obviously not in play. Like most industrial ethernet it uses a token based scheme for cyclic communications to provide deterministic performance. Recent additions to include an option for UDP encapsulation of request and response messages.
There are other proprietary protocols emanating from Japan like Yokogawa’s VNET-IP and Mitsubishi’s MELSECNET.
Many of the specs are available in English, or you can learn to read Japanese over the weekend.
One last thought on my Japan journey. I spent quite a bit of time with FIRST representatives, CERT’s and CSIRT’s - - people who deal with vulnerability disclosure and incident response as their primary job. It is clear that vulnerability disclosure has never been and is likely to never be a simple issue. Control system disclosure is in no way unique in its differing opinions on what is appropriate vulnerability handling and disclosure.
Author: Dale Peterson
Posted: March 28th, 2008 under SCADA Protocols, Vulnerability Disclosure.
Comments: 8
Comments
Comment from Bradley Ford
Time: March 29, 2008, 8:16 am
Its also interesting to note that Vnet/IP has recently been made an international standard.
Comment from Ralph Langner
Time: March 29, 2008, 3:48 pm
Dale, can you give us an idea if those Japanese protocols have any security features that would set them apart from Modbus etc.?
Comment from Dale Peterson
Time: March 30, 2008, 7:24 am
Ralph - To the best of my knowledge only DNP3, IEC 62351 and OPC UA are integrating security into the protocol. I guess you could add Secure ICCP which does a little bit at layer 6 and says to use https. We talked a bit about this at the end of the March podcast.
One other comment. Modbus is a very atypical control system protocol. I believe it gets a lot of attention because there are so many free or low cost implementations and can be implemented from scratch in a day or so.
Comment from Jake Brodsky
Time: March 31, 2008, 7:21 am
Clarification: IEC 62351 is the methodology behind the DNP Secure Authentication, not the protocol itself. I’ve heard that it is meant to apply to the IEC 60870 protocol as well, though I don’t know anything of those efforts.
Comment from Dale Peterson
Time: March 31, 2008, 7:57 am
Jake - Secure DNP3 and IEC 62351 are almost identical, and the group of authors for the two standards are many of the same people. There are a couple of minor differences we mentioned in the Secure DNP3 webcast.
You are correct that IEC 62351 is the security standard for IEC 60870. Thanks for clarifying.
Comment from Julian Rrushi
Time: March 31, 2008, 3:11 pm
—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1
Devising a standard of security mechanisms for a communication protocol standard has in fact become a common practice of IEC. In this regard I would like to add the example of IEC 62351-6 defining the security for IEC 61850 non-routable profiles.
Julian
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH8TdD3JhHvEZ9fsERAgu9AKDDBMfkJFSkMlATxkv8giu0QHpYVwCfRpGm
f77nSystlaBtrLHYSo4tKw4=
=2Dpd
—–END PGP SIGNATURE—–
Comment from Jake Brodsky
Time: April 1, 2008, 1:15 pm
Dale, the reason ‘62351 and Secure DNP look so similar is because they are both authored by the same person: Grant Gilchrist.
Much of the feedback from the DNP community has been integrated in to 62351 and input from the international community on 62351 has been presented to the DNP technical committee for consideration. Both have improved as a result.
Comment from Ralph Mackiewicz
Time: April 10, 2008, 2:09 pm
FYI: IEC 62351 also provides a profile for securing ICCP (IEC 60870-6 TASE.2).
Write a comment