<?xml version="1.0" encoding="utf-8"?>
<!-- 
     draft-rfcxml-general-template-standard-00
  
     This template includes examples of the most commonly used features of RFCXML with comments 
     explaining how to customise them. This template can be quickly turned into an I-D by editing 
     the examples provided. Look for [REPLACE], [REPLACE/DELETE], [CHECK] and edit accordingly.
     Note - 'DELETE' means delete the element or attribute, not just the contents.
     
     Documentation is at https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="info"
  docName="draft-liu-iotops-modbus-seriallink-sec-spec-07"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">
<!-- [REPLACE] 
       * docName with name of your draft
     [CHECK] 
       * category should be one of std, bcp, info, exp, historic
       * ipr should be one of trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
       * updates can be an RFC number as NNNN
       * obsoletes can be an RFC number as NNNN 
-->

  <front>
    <title abbrev="Security Protocol for Modbus Serial Link">Modbus Serial Link Communication Security Protocol Reference Specification and implementation guide</title>
    <!--  [REPLACE/DELETE] abbrev. The abbreviated title is required if the full title is longer than 39 characters -->

    <seriesInfo name="Internet-Draft" value="draft-liu-iotops-modbus-seriallink-sec-spec-07"/>

    <author fullname="Penghui Liu" initials="P." role="editor" surname="Liu">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <organization>Pengcheng Laboratory</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>No.2 Xingke 1 Street</street>
          <city>Shenzhen</city>
          <code>518055</code>
          <country>China</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>liuph@pcl.ac.cn</email>  
      </address>
    </author>
	

    <author fullname="Rongwei Yang" initials="R." role="editor" surname="Yang">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <organization>Pengcheng Laboratory</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>No.2 Xingke 1 Street</street>
          <city>Shenzhen</city>
          <code>518055</code>
          <country>China</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>yangrw@pcl.ac.cn</email>  
      </address>
    </author>
	
    <author fullname="Meiling Chen" initials="R." role="editor" surname="Chen">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <organization>China Mobile</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>No.32 Xuanwumen West Street</street>
          <city>Beijing</city>
          <code>100000</code>
          <country>China</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>chenmeiling@chinamobile.com</email>  
      </address>
    </author>	
	
    <author fullname="Yu Fu" initials="R." role="editor" surname="Fu">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <organization>China Telecom</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>No. 3 Penglaiyuan South Street</street>
          <city>Beijing</city>
          <code>100000</code>
          <country>China</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>fuy44@chinatelecom.cn</email>  
      </address>
    </author>
	
    <author fullname="Weizhe Zhang" initials="Y." role="editor" surname="Zhang">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <organization>Pengcheng Laboratory</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>No.2 Xingke 1 Street</street>
          <city>Shenzhen</city>
          <code>518055</code>
          <country>China</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>zhangwzh@pcl.ac.cn</email>  
      </address>
    </author>
	
    <date year="2026"/>
    <!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not the current one, it is necessary to specify at least a month and day="1" will be used.
    -->

    <area>Security</area>
    <workgroup>iotops</workgroup>
    
    <!-- "Internet Engineering Task Force" is fine for individual submissions.  If this element is 
          not present, the default is "Network Working Group", which is used by the RFC Editor as 
          a nod to the history of the RFC Series. -->

    <keyword>keyword</keyword>
    <!-- [REPLACE/DELETE]. Multiple allowed. Keywords are incorporated into HTML output files for 
         use by search engines. -->

    <abstract>
      <t>The Modbus TCP protocol has adopted TLS-based security standards; however, Modbus serial communication over EIA/TIA-485 multi-point systems, commonly used in 2-wire or 4-wire configurations, lacks standardized security mechanisms. These systems support cable lengths exceeding 1000m at baud rates up to 9600 bit/s with AWG26 or thicker cables, while Category 5 cables can reach up to 600m. As an application layer protocol, despite its widespread application, the absence of encryption and authentication in Modbus protocol via serial links exposes plaintext data to risks such as MIM interception, modification under attacks such as side-channel analysis etc., particularly in long-distance or bridged network scenarios. Enhancing Modbus serial link security requires introducing proper encryption and authentication methods tailored to varied deployment environments onsidering the characteristics of serial links. A proposed security standard guide outlines lightweight encryption and authentication mechanisms to improve confidentiality and integrity while maintaining compatibility with existing Modbus devices, offering a practical upgrade path for secure industrial control systems.</t>
	  </abstract>
 
  </front>

  <middle>
     <section anchor="IANA">
    <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA. </t>
    </section>
    
    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>This specification defines the reference native security protocol specification for the case with pure serial link communication, which (e.g., RS485-based Modbus) remains an unresolved challenge. Serial Modbus transmits data in plaintext, leaving it susceptible to interception, modification, and hardware-based side-channel attacks. There are currently no formal standards addressing security for Modbus over RS485, which is still widely used due to its simplicity and long-distance capabilities. Currently, for any EIA/TIA-485 multi-point system, whether it is a 2-wire or 4-wire configuration, the maximum length for cables with a maximum baud rate of 9600bit/s and AWG26 (or thicker) specifications can reach over 1000m. For RS485 Modbus, a sufficiently wide cable diameter should allow for a maximum length of over 1000m, and for RS485 Modbus using Category 5 cables, the maximum length can reach 600m. This lack of encryption and authentication mechanisms poses risks, particularly in scenarios involving relays or bridged networks. While Modbus TCP has seen notable advancements in security through TLS-based solutions, serial Modbus communication requires more attention. Introducing lightweight encryption and authentication mechanisms for serial links could provide a practical way to enhance security and protect legacy systems without significant infrastructure changes. Therefore, it is very necessary and valuable to improve and enhance the communication security of Modbus protocol under serial link mode, for reference by relevant institutions and organizations in various industries, in order to ensure the practical application security of various industrial control systems. With the introduction of the Modbus serial link security standard, the introduction of encryption and authentication mechanisms in the serial link communication channel of the Modbus protocol significantly improves its security, providing a relatively simple and direct upgrade path for existing devices that use Modbus extensively.</t>

    </section>
    
    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <!-- The recommended and simplest way to include a well known reference -->
        
      </references>
 
      <references>
        <name>Informative References</name>
        <reference anchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
			<author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>

        <reference anchor="RFC8439">
          <front>
            <title>ChaCha20 and Poly1305 for IETF Protocols</title>
            <author fullname="Y. Nir" initials="Y." surname="Nir"/>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <date month="June" year="2018"/>
            <abstract>
              <t>This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8439"/>
          <seriesInfo name="DOI" value="10.17487/RFC8439"/>
        </reference>
		
        <reference anchor="IEC62443-3-3">
          <front>
            <title>System Security Requirements and Security Levels</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2013"/>
            <abstract>
              <t>This standard specifies system-level security requirements for Industrial Automation and Control Systems (IACS). It includes guidelines for access control, authentication, data integrity, and monitoring, which are applicable to securing Modbus-based systems.</t>
			</abstract>
          </front>
          <seriesInfo name="IEC" value="62443"/>
        </reference>
		
         <reference anchor="IEC62443-4-2">
          <front>
            <title>Technical Security Requirements for IACS Components</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2019"/>
            <abstract>
              <t>This standard defines technical security requirements for industrial control devices, including secure communication protocols, encryption, and authentication mechanisms, relevant for improving the security of devices using Modbus.
			  </t>
			  </abstract>
          </front>
          <seriesInfo name="IEC" value="62443"/>
        </reference> 

         <reference anchor="IEC62351-3">
          <front>
            <title>Power Systems Management and Associated Information Exchange – Data and Communications Security – Part 3: Communication Network and System Security for Profiles Including TCP/IP</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2014"/>
            <abstract>
              <t>This standard provides securing communication networks that use TCP/IP, including Modbus TCP. It recommends encrypting communication and implementing authentication to mitigate cyber threats.			  </t>
			  </abstract>
          </front>
          <seriesInfo name="IEC" value="62351"/>
        </reference>   

         <reference anchor="IEC62351-4">
          <front>
            <title>Power Systems Management and Associated Information Exchange – Data and Communications Security – Part 4: Profiles Including MMS and Derivatives</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2018"/>
            <abstract>
              <t>This standard focuses on the security concerns for TCP/IP-based communication protocols, including Modbus TCP, and provides mechanisms for authentication and data integrity.</t>
			  </abstract>
          </front>
          <seriesInfo name="IEC" value="62351"/>
        </reference>   

         <reference anchor="NISTSP800-82">
          <front>
            <title>Guide to Industrial Control Systems (ICS) Security</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2018"/>
            <abstract>
              <t>This standard is published by the National Institute of Standards and Technology (NIST), this guideline provides documents for securing industrial control systems. For Modbus, it highlights: Using VPNs and encryption technologies such as TLS. Implementing network segmentation and access control policies. Monitoring and detecting unauthorized Modbus traffic.</t>
			  </abstract>
          </front>
          <seriesInfo name="NIST" value="SP800"/>
        </reference>   
		
         <reference anchor="ENISA-ICS-Security-Guidelines">
          <front>
            <title>Good Practices for Security of Industrial Control Systems</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2018"/>
            <abstract>
              <t>This standard is published by the National Institute of Standards and Technology (NIST), this guideline provides documents for securing industrial control systems. For Modbus, it highlights: Using VPNs and encryption technologies such as TLS. Implementing network segmentation and access control policies. Monitoring and detecting unauthorized Modbus traffic.</t>
			  </abstract>
          </front>
          <seriesInfo name="ENISA" value="ICS-Security-Guidelines"/>
        </reference> 

         <reference anchor="ETSI-SAGE-TS35.221">
          <front>
            <title>Specification of the 3GPP Confidentiality and Integrity Algorithms 128-EEA3 and 128-EIA3.Document 1:128-EEA3 and 128-EIA3 Specification</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2020"/>
            <abstract>
              <t>ETSI/SAGE TS35.221 and TS35.222 are technical specifications developed by the Security Algorithm Expert Group (SAGE) of the European Telecommunications Standards Institute (ETSI), belonging to a category of the ETSI standard system. These standards typically focus on security algorithms or technical implementation details in the telecommunications field.
			  </t>
			  </abstract>
          </front>
          <seriesInfo name="ETSI/SAGE" value="TS35.221"/>
        </reference>  
 
         <reference anchor="ETSI-SAGE-TS35.222">
          <front>
            <title>Specification of the 3GPP Confidentiality and Integrity Algorithms 128-EEA3 and 128-EIA3.Document 1:128-EEA3 and 128-EIA3 Specification</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2020"/>
            <abstract>
              <t>ETSI/SAGE TS35.221 and TS35.222 are technical specifications developed by the Security Algorithm Expert Group (SAGE) of the European Telecommunications Standards Institute (ETSI), belonging to a category of the ETSI standard system. These standards typically focus on security algorithms or technical implementation details in the telecommunications field.
			  </t>
			  </abstract>
          </front>
          <seriesInfo name="ETSI/SAGE" value="TS35.222"/>
        </reference>  

         <reference anchor="NIST.FIPS.203">
          <front>
            <title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2024"/>
            <abstract>
              <t>A key-encapsulation mechanism (KEM) is a set of algorithms that, under certain conditions, can be used by two parties to establish a shared secret key over a public channel. A shared secret key that is securely established using a KEM can then be used with symmetric-key cryptographic algorithms to perform basic tasks in secure communications, such as encryption and authentication. This standard specifies a key-encapsulation mechanism called ML-KEM. The security of ML-KEM is related to the computational difficulty of the Module Learning with Errors problem. At present, ML-KEM is believed to be secure, even against adversaries who possess a quantum computer. This standard specifies three parameter sets for ML-KEM. In order of increasing security strength and decreasing performance, these are ML-KEM-512, ML-KEM-768, and ML-KEM-1024.
			  </t>
			  </abstract>
          </front>
          <seriesInfo name="NIST" value="FIPS.203"/>
        </reference>  

         <reference anchor="NIST.FIPS.204">
          <front>
            <title>Module-Lattice-Based Digital Signature Standard</title>
			<author fullname=" " initials=" " surname=" "/>
            <date  year="2024"/>
            <abstract>
              <t>Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. In addition, the recipient of signed data can use a digital signature as evidence in demonstrating to a third party that the signature was, in fact, generated by the claimed signatory. This is known as non-repudiation since the signatory cannot easily repudiate the signature at a later time. This standard specifies ML-DSA, a set of algorithms that can be used to generate and verify digital signatures. ML-DSA is believed to be secure, even against adversaries in possession of a large-scale quantum computer.
			  </t>
			  </abstract>
          </front>
          <seriesInfo name="NIST" value="FIPS.204"/>
        </reference>  
		
      </references>
    </references>
    
 </back>
</rfc>
