<?xml version="1.0" encoding="utf-8"?>

<?xml-model href="rfc7991bis.rnc"?>  

<!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-rfcxml-rfc-swl-103k-04"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">
<!-- 
       * 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="Abbreviated Title">SW103K PROTOCOL</title>
    <!--  abbrev. The abbreviated title is required if the full title is longer than 39 characters -->

    <seriesInfo name="Internet-Draft" value="draft-rfcxml-rfc-swl-103k-04"/>
   
    <author fullname="Chazah" initials="C.G" role="editor" surname="ChazahGroup">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             Chazah Group Ltd

             * role="editor" is optional -->
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <organization>Organization ChazahGroup</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>Street </street>
          <city>City</city>
          <region>Region </region>
          <code>Postal code </code>
          <country>Country Uganda</country>
          <!-- Uses two letter country code -->
        </postal>        
        <phone>Phone </phone>
        <email>Email chief3@chazahgroup.org </email>  
        <!-- Can have more than one <email> element -->
        <uri>URI chazahgroup.org</uri>
      </address>
    </author>
   
    <date year="2025"/>
    <!-- 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>General</area>
    <workgroup>Internet Engineering Task Force</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>DataLink, Transport, Compression, decompression, Data Expansion </keyword>
    <!--  Multiple allowed.  Keywords are incorporated into HTML output files for 
         use by search engines. -->

    <abstract>
        <t>
    The SW103k protocol addresses challenges in networks with limited bandwidth, latency constraints, and data integrity concerns. It provides compression and decompression to optimize bandwidth utilization in environments such as IoT, satellite, and mobile communications.
  </t>
  <t>
    The protocol operates at the data link layer with a custom frame format including SW103K and HAVI headers. Key features include:
  </t>
  <t>
  - Batch processing of 103 packets with compression
  - Merkle tree-based integrity verification
    (merklesw103k root hash)
  - QoS mechanisms with 8-bit priority field
  - Security features including AES-256-GCM encryption
  - Physical layer synchronization with +-1us accuracy
</t>
 
  <t>
    Implementations include Linux kernel modules, FPGA encoders, and userspace daemons. The protocol supports interoperability with industrial standards like PROFINET and EtherCAT through custom mappings.
  </t>
    </abstract>
 
  </front>

  <middle>
    
    <section>
      <name>Introduction</name>
      <t>
      **1. Introduction**


This document proposes the SWL103K protocol for interoperable device communication within defined network scopes in order to ensure interoperability

**2. Protocol Features**

The SWL103K protocol SHOULD support data compression for efficient data exchange in resource-constrained environments.

**3. Security Considerations**

Implementations of this protocol MUST NOT store plaintext passwords in memory.

      
       The rapid growth of networked devices and the emergence of diverse
applications have led to the demand for efficient communication
protocols that can accommodate varying network conditions, scalability,
and resource constraints. The SWL103K protocol presented in this
document aims to address these challenges by providing a robust and
adaptable solution for data exchange in distributed networks.

As network environments become increasingly dynamic and heterogeneous,
traditional communication protocols may struggle to provide optimal
performance. The SWL103K protocol takes a novel approach by
integrating innovative techniques for data transmission, congestion
control, and routing. This ensures that the protocol remains
responsive and reliable, even in scenarios where network conditions may
change unpredictably.

This document outlines the fundamental design principles, key
features, and operational characteristics of the SWL103K protocol. It
describes the protocol's message format, data integrity mechanisms,
and how it handles various network scenarios. By providing a
comprehensive understanding of the SWL103K protocol, this document aims
to enable network engineers, researchers, and implementers to make
informed decisions about its adoption and integration into their
respective systems.

The following sections of this document delve into the specific
components of the SWL103K protocol, including its requirements, design
considerations, and operational guidelines. Additionally, the document
provides insights into its security considerations and interactions
with existing protocols. Overall, the SWL103K protocol aims to enhance
the reliability, efficiency, and adaptability of communication in
modern networked environments

What problems does this protocol solve?

This protocol solves several problems related to data transmission,
compression, decompression, and integrity verification. Specifically,
it aims to:

Efficiently transmit and manage a large number of small data packets.
Compress a batch of 103 data packets into a single compressed data
stream.
Decompress the compressed data back into the original 103 packets.
Calculate and verify the integrity of received data using a merkelsw103k Tree.
Handle various states of the communication process, including
compression and decompression.
  </t> 

      <section>
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
          RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
          interpreted as described in BCP 14 <xref target="RFC2119"/>
          <xref target="RFC8174"/> when, and only when, they appear in
          all capitals, as shown here.</t>
      </section>
      <!-- [CHECK] The 'Requirements Language' section is optional -->

    </section>
    
    <section>
      <name>How it works</name>
      <t>The provided custom protocol, which appears to be a part of a larger system or application, aims to address various communication and data handling challenges. Below are responses to your questions regarding the abstract understanding of this protocol:</t>
      
      <ol>
        <li>

Efficiently transmit and manage a large number of small data packets.
Compress a batch of 103 data packets into a single compressed data
stream.
Decompress the compressed data back into the original 103 packets.
Calculate and verify the integrity of received data using a merkelsw103k Tree.
Handle various states of the communication process, including
compression and decompression.
To implement this protocol, you would need to:

Define and initialize a struct sw103k_proto instance to manage the
protocol's state and data.
Implement the functions compressPackets and decompressPackets to
handle compression and decompression of data packets.
Handle various protocol states and operations in the
sw103k_proto_parse_pkt function, updating the protocol instance
accordingly.
Implement communication logic to send and receive data packets based
on the current protocol state.
Implement functions for integrity verification, such as constructing a
merkelsw103k Tree and comparing hashes.
Utilize this protocol in your application by calling its functions
based on your specific use case.

6. Abstract: How does this protocol's function compare to other
transport protocols?

This protocol appears to be a custom communication and data handling
protocol tailored to specific needs. Unlike widely used transport
protocols like TCP or UDP, which focus on reliable data transmission
or low-level data transfer, this custom protocol includes features for
data compression, decompression, and integrity verification.

The choice of using this protocol would depend on the specific
requirements of the application. TCP, for example, ensures reliable
data delivery, while UDP offers lower overhead but without guarantees
of reliability. This custom protocol seems to prioritize efficient data
compression and decompression, making it suitable for scenarios where
data size and compression are critical factors.

7. Why might someone decide to use this instead of something else
that already exists?

Someone might choose to use this custom protocol over existing
alternatives if their application requires:

Efficient compression and decompression of data packets.
Fine-grained control over data transmission and compression.
Integration of integrity verification using a merkelsw103k Tree.
Customized handling of communication states and operations.
Depending on the specific use case, existing transport protocols like
TCP or UDP may not provide the desired level of data compression or
customizability.

8. What are the security issues raised by using this protocol?

While the provided code includes features for calculating and verifying
packet integrity using a merkelsw103k Tree, it's essential to consider
potential security issues:

Data Integrity: The protocol relies on integrity verification using a
merkelsw103k Tree, but it assumes that the root hash provided is
trustworthy. Any compromise of the root hash could lead to data
integrity issues. (Fixed with data integrity checks)

Compression and Decompression: If not implemented securely,
compression and decompression routines can potentially introduce
vulnerabilities, such as buffer overflows or injection attacks.

Authentication and Authorization: The protocol does not appear to
address user authentication or authorization, which could be crucial
for secure communication.

Data Privacy: Depending on the nature of the data being transmitted,
encryption may be necessary to ensure data privacy.

Implementers should conduct thorough security assessments and consider
encryption, authentication mechanisms, and protection against common
security threats. In summary, the provided custom protocol offers a
tailored solution for data transmission, compression, and integrity
verification. Its use cases and advantages would depend on the specific
requirements of the application it is being implemented for, but it
provides flexibility and control over these aspects compared to more
standardized transport protocols. Security considerations are essential
when implementing and deploying this protocol in real-world
applications.

Below is how we are fixing the security concerns

Threat Modeling: Start by conducting a threat modeling exercise.
Identify potential threats and vulnerabilities in your protocol.
Consider various attack vectors, such as eavesdropping, tampering, and
unauthorized access.

Authentication: Implement strong authentication mechanisms to ensure
that communication parties can verify each other's identities. This can
involve using cryptographic protocols like TLS/SSL for secure
communication.

Data Encryption: Encrypt sensitive data to protect it from
eavesdropping. Use well-established encryption algorithms and ensure
that keys are managed securely.

Access Control: Enforce proper access controls to prevent unauthorized
access to resources. Ensure that only authorized users or devices can
interact with the protocol.

Data Integrity: Implement mechanisms to verify the integrity of data
during transmission. This can include using checksums, digital
signatures, or HMAC (Hash-based Message Authentication Code).

Secure Key Management: Properly manage cryptographic keys used for
encryption and authentication. Store keys securely and rotate them
periodically.

Secure Coding Practices: Follow secure coding practices to avoid common
vulnerabilities such as buffer overflows, injection attacks, and format
string vulnerabilities.

Error Handling: Implement robust error handling to prevent information
leakage through error messages. Provide generic error messages to users
and log detailed error information for administrators.

Logging and Monitoring: Implement logging and monitoring to detect and
respond to security incidents. Log relevant security events and
regularly review logs for suspicious activities.

Penetration Testing: Conduct penetration testing and security audits to
identify vulnerabilities that may not be apparent during design and
development.

Regular Updates: Keep the protocol and its dependencies up to date.
Security vulnerabilities can be discovered in libraries or components
used by the protocol.

Documentation: Provide clear and up-to-date documentation on security
best practices for users and administrators of the protocol.

User Education: Educate users and administrators about security best
practices when using the protocol. This includes password hygiene,
avoiding suspicious links or attachments, and recognizing phishing
attempts.

Security Review: Consider involving security experts or third-party
security audits to evaluate the protocol's security posture.

Compliance: Ensure that the protocol complies with relevant security
standards and regulations, if applicable.

Incident Response Plan: Develop an incident response plan to address
security breaches or incidents. Define procedures for identifying,
reporting, and mitigating security issues.



 </li>
      </ol>
      
      <ul>
        <li> How does this protocol work?
               The protocol works by defining a set of states (e.g., CONNECTING, COMPRESSING, DECOMPRESSING) and operations (e.g., SEND_COMPRESSED_DATA, RECEIVE_COMPRESSED_DATA). It provides functions for compressing and decompressing data, as well as for calculating and verifying packet integrity using a merkelsw103k Tree.
 </li>
      </ul>
      
      <dl newline="true">
        <!-- Omit newline="true" if you want each definition to start on the same line as the corresponding term -->
        <dt>First term: SW103K</dt>
        <dd>Definition is the name of the protocol </dd>
        <dt>Second term: HaviPackets </dt>
        <dd>Definition is the packets name on the transport layer </dd>
      </dl>
      
      <table>
        <thead>
        <!--  a table header is optional -->
          <tr><th>Compression Command C</th></tr>
        </thead>
        <tbody>
          <tr><td>Decompression Command D </td></tr>
        </tbody>
      </table>

      <figure>
  <name>Source boiler code</name>
  <sourcecode name="network_app_protocol.c" type="c" markers="true">
<![CDATA[<CODE BEGINS>
#include "network_app_protocol.h"

int main() {
    // Initialize your custom protocol and
    // perform any necessary setup
    struct sw103k_proto mp;
    // Initialize mp and set its initial
    // state, buffers, etc.

    // Example function calls
    sendCommand(&mp, "CONNECT");
    authenticate(&mp, "networkuser",
               "networkpassword");

    // Continuously receive and process data
    while (1) {
        custom_receive(&mp, network_socket);
        // Replace 'network_socket' with your
        // actual socket
    }

    // Clean up and exit
    // Close sockets, free memory, etc.

    return 0;
}
<CODE ENDS>]]>
  </sourcecode>
</figure>

      <figure>
        <name>Diagram </name>
        <artset>
        <!-- This <artset> includes two <artwork> elements, each of a different type -->
          <artwork type="svg" src="https://www.rfc-editor.org/materials/format/svg/stream.svg" />
          <!--src points to either a local file or a URI. -->
          <artwork type="ascii-art" name="stream.txt">
            <!--  recommends a filename to use if the diagram is extracted -->  
            <![CDATA[
               +-----------------------------------------------------+
   |                Custom Protocol (C Code)             |
   +-----------------------------------------------------+
   |                                                     |
   |  +---------------------+     +----------------+     |
   |  | Compression         |     | Decompression  |     |
   |  | Functions           |     | Functions      |     |
   |  +---------------------+     +----------------+     |
   |        |                        |       |            |
   |        |                        |       |            |
   |  +-----v---+           +------v---+   |            |
   |  | Send    |           | Receive  |   |            |
   |  | Command |           | MP4 Data |   |            |
   |  | Function|           | Function |   |            |
   |  +---------+           +----------+   |            |
   |        |                   |         |            |
   |        |                   |         |            |
   |  +-----v-------------------v---------v----+       |
   |  |          Main Protocol Handling           |       |
   |  |              (sw103k_proto_parse_pkt)       |       |
   |  +------------------------------------------+       |
   |        |                                          |
   |        |                                          |
   |  +-----v-------------------------------+         |
   |  |             merkelsw103k Tree            |         |
   |  |       Construction and Integrity   |         |
   |  |             Verification            |         |
   |  +-----------------------------------+         |
   |        |                                      |
   |        |                                      |
   |  +-----v----------------------------------+  |
   |  |          State Management               |  |
   |  |     and Custom Hash Calculations       |  |
   |  +----------------------------------------+  |
   |        |                                    |
   |        |                                    |
   +--------v------------------------------------+
            |
            |
   +--------v------------------------------------+
   |               File Handling                 |
   |  (Sending and Receiving MP4 Data, File I/O) |
   +--------------------------------------------+
            |
            |
   +--------v------------------------------------+
   |          Custom Hash Functions              |
   |      (Hash Calculation and Combination)     |
   +--------------------------------------------+
   

 
            ]]>
          </artwork>
        </artset>
      </figure>
    </section>   
    
    <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 document should not affect the security of the Internet. </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://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
        <!-- The recommended and simplest way to include a well known reference -->
        
      </references>
 
      <references>
        <name>Informative References</name>
       
        <reference anchor="exampleRefMin">
        <!-- minimum reference -->
          <front>
            <title>Title </title>
            <author initials="Initials O.J" surname="garith ">
              <organization/>
            </author>
            <date year="2006"/>
            <!-- [CHECK] -->
          </front>
        </reference>

        <reference anchor="exampleRefOrg" target="http://www.example.com/">
        <!--  reference written by an organization not a person -->
          <front>
            <title>Title LLC</title>
            <author>
              <organization>IEEE 802 working group</organization>
            </author>
            <date year="1984"/>
            <!-- [CHECK] -->
          </front>
        </reference>       
       
      </references>
    </references>
    
    <section>
      <name>Appendix 1 </name>
      <t>Appendix</t>
    </section>

    <section anchor="Acknowledgements" numbered="false">
      <!--  an Acknowledgements section is optional -->
      <name>Acknowledgements</name>
      <t>This work is supported by chazha group </t>
    </section>
    
    <section anchor="Contributors" numbered="false">
      <!--  a Contributors section is optional -->
      <name>Contributors</name>
      <t>Thanks to chazah group ltd </t>
      <!-- [CHECK] it is optional to add a <contact> record for some or all contributors -->
    </section>

    <section anchor="changelog" numbered="false">
  <name>Change Log</name>
  <t>Changes in this version (draft-rfcxml-rfc-swl-103k-03):</t>
  <t>- Clarified the applicability of the SWL103K protocol to avoid implying</t>
  <t>  global deployment.</t>
  <t>- Updated normative language: changed "MUST be implemented by all network</t>
  <t>  devices" to a more realistic recommendation for scoped environments.</t>
  <t>- Responded to feedback from Area Directors regarding clarity and protocol</t>
  <t>  deployment assumptions.</t>
</section>

    
 </back>
</rfc>