Ouroboros - User contributions [en]

Prototype Version History

2026-02-22T16:59:51Z

Dimitri: /* 0.23 (Current version, February 22, 2026) */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 (Current version, February 22, 2026) ==

* Added PQC support to the library, including ML-KEM, Hybrid ECDH-KEM key exchange and ML-DSA and SLH-DSA based authentication.
* IRMd now negotiates encryption strength between endpoints based on lowest-floor exchange.
* Replaced the rdrbuff with per-user and priviliged shared slab allocator pools for shared memory packet buffers.
* Added automatic key rotation for encrypted flows.
* Refactored the ring buffer implementation and removed the old rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules, plus new targets for coverage reports and automatic version parsing from git tags.

== 0.22 ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:59:07Z

Dimitri: /* 0.23 (Current version, February 22, 2026) */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 (Current version, February 22, 2026) ==

* Added PQC support to the library, including ML-KEM, Hybrid ECDH-KEM key exchange and ML-DSA and SLH-DSA based authentication.
* IRMd now negotiates encryption strength between endpoints based on lowest-floor exchange.
* Replaced the rdrbuff with per-user and priviliged shared slab allocator pools for shared memory packet buffers.
* Added automatic key rotation for encrypted flows.
* Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules, plus new targets for coverage reports and automatic version parsing from git tags.

== 0.22 ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:58:10Z

Dimitri: /* 0.23 (Current version, February 22, 2026) */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 (Current version, February 22, 2026) ==

* Added PQC support to the library, including ML-KEM, Hybrid ECDH-KEM key exchange and ML-DSA and SLH-DSA based authentication.
* IRMd now negotiates encryption strength between endpoints,.
* Replaced the rdrbuff with per-user and priviliged shared slab allocator pools for shared memory packet buffers.
* Added automatic key rotation for encrypted flows.
* Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules, plus new targets for coverage reports and automatic version parsing from git tags.

== 0.22 ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:56:18Z

Dimitri: /* 0.23 (Current version, February 22, 2026) */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 (Current version, February 22, 2026) ==

* Added PQC support to the library, including ML-KEM, Hybrid ECDH-KEM and ML-DSA and SLH-DSA authentication.
* IRMd now negotiates encryption strength between endpoints,.
* Replaced the rdrbuff with per-user and priviliged shared slab allocator pools for shared memory packet buffers.
* Added automatic key rotation for encrypted flows.
* Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules, plus new targets for coverage reports and automatic version parsing from git tags.

== 0.22 ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:54:11Z

Dimitri: /* 0.23 (Current version, February 22, 2026) */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 (Current version, February 22, 2026) ==

* Added PQC support to the library, including ML-KEM, Hybrid ECDH-KEM and ML-DSA and SLH-DSA authentication.
* IRMd now negotiates encryption strength between endpoints, with fixes for client-side encryption requests.
* Replaced the rdrbuff with a proper slab allocator for shared memory packet buffers, a significant data-plane redesign.
* Added automatic key rotation for encrypted flows, with related fixes for IV/tag allocation and speedup of key rotation tests.
* Introduced per-user shared memory packet pools, improving multi-user isolation. Also added mlock() on shared memory buffers.
* Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules back to in-tree CMakeLists, plus new targets for coverage reports, build_tests, and automatic version parsing from git tags.

== 0.22 ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:53:49Z

Dimitri: /* 0.23 (Current version, February 22, 2026) */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 (Current version, February 22, 2026) ==

* Added PQC support to the library, including ML-KEM, Hybrid ECDH-KEM and ML-DSA and SLH-DSA.
* IRMd now negotiates encryption strength between endpoints, with fixes for client-side encryption requests.
* Replaced the rdrbuff with a proper slab allocator for shared memory packet buffers, a significant data-plane redesign.
* Added automatic key rotation for encrypted flows, with related fixes for IV/tag allocation and speedup of key rotation tests.
* Introduced per-user shared memory packet pools, improving multi-user isolation. Also added mlock() on shared memory buffers.
* Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules back to in-tree CMakeLists, plus new targets for coverage reports, build_tests, and automatic version parsing from git tags.

== 0.22 ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:52:57Z

Dimitri: /* 0.23 */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 (Current version, February 22, 2026) ==

* Added PQC support to the library, including SLH-DSA tests and per-algorithm gating, and PQC-aware config loading in IRMd.
* IRMd now negotiates encryption strength between endpoints, with fixes for client-side encryption requests.
* Replaced the rdrbuff with a proper slab allocator for shared memory packet buffers, a significant data-plane redesign.
* Added automatic key rotation for encrypted flows, with related fixes for IV/tag allocation and speedup of key rotation tests.
* Introduced per-user shared memory packet pools, improving multi-user isolation. Also added mlock() on shared memory buffers.
* Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules back to in-tree CMakeLists, plus new targets for coverage reports, build_tests, and automatic version parsing from git tags.

== 0.22 ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:52:31Z

Dimitri: /* 0.22 (Current version, November 7th 2025) */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 ==

* Added PQC support to the library, including SLH-DSA tests and per-algorithm gating, and PQC-aware config loading in IRMd.
* IRMd now negotiates encryption strength between endpoints, with fixes for client-side encryption requests.
* Replaced the rdrbuff with a proper slab allocator for shared memory packet buffers, a significant data-plane redesign.
* Added automatic key rotation for encrypted flows, with related fixes for IV/tag allocation and speedup of key rotation tests.
* Introduced per-user shared memory packet pools, improving multi-user isolation. Also added mlock() on shared memory buffers.
* Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules back to in-tree CMakeLists, plus new targets for coverage reports, build_tests, and automatic version parsing from git tags.

== 0.22 ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:52:13Z

Dimitri: /* 0.23 */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 ==

* Added PQC support to the library, including SLH-DSA tests and per-algorithm gating, and PQC-aware config loading in IRMd.
* IRMd now negotiates encryption strength between endpoints, with fixes for client-side encryption requests.
* Replaced the rdrbuff with a proper slab allocator for shared memory packet buffers, a significant data-plane redesign.
* Added automatic key rotation for encrypted flows, with related fixes for IV/tag allocation and speedup of key rotation tests.
* Introduced per-user shared memory packet pools, improving multi-user isolation. Also added mlock() on shared memory buffers.
* Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
* IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* Major refactoring of CMake modules back to in-tree CMakeLists, plus new targets for coverage reports, build_tests, and automatic version parsing from git tags.

== 0.22 (Current version, November 7th 2025) ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:51:29Z

Dimitri: /* 0.23 */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 ==

* Post-quantum cryptography support — Added PQC support to the library, including SLH-DSA tests and per-algorithm gating, and PQC-aware config loading in IRMd.
* Strength-based crypto negotiation — IRMd now negotiates encryption strength between endpoints, with fixes for client-side encryption requests.
* Slab allocator replacing rdrbuff — Replaced the rdrbuff with a proper slab allocator for shared memory packet buffers, a significant data-plane redesign.
* Automatic key rotation for encryption — Added automatic key rotation for encrypted flows, with related fixes for IV/tag allocation and speedup of key rotation tests.
* Per-user packet pools — Introduced per-user shared memory packet pools, improving multi-user isolation. Also added mlock() on shared memory buffers.
* rbuff refactoring — Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
* Direct rbuff between local processes — IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
* CMake build system overhaul — Major refactoring of CMake modules back to in-tree CMakeLists, plus new targets for coverage reports, build_tests, and automatic version parsing from git tags.

== 0.22 (Current version, November 7th 2025) ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Prototype Version History

2026-02-22T16:49:17Z

Dimitri: /* 0.23 (Current development branch) */

Ouroboros is still in an early proof-of-concept prototype phase. Versions 0.x.y have no forward nor backward compatibility. We bump minor version with API or protocol changes. Within a minor version, different patch levels ''should'' be compatible (no guarantees).

Once the functionality has reached a minimal critical mass, and a sufficient degree of software stability has been achieved, a version 1.0.0 will be released with the intention to maintain backwards compatibility from that point. This is still many (man)years off.

This page summarizes the progress and the plans for the next prototype (minor) version. For a summary of the current implementation state, see [[Ouroboros Implementation Overview| our status page]].

== 0.24 (Current development branch) ==

== 0.23 ==

# '''Post-quantum cryptography support''' — Added PQC support to the library, including SLH-DSA tests and per-algorithm gating, and PQC-aware config loading in IRMd.
# '''Slab allocator replacing rdrbuff''' — Replaced the rdrbuff with a proper slab allocator for shared memory packet buffers, a significant data-plane redesign.
# '''Automatic key rotation for encryption''' — Added automatic key rotation for encrypted flows, with related fixes for IV/tag allocation and speedup of key rotation tests.
# '''Strength-based crypto negotiation''' — IRMd now negotiates encryption strength between endpoints, with fixes for client-side encryption requests.
# '''Per-user packet pools''' — Introduced per-user shared memory packet pools, improving multi-user isolation. Also added mlock() on shared memory buffers.
# '''Rbuff refactoring''' — Refactored the ring buffer implementation and removed the old "lockless" rbuff_ll variant.
# '''Direct rbuff between local processes''' — IRMd now allows direct ring buffer connections between local processes, reducing overhead for same-machine IPC.
# '''Linked list with length tracking''' — Added struct llist to the library, providing list operations that also track element count.
# '''CMake build system overhaul''' — Major refactoring of CMake modules back to in-tree CMakeLists, plus new targets for coverage reports, build_tests, and automatic version parsing from git tags.
# '''Container compatibility & OS X fixes''' — Added a container compatibility build option, and fixed SSM pool creation, OpenSSL includes, and explicit_bzero on OS X.

== 0.22 (Current version, November 7th 2025) ==
* Added flow authentication and the Flow Allocation Protocol header in the irmd
* Added UDP/IPv6 support
* Added protocol level debug logging
* Moved encryption control from qosspec to naming system
* Removed qosspec parameter from the broadcast API
* Refactored and simplified enrolment and connection manager
* Complete rewrite of the DHT for the unicast layer
* Refactored Ethernet IPCPs
* Deprecated appveyor in favor of codeberg/woodpecker CI
* Improved test coverage
* Improved systemd service and pkgconfig installation logic
* Improved ctest integration into build system

== 0.21 ==
* Moved public key handling from library to IRMd
* Refactor of IRMd / registry implementation

== 0.20 ==
* Improved configuration file handling
* Improved FUSE stability
* Log unique IDs to enrollment requests
* Print logo on startup when logging to std output
* Fix most common hangs on exit

== 0.19 ==
* Pass the N-1 layer MPL at flow allocation
* Add flow liveness monitoring.
* Allow multiple directories in an IPCP
* Dropped support for raptor
* Use one UDP port for the IPCP over UDP/IPv4

== 0.18 ==
* Use QoS cube for ECN marking
* Always use 64-bit endpoint IDs
* Add RIB statistics for flow allocator
* Add congestion avoidance policies
* Add flow control policies
* Add GCC 10 static analyzer build option

== 0.17 ==
* Rename systemd service to ouroboros
* Add tests for LFA and ECMP routing
* Add Equal-Cost Multi-Path routing policy

== 0.16 ==
* Removed support for SWIG bindings
* Add support for appveyor CI
* Add encryption support using OpenSSL

== 0.15 ==
* Rename normal IPCP to unicast IPCP
* Add flow_join API for broadcast IPCP

== 0.14 ==
* Add Explicit Congestion Notification field to DT
* Add broadcast IPCP

== 0.13 ==
* Disable CRC32 by default

== 0.12 ==
* Split error checking from FRCT
* Rename port_id to flow_id
* Rename SDU to packet
* Pass QoS spec at flow allocation
* Initial retransmission logic
* Support QoS specs for oping
* Use Endpoint ID's in fa protocol instead of fd

== 0.11 ==
* Simplify reg/unreg API
* Support for partial packet reads
* Add IPCP over Ethernet DIX

== 0.10 ==
* Revise lookup tracking in DHT
* Update man pages to CC-BY 4.0

== 0.9 ==
* Add patchlevels for future versions
* Add support for Raptor FPGA Layer-1 PoC

== 0.8 ==
* Use "program" instead of "application process"
* Use "process" instead of "application process instance"
* Send timestamp in oping
* Use 3-clause BSD license for tools

== 0.7 ==
* Use ELF sections to init/fini ouroboros
* Simplify PFT for LFA routing
* Add RIB to expose metrics via FUSE
* Deprecate Common Distribution Application Protocol (CDAP)
* Simplify enroll API
* Deprecate Graph Adjancency Manager component

== 0.6 ==
* Added a threadpool manager for improved concurrency
* Added Loop-Free Alternates (LFA) routing
* Add DHT as default directory policy

== 0.5 ==
* Move FRCT logic from IPCP to application library
* Split connection establishment from flow allocation
* Split flow manager into flow allocator and data transfer
* Register hashes in a layer instead of cleartext name
* Add netmap support for LLC shim
* Initial lockless rbuff implementation
* Add generic thread pool management
* Revise flow allocation API
* Split authentication from CACEP
* Revise CACEP API
* Exchange application protocol information during CACEP

== 0.4 ==
* Add support for syslog logging
* Revise RIB/CDAP as a btree structure
* Add B-tree implementation
* Add full-mesh policy for GAM
* Add Graph Adjacency Manager (GAM)
* Add flat address policy
* Add initial directory to normal IPCP
* Initial RIB/CDAP synchronization
* Add RIB/CDAP objects
* Add operf tool

== 0.3 ==
* Move all shared memory (shm) mgmt to IRMd
* Use shared memory tx/rx ring buffer per flow
* Split off bind/unbind (map/unmap name to process) from reg/unreg

== 0.2 ==
* Add shim DIF over LLC Ethernet
* Add CBR tool for performance testing
* Add IPCP over local memory

== 0.1 ==
* Add full flow allocator to UDP shim
* Implementation of flow related ops
* Simple echo application
* Initial shim IPCP over UDP/IPv4
* Add RINA name helpers
* Initial library code
* Initial SDU/PDU buffer code
* Initial APIs for IRM/IPCP/CFAP/DIF allocator
* Initial CDAP header
* LICENSE and CONTRIBUTORS files
* Initial documenents and GPLv2 license

Ouroboros Tutorial 06

2026-02-14T15:16:19Z

Dimitri: /* Test 1: No Authentication, No Encryption */

= Ouroboros Tutorial 06 - Authenticated Flows =

This tutorial demonstrates setting up and using authenticated flows in Ouroboros with certificate-based authentication.

The overall flow of authenticated flow allocation is

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

'''Tutorial Directory:''' This tutorial will execute in <code>/tmp/o7s-tut06/</code>. All configuration files, generated certificates, logs, and packet captures will be stored in this directory.

We create a complete PKI (Public Key Infrastructure):

* '''Root CA''' (<code>ca.tut.o7s</code>): Self-signed trust anchor
* '''Intermediate CA''' (<code>sign.tut.o7s</code>): Signed by root with pathlen:0 constraint
* '''Server Certificate''' (<code>sec.oping.tut.o7s</code>): Signed by intermediate CA

This tutorial uses ECDSA P-384 with SHA-384 hashing.

== Setting Up the Tutorial ==

To properly understand and debug the authenticated flows, this tutorial uses a debug build of Ouroboros with OAP protocol debugging enabled.

<syntaxhighlight lang="bash">
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
</syntaxhighlight>

When built with these options, the IRMd will output detailed OAP protocol information.

=== Configuration Files ===

The following three files should be created in the tutorial directory (<code>/tmp/o7s-tut06/</code>) before starting the tutorial:

'''tut06.conf''' - IRMd configuration

<syntaxhighlight lang="ini">
# Ouroboros Tutorial 06 - Authenticated Flows Configuration
# Uses system-installed certificates at /etc/ouroboros/security/

[name."sec.oping.tut.o7s"]
prog=["/usr/bin/oping"]
args=["--listen"]

[eth-dix.eth-dix-lo]
bootstrap="eth-dix-network"
dev="lo"
reg=["sec.oping.tut.o7s"]
</syntaxhighlight>

'''ca.tut.o7s.cnf''' - OpenSSL configuration for PKI generation

<syntaxhighlight lang="text">
# Unified OpenSSL Configuration for Ouroboros Tutorial 06
# Named CA sections: CA_root (signs intermediate), CA_intermediate (signs server)
# Usage: openssl ca -name CA_root -config ca.tut.o7s.cnf ...

[ req ]
default_bits = 384
default_keyfile = private/key.pem
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha384
x509_extensions = v3_ca

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name

countryName_default = BE
stateOrProvinceName_default = OVL
localityName_default = Ghent
organizationName_default = o7s

[ ca ]
default_ca = CA_root

[ CA_root ]
dir = ./pki/root
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.tut.o7s.crt.pem
private_key = $dir/private/ca.tut.o7s.key.pem
default_days = 3650
default_md = sha384
policy = policy_loose

[ CA_intermediate ]
dir = ./pki/sign
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/sign.tut.o7s.crt.pem
private_key = $dir/private/sign.tut.o7s.key.pem
default_days = 365
default_md = sha384
policy = policy_loose

[ policy_loose ]
commonName = supplied

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
</syntaxhighlight>

'''gen-pki.sh''' - PKI generation script

This script will:
1. Create the directory structure
2. Generate the root CA key and certificate
3. Generate the intermediate CA key and CSR
4. Sign the intermediate CA certificate
5. Generate the server certificate key and CSR
6. Sign the server certificate
7. Verify the complete certificate chain

<syntaxhighlight lang="bash">
#!/bin/bash
# Ouroboros Tutorial 06 - PKI Generation Script (Simplified)
# Generates: Root CA, Intermediate CA, and Server Certificate

set -e

if [ ! -f ca.tut.o7s.cnf ]; then
echo "ERROR: ca.tut.o7s.cnf not found"
exit 1
fi

mkdir -p pki/{root,sign,server}/{certs,private,csr}

# Root CA
openssl ecparam -genkey -name secp384r1 -out pki/root/private/ca.tut.o7s.key.pem 2>/dev/null
openssl req -new -x509 -sha384 -days 7300 \
-config ca.tut.o7s.cnf \
-key pki/root/private/ca.tut.o7s.key.pem \
-out pki/root/certs/ca.tut.o7s.crt.pem \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=ca.tut.o7s" 2>/dev/null

# Intermediate CA
openssl ecparam -genkey -name secp384r1 -out pki/sign/private/sign.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/sign/private/sign.tut.o7s.key.pem \
-out pki/sign/csr/sign.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sign.tut.o7s" 2>/dev/null

touch pki/root/index.txt
echo 1000 > pki/root/serial

openssl ca -name CA_root -config ca.tut.o7s.cnf \
-extensions v3_intermediate_ca -days 3650 -md sha384 -batch \
-in pki/sign/csr/sign.tut.o7s.csr \
-out pki/sign/certs/sign.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Server Certificate
openssl ecparam -genkey -name secp384r1 -out pki/server/private/sec.oping.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/server/private/sec.oping.tut.o7s.key.pem \
-out pki/server/csr/sec.oping.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sec.oping.tut.o7s" 2>/dev/null

touch pki/sign/index.txt
echo 1000 > pki/sign/serial

openssl ca -name CA_intermediate -config ca.tut.o7s.cnf \
-extensions server_cert -days 365 -md sha384 -batch \
-in pki/server/csr/sec.oping.tut.o7s.csr \
-out pki/server/certs/sec.oping.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Verify chain
openssl verify -CAfile pki/root/certs/ca.tut.o7s.crt.pem \
-untrusted pki/sign/certs/sign.tut.o7s.crt.pem \
pki/server/certs/sec.oping.tut.o7s.crt.pem > /dev/null 2>&1

echo "PKI generation complete."
</syntaxhighlight>

== Part 1: Running the Tutorial - Single Session with 4 Tests ==

This section demonstrates a single continuous session with one IRMd and tcpdump instance. The configuration file (<code>tut06.conf</code>) includes autostart for oping, so the server is ready immediately when IRMd starts.

First install the '''CA and Intermediate CA only''' to the system security directories. The server certificate will be installed later during Test 3 (authentication test):

<syntaxhighlight lang="bash">
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}

# Run the PKI generation script
cd /tmp/o7s-tut06
sudo chmod +x gen-pki.sh
sudo ./gen-pki.sh

# Install Root CA (trust anchor)
sudo cp pki/root/certs/ca.tut.o7s.crt.pem /etc/ouroboros/security/cacert/

# Install Intermediate CA (for certificate chain validation)
sudo cp pki/sign/certs/sign.tut.o7s.crt.pem /etc/ouroboros/security/untrusted/
</syntaxhighlight>

=== Running the Tutorial (3 Terminals) ===

In this tutorial, we run a single IRMd session with a concurrent tcpdump instance to capture it. We then run four oping client tests while the IRMd/tcpdump sessions are going, modifying the security configuration between tests. After the tests are complete, we can will down the IRMd and tcpdump sessions with Ctrl-C.

'''Terminal 1: Start tcpdump to capture all packets (runs continuously)'''

<syntaxhighlight lang="bash">
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
</syntaxhighlight>

'''Terminal 2: Start IRMd with debug output (runs continuously)'''

<syntaxhighlight lang="bash">
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
</syntaxhighlight>

'''Terminal 3: Run the tests'''

==== Test 1: No Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Verify directories are empty
sudo ls -la /etc/ouroboros/security/client/sec.oping.tut.o7s/*
sudo ls -la /etc/ouroboros/security/server/sec.oping.tut.o7s/*

# Run first ping test
echo "=== Test 1: No Authentication, No Encryption ==="
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 1: Client initiates plaintext flow allocation'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:56 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 1: Server accepts and completes handshake'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' All OAP fields are <code><none></code> because no security is configured (except for the request hash in the response). Flow succeeds with plaintext communication.

==== Test 2: No Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run second ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 2: Client initiates flow with encryption enabled'''

<syntaxhighlight lang="text">
irmd/oap(II): Encryption enabled for sec.oping.tut.o7s.
irmd/oap(DB): [80fd6f9509a996b0] Generated ephemeral prime256v1 keys (91 bytes).
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 2: Server receives and responds with ephemeral key'''

<syntaxhighlight lang="text">
irmd/oap(DB): [80fd6f9509a996b0] No crt provided.
irmd/oap(DB): [80fd6f9509a996b0] Selected client cipher aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Selected client KDF sha256.
irmd/oap(II): [80fd6f9509a996b0] No key exchange.
irmd/oap(DB): [80fd6f9509a996b0] Generated prime256v1 ephemeral keys.
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' Both client and server generate ephemeral keys (91 bytes each) for encryption. No certificates because authentication is not required. Encryption and authentication are independent.

==== Test 3: With Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Install server certificates and keys
sudo cp /tmp/o7s-tut06/pki/server/certs/sec.oping.tut.o7s.crt.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/crt.pem
sudo cp /tmp/o7s-tut06/pki/server/private/sec.oping.tut.o7s.key.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/key.pem

# enc.conf is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 3: Client initiates flow with encryption and server has certificate'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] <--
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] -->
irmd/oap(PP): crt: [560 bytes]
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 3: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
irmd/oap(DB): [c904b18b563dc1b0] Loaded peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Got public key from crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully verified peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully authenticated peer.
</syntaxhighlight>

'''Key observations:''' Full OAP handshake with certificate (560 bytes) + ephemeral keys (91 bytes) + signature (103 bytes). Client verifies server's certificate against CA store and confirms authentication success.

==== Test 4: With Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [03e47baa966a5823 @ 2026-02-14 14:09:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>

'''IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [03e47baa966a5823 @ 2026-02-14 14:09:57 (UTC) ] -->
irmd/oap(PP): crt: [560 bytes]
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 4: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
irmd/oap(DB): [03e47baa966a5823] Loaded peer crt.
irmd/oap(DB): [03e47baa966a5823] Got public key from crt.
irmd/oap(DB): [03e47baa966a5823] Successfully verified peer crt.
irmd/oap(DB): [03e47baa966a5823] Successfully authenticated peer.
</syntaxhighlight>

'''Key observations:''' Server sends certificate + signature for authentication, but NO ephemeral keys (plaintext data). Data exchanged without encryption even though authenticated. Demonstrates that authentication and encryption are independent mechanisms.

=== Stop the IRMd and tcpdump, clean up the tutorial files ===

Once all tests complete:

<syntaxhighlight lang="bash">
# Stop IRMd in Terminal 2 (Ctrl+C)
# Stop tcpdump in Terminal 1 (Ctrl+C)

# Clean up tutorial security files from system
sudo rm -f /etc/ouroboros/security/cacert/ca.tut.o7s.crt.pem
</syntaxhighlight>

== Part 2: PCAP Trace Analysis ==

After the tutorial, we now explain the trace in the tcpdump pcap file.

=== Protocol Overview ===

This section summarizes the four protocols that work together in the captured packet flow.

==== Ethernet DIX Frame with EID Header ====

Ouroboros extends the DIX frame with a flow identifier (EID - Endpoint Identifier) and length field.

{| class="wikitable"
|-
! Field !! Octets !! Size !! Description
|-
| Destination MAC || 0-5 || 6 bytes || Hardware address of destination
|-
| Source MAC || 6-11 || 6 bytes || Hardware address of source
|-
| EtherType || 12-13 || 2 bytes || Protocol identifier (0xA000 for Ouroboros)
|-
| EID || 14-15 || 2 bytes || Destination Endpoint Identifier
|-
| Length || 16-17 || 2 bytes || Payload length (needed because of runt frame padding)
|-
| Payload || 18+ || Variable || Frame data (up to MTU size)
|}

==== Ethernet Flow Allocator - Management Protocol ====

The Ethernet DIX management protocol handles flow allocation, setup, and teardown. All management frames use destination EID <code>0x0000</code>.

'''Management Frame Types:'''

{| class="wikitable"
|-
! Code !! Type !! Direction !! Service Hash !! Purpose
|-
| <code>0x00</code> || <code>FLOW_REQ</code> || Client → Server || ✓ Included || Request new flow allocation
|-
| <code>0x01</code> || <code>FLOW_REPLY</code> || Server → Client || – Not included || Respond to flow request (success/failure)
|-
| <code>0x02</code> || <code>NAME_QUERY_REQ</code> || Client → Server || ✓ Included || Query if a remote name is reachable
|-
| <code>0x03</code> || <code>NAME_QUERY_REPLY</code> || Server → Client || ✓ Included || Response to name query
|}

'''Note:''' The 32-byte service hash (SHA3-256) is appended after the management protocol header for NAME_QUERY_* and FLOW_REQ messages to identify which service is being queried or allocated. FLOW_REPLY does not include the service hash; the endpoints are already identified by the allocated EIDs (SEID/DEID) and the flow allocation ID in the OAP header (see below).

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| SEID || 0-1 || 2 bytes || Source Endpoint ID
|-
| DEID || 2-3 || 2 bytes || Destination Endpoint ID
|-
| Loss || 4-7 || 4 bytes || Acceptable packet loss (ppm)
|-
| Bandwidth || 8-15 || 8 bytes || Required bandwidth (bps)
|-
| BER || 16-19 || 4 bytes || Bit error rate (ppm)
|-
| Max Gap || 20-23 || 4 bytes || Maximum consecutive lost packets
|-
| Delay || 24-27 || 4 bytes || Maximum latency (ms)
|-
| Timeout || 28-31 || 4 bytes || Flow idle timeout (seconds)
|-
| Response || 32-35 || 4 bytes || Response code (0=success, negative=error)
|-
| In-Order || 36 || 1 byte || In-order delivery requirement (boolean)
|-
| Code || 37 || 1 byte || Message type (FLOW_REQ, FLOW_REPLY, etc.)
|-
| Availability || 38 || 1 byte || Availability status
|-
| Service hash || 39-61 || 32 bytes || SHA3-256 hash (optional, see above)
|}

==== Ouroboros Flow Allocation Protocol (OAP) ====

The Ouroboros Application Protocol (OAP) is the flow allocation and authentication protocol. It carries flow negotiation requests, responses, and authentication credentials. OAP frames are encapsulated as data payload over the management protocol.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| ID || 0-15 || 16 bytes || Unique flow allocation identifier
|-
| Timestamp || 16-23 || 8 bytes || Creation timestamp (UTC, seconds and microseconds)
|-
| Crt Length || 24-25 || 2 bytes || Certificate length (bytes)
|-
| Certificate || 26+ || Variable || X.509 certificate (DER encoded)
|-
| Eph Length || Variable || 2 bytes || Ephemeral public key length (bytes)
|-
| Ephemeral Key || Variable || Variable || ECDHE public key (DER/raw encoded)
|-
| Data Length || Variable || 2 bytes || Application data length (bytes)
|-
| Data || Variable || Variable || Piggybacked application-layer data
|-
| Sig Length || Variable || 2 bytes || Signature length (bytes)
|-
| Signature || Variable || Variable || Digital signature (ECDSA, DER encoded)
|}

==== Oping Application Protocol ====

The Ouroboros Ping (oping) application is a simple echo/reply protocol used to measure round-trip time and validate connectivity between applications. It implements a request/reply pattern similar to ICMP ping.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| Type || 0-3 || 4 bytes || Message type (ECHO_REQUEST=0 or ECHO_REPLY=1)
|-
| ID || 4-7 || 4 bytes || Sequence number / message identifier
|-
| Timestamp (seconds) || 8-15 || 8 bytes || Seconds when message was sent (CLOCK_REALTIME)
|-
| Timestamp (nanoseconds) || 16-23 || 8 bytes || Nanoseconds component of timestamp
|-
| Payload || 24+ || Variable || Application data (configurable size, default 64 bytes)
|}

'''Field Definitions:'''

* '''Type''' (4 bytes): Message type selector
** <code>0x00000000</code> (ECHO_REQUEST): Client-to-server ping request
** <code>0x00000001</code> (ECHO_REPLY): Server-to-client response

* '''ID''' (4 bytes): Sequence number for matching requests with replies. Incremented for each ping sent.

* '''Timestamp (seconds)''' (8 bytes): Network-byte-order 64-bit seconds component from when the ping was sent (CLOCK_REALTIME).

* '''Timestamp (nanoseconds)''' (8 bytes): Network-byte-order 64-bit nanoseconds component (0-999999999) for high-resolution timing.

* '''Payload''' (Variable): Application data echoed back by the server. Size is configurable (default 64 bytes, maximum 1500 bytes).

'''Usage:'''

* Client sends ECHO_REQUEST with current timestamp
* Server receives request and echoes back as ECHO_REPLY with the same ID and timestamps
* Client calculates RTT by comparing reception time with original timestamps
* Out-of-order detection by tracking sequence numbers (ID field)

=== Packet Analysis: Test 1 - No authentication/encryption ===

==== Packet 1: NAME_QUERY_REQ ====

'''Summary:''' Client sends a NAME_QUERY_REQ message to discover if the service <code>sec.oping.tut.o7s</code> is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.165639 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0002 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

==== Packet 2: NAME_QUERY_REPLY ====

'''Summary:''' Server responds to the NAME_QUERY_REQ by sending a NAME_QUERY_REPLY for the service hash.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.166073 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0003 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code> (echoed back)
|}

==== Packet 3: FLOW_REQ ====

'''Summary:''' Client initiates a flow allocation request (FLOW_REQ) with minimal OAP headers since no authentication or encryption is being used.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.167222 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a51 8a56 ff6f ..f.i.._...Q.V.o
0x0050: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e103 [...}....0w.....
0x0060: 3e52 3300 0000 0000 0000 00 >R3........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || -- || '''UNUSED'''
|-
| 0x24-0x27 || <code>0001 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload'''

The OAP payload starts at offset 0x4b (after management protocol + service hash):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e103 3e52 33</code> || '''Timestamp''' || 8 || Network order || Creation timestamp (seconds + microseconds)
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 (first allocated flow ID for this session)
* Service hash is carried in management protocol payload (32 bytes)
* OAP header is minimal: only ID and timestamp, no optional fields
* No certificate, ephemeral key, data, or signature in this initial request
* Client sends minimal OAP headers with no authentication or encryption setup at allocation time

==== Packet 4: FLOW_REPLY ====

'''Summary:''' Server responds to FLOW_REQ by sending FLOW_REPLY with a new DEID (destination endpoint ID 0x0041) to establish the allocated flow for data transfer.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:49.178732 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0041 0040 0000 0000 0000 0000 ...G.A.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0051 8a56 ff6f ...........Q.V.o
0x0030: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e13f [...}....0w....?
0x0040: a347 3800 0000 0000 0000 00 .G8........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server-side flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0|| Response code (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload'''

The OAP payload starts at offset 0x2b (no service hash in FLOW_REPLY):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Echo of client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e13f a347 38</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x47-0x48 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x49-0x4a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0041 is the newly allocated server-side flow endpoint
* DEID 0x0040 reflects the client's flow ID, creating a bidirectional mapping
* No service hash included (FLOW_REPLY only needs the EIDs to identify the flow)
* OAP echoes the client's ID and timestamp, confirming the flow allocation
* Response code 0x00000000 indicates success
* Both client and server now have their respective flow IDs (0x0040 and 0x0041) for data transfer
* Response code 0x00000000 indicates success

==== Packet 5: ECHO_REQUEST - Plaintext Data ====

'''Summary:''' Client sends an oping ECHO_REQUEST packet to the server using the allocated flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.180824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 7377 0000 .A.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Source Endpoint ID (server → client)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REQUEST Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number (first ping)
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Seconds component
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Nanoseconds component
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (default 64 bytes total - 24 byte header = 40 bytes data)
|}

'''Key observations:'''
* EID 0x0041 shows traffic from server-side flow ID
* This is the first ping request (ID = 0x00000000)
* Timestamp captures when the ping was sent (seconds in network order)
* Default oping payload is 64 bytes total; 24 bytes header + 40 bytes data

==== Packet 6: ECHO_REPLY - Plaintext Data ====

'''Summary:''' Server receives the ECHO_REQUEST and immediately sends back an ECHO_REPLY with the same ID and timestamps, echoing the client's message.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.181496 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 7377 0000 .@.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client ← server)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REPLY Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Echo of original seconds
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Echo of original nanoseconds
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (unchanged from request)
|}

'''Key observations:'''
* EID 0x0040 shows traffic from client-side flow ID receiving the reply
* Type field changed from 0x00000000 (REQUEST) to 0x00000001 (REPLY)
* ID, timestamps, and payload data are identical to the request (echoed back)
* Round-trip time can be calculated by comparing current time with echoed timestamp
* Ping succeeded on first attempt with minimal latency (~1 millisecond between timestamps)

=== Packet Analysis: Test 2 - No authentication, with encryption ===

==== Packet 7: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with encryption enabled. This FLOW_REQ carries an OAP header with an ephemeral ECDHE P-384 public key (91 bytes) for encryption setup.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.808158 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8af1 766b 547c ..f.i.._....vkT|
0x0050: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0060: 8b6c 9000 0000 5b30 5930 1306 072a 8648 .l....[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 c508 1c19 6106 b7e9 3074 57b9 bb16 ......a...0tW...
0x0090: 6959 4a55 81f9 169b cc79 fe10 a882 41fe iYJU.....y....A.
0x00a0: 0697 c9b4 f8f0 5562 7fa2 c7a0 a020 1ac6 ......Ub........
0x00b0: 939f 23ff b2fb 07a2 b747 aacc 474a 3dab ..#......G..GJ=.
0x00c0: 2598 0000 0000 %.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Mixed || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 ... 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e253 8b6c 90</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 ... 3dab 2598</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || ECDHE P-384 public key (DER encoded)
|-
| 0xd3-0xd4 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd5-0xd6 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* Encryption enabled: ephemeral key present (91 bytes)
* Client sends no certificate, allowing anonymous encryption setup
* No signature (unsigned OAP)
* Ephemeral key is ECDHE P-384 for key exchange

==== Packet 8: FLOW_REPLY ====

'''Summary:''' Server accepts the encrypted flow allocation request. FLOW_REPLY contains the server's ephemeral key but no certificate (since client didn't send one).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.810564 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 180:
0x0000: 0000 00a2 0042 0040 0000 0000 0000 0000 .....B.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 00f1 766b 547c ............vkT|
0x0030: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0040: b694 e800 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0050: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0060: 0004 5f3c 6929 cca2 024a ae9f 9aa1 dfc2 .._<i)...J......
0x0070: a493 3ff3 ff58 b054 74dc d2e2 47fc 7c5b ..?..X.Tt...G.|[
0x0080: eff5 e129 72b4 de1e 7c09 bf8c fe38 5e8b ...)r...|....8^.
0x0090: b22e 59ed 6eb9 dfda 369d 691e 6e2c 122c ..Y.n...6.i.n,.,
0x00a0: 9936 0000 0000 .6....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00a2</code> || '''Length''' || 2 || 162 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0042</code> || '''SEID''' || 2 || 0x0042 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || Echo of client ID || Echoes client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e253 b694 e8</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x47-0xa1 || <code>30 5930...9936</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || Server's ECDHE P-384 public key (DER encoded)
|-
| 0xd1-0xd2 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd3-0xd4 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0042 is the new server-side flow endpoint
* Both keys are now exchanged; client and server can derive shared secret
* No authentication (no certificates) but encryption is negotiated
* Response indicates successful allocation

==== Packet 9: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after encryption keys are established. The payload is encrypted with the derived shared secret.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.815771 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0042 0060 a691 6d83 8446 cbeb ac95 c2eb .B.`..m..F......
0x0010: 4b42 e819 c67f 92c8 58d7 0641 d8a6 6e1f KB......X..A..n.
0x0020: fc90 feed ef55 b791 4fbd a832 74bd 8bed .....U..O..2t...
0x0030: 249c 4cee 0fc0 cec6 2f1b aec1 2428 bdbd $.L...../...$(..
0x0040: 36b5 01b5 1257 004e 6ed6 7ecd f0c7 7d11 6....W.Nn.~...}.
0x0050: 20ba e81b f43a 4de9 b141 1624 e1ba 0a84 .....:M..A.$....
0x0060: 74b1 9a9a t...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0042</code> || '''EID''' || 2 || 0x0042 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REQUEST (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>a691 6d83 8446 cbeb...74b1 9a9a</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* All 96 bytes of oping data (type, ID, timestamps, payload) are encrypted
* No plaintext oping headers visible; entire packet is ciphertext
* Flow IDs (0x0042) identify which encryption context to use
* Ping still works with encryption transparently

==== Packet 10: Encrypted ECHO_REPLY ====

'''Summary:''' Server receives encrypted ping request, decrypts it, and sends encrypted ECHO_REPLY.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.819574 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 c6ea 2222 5618 0268 b27e 9a91 .@.`..""V..h.~..
0x0010: f124 1f8d bccc 478c 26fe 9b13 b3cb 5398 .$....G.&.....S.
0x0020: 6869 3cdb 4928 510d 4de8 dc6a 3f3a 6a6d hi<.I(Q.M..j?:jm
0x0030: 6487 dcd8 c8cd 1a85 fba2 9ecd 3566 57d1 d...........5fW.
0x0040: 1c94 ac35 518e 8509 873a 3a5e 04d9 8ee2 ...5Q....::^....
0x0050: 9d74 2527 e425 5433 9d73 9ccd f56a 1f8d .t%'.%T3.s...j..
0x0060: f328 7237 .(r7
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REPLY (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>c6ea 2222 5618 0268...f328 7237</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* EID 0x0040 shows reply going back to client-side flow
* Ciphertext is different from request (different plaintext: type field differs)
* Both encrypted packets are 96 bytes (same size as Packet 9)
* Client receives encrypted reply, decrypts it, verifies ID and timestamps match request
* Encryption is transparent at application layer: oping works exactly as with plaintext flows

=== Packet Analysis: Test 3 - Authentication and encryption ===

==== Packet 11: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation request with encryption enabled. Sends ephemeral public key for ECDHE key exchange but no certificate (client is not authenticating in this tutorial). The management protocol now carries a valid allocated SEID (0x0040).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:58.827411 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a66 bb82 95fa ..f.i.._...f....
0x0050: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0060: c0d2 ad00 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 9dea c238 6732 4987 1cd4 7133 9614 .....8g2I...q3..
0x0090: 9d04 4fde 3f68 42f1 54fb 7ef3 88d0 ffe6 ..O.?hB.T.~.....
0x00a0: 7e01 432e 56c2 2d64 72c9 19fc b0cf 1eca ~.C.V.-dr.......
0x00b0: 689e 3536 771a 8041 726c 20e2 d9bb 3589 h.56w..Arl....5.
0x00c0: 86e7 0000 0000 ......
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (client flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ... 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier for Test 3
|-
| 0x5b-0x62 || <code>18 86a8 e37e c0d2 ad</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || Client not authenticating
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Ephemeral public key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 1306 ... 3589</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Client's ephemeral ECDHE public key for encryption negotiation
|-
| 0xc2-0xc3 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xc4-0xc5 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 - Same as Test 2 (Encrypted) because this is the same client session reusing the same allocated ID from the previous test
* No Certificate - <code>crt_len = 0x0000</code> because the client does not have authentication credentials; the server will authenticate instead
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> because encryption is enabled on the client
* No Signature - <code>sig_len = 0x0000</code> because client is not signing (no certificate to sign with)
* FLOW_REQ Message Type - Code field is 0x00, and service hash is present because FLOW_REQ always includes the service hash
* Timestamp Consistency - Same OAP ID and timestamp structure as Test 2, but with additional security handshake

==== Packet 12: FLOW_REPLY ====

'''Summary:''' Server responds to client's FLOW_REQ by sending FLOW_REPLY with its certificate for authentication, ephemeral public key for ECDHE encryption setup, and a digital signature proving ownership of the certificate. This is the full authentication response.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:39:58.828806 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 843:
0x0000: 0000 0339 0043 0040 0000 0000 0000 0000 ...9.C.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0066 bb82 95fa ...........f....
0x0030: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0040: d566 a002 2f30 8202 2b30 8201 b2a0 0302 .f../0..+0......
(... certificate and signature bytes ...)
0x0320: ef11 c358 f5d0 5cd7 3906 adf1 8a2c 9b25 ...X..\.9....,.%
0x0330: dc78 6050 ab61 3a3f 81c0 254b d193 7827 .x`P.a:?..%K..x'
0x0340: c0e9 38c7 e0d1 c517 d299 9992 07 ..8..........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0339</code> || '''Length''' || 2 || 825 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0043</code> || '''SEID''' || 2 || 0x0043 || Source Endpoint ID (server-side allocated flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (echoed back)
|-
| 0x3b-0x42 || <code>18 86a8 e37e d566 a0</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>022f</code> || '''Crt_len''' || 2 || 559 (0x022f) || Server certificate length: 559 bytes
|-
| 0x45-0x243 || <code>2f30 8202 2b ... 81c8 30</code> || '''Certificate''' || 559 || DER-encoded X.509 || Server's certificate (signed by intermediate CA)
|-
| 0x244-0x245 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Server's ephemeral public key length: 91 bytes
|-
| 0x246-0x2a0 || <code>30 5930 1306 ... 9936</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Server's ephemeral ECDHE public key
|-
| 0x2a4-0x2a5 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x2a6-0x2a7 || <code>0068</code> || '''Sig_len''' || 2 || 104 (0x0068) || Digital signature length: 104 bytes
|-
| 0x2a8-0x30f || <code>30 6602 3100 ... 07</code> || '''Signature''' || 104 || ECDSA signature (DER encoded) || Server's signature over OAP header proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0043 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from the FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Full Certificate - <code>crt_len = 0x022f (559)</code> carrying server's complete X.509 certificate signed by intermediate CA
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> with server's ECDHE public key for encryption
* Signature Included - <code>sig_len = 0x0068 (104)</code> containing ECDSA digital signature over the entire OAP header
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ to confirm association (included in signature, binding response to this specific client request)
* Large Payload - Total of 825 bytes due to certificate (559) + ephemeral key (91) + signature (104) + overhead
* Authentication Complete - Client verifies: (1) certificate against CA store, (2) signature over entire response ensures authenticity and integrity, (3) echoed ID binds response to this specific request, (4) timestamp prevents replay attacks

'''Summary:''' Server responds with its certificate for authentication, ephemeral public key for ECDHE encryption, and a digital signature proving ownership of the certificate.

==== Packet 13: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after authentication handshake. All application data is protected by encryption using the ephemeral keys established in Packets 11-12.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836485 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0043 0060 3bed 0b48 1be1 6930 cf3d dee9 .C.`.;..H..i0.=..
0x0010: 4fc9 774b 5d63 cc9b 5a34 6604 f9ac 1016 O.wK]c..Z4f.....
0x0020: 1c6d c9ac f80e dc89 31c1 9634 1a4f b2c7 .m......1..4.O..
0x0030: 4721 e402 8259 b0aa 8870 4566 33d1 9c18 G!...Y.. .pEf3...
0x0040: 06da 50c3 8b75 86b0 f240 d109 840e a6cd ..P..u...@......
0x0050: d115 77cb 5652 5bfb e6d5 0ca9 dbc3 d0b8 ..w.VR[.........
0x0060: 0058 fd19 .X..
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0043</code> || Client flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REQUEST data'''
|}

'''Key observations:'''
* No visible protocol structure - all application data appears as ciphertext
* Uses the same source/destination EID pair (0x0043 → 0x0060) established in the FLOW_REQ/FLOW_REPLY handshake
* Encryption is done using the ephemeral key (91 bytes) exchanged in Packet 11's OAP header
* Unlike Packets 11-12, this packet contains no certificate, public keys, or signatures
* The 110-byte encrypted data corresponds to the original oping ECHO_REQUEST message

==== Packet 14: Encrypted ECHO_REPLY ====

'''Summary:''' Server sends encrypted ping reply. Note that the flow identifiers swap, demonstrating bidirectional encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836930 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 d552 e100 e681 940c e35a 07d0 .@.`..........Z..
0x0010: a293 1d73 33a5 854e 0fce 4f4d 6655 267a ...s3..N..OMfU&z
0x0020: 3de2 663b 709d 739a a696 2ddd 7b34 28b8 =.f;p.s...-{4(...
0x0030: 5a98 eec2 52c6 4288 3885 ae16 e466 4181 Z...R.B.8...fA..
0x0040: f2d6 44c1 b51b 8728 58a4 7525 fb5e 3fd6 ..D...(X.u%.^?..
0x0050: 7e49 532a d2a5 bea7 55e9 c274 f1b2 0412 ~IS*....U..t....
0x0060: 73d4 6436 s.d6
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0040</code> || Client's inbound flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REPLY data'''
|}

'''Key observations:'''
* The EID in offset 0x00 is now 0x0040 (server's view of client's inbound flow)
* Uses the same ephemeral key material as Packet 13, but encryption direction is reversed
* Both packets use AES-GCM with keys derived from the ECDH exchange
* Timestamp 17:39:59.836930 is only 445 microseconds after Packet 13, indicating server-side processing
* The 110-byte encrypted ECHO_REPLY payload is the same size as the request
* All application data is protected by both authentication (X.509 + ECDSA) and encryption (AES)

=== Packet Analysis: Test 4 - Authentication, no encryption ===

==== Packet 15: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with authentication enabled but encryption disabled. This FLOW_REQ carries an OAP header but '''no ephemeral key''' since the client does not request encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:03.413372 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a8f a6ab 6ea7 ..f.i.._........
0x0050: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0060: 0de6 6100 0000 0000 0000 00 ..a.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... dc40</code> || '''QoS (Various)''' || 28 || Mixed ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e490 0de6 61</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key (no encryption)'''
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* No encryption enabled: ephemeral key absent (Eph_len = 0x0000)
* Client requests authentication only
* Server will respond with certificate + signature but no ephemeral key
* Packet is minimal compared to Packet 11 (Test 3) which includes 91-byte ephemeral key

==== Packet 16: FLOW_REPLY ====

'''Summary:''' Server accepts the authenticated (but not encrypted) flow allocation request. FLOW_REPLY contains the server's X.509 certificate and ECDSA signature for client authentication, but '''no ephemeral key''' since encryption is not being used.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:40:03.416675 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 751:
0x0000: 0000 02dd 0041 0040 0000 0000 0000 0000 .......A.@......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 008f a6ab 6ea7 ................
0x0030: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0040: 3754 a702 2f30 8202 2b30 8201 b2a0 0302 7T../0..+0......
0x0050: 0102 0202 1000 300a 0608 2a86 48ce 3d04 ......0...*.H.=.
(... certificate and signature bytes ...)
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>02dd</code> || '''Length''' || 2 || 733 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (Packet 15 echoed back)
|-
| 0x3b-0x42 || <code>fa18 86a8 e490 3754</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>a702</code> || '''Crt_len''' || 2 || 0x02a7 (679 decimal) || '''Certificate length: 679 bytes'''
|-
| 0x45-0x270 || <code>2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ...</code> || '''Certificate''' || 679 || DER-encoded X.509 || Server's certificate signed by intermediate CA
|-
| 0x271-0x272 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key''' (no encryption)
|-
| 0x273-0x274 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x275-0x276 || <code>0067</code> || '''Sig_len''' || 2 || 0x0067 (103 decimal) || '''ECDSA signature length: 103 bytes'''
|-
| 0x277-0x2dd || <code>3065 0230 75dc 5717 ... 83</code> || '''Signature''' || 103 || ECDSA signature (DER encoded) || Server's ECDSA signature proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0041 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from Packet 15 FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Certificate Field - <code>crt_len = 0x02a7 (679)</code> carrying server's X.509 certificate signed by intermediate CA
* Separate Signature Field - <code>sig_len = 0x0067 (103)</code> with ECDSA signature over entire OAP header
* No Ephemeral Key - <code>eph_len = 0x0000</code> since encryption is '''not''' being used in Test 4
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ (included in signature, binding response to this specific client request)
* Complete OAP Structure - Full OAP header with all standard fields, just without ephemeral key data
* Plaintext Data Exchange - After this FLOW_REPLY, all subsequent application data will be transmitted in plaintext (but authenticated via certificate + signature verification)

==== Packet 17: ECHO_REQUEST ====

'''Summary:''' Client sends plaintext ECHO_REQUEST data through the authenticated (but unencrypted) flow. The oping application's ping request is transmitted directly without encryption, relying on the earlier certificate+signature authentication for security.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.419664 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 8177 0000 .A.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Request (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number / message identifier
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Seconds component from CLOCK_REALTIME
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Nanoseconds component (0-999999999)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0041 → Server Flow - Data is directed to the server's endpoint ID allocated in Packet 16 FLOW_REPLY
* Plaintext Transmission - No encryption layer; oping payload is sent as-is (compare to Packet 13 which had encryption)
* Authenticated Flow - Although plaintext, this data travels on the authenticated flow established in Packet 16 (certificate + signature verified)
* Type = ECHO_REQUEST - 0x00000000 indicates client-to-server ping request
* ID = 0 - Sequence number for matching request/reply pairs
* Test 4 Characteristic - Demonstrates authenticated communication '''without''' encryption; application data is readable but cryptographically bound to the authenticated flow
* Contrast to Test 3 - Packet 13 (Test 3 encrypted ECHO_REQUEST) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

==== Packet 18: ECHO_REPLY ====

'''Summary:''' Server responds with plaintext ECHO_REPLY data, echoing back the client's request. This confirms successful bidirectional communication over the authenticated (but unencrypted) flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.420088 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 8177 0000 .@.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Reply (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (seconds)
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (nanoseconds)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Echoed probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0040 → Client Flow - Server responds to client's endpoint ID from Packet 15 FLOW_REQ
* Type = ECHO_REPLY - 0x00000001 indicates server-to-client response
* ID = 0 - Echoes the request sequence number, matching this response to the request
* Timestamps Echo Request - Both timestamp fields are copied from Packet 17 unchanged (8177 0000 0000 0000 and aa16 1c16 0000 0000)
* Plaintext Reply - No encryption; server's response payload is readable (compare to Packet 14 which had encryption)
* Authenticated Channel - Although plaintext, this reply is part of the authenticated flow; client can verify integrity through earlier certificate+signature
* Test 4 Completion - Demonstrates '''full bidirectional plaintext communication''' over an authenticated (but unencrypted) flow
* Contrast to Test 3 - Packet 14 (Test 3 encrypted ECHO_REPLY) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

Ouroboros Tutorial 06

2026-02-14T15:15:44Z

Dimitri: /* Test 2: No Authentication, With Encryption */

= Ouroboros Tutorial 06 - Authenticated Flows =

This tutorial demonstrates setting up and using authenticated flows in Ouroboros with certificate-based authentication.

The overall flow of authenticated flow allocation is

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

'''Tutorial Directory:''' This tutorial will execute in <code>/tmp/o7s-tut06/</code>. All configuration files, generated certificates, logs, and packet captures will be stored in this directory.

We create a complete PKI (Public Key Infrastructure):

* '''Root CA''' (<code>ca.tut.o7s</code>): Self-signed trust anchor
* '''Intermediate CA''' (<code>sign.tut.o7s</code>): Signed by root with pathlen:0 constraint
* '''Server Certificate''' (<code>sec.oping.tut.o7s</code>): Signed by intermediate CA

This tutorial uses ECDSA P-384 with SHA-384 hashing.

== Setting Up the Tutorial ==

To properly understand and debug the authenticated flows, this tutorial uses a debug build of Ouroboros with OAP protocol debugging enabled.

<syntaxhighlight lang="bash">
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
</syntaxhighlight>

When built with these options, the IRMd will output detailed OAP protocol information.

=== Configuration Files ===

The following three files should be created in the tutorial directory (<code>/tmp/o7s-tut06/</code>) before starting the tutorial:

'''tut06.conf''' - IRMd configuration

<syntaxhighlight lang="ini">
# Ouroboros Tutorial 06 - Authenticated Flows Configuration
# Uses system-installed certificates at /etc/ouroboros/security/

[name."sec.oping.tut.o7s"]
prog=["/usr/bin/oping"]
args=["--listen"]

[eth-dix.eth-dix-lo]
bootstrap="eth-dix-network"
dev="lo"
reg=["sec.oping.tut.o7s"]
</syntaxhighlight>

'''ca.tut.o7s.cnf''' - OpenSSL configuration for PKI generation

<syntaxhighlight lang="text">
# Unified OpenSSL Configuration for Ouroboros Tutorial 06
# Named CA sections: CA_root (signs intermediate), CA_intermediate (signs server)
# Usage: openssl ca -name CA_root -config ca.tut.o7s.cnf ...

[ req ]
default_bits = 384
default_keyfile = private/key.pem
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha384
x509_extensions = v3_ca

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name

countryName_default = BE
stateOrProvinceName_default = OVL
localityName_default = Ghent
organizationName_default = o7s

[ ca ]
default_ca = CA_root

[ CA_root ]
dir = ./pki/root
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.tut.o7s.crt.pem
private_key = $dir/private/ca.tut.o7s.key.pem
default_days = 3650
default_md = sha384
policy = policy_loose

[ CA_intermediate ]
dir = ./pki/sign
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/sign.tut.o7s.crt.pem
private_key = $dir/private/sign.tut.o7s.key.pem
default_days = 365
default_md = sha384
policy = policy_loose

[ policy_loose ]
commonName = supplied

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
</syntaxhighlight>

'''gen-pki.sh''' - PKI generation script

This script will:
1. Create the directory structure
2. Generate the root CA key and certificate
3. Generate the intermediate CA key and CSR
4. Sign the intermediate CA certificate
5. Generate the server certificate key and CSR
6. Sign the server certificate
7. Verify the complete certificate chain

<syntaxhighlight lang="bash">
#!/bin/bash
# Ouroboros Tutorial 06 - PKI Generation Script (Simplified)
# Generates: Root CA, Intermediate CA, and Server Certificate

set -e

if [ ! -f ca.tut.o7s.cnf ]; then
echo "ERROR: ca.tut.o7s.cnf not found"
exit 1
fi

mkdir -p pki/{root,sign,server}/{certs,private,csr}

# Root CA
openssl ecparam -genkey -name secp384r1 -out pki/root/private/ca.tut.o7s.key.pem 2>/dev/null
openssl req -new -x509 -sha384 -days 7300 \
-config ca.tut.o7s.cnf \
-key pki/root/private/ca.tut.o7s.key.pem \
-out pki/root/certs/ca.tut.o7s.crt.pem \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=ca.tut.o7s" 2>/dev/null

# Intermediate CA
openssl ecparam -genkey -name secp384r1 -out pki/sign/private/sign.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/sign/private/sign.tut.o7s.key.pem \
-out pki/sign/csr/sign.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sign.tut.o7s" 2>/dev/null

touch pki/root/index.txt
echo 1000 > pki/root/serial

openssl ca -name CA_root -config ca.tut.o7s.cnf \
-extensions v3_intermediate_ca -days 3650 -md sha384 -batch \
-in pki/sign/csr/sign.tut.o7s.csr \
-out pki/sign/certs/sign.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Server Certificate
openssl ecparam -genkey -name secp384r1 -out pki/server/private/sec.oping.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/server/private/sec.oping.tut.o7s.key.pem \
-out pki/server/csr/sec.oping.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sec.oping.tut.o7s" 2>/dev/null

touch pki/sign/index.txt
echo 1000 > pki/sign/serial

openssl ca -name CA_intermediate -config ca.tut.o7s.cnf \
-extensions server_cert -days 365 -md sha384 -batch \
-in pki/server/csr/sec.oping.tut.o7s.csr \
-out pki/server/certs/sec.oping.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Verify chain
openssl verify -CAfile pki/root/certs/ca.tut.o7s.crt.pem \
-untrusted pki/sign/certs/sign.tut.o7s.crt.pem \
pki/server/certs/sec.oping.tut.o7s.crt.pem > /dev/null 2>&1

echo "PKI generation complete."
</syntaxhighlight>

== Part 1: Running the Tutorial - Single Session with 4 Tests ==

This section demonstrates a single continuous session with one IRMd and tcpdump instance. The configuration file (<code>tut06.conf</code>) includes autostart for oping, so the server is ready immediately when IRMd starts.

First install the '''CA and Intermediate CA only''' to the system security directories. The server certificate will be installed later during Test 3 (authentication test):

<syntaxhighlight lang="bash">
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}

# Run the PKI generation script
cd /tmp/o7s-tut06
sudo chmod +x gen-pki.sh
sudo ./gen-pki.sh

# Install Root CA (trust anchor)
sudo cp pki/root/certs/ca.tut.o7s.crt.pem /etc/ouroboros/security/cacert/

# Install Intermediate CA (for certificate chain validation)
sudo cp pki/sign/certs/sign.tut.o7s.crt.pem /etc/ouroboros/security/untrusted/
</syntaxhighlight>

=== Running the Tutorial (3 Terminals) ===

In this tutorial, we run a single IRMd session with a concurrent tcpdump instance to capture it. We then run four oping client tests while the IRMd/tcpdump sessions are going, modifying the security configuration between tests. After the tests are complete, we can will down the IRMd and tcpdump sessions with Ctrl-C.

'''Terminal 1: Start tcpdump to capture all packets (runs continuously)'''

<syntaxhighlight lang="bash">
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
</syntaxhighlight>

'''Terminal 2: Start IRMd with debug output (runs continuously)'''

<syntaxhighlight lang="bash">
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
</syntaxhighlight>

'''Terminal 3: Run the tests'''

==== Test 1: No Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Verify directories are empty
sudo ls -la /etc/ouroboros/security/client/sec.oping.tut.o7s/*
sudo ls -la /etc/ouroboros/security/server/sec.oping.tut.o7s/*

# Run first ping test
echo "=== Test 1: No Authentication, No Encryption ==="
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 1: Client initiates plaintext flow allocation'''

<syntaxhighlight lang="text">
irmd/oap(DB): [60e824383b3fbd6a] KEX config: algo=none, mode=server-encap, cipher=none.
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:56 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 1: Server accepts and completes handshake'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' All OAP fields are <code><none></code> because no security is configured (except for the request hash in the response). Flow succeeds with plaintext communication.

==== Test 2: No Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run second ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 2: Client initiates flow with encryption enabled'''

<syntaxhighlight lang="text">
irmd/oap(II): Encryption enabled for sec.oping.tut.o7s.
irmd/oap(DB): [80fd6f9509a996b0] Generated ephemeral prime256v1 keys (91 bytes).
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 2: Server receives and responds with ephemeral key'''

<syntaxhighlight lang="text">
irmd/oap(DB): [80fd6f9509a996b0] No crt provided.
irmd/oap(DB): [80fd6f9509a996b0] Selected client cipher aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Selected client KDF sha256.
irmd/oap(II): [80fd6f9509a996b0] No key exchange.
irmd/oap(DB): [80fd6f9509a996b0] Generated prime256v1 ephemeral keys.
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' Both client and server generate ephemeral keys (91 bytes each) for encryption. No certificates because authentication is not required. Encryption and authentication are independent.

==== Test 3: With Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Install server certificates and keys
sudo cp /tmp/o7s-tut06/pki/server/certs/sec.oping.tut.o7s.crt.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/crt.pem
sudo cp /tmp/o7s-tut06/pki/server/private/sec.oping.tut.o7s.key.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/key.pem

# enc.conf is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 3: Client initiates flow with encryption and server has certificate'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] <--
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] -->
irmd/oap(PP): crt: [560 bytes]
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 3: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
irmd/oap(DB): [c904b18b563dc1b0] Loaded peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Got public key from crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully verified peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully authenticated peer.
</syntaxhighlight>

'''Key observations:''' Full OAP handshake with certificate (560 bytes) + ephemeral keys (91 bytes) + signature (103 bytes). Client verifies server's certificate against CA store and confirms authentication success.

==== Test 4: With Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [03e47baa966a5823 @ 2026-02-14 14:09:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>

'''IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [03e47baa966a5823 @ 2026-02-14 14:09:57 (UTC) ] -->
irmd/oap(PP): crt: [560 bytes]
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 4: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
irmd/oap(DB): [03e47baa966a5823] Loaded peer crt.
irmd/oap(DB): [03e47baa966a5823] Got public key from crt.
irmd/oap(DB): [03e47baa966a5823] Successfully verified peer crt.
irmd/oap(DB): [03e47baa966a5823] Successfully authenticated peer.
</syntaxhighlight>

'''Key observations:''' Server sends certificate + signature for authentication, but NO ephemeral keys (plaintext data). Data exchanged without encryption even though authenticated. Demonstrates that authentication and encryption are independent mechanisms.

=== Stop the IRMd and tcpdump, clean up the tutorial files ===

Once all tests complete:

<syntaxhighlight lang="bash">
# Stop IRMd in Terminal 2 (Ctrl+C)
# Stop tcpdump in Terminal 1 (Ctrl+C)

# Clean up tutorial security files from system
sudo rm -f /etc/ouroboros/security/cacert/ca.tut.o7s.crt.pem
</syntaxhighlight>

== Part 2: PCAP Trace Analysis ==

After the tutorial, we now explain the trace in the tcpdump pcap file.

=== Protocol Overview ===

This section summarizes the four protocols that work together in the captured packet flow.

==== Ethernet DIX Frame with EID Header ====

Ouroboros extends the DIX frame with a flow identifier (EID - Endpoint Identifier) and length field.

{| class="wikitable"
|-
! Field !! Octets !! Size !! Description
|-
| Destination MAC || 0-5 || 6 bytes || Hardware address of destination
|-
| Source MAC || 6-11 || 6 bytes || Hardware address of source
|-
| EtherType || 12-13 || 2 bytes || Protocol identifier (0xA000 for Ouroboros)
|-
| EID || 14-15 || 2 bytes || Destination Endpoint Identifier
|-
| Length || 16-17 || 2 bytes || Payload length (needed because of runt frame padding)
|-
| Payload || 18+ || Variable || Frame data (up to MTU size)
|}

==== Ethernet Flow Allocator - Management Protocol ====

The Ethernet DIX management protocol handles flow allocation, setup, and teardown. All management frames use destination EID <code>0x0000</code>.

'''Management Frame Types:'''

{| class="wikitable"
|-
! Code !! Type !! Direction !! Service Hash !! Purpose
|-
| <code>0x00</code> || <code>FLOW_REQ</code> || Client → Server || ✓ Included || Request new flow allocation
|-
| <code>0x01</code> || <code>FLOW_REPLY</code> || Server → Client || – Not included || Respond to flow request (success/failure)
|-
| <code>0x02</code> || <code>NAME_QUERY_REQ</code> || Client → Server || ✓ Included || Query if a remote name is reachable
|-
| <code>0x03</code> || <code>NAME_QUERY_REPLY</code> || Server → Client || ✓ Included || Response to name query
|}

'''Note:''' The 32-byte service hash (SHA3-256) is appended after the management protocol header for NAME_QUERY_* and FLOW_REQ messages to identify which service is being queried or allocated. FLOW_REPLY does not include the service hash; the endpoints are already identified by the allocated EIDs (SEID/DEID) and the flow allocation ID in the OAP header (see below).

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| SEID || 0-1 || 2 bytes || Source Endpoint ID
|-
| DEID || 2-3 || 2 bytes || Destination Endpoint ID
|-
| Loss || 4-7 || 4 bytes || Acceptable packet loss (ppm)
|-
| Bandwidth || 8-15 || 8 bytes || Required bandwidth (bps)
|-
| BER || 16-19 || 4 bytes || Bit error rate (ppm)
|-
| Max Gap || 20-23 || 4 bytes || Maximum consecutive lost packets
|-
| Delay || 24-27 || 4 bytes || Maximum latency (ms)
|-
| Timeout || 28-31 || 4 bytes || Flow idle timeout (seconds)
|-
| Response || 32-35 || 4 bytes || Response code (0=success, negative=error)
|-
| In-Order || 36 || 1 byte || In-order delivery requirement (boolean)
|-
| Code || 37 || 1 byte || Message type (FLOW_REQ, FLOW_REPLY, etc.)
|-
| Availability || 38 || 1 byte || Availability status
|-
| Service hash || 39-61 || 32 bytes || SHA3-256 hash (optional, see above)
|}

==== Ouroboros Flow Allocation Protocol (OAP) ====

The Ouroboros Application Protocol (OAP) is the flow allocation and authentication protocol. It carries flow negotiation requests, responses, and authentication credentials. OAP frames are encapsulated as data payload over the management protocol.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| ID || 0-15 || 16 bytes || Unique flow allocation identifier
|-
| Timestamp || 16-23 || 8 bytes || Creation timestamp (UTC, seconds and microseconds)
|-
| Crt Length || 24-25 || 2 bytes || Certificate length (bytes)
|-
| Certificate || 26+ || Variable || X.509 certificate (DER encoded)
|-
| Eph Length || Variable || 2 bytes || Ephemeral public key length (bytes)
|-
| Ephemeral Key || Variable || Variable || ECDHE public key (DER/raw encoded)
|-
| Data Length || Variable || 2 bytes || Application data length (bytes)
|-
| Data || Variable || Variable || Piggybacked application-layer data
|-
| Sig Length || Variable || 2 bytes || Signature length (bytes)
|-
| Signature || Variable || Variable || Digital signature (ECDSA, DER encoded)
|}

==== Oping Application Protocol ====

The Ouroboros Ping (oping) application is a simple echo/reply protocol used to measure round-trip time and validate connectivity between applications. It implements a request/reply pattern similar to ICMP ping.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| Type || 0-3 || 4 bytes || Message type (ECHO_REQUEST=0 or ECHO_REPLY=1)
|-
| ID || 4-7 || 4 bytes || Sequence number / message identifier
|-
| Timestamp (seconds) || 8-15 || 8 bytes || Seconds when message was sent (CLOCK_REALTIME)
|-
| Timestamp (nanoseconds) || 16-23 || 8 bytes || Nanoseconds component of timestamp
|-
| Payload || 24+ || Variable || Application data (configurable size, default 64 bytes)
|}

'''Field Definitions:'''

* '''Type''' (4 bytes): Message type selector
** <code>0x00000000</code> (ECHO_REQUEST): Client-to-server ping request
** <code>0x00000001</code> (ECHO_REPLY): Server-to-client response

* '''ID''' (4 bytes): Sequence number for matching requests with replies. Incremented for each ping sent.

* '''Timestamp (seconds)''' (8 bytes): Network-byte-order 64-bit seconds component from when the ping was sent (CLOCK_REALTIME).

* '''Timestamp (nanoseconds)''' (8 bytes): Network-byte-order 64-bit nanoseconds component (0-999999999) for high-resolution timing.

* '''Payload''' (Variable): Application data echoed back by the server. Size is configurable (default 64 bytes, maximum 1500 bytes).

'''Usage:'''

* Client sends ECHO_REQUEST with current timestamp
* Server receives request and echoes back as ECHO_REPLY with the same ID and timestamps
* Client calculates RTT by comparing reception time with original timestamps
* Out-of-order detection by tracking sequence numbers (ID field)

=== Packet Analysis: Test 1 - No authentication/encryption ===

==== Packet 1: NAME_QUERY_REQ ====

'''Summary:''' Client sends a NAME_QUERY_REQ message to discover if the service <code>sec.oping.tut.o7s</code> is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.165639 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0002 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

==== Packet 2: NAME_QUERY_REPLY ====

'''Summary:''' Server responds to the NAME_QUERY_REQ by sending a NAME_QUERY_REPLY for the service hash.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.166073 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0003 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code> (echoed back)
|}

==== Packet 3: FLOW_REQ ====

'''Summary:''' Client initiates a flow allocation request (FLOW_REQ) with minimal OAP headers since no authentication or encryption is being used.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.167222 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a51 8a56 ff6f ..f.i.._...Q.V.o
0x0050: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e103 [...}....0w.....
0x0060: 3e52 3300 0000 0000 0000 00 >R3........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || -- || '''UNUSED'''
|-
| 0x24-0x27 || <code>0001 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload'''

The OAP payload starts at offset 0x4b (after management protocol + service hash):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e103 3e52 33</code> || '''Timestamp''' || 8 || Network order || Creation timestamp (seconds + microseconds)
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 (first allocated flow ID for this session)
* Service hash is carried in management protocol payload (32 bytes)
* OAP header is minimal: only ID and timestamp, no optional fields
* No certificate, ephemeral key, data, or signature in this initial request
* Client sends minimal OAP headers with no authentication or encryption setup at allocation time

==== Packet 4: FLOW_REPLY ====

'''Summary:''' Server responds to FLOW_REQ by sending FLOW_REPLY with a new DEID (destination endpoint ID 0x0041) to establish the allocated flow for data transfer.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:49.178732 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0041 0040 0000 0000 0000 0000 ...G.A.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0051 8a56 ff6f ...........Q.V.o
0x0030: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e13f [...}....0w....?
0x0040: a347 3800 0000 0000 0000 00 .G8........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server-side flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0|| Response code (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload'''

The OAP payload starts at offset 0x2b (no service hash in FLOW_REPLY):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Echo of client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e13f a347 38</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x47-0x48 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x49-0x4a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0041 is the newly allocated server-side flow endpoint
* DEID 0x0040 reflects the client's flow ID, creating a bidirectional mapping
* No service hash included (FLOW_REPLY only needs the EIDs to identify the flow)
* OAP echoes the client's ID and timestamp, confirming the flow allocation
* Response code 0x00000000 indicates success
* Both client and server now have their respective flow IDs (0x0040 and 0x0041) for data transfer
* Response code 0x00000000 indicates success

==== Packet 5: ECHO_REQUEST - Plaintext Data ====

'''Summary:''' Client sends an oping ECHO_REQUEST packet to the server using the allocated flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.180824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 7377 0000 .A.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Source Endpoint ID (server → client)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REQUEST Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number (first ping)
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Seconds component
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Nanoseconds component
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (default 64 bytes total - 24 byte header = 40 bytes data)
|}

'''Key observations:'''
* EID 0x0041 shows traffic from server-side flow ID
* This is the first ping request (ID = 0x00000000)
* Timestamp captures when the ping was sent (seconds in network order)
* Default oping payload is 64 bytes total; 24 bytes header + 40 bytes data

==== Packet 6: ECHO_REPLY - Plaintext Data ====

'''Summary:''' Server receives the ECHO_REQUEST and immediately sends back an ECHO_REPLY with the same ID and timestamps, echoing the client's message.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.181496 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 7377 0000 .@.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client ← server)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REPLY Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Echo of original seconds
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Echo of original nanoseconds
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (unchanged from request)
|}

'''Key observations:'''
* EID 0x0040 shows traffic from client-side flow ID receiving the reply
* Type field changed from 0x00000000 (REQUEST) to 0x00000001 (REPLY)
* ID, timestamps, and payload data are identical to the request (echoed back)
* Round-trip time can be calculated by comparing current time with echoed timestamp
* Ping succeeded on first attempt with minimal latency (~1 millisecond between timestamps)

=== Packet Analysis: Test 2 - No authentication, with encryption ===

==== Packet 7: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with encryption enabled. This FLOW_REQ carries an OAP header with an ephemeral ECDHE P-384 public key (91 bytes) for encryption setup.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.808158 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8af1 766b 547c ..f.i.._....vkT|
0x0050: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0060: 8b6c 9000 0000 5b30 5930 1306 072a 8648 .l....[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 c508 1c19 6106 b7e9 3074 57b9 bb16 ......a...0tW...
0x0090: 6959 4a55 81f9 169b cc79 fe10 a882 41fe iYJU.....y....A.
0x00a0: 0697 c9b4 f8f0 5562 7fa2 c7a0 a020 1ac6 ......Ub........
0x00b0: 939f 23ff b2fb 07a2 b747 aacc 474a 3dab ..#......G..GJ=.
0x00c0: 2598 0000 0000 %.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Mixed || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 ... 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e253 8b6c 90</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 ... 3dab 2598</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || ECDHE P-384 public key (DER encoded)
|-
| 0xd3-0xd4 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd5-0xd6 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* Encryption enabled: ephemeral key present (91 bytes)
* Client sends no certificate, allowing anonymous encryption setup
* No signature (unsigned OAP)
* Ephemeral key is ECDHE P-384 for key exchange

==== Packet 8: FLOW_REPLY ====

'''Summary:''' Server accepts the encrypted flow allocation request. FLOW_REPLY contains the server's ephemeral key but no certificate (since client didn't send one).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.810564 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 180:
0x0000: 0000 00a2 0042 0040 0000 0000 0000 0000 .....B.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 00f1 766b 547c ............vkT|
0x0030: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0040: b694 e800 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0050: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0060: 0004 5f3c 6929 cca2 024a ae9f 9aa1 dfc2 .._<i)...J......
0x0070: a493 3ff3 ff58 b054 74dc d2e2 47fc 7c5b ..?..X.Tt...G.|[
0x0080: eff5 e129 72b4 de1e 7c09 bf8c fe38 5e8b ...)r...|....8^.
0x0090: b22e 59ed 6eb9 dfda 369d 691e 6e2c 122c ..Y.n...6.i.n,.,
0x00a0: 9936 0000 0000 .6....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00a2</code> || '''Length''' || 2 || 162 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0042</code> || '''SEID''' || 2 || 0x0042 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || Echo of client ID || Echoes client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e253 b694 e8</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x47-0xa1 || <code>30 5930...9936</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || Server's ECDHE P-384 public key (DER encoded)
|-
| 0xd1-0xd2 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd3-0xd4 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0042 is the new server-side flow endpoint
* Both keys are now exchanged; client and server can derive shared secret
* No authentication (no certificates) but encryption is negotiated
* Response indicates successful allocation

==== Packet 9: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after encryption keys are established. The payload is encrypted with the derived shared secret.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.815771 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0042 0060 a691 6d83 8446 cbeb ac95 c2eb .B.`..m..F......
0x0010: 4b42 e819 c67f 92c8 58d7 0641 d8a6 6e1f KB......X..A..n.
0x0020: fc90 feed ef55 b791 4fbd a832 74bd 8bed .....U..O..2t...
0x0030: 249c 4cee 0fc0 cec6 2f1b aec1 2428 bdbd $.L...../...$(..
0x0040: 36b5 01b5 1257 004e 6ed6 7ecd f0c7 7d11 6....W.Nn.~...}.
0x0050: 20ba e81b f43a 4de9 b141 1624 e1ba 0a84 .....:M..A.$....
0x0060: 74b1 9a9a t...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0042</code> || '''EID''' || 2 || 0x0042 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REQUEST (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>a691 6d83 8446 cbeb...74b1 9a9a</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* All 96 bytes of oping data (type, ID, timestamps, payload) are encrypted
* No plaintext oping headers visible; entire packet is ciphertext
* Flow IDs (0x0042) identify which encryption context to use
* Ping still works with encryption transparently

==== Packet 10: Encrypted ECHO_REPLY ====

'''Summary:''' Server receives encrypted ping request, decrypts it, and sends encrypted ECHO_REPLY.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.819574 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 c6ea 2222 5618 0268 b27e 9a91 .@.`..""V..h.~..
0x0010: f124 1f8d bccc 478c 26fe 9b13 b3cb 5398 .$....G.&.....S.
0x0020: 6869 3cdb 4928 510d 4de8 dc6a 3f3a 6a6d hi<.I(Q.M..j?:jm
0x0030: 6487 dcd8 c8cd 1a85 fba2 9ecd 3566 57d1 d...........5fW.
0x0040: 1c94 ac35 518e 8509 873a 3a5e 04d9 8ee2 ...5Q....::^....
0x0050: 9d74 2527 e425 5433 9d73 9ccd f56a 1f8d .t%'.%T3.s...j..
0x0060: f328 7237 .(r7
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REPLY (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>c6ea 2222 5618 0268...f328 7237</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* EID 0x0040 shows reply going back to client-side flow
* Ciphertext is different from request (different plaintext: type field differs)
* Both encrypted packets are 96 bytes (same size as Packet 9)
* Client receives encrypted reply, decrypts it, verifies ID and timestamps match request
* Encryption is transparent at application layer: oping works exactly as with plaintext flows

=== Packet Analysis: Test 3 - Authentication and encryption ===

==== Packet 11: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation request with encryption enabled. Sends ephemeral public key for ECDHE key exchange but no certificate (client is not authenticating in this tutorial). The management protocol now carries a valid allocated SEID (0x0040).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:58.827411 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a66 bb82 95fa ..f.i.._...f....
0x0050: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0060: c0d2 ad00 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 9dea c238 6732 4987 1cd4 7133 9614 .....8g2I...q3..
0x0090: 9d04 4fde 3f68 42f1 54fb 7ef3 88d0 ffe6 ..O.?hB.T.~.....
0x00a0: 7e01 432e 56c2 2d64 72c9 19fc b0cf 1eca ~.C.V.-dr.......
0x00b0: 689e 3536 771a 8041 726c 20e2 d9bb 3589 h.56w..Arl....5.
0x00c0: 86e7 0000 0000 ......
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (client flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ... 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier for Test 3
|-
| 0x5b-0x62 || <code>18 86a8 e37e c0d2 ad</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || Client not authenticating
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Ephemeral public key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 1306 ... 3589</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Client's ephemeral ECDHE public key for encryption negotiation
|-
| 0xc2-0xc3 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xc4-0xc5 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 - Same as Test 2 (Encrypted) because this is the same client session reusing the same allocated ID from the previous test
* No Certificate - <code>crt_len = 0x0000</code> because the client does not have authentication credentials; the server will authenticate instead
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> because encryption is enabled on the client
* No Signature - <code>sig_len = 0x0000</code> because client is not signing (no certificate to sign with)
* FLOW_REQ Message Type - Code field is 0x00, and service hash is present because FLOW_REQ always includes the service hash
* Timestamp Consistency - Same OAP ID and timestamp structure as Test 2, but with additional security handshake

==== Packet 12: FLOW_REPLY ====

'''Summary:''' Server responds to client's FLOW_REQ by sending FLOW_REPLY with its certificate for authentication, ephemeral public key for ECDHE encryption setup, and a digital signature proving ownership of the certificate. This is the full authentication response.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:39:58.828806 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 843:
0x0000: 0000 0339 0043 0040 0000 0000 0000 0000 ...9.C.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0066 bb82 95fa ...........f....
0x0030: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0040: d566 a002 2f30 8202 2b30 8201 b2a0 0302 .f../0..+0......
(... certificate and signature bytes ...)
0x0320: ef11 c358 f5d0 5cd7 3906 adf1 8a2c 9b25 ...X..\.9....,.%
0x0330: dc78 6050 ab61 3a3f 81c0 254b d193 7827 .x`P.a:?..%K..x'
0x0340: c0e9 38c7 e0d1 c517 d299 9992 07 ..8..........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0339</code> || '''Length''' || 2 || 825 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0043</code> || '''SEID''' || 2 || 0x0043 || Source Endpoint ID (server-side allocated flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (echoed back)
|-
| 0x3b-0x42 || <code>18 86a8 e37e d566 a0</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>022f</code> || '''Crt_len''' || 2 || 559 (0x022f) || Server certificate length: 559 bytes
|-
| 0x45-0x243 || <code>2f30 8202 2b ... 81c8 30</code> || '''Certificate''' || 559 || DER-encoded X.509 || Server's certificate (signed by intermediate CA)
|-
| 0x244-0x245 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Server's ephemeral public key length: 91 bytes
|-
| 0x246-0x2a0 || <code>30 5930 1306 ... 9936</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Server's ephemeral ECDHE public key
|-
| 0x2a4-0x2a5 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x2a6-0x2a7 || <code>0068</code> || '''Sig_len''' || 2 || 104 (0x0068) || Digital signature length: 104 bytes
|-
| 0x2a8-0x30f || <code>30 6602 3100 ... 07</code> || '''Signature''' || 104 || ECDSA signature (DER encoded) || Server's signature over OAP header proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0043 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from the FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Full Certificate - <code>crt_len = 0x022f (559)</code> carrying server's complete X.509 certificate signed by intermediate CA
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> with server's ECDHE public key for encryption
* Signature Included - <code>sig_len = 0x0068 (104)</code> containing ECDSA digital signature over the entire OAP header
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ to confirm association (included in signature, binding response to this specific client request)
* Large Payload - Total of 825 bytes due to certificate (559) + ephemeral key (91) + signature (104) + overhead
* Authentication Complete - Client verifies: (1) certificate against CA store, (2) signature over entire response ensures authenticity and integrity, (3) echoed ID binds response to this specific request, (4) timestamp prevents replay attacks

'''Summary:''' Server responds with its certificate for authentication, ephemeral public key for ECDHE encryption, and a digital signature proving ownership of the certificate.

==== Packet 13: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after authentication handshake. All application data is protected by encryption using the ephemeral keys established in Packets 11-12.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836485 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0043 0060 3bed 0b48 1be1 6930 cf3d dee9 .C.`.;..H..i0.=..
0x0010: 4fc9 774b 5d63 cc9b 5a34 6604 f9ac 1016 O.wK]c..Z4f.....
0x0020: 1c6d c9ac f80e dc89 31c1 9634 1a4f b2c7 .m......1..4.O..
0x0030: 4721 e402 8259 b0aa 8870 4566 33d1 9c18 G!...Y.. .pEf3...
0x0040: 06da 50c3 8b75 86b0 f240 d109 840e a6cd ..P..u...@......
0x0050: d115 77cb 5652 5bfb e6d5 0ca9 dbc3 d0b8 ..w.VR[.........
0x0060: 0058 fd19 .X..
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0043</code> || Client flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REQUEST data'''
|}

'''Key observations:'''
* No visible protocol structure - all application data appears as ciphertext
* Uses the same source/destination EID pair (0x0043 → 0x0060) established in the FLOW_REQ/FLOW_REPLY handshake
* Encryption is done using the ephemeral key (91 bytes) exchanged in Packet 11's OAP header
* Unlike Packets 11-12, this packet contains no certificate, public keys, or signatures
* The 110-byte encrypted data corresponds to the original oping ECHO_REQUEST message

==== Packet 14: Encrypted ECHO_REPLY ====

'''Summary:''' Server sends encrypted ping reply. Note that the flow identifiers swap, demonstrating bidirectional encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836930 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 d552 e100 e681 940c e35a 07d0 .@.`..........Z..
0x0010: a293 1d73 33a5 854e 0fce 4f4d 6655 267a ...s3..N..OMfU&z
0x0020: 3de2 663b 709d 739a a696 2ddd 7b34 28b8 =.f;p.s...-{4(...
0x0030: 5a98 eec2 52c6 4288 3885 ae16 e466 4181 Z...R.B.8...fA..
0x0040: f2d6 44c1 b51b 8728 58a4 7525 fb5e 3fd6 ..D...(X.u%.^?..
0x0050: 7e49 532a d2a5 bea7 55e9 c274 f1b2 0412 ~IS*....U..t....
0x0060: 73d4 6436 s.d6
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0040</code> || Client's inbound flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REPLY data'''
|}

'''Key observations:'''
* The EID in offset 0x00 is now 0x0040 (server's view of client's inbound flow)
* Uses the same ephemeral key material as Packet 13, but encryption direction is reversed
* Both packets use AES-GCM with keys derived from the ECDH exchange
* Timestamp 17:39:59.836930 is only 445 microseconds after Packet 13, indicating server-side processing
* The 110-byte encrypted ECHO_REPLY payload is the same size as the request
* All application data is protected by both authentication (X.509 + ECDSA) and encryption (AES)

=== Packet Analysis: Test 4 - Authentication, no encryption ===

==== Packet 15: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with authentication enabled but encryption disabled. This FLOW_REQ carries an OAP header but '''no ephemeral key''' since the client does not request encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:03.413372 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a8f a6ab 6ea7 ..f.i.._........
0x0050: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0060: 0de6 6100 0000 0000 0000 00 ..a.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... dc40</code> || '''QoS (Various)''' || 28 || Mixed ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e490 0de6 61</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key (no encryption)'''
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* No encryption enabled: ephemeral key absent (Eph_len = 0x0000)
* Client requests authentication only
* Server will respond with certificate + signature but no ephemeral key
* Packet is minimal compared to Packet 11 (Test 3) which includes 91-byte ephemeral key

==== Packet 16: FLOW_REPLY ====

'''Summary:''' Server accepts the authenticated (but not encrypted) flow allocation request. FLOW_REPLY contains the server's X.509 certificate and ECDSA signature for client authentication, but '''no ephemeral key''' since encryption is not being used.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:40:03.416675 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 751:
0x0000: 0000 02dd 0041 0040 0000 0000 0000 0000 .......A.@......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 008f a6ab 6ea7 ................
0x0030: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0040: 3754 a702 2f30 8202 2b30 8201 b2a0 0302 7T../0..+0......
0x0050: 0102 0202 1000 300a 0608 2a86 48ce 3d04 ......0...*.H.=.
(... certificate and signature bytes ...)
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>02dd</code> || '''Length''' || 2 || 733 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (Packet 15 echoed back)
|-
| 0x3b-0x42 || <code>fa18 86a8 e490 3754</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>a702</code> || '''Crt_len''' || 2 || 0x02a7 (679 decimal) || '''Certificate length: 679 bytes'''
|-
| 0x45-0x270 || <code>2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ...</code> || '''Certificate''' || 679 || DER-encoded X.509 || Server's certificate signed by intermediate CA
|-
| 0x271-0x272 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key''' (no encryption)
|-
| 0x273-0x274 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x275-0x276 || <code>0067</code> || '''Sig_len''' || 2 || 0x0067 (103 decimal) || '''ECDSA signature length: 103 bytes'''
|-
| 0x277-0x2dd || <code>3065 0230 75dc 5717 ... 83</code> || '''Signature''' || 103 || ECDSA signature (DER encoded) || Server's ECDSA signature proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0041 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from Packet 15 FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Certificate Field - <code>crt_len = 0x02a7 (679)</code> carrying server's X.509 certificate signed by intermediate CA
* Separate Signature Field - <code>sig_len = 0x0067 (103)</code> with ECDSA signature over entire OAP header
* No Ephemeral Key - <code>eph_len = 0x0000</code> since encryption is '''not''' being used in Test 4
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ (included in signature, binding response to this specific client request)
* Complete OAP Structure - Full OAP header with all standard fields, just without ephemeral key data
* Plaintext Data Exchange - After this FLOW_REPLY, all subsequent application data will be transmitted in plaintext (but authenticated via certificate + signature verification)

==== Packet 17: ECHO_REQUEST ====

'''Summary:''' Client sends plaintext ECHO_REQUEST data through the authenticated (but unencrypted) flow. The oping application's ping request is transmitted directly without encryption, relying on the earlier certificate+signature authentication for security.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.419664 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 8177 0000 .A.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Request (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number / message identifier
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Seconds component from CLOCK_REALTIME
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Nanoseconds component (0-999999999)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0041 → Server Flow - Data is directed to the server's endpoint ID allocated in Packet 16 FLOW_REPLY
* Plaintext Transmission - No encryption layer; oping payload is sent as-is (compare to Packet 13 which had encryption)
* Authenticated Flow - Although plaintext, this data travels on the authenticated flow established in Packet 16 (certificate + signature verified)
* Type = ECHO_REQUEST - 0x00000000 indicates client-to-server ping request
* ID = 0 - Sequence number for matching request/reply pairs
* Test 4 Characteristic - Demonstrates authenticated communication '''without''' encryption; application data is readable but cryptographically bound to the authenticated flow
* Contrast to Test 3 - Packet 13 (Test 3 encrypted ECHO_REQUEST) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

==== Packet 18: ECHO_REPLY ====

'''Summary:''' Server responds with plaintext ECHO_REPLY data, echoing back the client's request. This confirms successful bidirectional communication over the authenticated (but unencrypted) flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.420088 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 8177 0000 .@.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Reply (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (seconds)
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (nanoseconds)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Echoed probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0040 → Client Flow - Server responds to client's endpoint ID from Packet 15 FLOW_REQ
* Type = ECHO_REPLY - 0x00000001 indicates server-to-client response
* ID = 0 - Echoes the request sequence number, matching this response to the request
* Timestamps Echo Request - Both timestamp fields are copied from Packet 17 unchanged (8177 0000 0000 0000 and aa16 1c16 0000 0000)
* Plaintext Reply - No encryption; server's response payload is readable (compare to Packet 14 which had encryption)
* Authenticated Channel - Although plaintext, this reply is part of the authenticated flow; client can verify integrity through earlier certificate+signature
* Test 4 Completion - Demonstrates '''full bidirectional plaintext communication''' over an authenticated (but unencrypted) flow
* Contrast to Test 3 - Packet 14 (Test 3 encrypted ECHO_REPLY) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

Ouroboros Tutorial 06

2026-02-14T15:14:50Z

Dimitri: /* Test 4: With Authentication, No Encryption */

= Ouroboros Tutorial 06 - Authenticated Flows =

This tutorial demonstrates setting up and using authenticated flows in Ouroboros with certificate-based authentication.

The overall flow of authenticated flow allocation is

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

'''Tutorial Directory:''' This tutorial will execute in <code>/tmp/o7s-tut06/</code>. All configuration files, generated certificates, logs, and packet captures will be stored in this directory.

We create a complete PKI (Public Key Infrastructure):

* '''Root CA''' (<code>ca.tut.o7s</code>): Self-signed trust anchor
* '''Intermediate CA''' (<code>sign.tut.o7s</code>): Signed by root with pathlen:0 constraint
* '''Server Certificate''' (<code>sec.oping.tut.o7s</code>): Signed by intermediate CA

This tutorial uses ECDSA P-384 with SHA-384 hashing.

== Setting Up the Tutorial ==

To properly understand and debug the authenticated flows, this tutorial uses a debug build of Ouroboros with OAP protocol debugging enabled.

<syntaxhighlight lang="bash">
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
</syntaxhighlight>

When built with these options, the IRMd will output detailed OAP protocol information.

=== Configuration Files ===

The following three files should be created in the tutorial directory (<code>/tmp/o7s-tut06/</code>) before starting the tutorial:

'''tut06.conf''' - IRMd configuration

<syntaxhighlight lang="ini">
# Ouroboros Tutorial 06 - Authenticated Flows Configuration
# Uses system-installed certificates at /etc/ouroboros/security/

[name."sec.oping.tut.o7s"]
prog=["/usr/bin/oping"]
args=["--listen"]

[eth-dix.eth-dix-lo]
bootstrap="eth-dix-network"
dev="lo"
reg=["sec.oping.tut.o7s"]
</syntaxhighlight>

'''ca.tut.o7s.cnf''' - OpenSSL configuration for PKI generation

<syntaxhighlight lang="text">
# Unified OpenSSL Configuration for Ouroboros Tutorial 06
# Named CA sections: CA_root (signs intermediate), CA_intermediate (signs server)
# Usage: openssl ca -name CA_root -config ca.tut.o7s.cnf ...

[ req ]
default_bits = 384
default_keyfile = private/key.pem
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha384
x509_extensions = v3_ca

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name

countryName_default = BE
stateOrProvinceName_default = OVL
localityName_default = Ghent
organizationName_default = o7s

[ ca ]
default_ca = CA_root

[ CA_root ]
dir = ./pki/root
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.tut.o7s.crt.pem
private_key = $dir/private/ca.tut.o7s.key.pem
default_days = 3650
default_md = sha384
policy = policy_loose

[ CA_intermediate ]
dir = ./pki/sign
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/sign.tut.o7s.crt.pem
private_key = $dir/private/sign.tut.o7s.key.pem
default_days = 365
default_md = sha384
policy = policy_loose

[ policy_loose ]
commonName = supplied

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
</syntaxhighlight>

'''gen-pki.sh''' - PKI generation script

This script will:
1. Create the directory structure
2. Generate the root CA key and certificate
3. Generate the intermediate CA key and CSR
4. Sign the intermediate CA certificate
5. Generate the server certificate key and CSR
6. Sign the server certificate
7. Verify the complete certificate chain

<syntaxhighlight lang="bash">
#!/bin/bash
# Ouroboros Tutorial 06 - PKI Generation Script (Simplified)
# Generates: Root CA, Intermediate CA, and Server Certificate

set -e

if [ ! -f ca.tut.o7s.cnf ]; then
echo "ERROR: ca.tut.o7s.cnf not found"
exit 1
fi

mkdir -p pki/{root,sign,server}/{certs,private,csr}

# Root CA
openssl ecparam -genkey -name secp384r1 -out pki/root/private/ca.tut.o7s.key.pem 2>/dev/null
openssl req -new -x509 -sha384 -days 7300 \
-config ca.tut.o7s.cnf \
-key pki/root/private/ca.tut.o7s.key.pem \
-out pki/root/certs/ca.tut.o7s.crt.pem \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=ca.tut.o7s" 2>/dev/null

# Intermediate CA
openssl ecparam -genkey -name secp384r1 -out pki/sign/private/sign.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/sign/private/sign.tut.o7s.key.pem \
-out pki/sign/csr/sign.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sign.tut.o7s" 2>/dev/null

touch pki/root/index.txt
echo 1000 > pki/root/serial

openssl ca -name CA_root -config ca.tut.o7s.cnf \
-extensions v3_intermediate_ca -days 3650 -md sha384 -batch \
-in pki/sign/csr/sign.tut.o7s.csr \
-out pki/sign/certs/sign.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Server Certificate
openssl ecparam -genkey -name secp384r1 -out pki/server/private/sec.oping.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/server/private/sec.oping.tut.o7s.key.pem \
-out pki/server/csr/sec.oping.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sec.oping.tut.o7s" 2>/dev/null

touch pki/sign/index.txt
echo 1000 > pki/sign/serial

openssl ca -name CA_intermediate -config ca.tut.o7s.cnf \
-extensions server_cert -days 365 -md sha384 -batch \
-in pki/server/csr/sec.oping.tut.o7s.csr \
-out pki/server/certs/sec.oping.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Verify chain
openssl verify -CAfile pki/root/certs/ca.tut.o7s.crt.pem \
-untrusted pki/sign/certs/sign.tut.o7s.crt.pem \
pki/server/certs/sec.oping.tut.o7s.crt.pem > /dev/null 2>&1

echo "PKI generation complete."
</syntaxhighlight>

== Part 1: Running the Tutorial - Single Session with 4 Tests ==

This section demonstrates a single continuous session with one IRMd and tcpdump instance. The configuration file (<code>tut06.conf</code>) includes autostart for oping, so the server is ready immediately when IRMd starts.

First install the '''CA and Intermediate CA only''' to the system security directories. The server certificate will be installed later during Test 3 (authentication test):

<syntaxhighlight lang="bash">
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}

# Run the PKI generation script
cd /tmp/o7s-tut06
sudo chmod +x gen-pki.sh
sudo ./gen-pki.sh

# Install Root CA (trust anchor)
sudo cp pki/root/certs/ca.tut.o7s.crt.pem /etc/ouroboros/security/cacert/

# Install Intermediate CA (for certificate chain validation)
sudo cp pki/sign/certs/sign.tut.o7s.crt.pem /etc/ouroboros/security/untrusted/
</syntaxhighlight>

=== Running the Tutorial (3 Terminals) ===

In this tutorial, we run a single IRMd session with a concurrent tcpdump instance to capture it. We then run four oping client tests while the IRMd/tcpdump sessions are going, modifying the security configuration between tests. After the tests are complete, we can will down the IRMd and tcpdump sessions with Ctrl-C.

'''Terminal 1: Start tcpdump to capture all packets (runs continuously)'''

<syntaxhighlight lang="bash">
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
</syntaxhighlight>

'''Terminal 2: Start IRMd with debug output (runs continuously)'''

<syntaxhighlight lang="bash">
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
</syntaxhighlight>

'''Terminal 3: Run the tests'''

==== Test 1: No Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Verify directories are empty
sudo ls -la /etc/ouroboros/security/client/sec.oping.tut.o7s/*
sudo ls -la /etc/ouroboros/security/server/sec.oping.tut.o7s/*

# Run first ping test
echo "=== Test 1: No Authentication, No Encryption ==="
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 1: Client initiates plaintext flow allocation'''

<syntaxhighlight lang="text">
irmd/oap(DB): [60e824383b3fbd6a] KEX config: algo=none, mode=server-encap, cipher=none.
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:56 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 1: Server accepts and completes handshake'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' All OAP fields are <code><none></code> because no security is configured (except for the request hash in the response). Flow succeeds with plaintext communication.

==== Test 2: No Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run second ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 2: Client initiates flow with encryption enabled'''

<syntaxhighlight lang="text">
irmd/oap(II): Encryption enabled for sec.oping.tut.o7s.
irmd/oap(DB): [80fd6f9509a996b0] KEX config: algo=prime256v1, mode=server-encap, cipher=aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Generated ephemeral prime256v1 keys (91 bytes).
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 2: Server receives and responds with ephemeral key'''

<syntaxhighlight lang="text">
irmd/oap(DB): [80fd6f9509a996b0] No crt provided.
irmd/oap(DB): [80fd6f9509a996b0] Selected client cipher aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Selected client KDF sha256.
irmd/oap(II): [80fd6f9509a996b0] No key exchange.
irmd/oap(DB): [80fd6f9509a996b0] Generated prime256v1 ephemeral keys.
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' Both client and server generate ephemeral keys (91 bytes each) for encryption. No certificates because authentication is not required. Encryption and authentication are independent.

==== Test 3: With Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Install server certificates and keys
sudo cp /tmp/o7s-tut06/pki/server/certs/sec.oping.tut.o7s.crt.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/crt.pem
sudo cp /tmp/o7s-tut06/pki/server/private/sec.oping.tut.o7s.key.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/key.pem

# enc.conf is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 3: Client initiates flow with encryption and server has certificate'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] <--
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] -->
irmd/oap(PP): crt: [560 bytes]
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 3: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
irmd/oap(DB): [c904b18b563dc1b0] Loaded peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Got public key from crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully verified peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully authenticated peer.
</syntaxhighlight>

'''Key observations:''' Full OAP handshake with certificate (560 bytes) + ephemeral keys (91 bytes) + signature (103 bytes). Client verifies server's certificate against CA store and confirms authentication success.

==== Test 4: With Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [03e47baa966a5823 @ 2026-02-14 14:09:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>

'''IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [03e47baa966a5823 @ 2026-02-14 14:09:57 (UTC) ] -->
irmd/oap(PP): crt: [560 bytes]
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 4: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
irmd/oap(DB): [03e47baa966a5823] Loaded peer crt.
irmd/oap(DB): [03e47baa966a5823] Got public key from crt.
irmd/oap(DB): [03e47baa966a5823] Successfully verified peer crt.
irmd/oap(DB): [03e47baa966a5823] Successfully authenticated peer.
</syntaxhighlight>

'''Key observations:''' Server sends certificate + signature for authentication, but NO ephemeral keys (plaintext data). Data exchanged without encryption even though authenticated. Demonstrates that authentication and encryption are independent mechanisms.

=== Stop the IRMd and tcpdump, clean up the tutorial files ===

Once all tests complete:

<syntaxhighlight lang="bash">
# Stop IRMd in Terminal 2 (Ctrl+C)
# Stop tcpdump in Terminal 1 (Ctrl+C)

# Clean up tutorial security files from system
sudo rm -f /etc/ouroboros/security/cacert/ca.tut.o7s.crt.pem
</syntaxhighlight>

== Part 2: PCAP Trace Analysis ==

After the tutorial, we now explain the trace in the tcpdump pcap file.

=== Protocol Overview ===

This section summarizes the four protocols that work together in the captured packet flow.

==== Ethernet DIX Frame with EID Header ====

Ouroboros extends the DIX frame with a flow identifier (EID - Endpoint Identifier) and length field.

{| class="wikitable"
|-
! Field !! Octets !! Size !! Description
|-
| Destination MAC || 0-5 || 6 bytes || Hardware address of destination
|-
| Source MAC || 6-11 || 6 bytes || Hardware address of source
|-
| EtherType || 12-13 || 2 bytes || Protocol identifier (0xA000 for Ouroboros)
|-
| EID || 14-15 || 2 bytes || Destination Endpoint Identifier
|-
| Length || 16-17 || 2 bytes || Payload length (needed because of runt frame padding)
|-
| Payload || 18+ || Variable || Frame data (up to MTU size)
|}

==== Ethernet Flow Allocator - Management Protocol ====

The Ethernet DIX management protocol handles flow allocation, setup, and teardown. All management frames use destination EID <code>0x0000</code>.

'''Management Frame Types:'''

{| class="wikitable"
|-
! Code !! Type !! Direction !! Service Hash !! Purpose
|-
| <code>0x00</code> || <code>FLOW_REQ</code> || Client → Server || ✓ Included || Request new flow allocation
|-
| <code>0x01</code> || <code>FLOW_REPLY</code> || Server → Client || – Not included || Respond to flow request (success/failure)
|-
| <code>0x02</code> || <code>NAME_QUERY_REQ</code> || Client → Server || ✓ Included || Query if a remote name is reachable
|-
| <code>0x03</code> || <code>NAME_QUERY_REPLY</code> || Server → Client || ✓ Included || Response to name query
|}

'''Note:''' The 32-byte service hash (SHA3-256) is appended after the management protocol header for NAME_QUERY_* and FLOW_REQ messages to identify which service is being queried or allocated. FLOW_REPLY does not include the service hash; the endpoints are already identified by the allocated EIDs (SEID/DEID) and the flow allocation ID in the OAP header (see below).

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| SEID || 0-1 || 2 bytes || Source Endpoint ID
|-
| DEID || 2-3 || 2 bytes || Destination Endpoint ID
|-
| Loss || 4-7 || 4 bytes || Acceptable packet loss (ppm)
|-
| Bandwidth || 8-15 || 8 bytes || Required bandwidth (bps)
|-
| BER || 16-19 || 4 bytes || Bit error rate (ppm)
|-
| Max Gap || 20-23 || 4 bytes || Maximum consecutive lost packets
|-
| Delay || 24-27 || 4 bytes || Maximum latency (ms)
|-
| Timeout || 28-31 || 4 bytes || Flow idle timeout (seconds)
|-
| Response || 32-35 || 4 bytes || Response code (0=success, negative=error)
|-
| In-Order || 36 || 1 byte || In-order delivery requirement (boolean)
|-
| Code || 37 || 1 byte || Message type (FLOW_REQ, FLOW_REPLY, etc.)
|-
| Availability || 38 || 1 byte || Availability status
|-
| Service hash || 39-61 || 32 bytes || SHA3-256 hash (optional, see above)
|}

==== Ouroboros Flow Allocation Protocol (OAP) ====

The Ouroboros Application Protocol (OAP) is the flow allocation and authentication protocol. It carries flow negotiation requests, responses, and authentication credentials. OAP frames are encapsulated as data payload over the management protocol.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| ID || 0-15 || 16 bytes || Unique flow allocation identifier
|-
| Timestamp || 16-23 || 8 bytes || Creation timestamp (UTC, seconds and microseconds)
|-
| Crt Length || 24-25 || 2 bytes || Certificate length (bytes)
|-
| Certificate || 26+ || Variable || X.509 certificate (DER encoded)
|-
| Eph Length || Variable || 2 bytes || Ephemeral public key length (bytes)
|-
| Ephemeral Key || Variable || Variable || ECDHE public key (DER/raw encoded)
|-
| Data Length || Variable || 2 bytes || Application data length (bytes)
|-
| Data || Variable || Variable || Piggybacked application-layer data
|-
| Sig Length || Variable || 2 bytes || Signature length (bytes)
|-
| Signature || Variable || Variable || Digital signature (ECDSA, DER encoded)
|}

==== Oping Application Protocol ====

The Ouroboros Ping (oping) application is a simple echo/reply protocol used to measure round-trip time and validate connectivity between applications. It implements a request/reply pattern similar to ICMP ping.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| Type || 0-3 || 4 bytes || Message type (ECHO_REQUEST=0 or ECHO_REPLY=1)
|-
| ID || 4-7 || 4 bytes || Sequence number / message identifier
|-
| Timestamp (seconds) || 8-15 || 8 bytes || Seconds when message was sent (CLOCK_REALTIME)
|-
| Timestamp (nanoseconds) || 16-23 || 8 bytes || Nanoseconds component of timestamp
|-
| Payload || 24+ || Variable || Application data (configurable size, default 64 bytes)
|}

'''Field Definitions:'''

* '''Type''' (4 bytes): Message type selector
** <code>0x00000000</code> (ECHO_REQUEST): Client-to-server ping request
** <code>0x00000001</code> (ECHO_REPLY): Server-to-client response

* '''ID''' (4 bytes): Sequence number for matching requests with replies. Incremented for each ping sent.

* '''Timestamp (seconds)''' (8 bytes): Network-byte-order 64-bit seconds component from when the ping was sent (CLOCK_REALTIME).

* '''Timestamp (nanoseconds)''' (8 bytes): Network-byte-order 64-bit nanoseconds component (0-999999999) for high-resolution timing.

* '''Payload''' (Variable): Application data echoed back by the server. Size is configurable (default 64 bytes, maximum 1500 bytes).

'''Usage:'''

* Client sends ECHO_REQUEST with current timestamp
* Server receives request and echoes back as ECHO_REPLY with the same ID and timestamps
* Client calculates RTT by comparing reception time with original timestamps
* Out-of-order detection by tracking sequence numbers (ID field)

=== Packet Analysis: Test 1 - No authentication/encryption ===

==== Packet 1: NAME_QUERY_REQ ====

'''Summary:''' Client sends a NAME_QUERY_REQ message to discover if the service <code>sec.oping.tut.o7s</code> is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.165639 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0002 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

==== Packet 2: NAME_QUERY_REPLY ====

'''Summary:''' Server responds to the NAME_QUERY_REQ by sending a NAME_QUERY_REPLY for the service hash.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.166073 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0003 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code> (echoed back)
|}

==== Packet 3: FLOW_REQ ====

'''Summary:''' Client initiates a flow allocation request (FLOW_REQ) with minimal OAP headers since no authentication or encryption is being used.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.167222 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a51 8a56 ff6f ..f.i.._...Q.V.o
0x0050: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e103 [...}....0w.....
0x0060: 3e52 3300 0000 0000 0000 00 >R3........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || -- || '''UNUSED'''
|-
| 0x24-0x27 || <code>0001 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload'''

The OAP payload starts at offset 0x4b (after management protocol + service hash):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e103 3e52 33</code> || '''Timestamp''' || 8 || Network order || Creation timestamp (seconds + microseconds)
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 (first allocated flow ID for this session)
* Service hash is carried in management protocol payload (32 bytes)
* OAP header is minimal: only ID and timestamp, no optional fields
* No certificate, ephemeral key, data, or signature in this initial request
* Client sends minimal OAP headers with no authentication or encryption setup at allocation time

==== Packet 4: FLOW_REPLY ====

'''Summary:''' Server responds to FLOW_REQ by sending FLOW_REPLY with a new DEID (destination endpoint ID 0x0041) to establish the allocated flow for data transfer.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:49.178732 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0041 0040 0000 0000 0000 0000 ...G.A.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0051 8a56 ff6f ...........Q.V.o
0x0030: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e13f [...}....0w....?
0x0040: a347 3800 0000 0000 0000 00 .G8........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server-side flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0|| Response code (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload'''

The OAP payload starts at offset 0x2b (no service hash in FLOW_REPLY):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Echo of client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e13f a347 38</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x47-0x48 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x49-0x4a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0041 is the newly allocated server-side flow endpoint
* DEID 0x0040 reflects the client's flow ID, creating a bidirectional mapping
* No service hash included (FLOW_REPLY only needs the EIDs to identify the flow)
* OAP echoes the client's ID and timestamp, confirming the flow allocation
* Response code 0x00000000 indicates success
* Both client and server now have their respective flow IDs (0x0040 and 0x0041) for data transfer
* Response code 0x00000000 indicates success

==== Packet 5: ECHO_REQUEST - Plaintext Data ====

'''Summary:''' Client sends an oping ECHO_REQUEST packet to the server using the allocated flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.180824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 7377 0000 .A.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Source Endpoint ID (server → client)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REQUEST Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number (first ping)
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Seconds component
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Nanoseconds component
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (default 64 bytes total - 24 byte header = 40 bytes data)
|}

'''Key observations:'''
* EID 0x0041 shows traffic from server-side flow ID
* This is the first ping request (ID = 0x00000000)
* Timestamp captures when the ping was sent (seconds in network order)
* Default oping payload is 64 bytes total; 24 bytes header + 40 bytes data

==== Packet 6: ECHO_REPLY - Plaintext Data ====

'''Summary:''' Server receives the ECHO_REQUEST and immediately sends back an ECHO_REPLY with the same ID and timestamps, echoing the client's message.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.181496 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 7377 0000 .@.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client ← server)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REPLY Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Echo of original seconds
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Echo of original nanoseconds
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (unchanged from request)
|}

'''Key observations:'''
* EID 0x0040 shows traffic from client-side flow ID receiving the reply
* Type field changed from 0x00000000 (REQUEST) to 0x00000001 (REPLY)
* ID, timestamps, and payload data are identical to the request (echoed back)
* Round-trip time can be calculated by comparing current time with echoed timestamp
* Ping succeeded on first attempt with minimal latency (~1 millisecond between timestamps)

=== Packet Analysis: Test 2 - No authentication, with encryption ===

==== Packet 7: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with encryption enabled. This FLOW_REQ carries an OAP header with an ephemeral ECDHE P-384 public key (91 bytes) for encryption setup.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.808158 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8af1 766b 547c ..f.i.._....vkT|
0x0050: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0060: 8b6c 9000 0000 5b30 5930 1306 072a 8648 .l....[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 c508 1c19 6106 b7e9 3074 57b9 bb16 ......a...0tW...
0x0090: 6959 4a55 81f9 169b cc79 fe10 a882 41fe iYJU.....y....A.
0x00a0: 0697 c9b4 f8f0 5562 7fa2 c7a0 a020 1ac6 ......Ub........
0x00b0: 939f 23ff b2fb 07a2 b747 aacc 474a 3dab ..#......G..GJ=.
0x00c0: 2598 0000 0000 %.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Mixed || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 ... 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e253 8b6c 90</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 ... 3dab 2598</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || ECDHE P-384 public key (DER encoded)
|-
| 0xd3-0xd4 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd5-0xd6 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* Encryption enabled: ephemeral key present (91 bytes)
* Client sends no certificate, allowing anonymous encryption setup
* No signature (unsigned OAP)
* Ephemeral key is ECDHE P-384 for key exchange

==== Packet 8: FLOW_REPLY ====

'''Summary:''' Server accepts the encrypted flow allocation request. FLOW_REPLY contains the server's ephemeral key but no certificate (since client didn't send one).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.810564 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 180:
0x0000: 0000 00a2 0042 0040 0000 0000 0000 0000 .....B.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 00f1 766b 547c ............vkT|
0x0030: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0040: b694 e800 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0050: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0060: 0004 5f3c 6929 cca2 024a ae9f 9aa1 dfc2 .._<i)...J......
0x0070: a493 3ff3 ff58 b054 74dc d2e2 47fc 7c5b ..?..X.Tt...G.|[
0x0080: eff5 e129 72b4 de1e 7c09 bf8c fe38 5e8b ...)r...|....8^.
0x0090: b22e 59ed 6eb9 dfda 369d 691e 6e2c 122c ..Y.n...6.i.n,.,
0x00a0: 9936 0000 0000 .6....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00a2</code> || '''Length''' || 2 || 162 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0042</code> || '''SEID''' || 2 || 0x0042 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || Echo of client ID || Echoes client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e253 b694 e8</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x47-0xa1 || <code>30 5930...9936</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || Server's ECDHE P-384 public key (DER encoded)
|-
| 0xd1-0xd2 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd3-0xd4 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0042 is the new server-side flow endpoint
* Both keys are now exchanged; client and server can derive shared secret
* No authentication (no certificates) but encryption is negotiated
* Response indicates successful allocation

==== Packet 9: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after encryption keys are established. The payload is encrypted with the derived shared secret.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.815771 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0042 0060 a691 6d83 8446 cbeb ac95 c2eb .B.`..m..F......
0x0010: 4b42 e819 c67f 92c8 58d7 0641 d8a6 6e1f KB......X..A..n.
0x0020: fc90 feed ef55 b791 4fbd a832 74bd 8bed .....U..O..2t...
0x0030: 249c 4cee 0fc0 cec6 2f1b aec1 2428 bdbd $.L...../...$(..
0x0040: 36b5 01b5 1257 004e 6ed6 7ecd f0c7 7d11 6....W.Nn.~...}.
0x0050: 20ba e81b f43a 4de9 b141 1624 e1ba 0a84 .....:M..A.$....
0x0060: 74b1 9a9a t...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0042</code> || '''EID''' || 2 || 0x0042 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REQUEST (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>a691 6d83 8446 cbeb...74b1 9a9a</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* All 96 bytes of oping data (type, ID, timestamps, payload) are encrypted
* No plaintext oping headers visible; entire packet is ciphertext
* Flow IDs (0x0042) identify which encryption context to use
* Ping still works with encryption transparently

==== Packet 10: Encrypted ECHO_REPLY ====

'''Summary:''' Server receives encrypted ping request, decrypts it, and sends encrypted ECHO_REPLY.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.819574 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 c6ea 2222 5618 0268 b27e 9a91 .@.`..""V..h.~..
0x0010: f124 1f8d bccc 478c 26fe 9b13 b3cb 5398 .$....G.&.....S.
0x0020: 6869 3cdb 4928 510d 4de8 dc6a 3f3a 6a6d hi<.I(Q.M..j?:jm
0x0030: 6487 dcd8 c8cd 1a85 fba2 9ecd 3566 57d1 d...........5fW.
0x0040: 1c94 ac35 518e 8509 873a 3a5e 04d9 8ee2 ...5Q....::^....
0x0050: 9d74 2527 e425 5433 9d73 9ccd f56a 1f8d .t%'.%T3.s...j..
0x0060: f328 7237 .(r7
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REPLY (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>c6ea 2222 5618 0268...f328 7237</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* EID 0x0040 shows reply going back to client-side flow
* Ciphertext is different from request (different plaintext: type field differs)
* Both encrypted packets are 96 bytes (same size as Packet 9)
* Client receives encrypted reply, decrypts it, verifies ID and timestamps match request
* Encryption is transparent at application layer: oping works exactly as with plaintext flows

=== Packet Analysis: Test 3 - Authentication and encryption ===

==== Packet 11: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation request with encryption enabled. Sends ephemeral public key for ECDHE key exchange but no certificate (client is not authenticating in this tutorial). The management protocol now carries a valid allocated SEID (0x0040).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:58.827411 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a66 bb82 95fa ..f.i.._...f....
0x0050: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0060: c0d2 ad00 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 9dea c238 6732 4987 1cd4 7133 9614 .....8g2I...q3..
0x0090: 9d04 4fde 3f68 42f1 54fb 7ef3 88d0 ffe6 ..O.?hB.T.~.....
0x00a0: 7e01 432e 56c2 2d64 72c9 19fc b0cf 1eca ~.C.V.-dr.......
0x00b0: 689e 3536 771a 8041 726c 20e2 d9bb 3589 h.56w..Arl....5.
0x00c0: 86e7 0000 0000 ......
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (client flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ... 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier for Test 3
|-
| 0x5b-0x62 || <code>18 86a8 e37e c0d2 ad</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || Client not authenticating
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Ephemeral public key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 1306 ... 3589</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Client's ephemeral ECDHE public key for encryption negotiation
|-
| 0xc2-0xc3 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xc4-0xc5 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 - Same as Test 2 (Encrypted) because this is the same client session reusing the same allocated ID from the previous test
* No Certificate - <code>crt_len = 0x0000</code> because the client does not have authentication credentials; the server will authenticate instead
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> because encryption is enabled on the client
* No Signature - <code>sig_len = 0x0000</code> because client is not signing (no certificate to sign with)
* FLOW_REQ Message Type - Code field is 0x00, and service hash is present because FLOW_REQ always includes the service hash
* Timestamp Consistency - Same OAP ID and timestamp structure as Test 2, but with additional security handshake

==== Packet 12: FLOW_REPLY ====

'''Summary:''' Server responds to client's FLOW_REQ by sending FLOW_REPLY with its certificate for authentication, ephemeral public key for ECDHE encryption setup, and a digital signature proving ownership of the certificate. This is the full authentication response.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:39:58.828806 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 843:
0x0000: 0000 0339 0043 0040 0000 0000 0000 0000 ...9.C.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0066 bb82 95fa ...........f....
0x0030: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0040: d566 a002 2f30 8202 2b30 8201 b2a0 0302 .f../0..+0......
(... certificate and signature bytes ...)
0x0320: ef11 c358 f5d0 5cd7 3906 adf1 8a2c 9b25 ...X..\.9....,.%
0x0330: dc78 6050 ab61 3a3f 81c0 254b d193 7827 .x`P.a:?..%K..x'
0x0340: c0e9 38c7 e0d1 c517 d299 9992 07 ..8..........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0339</code> || '''Length''' || 2 || 825 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0043</code> || '''SEID''' || 2 || 0x0043 || Source Endpoint ID (server-side allocated flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (echoed back)
|-
| 0x3b-0x42 || <code>18 86a8 e37e d566 a0</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>022f</code> || '''Crt_len''' || 2 || 559 (0x022f) || Server certificate length: 559 bytes
|-
| 0x45-0x243 || <code>2f30 8202 2b ... 81c8 30</code> || '''Certificate''' || 559 || DER-encoded X.509 || Server's certificate (signed by intermediate CA)
|-
| 0x244-0x245 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Server's ephemeral public key length: 91 bytes
|-
| 0x246-0x2a0 || <code>30 5930 1306 ... 9936</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Server's ephemeral ECDHE public key
|-
| 0x2a4-0x2a5 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x2a6-0x2a7 || <code>0068</code> || '''Sig_len''' || 2 || 104 (0x0068) || Digital signature length: 104 bytes
|-
| 0x2a8-0x30f || <code>30 6602 3100 ... 07</code> || '''Signature''' || 104 || ECDSA signature (DER encoded) || Server's signature over OAP header proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0043 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from the FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Full Certificate - <code>crt_len = 0x022f (559)</code> carrying server's complete X.509 certificate signed by intermediate CA
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> with server's ECDHE public key for encryption
* Signature Included - <code>sig_len = 0x0068 (104)</code> containing ECDSA digital signature over the entire OAP header
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ to confirm association (included in signature, binding response to this specific client request)
* Large Payload - Total of 825 bytes due to certificate (559) + ephemeral key (91) + signature (104) + overhead
* Authentication Complete - Client verifies: (1) certificate against CA store, (2) signature over entire response ensures authenticity and integrity, (3) echoed ID binds response to this specific request, (4) timestamp prevents replay attacks

'''Summary:''' Server responds with its certificate for authentication, ephemeral public key for ECDHE encryption, and a digital signature proving ownership of the certificate.

==== Packet 13: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after authentication handshake. All application data is protected by encryption using the ephemeral keys established in Packets 11-12.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836485 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0043 0060 3bed 0b48 1be1 6930 cf3d dee9 .C.`.;..H..i0.=..
0x0010: 4fc9 774b 5d63 cc9b 5a34 6604 f9ac 1016 O.wK]c..Z4f.....
0x0020: 1c6d c9ac f80e dc89 31c1 9634 1a4f b2c7 .m......1..4.O..
0x0030: 4721 e402 8259 b0aa 8870 4566 33d1 9c18 G!...Y.. .pEf3...
0x0040: 06da 50c3 8b75 86b0 f240 d109 840e a6cd ..P..u...@......
0x0050: d115 77cb 5652 5bfb e6d5 0ca9 dbc3 d0b8 ..w.VR[.........
0x0060: 0058 fd19 .X..
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0043</code> || Client flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REQUEST data'''
|}

'''Key observations:'''
* No visible protocol structure - all application data appears as ciphertext
* Uses the same source/destination EID pair (0x0043 → 0x0060) established in the FLOW_REQ/FLOW_REPLY handshake
* Encryption is done using the ephemeral key (91 bytes) exchanged in Packet 11's OAP header
* Unlike Packets 11-12, this packet contains no certificate, public keys, or signatures
* The 110-byte encrypted data corresponds to the original oping ECHO_REQUEST message

==== Packet 14: Encrypted ECHO_REPLY ====

'''Summary:''' Server sends encrypted ping reply. Note that the flow identifiers swap, demonstrating bidirectional encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836930 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 d552 e100 e681 940c e35a 07d0 .@.`..........Z..
0x0010: a293 1d73 33a5 854e 0fce 4f4d 6655 267a ...s3..N..OMfU&z
0x0020: 3de2 663b 709d 739a a696 2ddd 7b34 28b8 =.f;p.s...-{4(...
0x0030: 5a98 eec2 52c6 4288 3885 ae16 e466 4181 Z...R.B.8...fA..
0x0040: f2d6 44c1 b51b 8728 58a4 7525 fb5e 3fd6 ..D...(X.u%.^?..
0x0050: 7e49 532a d2a5 bea7 55e9 c274 f1b2 0412 ~IS*....U..t....
0x0060: 73d4 6436 s.d6
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0040</code> || Client's inbound flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REPLY data'''
|}

'''Key observations:'''
* The EID in offset 0x00 is now 0x0040 (server's view of client's inbound flow)
* Uses the same ephemeral key material as Packet 13, but encryption direction is reversed
* Both packets use AES-GCM with keys derived from the ECDH exchange
* Timestamp 17:39:59.836930 is only 445 microseconds after Packet 13, indicating server-side processing
* The 110-byte encrypted ECHO_REPLY payload is the same size as the request
* All application data is protected by both authentication (X.509 + ECDSA) and encryption (AES)

=== Packet Analysis: Test 4 - Authentication, no encryption ===

==== Packet 15: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with authentication enabled but encryption disabled. This FLOW_REQ carries an OAP header but '''no ephemeral key''' since the client does not request encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:03.413372 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a8f a6ab 6ea7 ..f.i.._........
0x0050: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0060: 0de6 6100 0000 0000 0000 00 ..a.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... dc40</code> || '''QoS (Various)''' || 28 || Mixed ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e490 0de6 61</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key (no encryption)'''
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* No encryption enabled: ephemeral key absent (Eph_len = 0x0000)
* Client requests authentication only
* Server will respond with certificate + signature but no ephemeral key
* Packet is minimal compared to Packet 11 (Test 3) which includes 91-byte ephemeral key

==== Packet 16: FLOW_REPLY ====

'''Summary:''' Server accepts the authenticated (but not encrypted) flow allocation request. FLOW_REPLY contains the server's X.509 certificate and ECDSA signature for client authentication, but '''no ephemeral key''' since encryption is not being used.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:40:03.416675 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 751:
0x0000: 0000 02dd 0041 0040 0000 0000 0000 0000 .......A.@......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 008f a6ab 6ea7 ................
0x0030: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0040: 3754 a702 2f30 8202 2b30 8201 b2a0 0302 7T../0..+0......
0x0050: 0102 0202 1000 300a 0608 2a86 48ce 3d04 ......0...*.H.=.
(... certificate and signature bytes ...)
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>02dd</code> || '''Length''' || 2 || 733 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (Packet 15 echoed back)
|-
| 0x3b-0x42 || <code>fa18 86a8 e490 3754</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>a702</code> || '''Crt_len''' || 2 || 0x02a7 (679 decimal) || '''Certificate length: 679 bytes'''
|-
| 0x45-0x270 || <code>2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ...</code> || '''Certificate''' || 679 || DER-encoded X.509 || Server's certificate signed by intermediate CA
|-
| 0x271-0x272 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key''' (no encryption)
|-
| 0x273-0x274 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x275-0x276 || <code>0067</code> || '''Sig_len''' || 2 || 0x0067 (103 decimal) || '''ECDSA signature length: 103 bytes'''
|-
| 0x277-0x2dd || <code>3065 0230 75dc 5717 ... 83</code> || '''Signature''' || 103 || ECDSA signature (DER encoded) || Server's ECDSA signature proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0041 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from Packet 15 FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Certificate Field - <code>crt_len = 0x02a7 (679)</code> carrying server's X.509 certificate signed by intermediate CA
* Separate Signature Field - <code>sig_len = 0x0067 (103)</code> with ECDSA signature over entire OAP header
* No Ephemeral Key - <code>eph_len = 0x0000</code> since encryption is '''not''' being used in Test 4
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ (included in signature, binding response to this specific client request)
* Complete OAP Structure - Full OAP header with all standard fields, just without ephemeral key data
* Plaintext Data Exchange - After this FLOW_REPLY, all subsequent application data will be transmitted in plaintext (but authenticated via certificate + signature verification)

==== Packet 17: ECHO_REQUEST ====

'''Summary:''' Client sends plaintext ECHO_REQUEST data through the authenticated (but unencrypted) flow. The oping application's ping request is transmitted directly without encryption, relying on the earlier certificate+signature authentication for security.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.419664 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 8177 0000 .A.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Request (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number / message identifier
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Seconds component from CLOCK_REALTIME
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Nanoseconds component (0-999999999)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0041 → Server Flow - Data is directed to the server's endpoint ID allocated in Packet 16 FLOW_REPLY
* Plaintext Transmission - No encryption layer; oping payload is sent as-is (compare to Packet 13 which had encryption)
* Authenticated Flow - Although plaintext, this data travels on the authenticated flow established in Packet 16 (certificate + signature verified)
* Type = ECHO_REQUEST - 0x00000000 indicates client-to-server ping request
* ID = 0 - Sequence number for matching request/reply pairs
* Test 4 Characteristic - Demonstrates authenticated communication '''without''' encryption; application data is readable but cryptographically bound to the authenticated flow
* Contrast to Test 3 - Packet 13 (Test 3 encrypted ECHO_REQUEST) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

==== Packet 18: ECHO_REPLY ====

'''Summary:''' Server responds with plaintext ECHO_REPLY data, echoing back the client's request. This confirms successful bidirectional communication over the authenticated (but unencrypted) flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.420088 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 8177 0000 .@.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Reply (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (seconds)
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (nanoseconds)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Echoed probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0040 → Client Flow - Server responds to client's endpoint ID from Packet 15 FLOW_REQ
* Type = ECHO_REPLY - 0x00000001 indicates server-to-client response
* ID = 0 - Echoes the request sequence number, matching this response to the request
* Timestamps Echo Request - Both timestamp fields are copied from Packet 17 unchanged (8177 0000 0000 0000 and aa16 1c16 0000 0000)
* Plaintext Reply - No encryption; server's response payload is readable (compare to Packet 14 which had encryption)
* Authenticated Channel - Although plaintext, this reply is part of the authenticated flow; client can verify integrity through earlier certificate+signature
* Test 4 Completion - Demonstrates '''full bidirectional plaintext communication''' over an authenticated (but unencrypted) flow
* Contrast to Test 3 - Packet 14 (Test 3 encrypted ECHO_REPLY) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

Ouroboros Tutorial 06

2026-02-14T14:59:54Z

Dimitri: /* Test 4: With Authentication, No Encryption */

= Ouroboros Tutorial 06 - Authenticated Flows =

This tutorial demonstrates setting up and using authenticated flows in Ouroboros with certificate-based authentication.

The overall flow of authenticated flow allocation is

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

'''Tutorial Directory:''' This tutorial will execute in <code>/tmp/o7s-tut06/</code>. All configuration files, generated certificates, logs, and packet captures will be stored in this directory.

We create a complete PKI (Public Key Infrastructure):

* '''Root CA''' (<code>ca.tut.o7s</code>): Self-signed trust anchor
* '''Intermediate CA''' (<code>sign.tut.o7s</code>): Signed by root with pathlen:0 constraint
* '''Server Certificate''' (<code>sec.oping.tut.o7s</code>): Signed by intermediate CA

This tutorial uses ECDSA P-384 with SHA-384 hashing.

== Setting Up the Tutorial ==

To properly understand and debug the authenticated flows, this tutorial uses a debug build of Ouroboros with OAP protocol debugging enabled.

<syntaxhighlight lang="bash">
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
</syntaxhighlight>

When built with these options, the IRMd will output detailed OAP protocol information.

=== Configuration Files ===

The following three files should be created in the tutorial directory (<code>/tmp/o7s-tut06/</code>) before starting the tutorial:

'''tut06.conf''' - IRMd configuration

<syntaxhighlight lang="ini">
# Ouroboros Tutorial 06 - Authenticated Flows Configuration
# Uses system-installed certificates at /etc/ouroboros/security/

[name."sec.oping.tut.o7s"]
prog=["/usr/bin/oping"]
args=["--listen"]

[eth-dix.eth-dix-lo]
bootstrap="eth-dix-network"
dev="lo"
reg=["sec.oping.tut.o7s"]
</syntaxhighlight>

'''ca.tut.o7s.cnf''' - OpenSSL configuration for PKI generation

<syntaxhighlight lang="text">
# Unified OpenSSL Configuration for Ouroboros Tutorial 06
# Named CA sections: CA_root (signs intermediate), CA_intermediate (signs server)
# Usage: openssl ca -name CA_root -config ca.tut.o7s.cnf ...

[ req ]
default_bits = 384
default_keyfile = private/key.pem
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha384
x509_extensions = v3_ca

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name

countryName_default = BE
stateOrProvinceName_default = OVL
localityName_default = Ghent
organizationName_default = o7s

[ ca ]
default_ca = CA_root

[ CA_root ]
dir = ./pki/root
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.tut.o7s.crt.pem
private_key = $dir/private/ca.tut.o7s.key.pem
default_days = 3650
default_md = sha384
policy = policy_loose

[ CA_intermediate ]
dir = ./pki/sign
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/sign.tut.o7s.crt.pem
private_key = $dir/private/sign.tut.o7s.key.pem
default_days = 365
default_md = sha384
policy = policy_loose

[ policy_loose ]
commonName = supplied

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
</syntaxhighlight>

'''gen-pki.sh''' - PKI generation script

This script will:
1. Create the directory structure
2. Generate the root CA key and certificate
3. Generate the intermediate CA key and CSR
4. Sign the intermediate CA certificate
5. Generate the server certificate key and CSR
6. Sign the server certificate
7. Verify the complete certificate chain

<syntaxhighlight lang="bash">
#!/bin/bash
# Ouroboros Tutorial 06 - PKI Generation Script (Simplified)
# Generates: Root CA, Intermediate CA, and Server Certificate

set -e

if [ ! -f ca.tut.o7s.cnf ]; then
echo "ERROR: ca.tut.o7s.cnf not found"
exit 1
fi

mkdir -p pki/{root,sign,server}/{certs,private,csr}

# Root CA
openssl ecparam -genkey -name secp384r1 -out pki/root/private/ca.tut.o7s.key.pem 2>/dev/null
openssl req -new -x509 -sha384 -days 7300 \
-config ca.tut.o7s.cnf \
-key pki/root/private/ca.tut.o7s.key.pem \
-out pki/root/certs/ca.tut.o7s.crt.pem \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=ca.tut.o7s" 2>/dev/null

# Intermediate CA
openssl ecparam -genkey -name secp384r1 -out pki/sign/private/sign.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/sign/private/sign.tut.o7s.key.pem \
-out pki/sign/csr/sign.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sign.tut.o7s" 2>/dev/null

touch pki/root/index.txt
echo 1000 > pki/root/serial

openssl ca -name CA_root -config ca.tut.o7s.cnf \
-extensions v3_intermediate_ca -days 3650 -md sha384 -batch \
-in pki/sign/csr/sign.tut.o7s.csr \
-out pki/sign/certs/sign.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Server Certificate
openssl ecparam -genkey -name secp384r1 -out pki/server/private/sec.oping.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/server/private/sec.oping.tut.o7s.key.pem \
-out pki/server/csr/sec.oping.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sec.oping.tut.o7s" 2>/dev/null

touch pki/sign/index.txt
echo 1000 > pki/sign/serial

openssl ca -name CA_intermediate -config ca.tut.o7s.cnf \
-extensions server_cert -days 365 -md sha384 -batch \
-in pki/server/csr/sec.oping.tut.o7s.csr \
-out pki/server/certs/sec.oping.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Verify chain
openssl verify -CAfile pki/root/certs/ca.tut.o7s.crt.pem \
-untrusted pki/sign/certs/sign.tut.o7s.crt.pem \
pki/server/certs/sec.oping.tut.o7s.crt.pem > /dev/null 2>&1

echo "PKI generation complete."
</syntaxhighlight>

== Part 1: Running the Tutorial - Single Session with 4 Tests ==

This section demonstrates a single continuous session with one IRMd and tcpdump instance. The configuration file (<code>tut06.conf</code>) includes autostart for oping, so the server is ready immediately when IRMd starts.

First install the '''CA and Intermediate CA only''' to the system security directories. The server certificate will be installed later during Test 3 (authentication test):

<syntaxhighlight lang="bash">
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}

# Run the PKI generation script
cd /tmp/o7s-tut06
sudo chmod +x gen-pki.sh
sudo ./gen-pki.sh

# Install Root CA (trust anchor)
sudo cp pki/root/certs/ca.tut.o7s.crt.pem /etc/ouroboros/security/cacert/

# Install Intermediate CA (for certificate chain validation)
sudo cp pki/sign/certs/sign.tut.o7s.crt.pem /etc/ouroboros/security/untrusted/
</syntaxhighlight>

=== Running the Tutorial (3 Terminals) ===

In this tutorial, we run a single IRMd session with a concurrent tcpdump instance to capture it. We then run four oping client tests while the IRMd/tcpdump sessions are going, modifying the security configuration between tests. After the tests are complete, we can will down the IRMd and tcpdump sessions with Ctrl-C.

'''Terminal 1: Start tcpdump to capture all packets (runs continuously)'''

<syntaxhighlight lang="bash">
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
</syntaxhighlight>

'''Terminal 2: Start IRMd with debug output (runs continuously)'''

<syntaxhighlight lang="bash">
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
</syntaxhighlight>

'''Terminal 3: Run the tests'''

==== Test 1: No Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Verify directories are empty
sudo ls -la /etc/ouroboros/security/client/sec.oping.tut.o7s/*
sudo ls -la /etc/ouroboros/security/server/sec.oping.tut.o7s/*

# Run first ping test
echo "=== Test 1: No Authentication, No Encryption ==="
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 1: Client initiates plaintext flow allocation'''

<syntaxhighlight lang="text">
irmd/oap(DB): [60e824383b3fbd6a] KEX config: algo=none, mode=server-encap, cipher=none.
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:56 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 1: Server accepts and completes handshake'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' All OAP fields are <code><none></code> because no security is configured (except for the request hash in the response). Flow succeeds with plaintext communication.

==== Test 2: No Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run second ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 2: Client initiates flow with encryption enabled'''

<syntaxhighlight lang="text">
irmd/oap(II): Encryption enabled for sec.oping.tut.o7s.
irmd/oap(DB): [80fd6f9509a996b0] KEX config: algo=prime256v1, mode=server-encap, cipher=aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Generated ephemeral prime256v1 keys (91 bytes).
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 2: Server receives and responds with ephemeral key'''

<syntaxhighlight lang="text">
irmd/oap(DB): [80fd6f9509a996b0] No crt provided.
irmd/oap(DB): [80fd6f9509a996b0] Selected client cipher aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Selected client KDF sha256.
irmd/oap(II): [80fd6f9509a996b0] No key exchange.
irmd/oap(DB): [80fd6f9509a996b0] Generated prime256v1 ephemeral keys.
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' Both client and server generate ephemeral keys (91 bytes each) for encryption. No certificates because authentication is not required. Encryption and authentication are independent.

==== Test 3: With Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Install server certificates and keys
sudo cp /tmp/o7s-tut06/pki/server/certs/sec.oping.tut.o7s.crt.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/crt.pem
sudo cp /tmp/o7s-tut06/pki/server/private/sec.oping.tut.o7s.key.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/key.pem

# enc.conf is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 3: Client initiates flow with encryption and server has certificate'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] <--
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] -->
irmd/oap(PP): crt: [560 bytes]
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 3: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
irmd/oap(DB): [c904b18b563dc1b0] Loaded peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Got public key from crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully verified peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully authenticated peer.
</syntaxhighlight>

'''Key observations:''' Full OAP handshake with certificate (560 bytes) + ephemeral keys (91 bytes) + signature (103 bytes). Client verifies server's certificate against CA store and confirms authentication success.

==== Test 4: With Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)'''

<syntaxhighlight lang="text">
irmd/oap(DB): [03e47baa966a5823] KEX config: algo=none, mode=server-encap, cipher=none.
irmd/oap(PP): OAP_HDR [03e47baa966a5823 @ 2026-02-14 14:09:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>

'''IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [03e47baa966a5823 @ 2026-02-14 14:09:57 (UTC) ] -->
irmd/oap(PP): crt: [560 bytes]
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 4: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
irmd/oap(DB): [03e47baa966a5823] Loaded peer crt.
irmd/oap(DB): [03e47baa966a5823] Got public key from crt.
irmd/oap(DB): [03e47baa966a5823] Successfully verified peer crt.
irmd/oap(DB): [03e47baa966a5823] Successfully authenticated peer.
</syntaxhighlight>

'''Key observations:''' Server sends certificate + signature for authentication, but NO ephemeral keys (plaintext data). Data exchanged without encryption even though authenticated. Demonstrates that authentication and encryption are independent mechanisms.

=== Stop the IRMd and tcpdump, clean up the tutorial files ===

Once all tests complete:

<syntaxhighlight lang="bash">
# Stop IRMd in Terminal 2 (Ctrl+C)
# Stop tcpdump in Terminal 1 (Ctrl+C)

# Clean up tutorial security files from system
sudo rm -f /etc/ouroboros/security/cacert/ca.tut.o7s.crt.pem
</syntaxhighlight>

== Part 2: PCAP Trace Analysis ==

After the tutorial, we now explain the trace in the tcpdump pcap file.

=== Protocol Overview ===

This section summarizes the four protocols that work together in the captured packet flow.

==== Ethernet DIX Frame with EID Header ====

Ouroboros extends the DIX frame with a flow identifier (EID - Endpoint Identifier) and length field.

{| class="wikitable"
|-
! Field !! Octets !! Size !! Description
|-
| Destination MAC || 0-5 || 6 bytes || Hardware address of destination
|-
| Source MAC || 6-11 || 6 bytes || Hardware address of source
|-
| EtherType || 12-13 || 2 bytes || Protocol identifier (0xA000 for Ouroboros)
|-
| EID || 14-15 || 2 bytes || Destination Endpoint Identifier
|-
| Length || 16-17 || 2 bytes || Payload length (needed because of runt frame padding)
|-
| Payload || 18+ || Variable || Frame data (up to MTU size)
|}

==== Ethernet Flow Allocator - Management Protocol ====

The Ethernet DIX management protocol handles flow allocation, setup, and teardown. All management frames use destination EID <code>0x0000</code>.

'''Management Frame Types:'''

{| class="wikitable"
|-
! Code !! Type !! Direction !! Service Hash !! Purpose
|-
| <code>0x00</code> || <code>FLOW_REQ</code> || Client → Server || ✓ Included || Request new flow allocation
|-
| <code>0x01</code> || <code>FLOW_REPLY</code> || Server → Client || – Not included || Respond to flow request (success/failure)
|-
| <code>0x02</code> || <code>NAME_QUERY_REQ</code> || Client → Server || ✓ Included || Query if a remote name is reachable
|-
| <code>0x03</code> || <code>NAME_QUERY_REPLY</code> || Server → Client || ✓ Included || Response to name query
|}

'''Note:''' The 32-byte service hash (SHA3-256) is appended after the management protocol header for NAME_QUERY_* and FLOW_REQ messages to identify which service is being queried or allocated. FLOW_REPLY does not include the service hash; the endpoints are already identified by the allocated EIDs (SEID/DEID) and the flow allocation ID in the OAP header (see below).

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| SEID || 0-1 || 2 bytes || Source Endpoint ID
|-
| DEID || 2-3 || 2 bytes || Destination Endpoint ID
|-
| Loss || 4-7 || 4 bytes || Acceptable packet loss (ppm)
|-
| Bandwidth || 8-15 || 8 bytes || Required bandwidth (bps)
|-
| BER || 16-19 || 4 bytes || Bit error rate (ppm)
|-
| Max Gap || 20-23 || 4 bytes || Maximum consecutive lost packets
|-
| Delay || 24-27 || 4 bytes || Maximum latency (ms)
|-
| Timeout || 28-31 || 4 bytes || Flow idle timeout (seconds)
|-
| Response || 32-35 || 4 bytes || Response code (0=success, negative=error)
|-
| In-Order || 36 || 1 byte || In-order delivery requirement (boolean)
|-
| Code || 37 || 1 byte || Message type (FLOW_REQ, FLOW_REPLY, etc.)
|-
| Availability || 38 || 1 byte || Availability status
|-
| Service hash || 39-61 || 32 bytes || SHA3-256 hash (optional, see above)
|}

==== Ouroboros Flow Allocation Protocol (OAP) ====

The Ouroboros Application Protocol (OAP) is the flow allocation and authentication protocol. It carries flow negotiation requests, responses, and authentication credentials. OAP frames are encapsulated as data payload over the management protocol.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| ID || 0-15 || 16 bytes || Unique flow allocation identifier
|-
| Timestamp || 16-23 || 8 bytes || Creation timestamp (UTC, seconds and microseconds)
|-
| Crt Length || 24-25 || 2 bytes || Certificate length (bytes)
|-
| Certificate || 26+ || Variable || X.509 certificate (DER encoded)
|-
| Eph Length || Variable || 2 bytes || Ephemeral public key length (bytes)
|-
| Ephemeral Key || Variable || Variable || ECDHE public key (DER/raw encoded)
|-
| Data Length || Variable || 2 bytes || Application data length (bytes)
|-
| Data || Variable || Variable || Piggybacked application-layer data
|-
| Sig Length || Variable || 2 bytes || Signature length (bytes)
|-
| Signature || Variable || Variable || Digital signature (ECDSA, DER encoded)
|}

==== Oping Application Protocol ====

The Ouroboros Ping (oping) application is a simple echo/reply protocol used to measure round-trip time and validate connectivity between applications. It implements a request/reply pattern similar to ICMP ping.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| Type || 0-3 || 4 bytes || Message type (ECHO_REQUEST=0 or ECHO_REPLY=1)
|-
| ID || 4-7 || 4 bytes || Sequence number / message identifier
|-
| Timestamp (seconds) || 8-15 || 8 bytes || Seconds when message was sent (CLOCK_REALTIME)
|-
| Timestamp (nanoseconds) || 16-23 || 8 bytes || Nanoseconds component of timestamp
|-
| Payload || 24+ || Variable || Application data (configurable size, default 64 bytes)
|}

'''Field Definitions:'''

* '''Type''' (4 bytes): Message type selector
** <code>0x00000000</code> (ECHO_REQUEST): Client-to-server ping request
** <code>0x00000001</code> (ECHO_REPLY): Server-to-client response

* '''ID''' (4 bytes): Sequence number for matching requests with replies. Incremented for each ping sent.

* '''Timestamp (seconds)''' (8 bytes): Network-byte-order 64-bit seconds component from when the ping was sent (CLOCK_REALTIME).

* '''Timestamp (nanoseconds)''' (8 bytes): Network-byte-order 64-bit nanoseconds component (0-999999999) for high-resolution timing.

* '''Payload''' (Variable): Application data echoed back by the server. Size is configurable (default 64 bytes, maximum 1500 bytes).

'''Usage:'''

* Client sends ECHO_REQUEST with current timestamp
* Server receives request and echoes back as ECHO_REPLY with the same ID and timestamps
* Client calculates RTT by comparing reception time with original timestamps
* Out-of-order detection by tracking sequence numbers (ID field)

=== Packet Analysis: Test 1 - No authentication/encryption ===

==== Packet 1: NAME_QUERY_REQ ====

'''Summary:''' Client sends a NAME_QUERY_REQ message to discover if the service <code>sec.oping.tut.o7s</code> is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.165639 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0002 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

==== Packet 2: NAME_QUERY_REPLY ====

'''Summary:''' Server responds to the NAME_QUERY_REQ by sending a NAME_QUERY_REPLY for the service hash.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.166073 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0003 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code> (echoed back)
|}

==== Packet 3: FLOW_REQ ====

'''Summary:''' Client initiates a flow allocation request (FLOW_REQ) with minimal OAP headers since no authentication or encryption is being used.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.167222 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a51 8a56 ff6f ..f.i.._...Q.V.o
0x0050: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e103 [...}....0w.....
0x0060: 3e52 3300 0000 0000 0000 00 >R3........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || -- || '''UNUSED'''
|-
| 0x24-0x27 || <code>0001 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload'''

The OAP payload starts at offset 0x4b (after management protocol + service hash):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e103 3e52 33</code> || '''Timestamp''' || 8 || Network order || Creation timestamp (seconds + microseconds)
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 (first allocated flow ID for this session)
* Service hash is carried in management protocol payload (32 bytes)
* OAP header is minimal: only ID and timestamp, no optional fields
* No certificate, ephemeral key, data, or signature in this initial request
* Client sends minimal OAP headers with no authentication or encryption setup at allocation time

==== Packet 4: FLOW_REPLY ====

'''Summary:''' Server responds to FLOW_REQ by sending FLOW_REPLY with a new DEID (destination endpoint ID 0x0041) to establish the allocated flow for data transfer.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:49.178732 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0041 0040 0000 0000 0000 0000 ...G.A.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0051 8a56 ff6f ...........Q.V.o
0x0030: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e13f [...}....0w....?
0x0040: a347 3800 0000 0000 0000 00 .G8........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server-side flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0|| Response code (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload'''

The OAP payload starts at offset 0x2b (no service hash in FLOW_REPLY):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Echo of client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e13f a347 38</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x47-0x48 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x49-0x4a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0041 is the newly allocated server-side flow endpoint
* DEID 0x0040 reflects the client's flow ID, creating a bidirectional mapping
* No service hash included (FLOW_REPLY only needs the EIDs to identify the flow)
* OAP echoes the client's ID and timestamp, confirming the flow allocation
* Response code 0x00000000 indicates success
* Both client and server now have their respective flow IDs (0x0040 and 0x0041) for data transfer
* Response code 0x00000000 indicates success

==== Packet 5: ECHO_REQUEST - Plaintext Data ====

'''Summary:''' Client sends an oping ECHO_REQUEST packet to the server using the allocated flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.180824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 7377 0000 .A.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Source Endpoint ID (server → client)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REQUEST Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number (first ping)
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Seconds component
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Nanoseconds component
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (default 64 bytes total - 24 byte header = 40 bytes data)
|}

'''Key observations:'''
* EID 0x0041 shows traffic from server-side flow ID
* This is the first ping request (ID = 0x00000000)
* Timestamp captures when the ping was sent (seconds in network order)
* Default oping payload is 64 bytes total; 24 bytes header + 40 bytes data

==== Packet 6: ECHO_REPLY - Plaintext Data ====

'''Summary:''' Server receives the ECHO_REQUEST and immediately sends back an ECHO_REPLY with the same ID and timestamps, echoing the client's message.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.181496 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 7377 0000 .@.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client ← server)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REPLY Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Echo of original seconds
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Echo of original nanoseconds
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (unchanged from request)
|}

'''Key observations:'''
* EID 0x0040 shows traffic from client-side flow ID receiving the reply
* Type field changed from 0x00000000 (REQUEST) to 0x00000001 (REPLY)
* ID, timestamps, and payload data are identical to the request (echoed back)
* Round-trip time can be calculated by comparing current time with echoed timestamp
* Ping succeeded on first attempt with minimal latency (~1 millisecond between timestamps)

=== Packet Analysis: Test 2 - No authentication, with encryption ===

==== Packet 7: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with encryption enabled. This FLOW_REQ carries an OAP header with an ephemeral ECDHE P-384 public key (91 bytes) for encryption setup.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.808158 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8af1 766b 547c ..f.i.._....vkT|
0x0050: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0060: 8b6c 9000 0000 5b30 5930 1306 072a 8648 .l....[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 c508 1c19 6106 b7e9 3074 57b9 bb16 ......a...0tW...
0x0090: 6959 4a55 81f9 169b cc79 fe10 a882 41fe iYJU.....y....A.
0x00a0: 0697 c9b4 f8f0 5562 7fa2 c7a0 a020 1ac6 ......Ub........
0x00b0: 939f 23ff b2fb 07a2 b747 aacc 474a 3dab ..#......G..GJ=.
0x00c0: 2598 0000 0000 %.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Mixed || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 ... 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e253 8b6c 90</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 ... 3dab 2598</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || ECDHE P-384 public key (DER encoded)
|-
| 0xd3-0xd4 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd5-0xd6 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* Encryption enabled: ephemeral key present (91 bytes)
* Client sends no certificate, allowing anonymous encryption setup
* No signature (unsigned OAP)
* Ephemeral key is ECDHE P-384 for key exchange

==== Packet 8: FLOW_REPLY ====

'''Summary:''' Server accepts the encrypted flow allocation request. FLOW_REPLY contains the server's ephemeral key but no certificate (since client didn't send one).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.810564 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 180:
0x0000: 0000 00a2 0042 0040 0000 0000 0000 0000 .....B.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 00f1 766b 547c ............vkT|
0x0030: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0040: b694 e800 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0050: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0060: 0004 5f3c 6929 cca2 024a ae9f 9aa1 dfc2 .._<i)...J......
0x0070: a493 3ff3 ff58 b054 74dc d2e2 47fc 7c5b ..?..X.Tt...G.|[
0x0080: eff5 e129 72b4 de1e 7c09 bf8c fe38 5e8b ...)r...|....8^.
0x0090: b22e 59ed 6eb9 dfda 369d 691e 6e2c 122c ..Y.n...6.i.n,.,
0x00a0: 9936 0000 0000 .6....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00a2</code> || '''Length''' || 2 || 162 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0042</code> || '''SEID''' || 2 || 0x0042 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || Echo of client ID || Echoes client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e253 b694 e8</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x47-0xa1 || <code>30 5930...9936</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || Server's ECDHE P-384 public key (DER encoded)
|-
| 0xd1-0xd2 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd3-0xd4 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0042 is the new server-side flow endpoint
* Both keys are now exchanged; client and server can derive shared secret
* No authentication (no certificates) but encryption is negotiated
* Response indicates successful allocation

==== Packet 9: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after encryption keys are established. The payload is encrypted with the derived shared secret.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.815771 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0042 0060 a691 6d83 8446 cbeb ac95 c2eb .B.`..m..F......
0x0010: 4b42 e819 c67f 92c8 58d7 0641 d8a6 6e1f KB......X..A..n.
0x0020: fc90 feed ef55 b791 4fbd a832 74bd 8bed .....U..O..2t...
0x0030: 249c 4cee 0fc0 cec6 2f1b aec1 2428 bdbd $.L...../...$(..
0x0040: 36b5 01b5 1257 004e 6ed6 7ecd f0c7 7d11 6....W.Nn.~...}.
0x0050: 20ba e81b f43a 4de9 b141 1624 e1ba 0a84 .....:M..A.$....
0x0060: 74b1 9a9a t...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0042</code> || '''EID''' || 2 || 0x0042 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REQUEST (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>a691 6d83 8446 cbeb...74b1 9a9a</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* All 96 bytes of oping data (type, ID, timestamps, payload) are encrypted
* No plaintext oping headers visible; entire packet is ciphertext
* Flow IDs (0x0042) identify which encryption context to use
* Ping still works with encryption transparently

==== Packet 10: Encrypted ECHO_REPLY ====

'''Summary:''' Server receives encrypted ping request, decrypts it, and sends encrypted ECHO_REPLY.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.819574 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 c6ea 2222 5618 0268 b27e 9a91 .@.`..""V..h.~..
0x0010: f124 1f8d bccc 478c 26fe 9b13 b3cb 5398 .$....G.&.....S.
0x0020: 6869 3cdb 4928 510d 4de8 dc6a 3f3a 6a6d hi<.I(Q.M..j?:jm
0x0030: 6487 dcd8 c8cd 1a85 fba2 9ecd 3566 57d1 d...........5fW.
0x0040: 1c94 ac35 518e 8509 873a 3a5e 04d9 8ee2 ...5Q....::^....
0x0050: 9d74 2527 e425 5433 9d73 9ccd f56a 1f8d .t%'.%T3.s...j..
0x0060: f328 7237 .(r7
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REPLY (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>c6ea 2222 5618 0268...f328 7237</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* EID 0x0040 shows reply going back to client-side flow
* Ciphertext is different from request (different plaintext: type field differs)
* Both encrypted packets are 96 bytes (same size as Packet 9)
* Client receives encrypted reply, decrypts it, verifies ID and timestamps match request
* Encryption is transparent at application layer: oping works exactly as with plaintext flows

=== Packet Analysis: Test 3 - Authentication and encryption ===

==== Packet 11: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation request with encryption enabled. Sends ephemeral public key for ECDHE key exchange but no certificate (client is not authenticating in this tutorial). The management protocol now carries a valid allocated SEID (0x0040).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:58.827411 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a66 bb82 95fa ..f.i.._...f....
0x0050: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0060: c0d2 ad00 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 9dea c238 6732 4987 1cd4 7133 9614 .....8g2I...q3..
0x0090: 9d04 4fde 3f68 42f1 54fb 7ef3 88d0 ffe6 ..O.?hB.T.~.....
0x00a0: 7e01 432e 56c2 2d64 72c9 19fc b0cf 1eca ~.C.V.-dr.......
0x00b0: 689e 3536 771a 8041 726c 20e2 d9bb 3589 h.56w..Arl....5.
0x00c0: 86e7 0000 0000 ......
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (client flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ... 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier for Test 3
|-
| 0x5b-0x62 || <code>18 86a8 e37e c0d2 ad</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || Client not authenticating
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Ephemeral public key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 1306 ... 3589</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Client's ephemeral ECDHE public key for encryption negotiation
|-
| 0xc2-0xc3 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xc4-0xc5 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 - Same as Test 2 (Encrypted) because this is the same client session reusing the same allocated ID from the previous test
* No Certificate - <code>crt_len = 0x0000</code> because the client does not have authentication credentials; the server will authenticate instead
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> because encryption is enabled on the client
* No Signature - <code>sig_len = 0x0000</code> because client is not signing (no certificate to sign with)
* FLOW_REQ Message Type - Code field is 0x00, and service hash is present because FLOW_REQ always includes the service hash
* Timestamp Consistency - Same OAP ID and timestamp structure as Test 2, but with additional security handshake

==== Packet 12: FLOW_REPLY ====

'''Summary:''' Server responds to client's FLOW_REQ by sending FLOW_REPLY with its certificate for authentication, ephemeral public key for ECDHE encryption setup, and a digital signature proving ownership of the certificate. This is the full authentication response.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:39:58.828806 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 843:
0x0000: 0000 0339 0043 0040 0000 0000 0000 0000 ...9.C.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0066 bb82 95fa ...........f....
0x0030: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0040: d566 a002 2f30 8202 2b30 8201 b2a0 0302 .f../0..+0......
(... certificate and signature bytes ...)
0x0320: ef11 c358 f5d0 5cd7 3906 adf1 8a2c 9b25 ...X..\.9....,.%
0x0330: dc78 6050 ab61 3a3f 81c0 254b d193 7827 .x`P.a:?..%K..x'
0x0340: c0e9 38c7 e0d1 c517 d299 9992 07 ..8..........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0339</code> || '''Length''' || 2 || 825 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0043</code> || '''SEID''' || 2 || 0x0043 || Source Endpoint ID (server-side allocated flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (echoed back)
|-
| 0x3b-0x42 || <code>18 86a8 e37e d566 a0</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>022f</code> || '''Crt_len''' || 2 || 559 (0x022f) || Server certificate length: 559 bytes
|-
| 0x45-0x243 || <code>2f30 8202 2b ... 81c8 30</code> || '''Certificate''' || 559 || DER-encoded X.509 || Server's certificate (signed by intermediate CA)
|-
| 0x244-0x245 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Server's ephemeral public key length: 91 bytes
|-
| 0x246-0x2a0 || <code>30 5930 1306 ... 9936</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Server's ephemeral ECDHE public key
|-
| 0x2a4-0x2a5 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x2a6-0x2a7 || <code>0068</code> || '''Sig_len''' || 2 || 104 (0x0068) || Digital signature length: 104 bytes
|-
| 0x2a8-0x30f || <code>30 6602 3100 ... 07</code> || '''Signature''' || 104 || ECDSA signature (DER encoded) || Server's signature over OAP header proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0043 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from the FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Full Certificate - <code>crt_len = 0x022f (559)</code> carrying server's complete X.509 certificate signed by intermediate CA
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> with server's ECDHE public key for encryption
* Signature Included - <code>sig_len = 0x0068 (104)</code> containing ECDSA digital signature over the entire OAP header
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ to confirm association (included in signature, binding response to this specific client request)
* Large Payload - Total of 825 bytes due to certificate (559) + ephemeral key (91) + signature (104) + overhead
* Authentication Complete - Client verifies: (1) certificate against CA store, (2) signature over entire response ensures authenticity and integrity, (3) echoed ID binds response to this specific request, (4) timestamp prevents replay attacks

'''Summary:''' Server responds with its certificate for authentication, ephemeral public key for ECDHE encryption, and a digital signature proving ownership of the certificate.

==== Packet 13: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after authentication handshake. All application data is protected by encryption using the ephemeral keys established in Packets 11-12.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836485 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0043 0060 3bed 0b48 1be1 6930 cf3d dee9 .C.`.;..H..i0.=..
0x0010: 4fc9 774b 5d63 cc9b 5a34 6604 f9ac 1016 O.wK]c..Z4f.....
0x0020: 1c6d c9ac f80e dc89 31c1 9634 1a4f b2c7 .m......1..4.O..
0x0030: 4721 e402 8259 b0aa 8870 4566 33d1 9c18 G!...Y.. .pEf3...
0x0040: 06da 50c3 8b75 86b0 f240 d109 840e a6cd ..P..u...@......
0x0050: d115 77cb 5652 5bfb e6d5 0ca9 dbc3 d0b8 ..w.VR[.........
0x0060: 0058 fd19 .X..
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0043</code> || Client flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REQUEST data'''
|}

'''Key observations:'''
* No visible protocol structure - all application data appears as ciphertext
* Uses the same source/destination EID pair (0x0043 → 0x0060) established in the FLOW_REQ/FLOW_REPLY handshake
* Encryption is done using the ephemeral key (91 bytes) exchanged in Packet 11's OAP header
* Unlike Packets 11-12, this packet contains no certificate, public keys, or signatures
* The 110-byte encrypted data corresponds to the original oping ECHO_REQUEST message

==== Packet 14: Encrypted ECHO_REPLY ====

'''Summary:''' Server sends encrypted ping reply. Note that the flow identifiers swap, demonstrating bidirectional encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836930 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 d552 e100 e681 940c e35a 07d0 .@.`..........Z..
0x0010: a293 1d73 33a5 854e 0fce 4f4d 6655 267a ...s3..N..OMfU&z
0x0020: 3de2 663b 709d 739a a696 2ddd 7b34 28b8 =.f;p.s...-{4(...
0x0030: 5a98 eec2 52c6 4288 3885 ae16 e466 4181 Z...R.B.8...fA..
0x0040: f2d6 44c1 b51b 8728 58a4 7525 fb5e 3fd6 ..D...(X.u%.^?..
0x0050: 7e49 532a d2a5 bea7 55e9 c274 f1b2 0412 ~IS*....U..t....
0x0060: 73d4 6436 s.d6
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0040</code> || Client's inbound flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REPLY data'''
|}

'''Key observations:'''
* The EID in offset 0x00 is now 0x0040 (server's view of client's inbound flow)
* Uses the same ephemeral key material as Packet 13, but encryption direction is reversed
* Both packets use AES-GCM with keys derived from the ECDH exchange
* Timestamp 17:39:59.836930 is only 445 microseconds after Packet 13, indicating server-side processing
* The 110-byte encrypted ECHO_REPLY payload is the same size as the request
* All application data is protected by both authentication (X.509 + ECDSA) and encryption (AES)

=== Packet Analysis: Test 4 - Authentication, no encryption ===

==== Packet 15: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with authentication enabled but encryption disabled. This FLOW_REQ carries an OAP header but '''no ephemeral key''' since the client does not request encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:03.413372 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a8f a6ab 6ea7 ..f.i.._........
0x0050: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0060: 0de6 6100 0000 0000 0000 00 ..a.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... dc40</code> || '''QoS (Various)''' || 28 || Mixed ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e490 0de6 61</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key (no encryption)'''
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* No encryption enabled: ephemeral key absent (Eph_len = 0x0000)
* Client requests authentication only
* Server will respond with certificate + signature but no ephemeral key
* Packet is minimal compared to Packet 11 (Test 3) which includes 91-byte ephemeral key

==== Packet 16: FLOW_REPLY ====

'''Summary:''' Server accepts the authenticated (but not encrypted) flow allocation request. FLOW_REPLY contains the server's X.509 certificate and ECDSA signature for client authentication, but '''no ephemeral key''' since encryption is not being used.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:40:03.416675 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 751:
0x0000: 0000 02dd 0041 0040 0000 0000 0000 0000 .......A.@......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 008f a6ab 6ea7 ................
0x0030: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0040: 3754 a702 2f30 8202 2b30 8201 b2a0 0302 7T../0..+0......
0x0050: 0102 0202 1000 300a 0608 2a86 48ce 3d04 ......0...*.H.=.
(... certificate and signature bytes ...)
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>02dd</code> || '''Length''' || 2 || 733 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (Packet 15 echoed back)
|-
| 0x3b-0x42 || <code>fa18 86a8 e490 3754</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>a702</code> || '''Crt_len''' || 2 || 0x02a7 (679 decimal) || '''Certificate length: 679 bytes'''
|-
| 0x45-0x270 || <code>2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ...</code> || '''Certificate''' || 679 || DER-encoded X.509 || Server's certificate signed by intermediate CA
|-
| 0x271-0x272 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key''' (no encryption)
|-
| 0x273-0x274 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x275-0x276 || <code>0067</code> || '''Sig_len''' || 2 || 0x0067 (103 decimal) || '''ECDSA signature length: 103 bytes'''
|-
| 0x277-0x2dd || <code>3065 0230 75dc 5717 ... 83</code> || '''Signature''' || 103 || ECDSA signature (DER encoded) || Server's ECDSA signature proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0041 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from Packet 15 FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Certificate Field - <code>crt_len = 0x02a7 (679)</code> carrying server's X.509 certificate signed by intermediate CA
* Separate Signature Field - <code>sig_len = 0x0067 (103)</code> with ECDSA signature over entire OAP header
* No Ephemeral Key - <code>eph_len = 0x0000</code> since encryption is '''not''' being used in Test 4
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ (included in signature, binding response to this specific client request)
* Complete OAP Structure - Full OAP header with all standard fields, just without ephemeral key data
* Plaintext Data Exchange - After this FLOW_REPLY, all subsequent application data will be transmitted in plaintext (but authenticated via certificate + signature verification)

==== Packet 17: ECHO_REQUEST ====

'''Summary:''' Client sends plaintext ECHO_REQUEST data through the authenticated (but unencrypted) flow. The oping application's ping request is transmitted directly without encryption, relying on the earlier certificate+signature authentication for security.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.419664 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 8177 0000 .A.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Request (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number / message identifier
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Seconds component from CLOCK_REALTIME
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Nanoseconds component (0-999999999)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0041 → Server Flow - Data is directed to the server's endpoint ID allocated in Packet 16 FLOW_REPLY
* Plaintext Transmission - No encryption layer; oping payload is sent as-is (compare to Packet 13 which had encryption)
* Authenticated Flow - Although plaintext, this data travels on the authenticated flow established in Packet 16 (certificate + signature verified)
* Type = ECHO_REQUEST - 0x00000000 indicates client-to-server ping request
* ID = 0 - Sequence number for matching request/reply pairs
* Test 4 Characteristic - Demonstrates authenticated communication '''without''' encryption; application data is readable but cryptographically bound to the authenticated flow
* Contrast to Test 3 - Packet 13 (Test 3 encrypted ECHO_REQUEST) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

==== Packet 18: ECHO_REPLY ====

'''Summary:''' Server responds with plaintext ECHO_REPLY data, echoing back the client's request. This confirms successful bidirectional communication over the authenticated (but unencrypted) flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.420088 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 8177 0000 .@.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Reply (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (seconds)
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (nanoseconds)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Echoed probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0040 → Client Flow - Server responds to client's endpoint ID from Packet 15 FLOW_REQ
* Type = ECHO_REPLY - 0x00000001 indicates server-to-client response
* ID = 0 - Echoes the request sequence number, matching this response to the request
* Timestamps Echo Request - Both timestamp fields are copied from Packet 17 unchanged (8177 0000 0000 0000 and aa16 1c16 0000 0000)
* Plaintext Reply - No encryption; server's response payload is readable (compare to Packet 14 which had encryption)
* Authenticated Channel - Although plaintext, this reply is part of the authenticated flow; client can verify integrity through earlier certificate+signature
* Test 4 Completion - Demonstrates '''full bidirectional plaintext communication''' over an authenticated (but unencrypted) flow
* Contrast to Test 3 - Packet 14 (Test 3 encrypted ECHO_REPLY) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

Ouroboros Tutorial 06

2026-02-14T14:56:42Z

Dimitri: /* Test 3: With Authentication, With Encryption */

= Ouroboros Tutorial 06 - Authenticated Flows =

This tutorial demonstrates setting up and using authenticated flows in Ouroboros with certificate-based authentication.

The overall flow of authenticated flow allocation is

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

'''Tutorial Directory:''' This tutorial will execute in <code>/tmp/o7s-tut06/</code>. All configuration files, generated certificates, logs, and packet captures will be stored in this directory.

We create a complete PKI (Public Key Infrastructure):

* '''Root CA''' (<code>ca.tut.o7s</code>): Self-signed trust anchor
* '''Intermediate CA''' (<code>sign.tut.o7s</code>): Signed by root with pathlen:0 constraint
* '''Server Certificate''' (<code>sec.oping.tut.o7s</code>): Signed by intermediate CA

This tutorial uses ECDSA P-384 with SHA-384 hashing.

== Setting Up the Tutorial ==

To properly understand and debug the authenticated flows, this tutorial uses a debug build of Ouroboros with OAP protocol debugging enabled.

<syntaxhighlight lang="bash">
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
</syntaxhighlight>

When built with these options, the IRMd will output detailed OAP protocol information.

=== Configuration Files ===

The following three files should be created in the tutorial directory (<code>/tmp/o7s-tut06/</code>) before starting the tutorial:

'''tut06.conf''' - IRMd configuration

<syntaxhighlight lang="ini">
# Ouroboros Tutorial 06 - Authenticated Flows Configuration
# Uses system-installed certificates at /etc/ouroboros/security/

[name."sec.oping.tut.o7s"]
prog=["/usr/bin/oping"]
args=["--listen"]

[eth-dix.eth-dix-lo]
bootstrap="eth-dix-network"
dev="lo"
reg=["sec.oping.tut.o7s"]
</syntaxhighlight>

'''ca.tut.o7s.cnf''' - OpenSSL configuration for PKI generation

<syntaxhighlight lang="text">
# Unified OpenSSL Configuration for Ouroboros Tutorial 06
# Named CA sections: CA_root (signs intermediate), CA_intermediate (signs server)
# Usage: openssl ca -name CA_root -config ca.tut.o7s.cnf ...

[ req ]
default_bits = 384
default_keyfile = private/key.pem
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha384
x509_extensions = v3_ca

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name

countryName_default = BE
stateOrProvinceName_default = OVL
localityName_default = Ghent
organizationName_default = o7s

[ ca ]
default_ca = CA_root

[ CA_root ]
dir = ./pki/root
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.tut.o7s.crt.pem
private_key = $dir/private/ca.tut.o7s.key.pem
default_days = 3650
default_md = sha384
policy = policy_loose

[ CA_intermediate ]
dir = ./pki/sign
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/sign.tut.o7s.crt.pem
private_key = $dir/private/sign.tut.o7s.key.pem
default_days = 365
default_md = sha384
policy = policy_loose

[ policy_loose ]
commonName = supplied

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
</syntaxhighlight>

'''gen-pki.sh''' - PKI generation script

This script will:
1. Create the directory structure
2. Generate the root CA key and certificate
3. Generate the intermediate CA key and CSR
4. Sign the intermediate CA certificate
5. Generate the server certificate key and CSR
6. Sign the server certificate
7. Verify the complete certificate chain

<syntaxhighlight lang="bash">
#!/bin/bash
# Ouroboros Tutorial 06 - PKI Generation Script (Simplified)
# Generates: Root CA, Intermediate CA, and Server Certificate

set -e

if [ ! -f ca.tut.o7s.cnf ]; then
echo "ERROR: ca.tut.o7s.cnf not found"
exit 1
fi

mkdir -p pki/{root,sign,server}/{certs,private,csr}

# Root CA
openssl ecparam -genkey -name secp384r1 -out pki/root/private/ca.tut.o7s.key.pem 2>/dev/null
openssl req -new -x509 -sha384 -days 7300 \
-config ca.tut.o7s.cnf \
-key pki/root/private/ca.tut.o7s.key.pem \
-out pki/root/certs/ca.tut.o7s.crt.pem \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=ca.tut.o7s" 2>/dev/null

# Intermediate CA
openssl ecparam -genkey -name secp384r1 -out pki/sign/private/sign.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/sign/private/sign.tut.o7s.key.pem \
-out pki/sign/csr/sign.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sign.tut.o7s" 2>/dev/null

touch pki/root/index.txt
echo 1000 > pki/root/serial

openssl ca -name CA_root -config ca.tut.o7s.cnf \
-extensions v3_intermediate_ca -days 3650 -md sha384 -batch \
-in pki/sign/csr/sign.tut.o7s.csr \
-out pki/sign/certs/sign.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Server Certificate
openssl ecparam -genkey -name secp384r1 -out pki/server/private/sec.oping.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/server/private/sec.oping.tut.o7s.key.pem \
-out pki/server/csr/sec.oping.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sec.oping.tut.o7s" 2>/dev/null

touch pki/sign/index.txt
echo 1000 > pki/sign/serial

openssl ca -name CA_intermediate -config ca.tut.o7s.cnf \
-extensions server_cert -days 365 -md sha384 -batch \
-in pki/server/csr/sec.oping.tut.o7s.csr \
-out pki/server/certs/sec.oping.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Verify chain
openssl verify -CAfile pki/root/certs/ca.tut.o7s.crt.pem \
-untrusted pki/sign/certs/sign.tut.o7s.crt.pem \
pki/server/certs/sec.oping.tut.o7s.crt.pem > /dev/null 2>&1

echo "PKI generation complete."
</syntaxhighlight>

== Part 1: Running the Tutorial - Single Session with 4 Tests ==

This section demonstrates a single continuous session with one IRMd and tcpdump instance. The configuration file (<code>tut06.conf</code>) includes autostart for oping, so the server is ready immediately when IRMd starts.

First install the '''CA and Intermediate CA only''' to the system security directories. The server certificate will be installed later during Test 3 (authentication test):

<syntaxhighlight lang="bash">
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}

# Run the PKI generation script
cd /tmp/o7s-tut06
sudo chmod +x gen-pki.sh
sudo ./gen-pki.sh

# Install Root CA (trust anchor)
sudo cp pki/root/certs/ca.tut.o7s.crt.pem /etc/ouroboros/security/cacert/

# Install Intermediate CA (for certificate chain validation)
sudo cp pki/sign/certs/sign.tut.o7s.crt.pem /etc/ouroboros/security/untrusted/
</syntaxhighlight>

=== Running the Tutorial (3 Terminals) ===

In this tutorial, we run a single IRMd session with a concurrent tcpdump instance to capture it. We then run four oping client tests while the IRMd/tcpdump sessions are going, modifying the security configuration between tests. After the tests are complete, we can will down the IRMd and tcpdump sessions with Ctrl-C.

'''Terminal 1: Start tcpdump to capture all packets (runs continuously)'''

<syntaxhighlight lang="bash">
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
</syntaxhighlight>

'''Terminal 2: Start IRMd with debug output (runs continuously)'''

<syntaxhighlight lang="bash">
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
</syntaxhighlight>

'''Terminal 3: Run the tests'''

==== Test 1: No Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Verify directories are empty
sudo ls -la /etc/ouroboros/security/client/sec.oping.tut.o7s/*
sudo ls -la /etc/ouroboros/security/server/sec.oping.tut.o7s/*

# Run first ping test
echo "=== Test 1: No Authentication, No Encryption ==="
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 1: Client initiates plaintext flow allocation'''

<syntaxhighlight lang="text">
irmd/oap(DB): [60e824383b3fbd6a] KEX config: algo=none, mode=server-encap, cipher=none.
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:56 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 1: Server accepts and completes handshake'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' All OAP fields are <code><none></code> because no security is configured (except for the request hash in the response). Flow succeeds with plaintext communication.

==== Test 2: No Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run second ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 2: Client initiates flow with encryption enabled'''

<syntaxhighlight lang="text">
irmd/oap(II): Encryption enabled for sec.oping.tut.o7s.
irmd/oap(DB): [80fd6f9509a996b0] KEX config: algo=prime256v1, mode=server-encap, cipher=aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Generated ephemeral prime256v1 keys (91 bytes).
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 2: Server receives and responds with ephemeral key'''

<syntaxhighlight lang="text">
irmd/oap(DB): [80fd6f9509a996b0] No crt provided.
irmd/oap(DB): [80fd6f9509a996b0] Selected client cipher aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Selected client KDF sha256.
irmd/oap(II): [80fd6f9509a996b0] No key exchange.
irmd/oap(DB): [80fd6f9509a996b0] Generated prime256v1 ephemeral keys.
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' Both client and server generate ephemeral keys (91 bytes each) for encryption. No certificates because authentication is not required. Encryption and authentication are independent.

==== Test 3: With Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Install server certificates and keys
sudo cp /tmp/o7s-tut06/pki/server/certs/sec.oping.tut.o7s.crt.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/crt.pem
sudo cp /tmp/o7s-tut06/pki/server/private/sec.oping.tut.o7s.key.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/key.pem

# enc.conf is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 3: Client initiates flow with encryption and server has certificate'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] <--
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [c904b18b563dc1b0 @ 2026-02-14 14:09:47 (UTC) ] -->
irmd/oap(PP): crt: [560 bytes]
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 3: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
irmd/oap(DB): [c904b18b563dc1b0] Loaded peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Got public key from crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully verified peer crt.
irmd/oap(DB): [c904b18b563dc1b0] Successfully authenticated peer.
</syntaxhighlight>

'''Key observations:''' Full OAP handshake with certificate (560 bytes) + ephemeral keys (91 bytes) + signature (103 bytes). Client verifies server's certificate against CA store and confirms authentication success.

==== Test 4: With Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33642 to sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf does not exist.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211 @ 2026-01-01 11:27:34 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)'''

<syntaxhighlight lang="text">
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211] -->
==33047== irmd/oap(PP): Certificate: [560 bytes]
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 4: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Loaded peer certificate for sec.oping.tut.o7s.
==33047== irmd(DB): Certificate matches name sec.oping.tut.o7s.
==33047== irmd(DB): Got public key from certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully verified peer certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully authenticated sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Server sends certificate + signature for authentication, but NO ephemeral keys (plaintext data). Data exchanged without encryption even though authenticated. Demonstrates that authentication and encryption are independent mechanisms.

=== Stop the IRMd and tcpdump, clean up the tutorial files ===

Once all tests complete:

<syntaxhighlight lang="bash">
# Stop IRMd in Terminal 2 (Ctrl+C)
# Stop tcpdump in Terminal 1 (Ctrl+C)

# Clean up tutorial security files from system
sudo rm -f /etc/ouroboros/security/cacert/ca.tut.o7s.crt.pem
</syntaxhighlight>

== Part 2: PCAP Trace Analysis ==

After the tutorial, we now explain the trace in the tcpdump pcap file.

=== Protocol Overview ===

This section summarizes the four protocols that work together in the captured packet flow.

==== Ethernet DIX Frame with EID Header ====

Ouroboros extends the DIX frame with a flow identifier (EID - Endpoint Identifier) and length field.

{| class="wikitable"
|-
! Field !! Octets !! Size !! Description
|-
| Destination MAC || 0-5 || 6 bytes || Hardware address of destination
|-
| Source MAC || 6-11 || 6 bytes || Hardware address of source
|-
| EtherType || 12-13 || 2 bytes || Protocol identifier (0xA000 for Ouroboros)
|-
| EID || 14-15 || 2 bytes || Destination Endpoint Identifier
|-
| Length || 16-17 || 2 bytes || Payload length (needed because of runt frame padding)
|-
| Payload || 18+ || Variable || Frame data (up to MTU size)
|}

==== Ethernet Flow Allocator - Management Protocol ====

The Ethernet DIX management protocol handles flow allocation, setup, and teardown. All management frames use destination EID <code>0x0000</code>.

'''Management Frame Types:'''

{| class="wikitable"
|-
! Code !! Type !! Direction !! Service Hash !! Purpose
|-
| <code>0x00</code> || <code>FLOW_REQ</code> || Client → Server || ✓ Included || Request new flow allocation
|-
| <code>0x01</code> || <code>FLOW_REPLY</code> || Server → Client || – Not included || Respond to flow request (success/failure)
|-
| <code>0x02</code> || <code>NAME_QUERY_REQ</code> || Client → Server || ✓ Included || Query if a remote name is reachable
|-
| <code>0x03</code> || <code>NAME_QUERY_REPLY</code> || Server → Client || ✓ Included || Response to name query
|}

'''Note:''' The 32-byte service hash (SHA3-256) is appended after the management protocol header for NAME_QUERY_* and FLOW_REQ messages to identify which service is being queried or allocated. FLOW_REPLY does not include the service hash; the endpoints are already identified by the allocated EIDs (SEID/DEID) and the flow allocation ID in the OAP header (see below).

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| SEID || 0-1 || 2 bytes || Source Endpoint ID
|-
| DEID || 2-3 || 2 bytes || Destination Endpoint ID
|-
| Loss || 4-7 || 4 bytes || Acceptable packet loss (ppm)
|-
| Bandwidth || 8-15 || 8 bytes || Required bandwidth (bps)
|-
| BER || 16-19 || 4 bytes || Bit error rate (ppm)
|-
| Max Gap || 20-23 || 4 bytes || Maximum consecutive lost packets
|-
| Delay || 24-27 || 4 bytes || Maximum latency (ms)
|-
| Timeout || 28-31 || 4 bytes || Flow idle timeout (seconds)
|-
| Response || 32-35 || 4 bytes || Response code (0=success, negative=error)
|-
| In-Order || 36 || 1 byte || In-order delivery requirement (boolean)
|-
| Code || 37 || 1 byte || Message type (FLOW_REQ, FLOW_REPLY, etc.)
|-
| Availability || 38 || 1 byte || Availability status
|-
| Service hash || 39-61 || 32 bytes || SHA3-256 hash (optional, see above)
|}

==== Ouroboros Flow Allocation Protocol (OAP) ====

The Ouroboros Application Protocol (OAP) is the flow allocation and authentication protocol. It carries flow negotiation requests, responses, and authentication credentials. OAP frames are encapsulated as data payload over the management protocol.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| ID || 0-15 || 16 bytes || Unique flow allocation identifier
|-
| Timestamp || 16-23 || 8 bytes || Creation timestamp (UTC, seconds and microseconds)
|-
| Crt Length || 24-25 || 2 bytes || Certificate length (bytes)
|-
| Certificate || 26+ || Variable || X.509 certificate (DER encoded)
|-
| Eph Length || Variable || 2 bytes || Ephemeral public key length (bytes)
|-
| Ephemeral Key || Variable || Variable || ECDHE public key (DER/raw encoded)
|-
| Data Length || Variable || 2 bytes || Application data length (bytes)
|-
| Data || Variable || Variable || Piggybacked application-layer data
|-
| Sig Length || Variable || 2 bytes || Signature length (bytes)
|-
| Signature || Variable || Variable || Digital signature (ECDSA, DER encoded)
|}

==== Oping Application Protocol ====

The Ouroboros Ping (oping) application is a simple echo/reply protocol used to measure round-trip time and validate connectivity between applications. It implements a request/reply pattern similar to ICMP ping.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| Type || 0-3 || 4 bytes || Message type (ECHO_REQUEST=0 or ECHO_REPLY=1)
|-
| ID || 4-7 || 4 bytes || Sequence number / message identifier
|-
| Timestamp (seconds) || 8-15 || 8 bytes || Seconds when message was sent (CLOCK_REALTIME)
|-
| Timestamp (nanoseconds) || 16-23 || 8 bytes || Nanoseconds component of timestamp
|-
| Payload || 24+ || Variable || Application data (configurable size, default 64 bytes)
|}

'''Field Definitions:'''

* '''Type''' (4 bytes): Message type selector
** <code>0x00000000</code> (ECHO_REQUEST): Client-to-server ping request
** <code>0x00000001</code> (ECHO_REPLY): Server-to-client response

* '''ID''' (4 bytes): Sequence number for matching requests with replies. Incremented for each ping sent.

* '''Timestamp (seconds)''' (8 bytes): Network-byte-order 64-bit seconds component from when the ping was sent (CLOCK_REALTIME).

* '''Timestamp (nanoseconds)''' (8 bytes): Network-byte-order 64-bit nanoseconds component (0-999999999) for high-resolution timing.

* '''Payload''' (Variable): Application data echoed back by the server. Size is configurable (default 64 bytes, maximum 1500 bytes).

'''Usage:'''

* Client sends ECHO_REQUEST with current timestamp
* Server receives request and echoes back as ECHO_REPLY with the same ID and timestamps
* Client calculates RTT by comparing reception time with original timestamps
* Out-of-order detection by tracking sequence numbers (ID field)

=== Packet Analysis: Test 1 - No authentication/encryption ===

==== Packet 1: NAME_QUERY_REQ ====

'''Summary:''' Client sends a NAME_QUERY_REQ message to discover if the service <code>sec.oping.tut.o7s</code> is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.165639 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0002 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

==== Packet 2: NAME_QUERY_REPLY ====

'''Summary:''' Server responds to the NAME_QUERY_REQ by sending a NAME_QUERY_REPLY for the service hash.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.166073 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0003 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code> (echoed back)
|}

==== Packet 3: FLOW_REQ ====

'''Summary:''' Client initiates a flow allocation request (FLOW_REQ) with minimal OAP headers since no authentication or encryption is being used.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.167222 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a51 8a56 ff6f ..f.i.._...Q.V.o
0x0050: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e103 [...}....0w.....
0x0060: 3e52 3300 0000 0000 0000 00 >R3........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || -- || '''UNUSED'''
|-
| 0x24-0x27 || <code>0001 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload'''

The OAP payload starts at offset 0x4b (after management protocol + service hash):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e103 3e52 33</code> || '''Timestamp''' || 8 || Network order || Creation timestamp (seconds + microseconds)
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 (first allocated flow ID for this session)
* Service hash is carried in management protocol payload (32 bytes)
* OAP header is minimal: only ID and timestamp, no optional fields
* No certificate, ephemeral key, data, or signature in this initial request
* Client sends minimal OAP headers with no authentication or encryption setup at allocation time

==== Packet 4: FLOW_REPLY ====

'''Summary:''' Server responds to FLOW_REQ by sending FLOW_REPLY with a new DEID (destination endpoint ID 0x0041) to establish the allocated flow for data transfer.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:49.178732 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0041 0040 0000 0000 0000 0000 ...G.A.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0051 8a56 ff6f ...........Q.V.o
0x0030: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e13f [...}....0w....?
0x0040: a347 3800 0000 0000 0000 00 .G8........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server-side flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0|| Response code (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload'''

The OAP payload starts at offset 0x2b (no service hash in FLOW_REPLY):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Echo of client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e13f a347 38</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x47-0x48 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x49-0x4a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0041 is the newly allocated server-side flow endpoint
* DEID 0x0040 reflects the client's flow ID, creating a bidirectional mapping
* No service hash included (FLOW_REPLY only needs the EIDs to identify the flow)
* OAP echoes the client's ID and timestamp, confirming the flow allocation
* Response code 0x00000000 indicates success
* Both client and server now have their respective flow IDs (0x0040 and 0x0041) for data transfer
* Response code 0x00000000 indicates success

==== Packet 5: ECHO_REQUEST - Plaintext Data ====

'''Summary:''' Client sends an oping ECHO_REQUEST packet to the server using the allocated flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.180824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 7377 0000 .A.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Source Endpoint ID (server → client)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REQUEST Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number (first ping)
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Seconds component
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Nanoseconds component
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (default 64 bytes total - 24 byte header = 40 bytes data)
|}

'''Key observations:'''
* EID 0x0041 shows traffic from server-side flow ID
* This is the first ping request (ID = 0x00000000)
* Timestamp captures when the ping was sent (seconds in network order)
* Default oping payload is 64 bytes total; 24 bytes header + 40 bytes data

==== Packet 6: ECHO_REPLY - Plaintext Data ====

'''Summary:''' Server receives the ECHO_REQUEST and immediately sends back an ECHO_REPLY with the same ID and timestamps, echoing the client's message.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.181496 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 7377 0000 .@.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client ← server)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REPLY Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Echo of original seconds
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Echo of original nanoseconds
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (unchanged from request)
|}

'''Key observations:'''
* EID 0x0040 shows traffic from client-side flow ID receiving the reply
* Type field changed from 0x00000000 (REQUEST) to 0x00000001 (REPLY)
* ID, timestamps, and payload data are identical to the request (echoed back)
* Round-trip time can be calculated by comparing current time with echoed timestamp
* Ping succeeded on first attempt with minimal latency (~1 millisecond between timestamps)

=== Packet Analysis: Test 2 - No authentication, with encryption ===

==== Packet 7: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with encryption enabled. This FLOW_REQ carries an OAP header with an ephemeral ECDHE P-384 public key (91 bytes) for encryption setup.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.808158 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8af1 766b 547c ..f.i.._....vkT|
0x0050: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0060: 8b6c 9000 0000 5b30 5930 1306 072a 8648 .l....[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 c508 1c19 6106 b7e9 3074 57b9 bb16 ......a...0tW...
0x0090: 6959 4a55 81f9 169b cc79 fe10 a882 41fe iYJU.....y....A.
0x00a0: 0697 c9b4 f8f0 5562 7fa2 c7a0 a020 1ac6 ......Ub........
0x00b0: 939f 23ff b2fb 07a2 b747 aacc 474a 3dab ..#......G..GJ=.
0x00c0: 2598 0000 0000 %.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Mixed || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 ... 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e253 8b6c 90</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 ... 3dab 2598</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || ECDHE P-384 public key (DER encoded)
|-
| 0xd3-0xd4 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd5-0xd6 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* Encryption enabled: ephemeral key present (91 bytes)
* Client sends no certificate, allowing anonymous encryption setup
* No signature (unsigned OAP)
* Ephemeral key is ECDHE P-384 for key exchange

==== Packet 8: FLOW_REPLY ====

'''Summary:''' Server accepts the encrypted flow allocation request. FLOW_REPLY contains the server's ephemeral key but no certificate (since client didn't send one).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.810564 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 180:
0x0000: 0000 00a2 0042 0040 0000 0000 0000 0000 .....B.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 00f1 766b 547c ............vkT|
0x0030: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0040: b694 e800 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0050: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0060: 0004 5f3c 6929 cca2 024a ae9f 9aa1 dfc2 .._<i)...J......
0x0070: a493 3ff3 ff58 b054 74dc d2e2 47fc 7c5b ..?..X.Tt...G.|[
0x0080: eff5 e129 72b4 de1e 7c09 bf8c fe38 5e8b ...)r...|....8^.
0x0090: b22e 59ed 6eb9 dfda 369d 691e 6e2c 122c ..Y.n...6.i.n,.,
0x00a0: 9936 0000 0000 .6....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00a2</code> || '''Length''' || 2 || 162 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0042</code> || '''SEID''' || 2 || 0x0042 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || Echo of client ID || Echoes client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e253 b694 e8</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x47-0xa1 || <code>30 5930...9936</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || Server's ECDHE P-384 public key (DER encoded)
|-
| 0xd1-0xd2 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd3-0xd4 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0042 is the new server-side flow endpoint
* Both keys are now exchanged; client and server can derive shared secret
* No authentication (no certificates) but encryption is negotiated
* Response indicates successful allocation

==== Packet 9: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after encryption keys are established. The payload is encrypted with the derived shared secret.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.815771 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0042 0060 a691 6d83 8446 cbeb ac95 c2eb .B.`..m..F......
0x0010: 4b42 e819 c67f 92c8 58d7 0641 d8a6 6e1f KB......X..A..n.
0x0020: fc90 feed ef55 b791 4fbd a832 74bd 8bed .....U..O..2t...
0x0030: 249c 4cee 0fc0 cec6 2f1b aec1 2428 bdbd $.L...../...$(..
0x0040: 36b5 01b5 1257 004e 6ed6 7ecd f0c7 7d11 6....W.Nn.~...}.
0x0050: 20ba e81b f43a 4de9 b141 1624 e1ba 0a84 .....:M..A.$....
0x0060: 74b1 9a9a t...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0042</code> || '''EID''' || 2 || 0x0042 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REQUEST (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>a691 6d83 8446 cbeb...74b1 9a9a</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* All 96 bytes of oping data (type, ID, timestamps, payload) are encrypted
* No plaintext oping headers visible; entire packet is ciphertext
* Flow IDs (0x0042) identify which encryption context to use
* Ping still works with encryption transparently

==== Packet 10: Encrypted ECHO_REPLY ====

'''Summary:''' Server receives encrypted ping request, decrypts it, and sends encrypted ECHO_REPLY.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.819574 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 c6ea 2222 5618 0268 b27e 9a91 .@.`..""V..h.~..
0x0010: f124 1f8d bccc 478c 26fe 9b13 b3cb 5398 .$....G.&.....S.
0x0020: 6869 3cdb 4928 510d 4de8 dc6a 3f3a 6a6d hi<.I(Q.M..j?:jm
0x0030: 6487 dcd8 c8cd 1a85 fba2 9ecd 3566 57d1 d...........5fW.
0x0040: 1c94 ac35 518e 8509 873a 3a5e 04d9 8ee2 ...5Q....::^....
0x0050: 9d74 2527 e425 5433 9d73 9ccd f56a 1f8d .t%'.%T3.s...j..
0x0060: f328 7237 .(r7
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REPLY (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>c6ea 2222 5618 0268...f328 7237</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* EID 0x0040 shows reply going back to client-side flow
* Ciphertext is different from request (different plaintext: type field differs)
* Both encrypted packets are 96 bytes (same size as Packet 9)
* Client receives encrypted reply, decrypts it, verifies ID and timestamps match request
* Encryption is transparent at application layer: oping works exactly as with plaintext flows

=== Packet Analysis: Test 3 - Authentication and encryption ===

==== Packet 11: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation request with encryption enabled. Sends ephemeral public key for ECDHE key exchange but no certificate (client is not authenticating in this tutorial). The management protocol now carries a valid allocated SEID (0x0040).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:58.827411 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a66 bb82 95fa ..f.i.._...f....
0x0050: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0060: c0d2 ad00 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 9dea c238 6732 4987 1cd4 7133 9614 .....8g2I...q3..
0x0090: 9d04 4fde 3f68 42f1 54fb 7ef3 88d0 ffe6 ..O.?hB.T.~.....
0x00a0: 7e01 432e 56c2 2d64 72c9 19fc b0cf 1eca ~.C.V.-dr.......
0x00b0: 689e 3536 771a 8041 726c 20e2 d9bb 3589 h.56w..Arl....5.
0x00c0: 86e7 0000 0000 ......
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (client flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ... 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier for Test 3
|-
| 0x5b-0x62 || <code>18 86a8 e37e c0d2 ad</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || Client not authenticating
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Ephemeral public key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 1306 ... 3589</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Client's ephemeral ECDHE public key for encryption negotiation
|-
| 0xc2-0xc3 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xc4-0xc5 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 - Same as Test 2 (Encrypted) because this is the same client session reusing the same allocated ID from the previous test
* No Certificate - <code>crt_len = 0x0000</code> because the client does not have authentication credentials; the server will authenticate instead
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> because encryption is enabled on the client
* No Signature - <code>sig_len = 0x0000</code> because client is not signing (no certificate to sign with)
* FLOW_REQ Message Type - Code field is 0x00, and service hash is present because FLOW_REQ always includes the service hash
* Timestamp Consistency - Same OAP ID and timestamp structure as Test 2, but with additional security handshake

==== Packet 12: FLOW_REPLY ====

'''Summary:''' Server responds to client's FLOW_REQ by sending FLOW_REPLY with its certificate for authentication, ephemeral public key for ECDHE encryption setup, and a digital signature proving ownership of the certificate. This is the full authentication response.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:39:58.828806 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 843:
0x0000: 0000 0339 0043 0040 0000 0000 0000 0000 ...9.C.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0066 bb82 95fa ...........f....
0x0030: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0040: d566 a002 2f30 8202 2b30 8201 b2a0 0302 .f../0..+0......
(... certificate and signature bytes ...)
0x0320: ef11 c358 f5d0 5cd7 3906 adf1 8a2c 9b25 ...X..\.9....,.%
0x0330: dc78 6050 ab61 3a3f 81c0 254b d193 7827 .x`P.a:?..%K..x'
0x0340: c0e9 38c7 e0d1 c517 d299 9992 07 ..8..........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0339</code> || '''Length''' || 2 || 825 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0043</code> || '''SEID''' || 2 || 0x0043 || Source Endpoint ID (server-side allocated flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (echoed back)
|-
| 0x3b-0x42 || <code>18 86a8 e37e d566 a0</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>022f</code> || '''Crt_len''' || 2 || 559 (0x022f) || Server certificate length: 559 bytes
|-
| 0x45-0x243 || <code>2f30 8202 2b ... 81c8 30</code> || '''Certificate''' || 559 || DER-encoded X.509 || Server's certificate (signed by intermediate CA)
|-
| 0x244-0x245 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Server's ephemeral public key length: 91 bytes
|-
| 0x246-0x2a0 || <code>30 5930 1306 ... 9936</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Server's ephemeral ECDHE public key
|-
| 0x2a4-0x2a5 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x2a6-0x2a7 || <code>0068</code> || '''Sig_len''' || 2 || 104 (0x0068) || Digital signature length: 104 bytes
|-
| 0x2a8-0x30f || <code>30 6602 3100 ... 07</code> || '''Signature''' || 104 || ECDSA signature (DER encoded) || Server's signature over OAP header proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0043 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from the FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Full Certificate - <code>crt_len = 0x022f (559)</code> carrying server's complete X.509 certificate signed by intermediate CA
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> with server's ECDHE public key for encryption
* Signature Included - <code>sig_len = 0x0068 (104)</code> containing ECDSA digital signature over the entire OAP header
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ to confirm association (included in signature, binding response to this specific client request)
* Large Payload - Total of 825 bytes due to certificate (559) + ephemeral key (91) + signature (104) + overhead
* Authentication Complete - Client verifies: (1) certificate against CA store, (2) signature over entire response ensures authenticity and integrity, (3) echoed ID binds response to this specific request, (4) timestamp prevents replay attacks

'''Summary:''' Server responds with its certificate for authentication, ephemeral public key for ECDHE encryption, and a digital signature proving ownership of the certificate.

==== Packet 13: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after authentication handshake. All application data is protected by encryption using the ephemeral keys established in Packets 11-12.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836485 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0043 0060 3bed 0b48 1be1 6930 cf3d dee9 .C.`.;..H..i0.=..
0x0010: 4fc9 774b 5d63 cc9b 5a34 6604 f9ac 1016 O.wK]c..Z4f.....
0x0020: 1c6d c9ac f80e dc89 31c1 9634 1a4f b2c7 .m......1..4.O..
0x0030: 4721 e402 8259 b0aa 8870 4566 33d1 9c18 G!...Y.. .pEf3...
0x0040: 06da 50c3 8b75 86b0 f240 d109 840e a6cd ..P..u...@......
0x0050: d115 77cb 5652 5bfb e6d5 0ca9 dbc3 d0b8 ..w.VR[.........
0x0060: 0058 fd19 .X..
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0043</code> || Client flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REQUEST data'''
|}

'''Key observations:'''
* No visible protocol structure - all application data appears as ciphertext
* Uses the same source/destination EID pair (0x0043 → 0x0060) established in the FLOW_REQ/FLOW_REPLY handshake
* Encryption is done using the ephemeral key (91 bytes) exchanged in Packet 11's OAP header
* Unlike Packets 11-12, this packet contains no certificate, public keys, or signatures
* The 110-byte encrypted data corresponds to the original oping ECHO_REQUEST message

==== Packet 14: Encrypted ECHO_REPLY ====

'''Summary:''' Server sends encrypted ping reply. Note that the flow identifiers swap, demonstrating bidirectional encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836930 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 d552 e100 e681 940c e35a 07d0 .@.`..........Z..
0x0010: a293 1d73 33a5 854e 0fce 4f4d 6655 267a ...s3..N..OMfU&z
0x0020: 3de2 663b 709d 739a a696 2ddd 7b34 28b8 =.f;p.s...-{4(...
0x0030: 5a98 eec2 52c6 4288 3885 ae16 e466 4181 Z...R.B.8...fA..
0x0040: f2d6 44c1 b51b 8728 58a4 7525 fb5e 3fd6 ..D...(X.u%.^?..
0x0050: 7e49 532a d2a5 bea7 55e9 c274 f1b2 0412 ~IS*....U..t....
0x0060: 73d4 6436 s.d6
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0040</code> || Client's inbound flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REPLY data'''
|}

'''Key observations:'''
* The EID in offset 0x00 is now 0x0040 (server's view of client's inbound flow)
* Uses the same ephemeral key material as Packet 13, but encryption direction is reversed
* Both packets use AES-GCM with keys derived from the ECDH exchange
* Timestamp 17:39:59.836930 is only 445 microseconds after Packet 13, indicating server-side processing
* The 110-byte encrypted ECHO_REPLY payload is the same size as the request
* All application data is protected by both authentication (X.509 + ECDSA) and encryption (AES)

=== Packet Analysis: Test 4 - Authentication, no encryption ===

==== Packet 15: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with authentication enabled but encryption disabled. This FLOW_REQ carries an OAP header but '''no ephemeral key''' since the client does not request encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:03.413372 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a8f a6ab 6ea7 ..f.i.._........
0x0050: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0060: 0de6 6100 0000 0000 0000 00 ..a.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... dc40</code> || '''QoS (Various)''' || 28 || Mixed ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e490 0de6 61</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key (no encryption)'''
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* No encryption enabled: ephemeral key absent (Eph_len = 0x0000)
* Client requests authentication only
* Server will respond with certificate + signature but no ephemeral key
* Packet is minimal compared to Packet 11 (Test 3) which includes 91-byte ephemeral key

==== Packet 16: FLOW_REPLY ====

'''Summary:''' Server accepts the authenticated (but not encrypted) flow allocation request. FLOW_REPLY contains the server's X.509 certificate and ECDSA signature for client authentication, but '''no ephemeral key''' since encryption is not being used.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:40:03.416675 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 751:
0x0000: 0000 02dd 0041 0040 0000 0000 0000 0000 .......A.@......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 008f a6ab 6ea7 ................
0x0030: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0040: 3754 a702 2f30 8202 2b30 8201 b2a0 0302 7T../0..+0......
0x0050: 0102 0202 1000 300a 0608 2a86 48ce 3d04 ......0...*.H.=.
(... certificate and signature bytes ...)
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>02dd</code> || '''Length''' || 2 || 733 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (Packet 15 echoed back)
|-
| 0x3b-0x42 || <code>fa18 86a8 e490 3754</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>a702</code> || '''Crt_len''' || 2 || 0x02a7 (679 decimal) || '''Certificate length: 679 bytes'''
|-
| 0x45-0x270 || <code>2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ...</code> || '''Certificate''' || 679 || DER-encoded X.509 || Server's certificate signed by intermediate CA
|-
| 0x271-0x272 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key''' (no encryption)
|-
| 0x273-0x274 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x275-0x276 || <code>0067</code> || '''Sig_len''' || 2 || 0x0067 (103 decimal) || '''ECDSA signature length: 103 bytes'''
|-
| 0x277-0x2dd || <code>3065 0230 75dc 5717 ... 83</code> || '''Signature''' || 103 || ECDSA signature (DER encoded) || Server's ECDSA signature proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0041 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from Packet 15 FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Certificate Field - <code>crt_len = 0x02a7 (679)</code> carrying server's X.509 certificate signed by intermediate CA
* Separate Signature Field - <code>sig_len = 0x0067 (103)</code> with ECDSA signature over entire OAP header
* No Ephemeral Key - <code>eph_len = 0x0000</code> since encryption is '''not''' being used in Test 4
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ (included in signature, binding response to this specific client request)
* Complete OAP Structure - Full OAP header with all standard fields, just without ephemeral key data
* Plaintext Data Exchange - After this FLOW_REPLY, all subsequent application data will be transmitted in plaintext (but authenticated via certificate + signature verification)

==== Packet 17: ECHO_REQUEST ====

'''Summary:''' Client sends plaintext ECHO_REQUEST data through the authenticated (but unencrypted) flow. The oping application's ping request is transmitted directly without encryption, relying on the earlier certificate+signature authentication for security.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.419664 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 8177 0000 .A.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Request (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number / message identifier
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Seconds component from CLOCK_REALTIME
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Nanoseconds component (0-999999999)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0041 → Server Flow - Data is directed to the server's endpoint ID allocated in Packet 16 FLOW_REPLY
* Plaintext Transmission - No encryption layer; oping payload is sent as-is (compare to Packet 13 which had encryption)
* Authenticated Flow - Although plaintext, this data travels on the authenticated flow established in Packet 16 (certificate + signature verified)
* Type = ECHO_REQUEST - 0x00000000 indicates client-to-server ping request
* ID = 0 - Sequence number for matching request/reply pairs
* Test 4 Characteristic - Demonstrates authenticated communication '''without''' encryption; application data is readable but cryptographically bound to the authenticated flow
* Contrast to Test 3 - Packet 13 (Test 3 encrypted ECHO_REQUEST) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

==== Packet 18: ECHO_REPLY ====

'''Summary:''' Server responds with plaintext ECHO_REPLY data, echoing back the client's request. This confirms successful bidirectional communication over the authenticated (but unencrypted) flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.420088 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 8177 0000 .@.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Reply (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (seconds)
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (nanoseconds)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Echoed probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0040 → Client Flow - Server responds to client's endpoint ID from Packet 15 FLOW_REQ
* Type = ECHO_REPLY - 0x00000001 indicates server-to-client response
* ID = 0 - Echoes the request sequence number, matching this response to the request
* Timestamps Echo Request - Both timestamp fields are copied from Packet 17 unchanged (8177 0000 0000 0000 and aa16 1c16 0000 0000)
* Plaintext Reply - No encryption; server's response payload is readable (compare to Packet 14 which had encryption)
* Authenticated Channel - Although plaintext, this reply is part of the authenticated flow; client can verify integrity through earlier certificate+signature
* Test 4 Completion - Demonstrates '''full bidirectional plaintext communication''' over an authenticated (but unencrypted) flow
* Contrast to Test 3 - Packet 14 (Test 3 encrypted ECHO_REPLY) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

Ouroboros Tutorial 06

2026-02-14T14:51:49Z

Dimitri: /* Test 2: No Authentication, With Encryption */

= Ouroboros Tutorial 06 - Authenticated Flows =

This tutorial demonstrates setting up and using authenticated flows in Ouroboros with certificate-based authentication.

The overall flow of authenticated flow allocation is

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

'''Tutorial Directory:''' This tutorial will execute in <code>/tmp/o7s-tut06/</code>. All configuration files, generated certificates, logs, and packet captures will be stored in this directory.

We create a complete PKI (Public Key Infrastructure):

* '''Root CA''' (<code>ca.tut.o7s</code>): Self-signed trust anchor
* '''Intermediate CA''' (<code>sign.tut.o7s</code>): Signed by root with pathlen:0 constraint
* '''Server Certificate''' (<code>sec.oping.tut.o7s</code>): Signed by intermediate CA

This tutorial uses ECDSA P-384 with SHA-384 hashing.

== Setting Up the Tutorial ==

To properly understand and debug the authenticated flows, this tutorial uses a debug build of Ouroboros with OAP protocol debugging enabled.

<syntaxhighlight lang="bash">
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
</syntaxhighlight>

When built with these options, the IRMd will output detailed OAP protocol information.

=== Configuration Files ===

The following three files should be created in the tutorial directory (<code>/tmp/o7s-tut06/</code>) before starting the tutorial:

'''tut06.conf''' - IRMd configuration

<syntaxhighlight lang="ini">
# Ouroboros Tutorial 06 - Authenticated Flows Configuration
# Uses system-installed certificates at /etc/ouroboros/security/

[name."sec.oping.tut.o7s"]
prog=["/usr/bin/oping"]
args=["--listen"]

[eth-dix.eth-dix-lo]
bootstrap="eth-dix-network"
dev="lo"
reg=["sec.oping.tut.o7s"]
</syntaxhighlight>

'''ca.tut.o7s.cnf''' - OpenSSL configuration for PKI generation

<syntaxhighlight lang="text">
# Unified OpenSSL Configuration for Ouroboros Tutorial 06
# Named CA sections: CA_root (signs intermediate), CA_intermediate (signs server)
# Usage: openssl ca -name CA_root -config ca.tut.o7s.cnf ...

[ req ]
default_bits = 384
default_keyfile = private/key.pem
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha384
x509_extensions = v3_ca

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name

countryName_default = BE
stateOrProvinceName_default = OVL
localityName_default = Ghent
organizationName_default = o7s

[ ca ]
default_ca = CA_root

[ CA_root ]
dir = ./pki/root
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.tut.o7s.crt.pem
private_key = $dir/private/ca.tut.o7s.key.pem
default_days = 3650
default_md = sha384
policy = policy_loose

[ CA_intermediate ]
dir = ./pki/sign
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/sign.tut.o7s.crt.pem
private_key = $dir/private/sign.tut.o7s.key.pem
default_days = 365
default_md = sha384
policy = policy_loose

[ policy_loose ]
commonName = supplied

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
</syntaxhighlight>

'''gen-pki.sh''' - PKI generation script

This script will:
1. Create the directory structure
2. Generate the root CA key and certificate
3. Generate the intermediate CA key and CSR
4. Sign the intermediate CA certificate
5. Generate the server certificate key and CSR
6. Sign the server certificate
7. Verify the complete certificate chain

<syntaxhighlight lang="bash">
#!/bin/bash
# Ouroboros Tutorial 06 - PKI Generation Script (Simplified)
# Generates: Root CA, Intermediate CA, and Server Certificate

set -e

if [ ! -f ca.tut.o7s.cnf ]; then
echo "ERROR: ca.tut.o7s.cnf not found"
exit 1
fi

mkdir -p pki/{root,sign,server}/{certs,private,csr}

# Root CA
openssl ecparam -genkey -name secp384r1 -out pki/root/private/ca.tut.o7s.key.pem 2>/dev/null
openssl req -new -x509 -sha384 -days 7300 \
-config ca.tut.o7s.cnf \
-key pki/root/private/ca.tut.o7s.key.pem \
-out pki/root/certs/ca.tut.o7s.crt.pem \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=ca.tut.o7s" 2>/dev/null

# Intermediate CA
openssl ecparam -genkey -name secp384r1 -out pki/sign/private/sign.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/sign/private/sign.tut.o7s.key.pem \
-out pki/sign/csr/sign.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sign.tut.o7s" 2>/dev/null

touch pki/root/index.txt
echo 1000 > pki/root/serial

openssl ca -name CA_root -config ca.tut.o7s.cnf \
-extensions v3_intermediate_ca -days 3650 -md sha384 -batch \
-in pki/sign/csr/sign.tut.o7s.csr \
-out pki/sign/certs/sign.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Server Certificate
openssl ecparam -genkey -name secp384r1 -out pki/server/private/sec.oping.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/server/private/sec.oping.tut.o7s.key.pem \
-out pki/server/csr/sec.oping.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sec.oping.tut.o7s" 2>/dev/null

touch pki/sign/index.txt
echo 1000 > pki/sign/serial

openssl ca -name CA_intermediate -config ca.tut.o7s.cnf \
-extensions server_cert -days 365 -md sha384 -batch \
-in pki/server/csr/sec.oping.tut.o7s.csr \
-out pki/server/certs/sec.oping.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Verify chain
openssl verify -CAfile pki/root/certs/ca.tut.o7s.crt.pem \
-untrusted pki/sign/certs/sign.tut.o7s.crt.pem \
pki/server/certs/sec.oping.tut.o7s.crt.pem > /dev/null 2>&1

echo "PKI generation complete."
</syntaxhighlight>

== Part 1: Running the Tutorial - Single Session with 4 Tests ==

This section demonstrates a single continuous session with one IRMd and tcpdump instance. The configuration file (<code>tut06.conf</code>) includes autostart for oping, so the server is ready immediately when IRMd starts.

First install the '''CA and Intermediate CA only''' to the system security directories. The server certificate will be installed later during Test 3 (authentication test):

<syntaxhighlight lang="bash">
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}

# Run the PKI generation script
cd /tmp/o7s-tut06
sudo chmod +x gen-pki.sh
sudo ./gen-pki.sh

# Install Root CA (trust anchor)
sudo cp pki/root/certs/ca.tut.o7s.crt.pem /etc/ouroboros/security/cacert/

# Install Intermediate CA (for certificate chain validation)
sudo cp pki/sign/certs/sign.tut.o7s.crt.pem /etc/ouroboros/security/untrusted/
</syntaxhighlight>

=== Running the Tutorial (3 Terminals) ===

In this tutorial, we run a single IRMd session with a concurrent tcpdump instance to capture it. We then run four oping client tests while the IRMd/tcpdump sessions are going, modifying the security configuration between tests. After the tests are complete, we can will down the IRMd and tcpdump sessions with Ctrl-C.

'''Terminal 1: Start tcpdump to capture all packets (runs continuously)'''

<syntaxhighlight lang="bash">
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
</syntaxhighlight>

'''Terminal 2: Start IRMd with debug output (runs continuously)'''

<syntaxhighlight lang="bash">
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
</syntaxhighlight>

'''Terminal 3: Run the tests'''

==== Test 1: No Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Verify directories are empty
sudo ls -la /etc/ouroboros/security/client/sec.oping.tut.o7s/*
sudo ls -la /etc/ouroboros/security/server/sec.oping.tut.o7s/*

# Run first ping test
echo "=== Test 1: No Authentication, No Encryption ==="
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 1: Client initiates plaintext flow allocation'''

<syntaxhighlight lang="text">
irmd/oap(DB): [60e824383b3fbd6a] KEX config: algo=none, mode=server-encap, cipher=none.
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:56 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 1: Server accepts and completes handshake'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' All OAP fields are <code><none></code> because no security is configured (except for the request hash in the response). Flow succeeds with plaintext communication.

==== Test 2: No Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run second ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 2: Client initiates flow with encryption enabled'''

<syntaxhighlight lang="text">
irmd/oap(II): Encryption enabled for sec.oping.tut.o7s.
irmd/oap(DB): [80fd6f9509a996b0] KEX config: algo=prime256v1, mode=server-encap, cipher=aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Generated ephemeral prime256v1 keys (91 bytes).
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 2: Server receives and responds with ephemeral key'''

<syntaxhighlight lang="text">
irmd/oap(DB): [80fd6f9509a996b0] No crt provided.
irmd/oap(DB): [80fd6f9509a996b0] Selected client cipher aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Selected client KDF sha256.
irmd/oap(II): [80fd6f9509a996b0] No key exchange.
irmd/oap(DB): [80fd6f9509a996b0] Generated prime256v1 ephemeral keys.
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [32 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' Both client and server generate ephemeral keys (91 bytes each) for encryption. No certificates because authentication is not required. Encryption and authentication are independent.

==== Test 3: With Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Install server certificates and keys
sudo cp /tmp/o7s-tut06/pki/server/certs/sec.oping.tut.o7s.crt.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/crt.pem
sudo cp /tmp/o7s-tut06/pki/server/private/sec.oping.tut.o7s.key.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/key.pem

# enc.conf is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 3: Client initiates flow with encryption and server has certificate'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33500 to sec.oping.tut.o7s.
==33047== irmd(II): Encryption enabled for sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd(DB): Generated ephemeral keys for 33500.
==33047== irmd/oap(PP): OAP_HDR [3f89a905c0e5571b @ 2026-01-01 11:27:25 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Generated ephemeral keys for 33198.
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [3f89a905c0e5571b] -->
==33047== irmd/oap(PP): Certificate: [560 bytes]
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 3: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Loaded peer certificate for sec.oping.tut.o7s.
==33047== irmd(DB): Certificate matches name sec.oping.tut.o7s.
==33047== irmd(DB): Got public key from certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully verified peer certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully authenticated sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Full OAP handshake with certificate (560 bytes) + ephemeral keys (91 bytes) + signature (103 bytes). Client verifies server's certificate against CA store and confirms authentication success.

==== Test 4: With Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33642 to sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf does not exist.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211 @ 2026-01-01 11:27:34 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)'''

<syntaxhighlight lang="text">
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211] -->
==33047== irmd/oap(PP): Certificate: [560 bytes]
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 4: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Loaded peer certificate for sec.oping.tut.o7s.
==33047== irmd(DB): Certificate matches name sec.oping.tut.o7s.
==33047== irmd(DB): Got public key from certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully verified peer certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully authenticated sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Server sends certificate + signature for authentication, but NO ephemeral keys (plaintext data). Data exchanged without encryption even though authenticated. Demonstrates that authentication and encryption are independent mechanisms.

=== Stop the IRMd and tcpdump, clean up the tutorial files ===

Once all tests complete:

<syntaxhighlight lang="bash">
# Stop IRMd in Terminal 2 (Ctrl+C)
# Stop tcpdump in Terminal 1 (Ctrl+C)

# Clean up tutorial security files from system
sudo rm -f /etc/ouroboros/security/cacert/ca.tut.o7s.crt.pem
</syntaxhighlight>

== Part 2: PCAP Trace Analysis ==

After the tutorial, we now explain the trace in the tcpdump pcap file.

=== Protocol Overview ===

This section summarizes the four protocols that work together in the captured packet flow.

==== Ethernet DIX Frame with EID Header ====

Ouroboros extends the DIX frame with a flow identifier (EID - Endpoint Identifier) and length field.

{| class="wikitable"
|-
! Field !! Octets !! Size !! Description
|-
| Destination MAC || 0-5 || 6 bytes || Hardware address of destination
|-
| Source MAC || 6-11 || 6 bytes || Hardware address of source
|-
| EtherType || 12-13 || 2 bytes || Protocol identifier (0xA000 for Ouroboros)
|-
| EID || 14-15 || 2 bytes || Destination Endpoint Identifier
|-
| Length || 16-17 || 2 bytes || Payload length (needed because of runt frame padding)
|-
| Payload || 18+ || Variable || Frame data (up to MTU size)
|}

==== Ethernet Flow Allocator - Management Protocol ====

The Ethernet DIX management protocol handles flow allocation, setup, and teardown. All management frames use destination EID <code>0x0000</code>.

'''Management Frame Types:'''

{| class="wikitable"
|-
! Code !! Type !! Direction !! Service Hash !! Purpose
|-
| <code>0x00</code> || <code>FLOW_REQ</code> || Client → Server || ✓ Included || Request new flow allocation
|-
| <code>0x01</code> || <code>FLOW_REPLY</code> || Server → Client || – Not included || Respond to flow request (success/failure)
|-
| <code>0x02</code> || <code>NAME_QUERY_REQ</code> || Client → Server || ✓ Included || Query if a remote name is reachable
|-
| <code>0x03</code> || <code>NAME_QUERY_REPLY</code> || Server → Client || ✓ Included || Response to name query
|}

'''Note:''' The 32-byte service hash (SHA3-256) is appended after the management protocol header for NAME_QUERY_* and FLOW_REQ messages to identify which service is being queried or allocated. FLOW_REPLY does not include the service hash; the endpoints are already identified by the allocated EIDs (SEID/DEID) and the flow allocation ID in the OAP header (see below).

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| SEID || 0-1 || 2 bytes || Source Endpoint ID
|-
| DEID || 2-3 || 2 bytes || Destination Endpoint ID
|-
| Loss || 4-7 || 4 bytes || Acceptable packet loss (ppm)
|-
| Bandwidth || 8-15 || 8 bytes || Required bandwidth (bps)
|-
| BER || 16-19 || 4 bytes || Bit error rate (ppm)
|-
| Max Gap || 20-23 || 4 bytes || Maximum consecutive lost packets
|-
| Delay || 24-27 || 4 bytes || Maximum latency (ms)
|-
| Timeout || 28-31 || 4 bytes || Flow idle timeout (seconds)
|-
| Response || 32-35 || 4 bytes || Response code (0=success, negative=error)
|-
| In-Order || 36 || 1 byte || In-order delivery requirement (boolean)
|-
| Code || 37 || 1 byte || Message type (FLOW_REQ, FLOW_REPLY, etc.)
|-
| Availability || 38 || 1 byte || Availability status
|-
| Service hash || 39-61 || 32 bytes || SHA3-256 hash (optional, see above)
|}

==== Ouroboros Flow Allocation Protocol (OAP) ====

The Ouroboros Application Protocol (OAP) is the flow allocation and authentication protocol. It carries flow negotiation requests, responses, and authentication credentials. OAP frames are encapsulated as data payload over the management protocol.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| ID || 0-15 || 16 bytes || Unique flow allocation identifier
|-
| Timestamp || 16-23 || 8 bytes || Creation timestamp (UTC, seconds and microseconds)
|-
| Crt Length || 24-25 || 2 bytes || Certificate length (bytes)
|-
| Certificate || 26+ || Variable || X.509 certificate (DER encoded)
|-
| Eph Length || Variable || 2 bytes || Ephemeral public key length (bytes)
|-
| Ephemeral Key || Variable || Variable || ECDHE public key (DER/raw encoded)
|-
| Data Length || Variable || 2 bytes || Application data length (bytes)
|-
| Data || Variable || Variable || Piggybacked application-layer data
|-
| Sig Length || Variable || 2 bytes || Signature length (bytes)
|-
| Signature || Variable || Variable || Digital signature (ECDSA, DER encoded)
|}

==== Oping Application Protocol ====

The Ouroboros Ping (oping) application is a simple echo/reply protocol used to measure round-trip time and validate connectivity between applications. It implements a request/reply pattern similar to ICMP ping.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| Type || 0-3 || 4 bytes || Message type (ECHO_REQUEST=0 or ECHO_REPLY=1)
|-
| ID || 4-7 || 4 bytes || Sequence number / message identifier
|-
| Timestamp (seconds) || 8-15 || 8 bytes || Seconds when message was sent (CLOCK_REALTIME)
|-
| Timestamp (nanoseconds) || 16-23 || 8 bytes || Nanoseconds component of timestamp
|-
| Payload || 24+ || Variable || Application data (configurable size, default 64 bytes)
|}

'''Field Definitions:'''

* '''Type''' (4 bytes): Message type selector
** <code>0x00000000</code> (ECHO_REQUEST): Client-to-server ping request
** <code>0x00000001</code> (ECHO_REPLY): Server-to-client response

* '''ID''' (4 bytes): Sequence number for matching requests with replies. Incremented for each ping sent.

* '''Timestamp (seconds)''' (8 bytes): Network-byte-order 64-bit seconds component from when the ping was sent (CLOCK_REALTIME).

* '''Timestamp (nanoseconds)''' (8 bytes): Network-byte-order 64-bit nanoseconds component (0-999999999) for high-resolution timing.

* '''Payload''' (Variable): Application data echoed back by the server. Size is configurable (default 64 bytes, maximum 1500 bytes).

'''Usage:'''

* Client sends ECHO_REQUEST with current timestamp
* Server receives request and echoes back as ECHO_REPLY with the same ID and timestamps
* Client calculates RTT by comparing reception time with original timestamps
* Out-of-order detection by tracking sequence numbers (ID field)

=== Packet Analysis: Test 1 - No authentication/encryption ===

==== Packet 1: NAME_QUERY_REQ ====

'''Summary:''' Client sends a NAME_QUERY_REQ message to discover if the service <code>sec.oping.tut.o7s</code> is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.165639 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0002 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

==== Packet 2: NAME_QUERY_REPLY ====

'''Summary:''' Server responds to the NAME_QUERY_REQ by sending a NAME_QUERY_REPLY for the service hash.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.166073 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0003 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code> (echoed back)
|}

==== Packet 3: FLOW_REQ ====

'''Summary:''' Client initiates a flow allocation request (FLOW_REQ) with minimal OAP headers since no authentication or encryption is being used.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.167222 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a51 8a56 ff6f ..f.i.._...Q.V.o
0x0050: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e103 [...}....0w.....
0x0060: 3e52 3300 0000 0000 0000 00 >R3........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || -- || '''UNUSED'''
|-
| 0x24-0x27 || <code>0001 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload'''

The OAP payload starts at offset 0x4b (after management protocol + service hash):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e103 3e52 33</code> || '''Timestamp''' || 8 || Network order || Creation timestamp (seconds + microseconds)
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 (first allocated flow ID for this session)
* Service hash is carried in management protocol payload (32 bytes)
* OAP header is minimal: only ID and timestamp, no optional fields
* No certificate, ephemeral key, data, or signature in this initial request
* Client sends minimal OAP headers with no authentication or encryption setup at allocation time

==== Packet 4: FLOW_REPLY ====

'''Summary:''' Server responds to FLOW_REQ by sending FLOW_REPLY with a new DEID (destination endpoint ID 0x0041) to establish the allocated flow for data transfer.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:49.178732 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0041 0040 0000 0000 0000 0000 ...G.A.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0051 8a56 ff6f ...........Q.V.o
0x0030: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e13f [...}....0w....?
0x0040: a347 3800 0000 0000 0000 00 .G8........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server-side flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0|| Response code (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload'''

The OAP payload starts at offset 0x2b (no service hash in FLOW_REPLY):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Echo of client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e13f a347 38</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x47-0x48 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x49-0x4a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0041 is the newly allocated server-side flow endpoint
* DEID 0x0040 reflects the client's flow ID, creating a bidirectional mapping
* No service hash included (FLOW_REPLY only needs the EIDs to identify the flow)
* OAP echoes the client's ID and timestamp, confirming the flow allocation
* Response code 0x00000000 indicates success
* Both client and server now have their respective flow IDs (0x0040 and 0x0041) for data transfer
* Response code 0x00000000 indicates success

==== Packet 5: ECHO_REQUEST - Plaintext Data ====

'''Summary:''' Client sends an oping ECHO_REQUEST packet to the server using the allocated flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.180824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 7377 0000 .A.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Source Endpoint ID (server → client)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REQUEST Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number (first ping)
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Seconds component
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Nanoseconds component
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (default 64 bytes total - 24 byte header = 40 bytes data)
|}

'''Key observations:'''
* EID 0x0041 shows traffic from server-side flow ID
* This is the first ping request (ID = 0x00000000)
* Timestamp captures when the ping was sent (seconds in network order)
* Default oping payload is 64 bytes total; 24 bytes header + 40 bytes data

==== Packet 6: ECHO_REPLY - Plaintext Data ====

'''Summary:''' Server receives the ECHO_REQUEST and immediately sends back an ECHO_REPLY with the same ID and timestamps, echoing the client's message.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.181496 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 7377 0000 .@.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client ← server)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REPLY Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Echo of original seconds
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Echo of original nanoseconds
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (unchanged from request)
|}

'''Key observations:'''
* EID 0x0040 shows traffic from client-side flow ID receiving the reply
* Type field changed from 0x00000000 (REQUEST) to 0x00000001 (REPLY)
* ID, timestamps, and payload data are identical to the request (echoed back)
* Round-trip time can be calculated by comparing current time with echoed timestamp
* Ping succeeded on first attempt with minimal latency (~1 millisecond between timestamps)

=== Packet Analysis: Test 2 - No authentication, with encryption ===

==== Packet 7: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with encryption enabled. This FLOW_REQ carries an OAP header with an ephemeral ECDHE P-384 public key (91 bytes) for encryption setup.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.808158 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8af1 766b 547c ..f.i.._....vkT|
0x0050: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0060: 8b6c 9000 0000 5b30 5930 1306 072a 8648 .l....[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 c508 1c19 6106 b7e9 3074 57b9 bb16 ......a...0tW...
0x0090: 6959 4a55 81f9 169b cc79 fe10 a882 41fe iYJU.....y....A.
0x00a0: 0697 c9b4 f8f0 5562 7fa2 c7a0 a020 1ac6 ......Ub........
0x00b0: 939f 23ff b2fb 07a2 b747 aacc 474a 3dab ..#......G..GJ=.
0x00c0: 2598 0000 0000 %.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Mixed || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 ... 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e253 8b6c 90</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 ... 3dab 2598</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || ECDHE P-384 public key (DER encoded)
|-
| 0xd3-0xd4 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd5-0xd6 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* Encryption enabled: ephemeral key present (91 bytes)
* Client sends no certificate, allowing anonymous encryption setup
* No signature (unsigned OAP)
* Ephemeral key is ECDHE P-384 for key exchange

==== Packet 8: FLOW_REPLY ====

'''Summary:''' Server accepts the encrypted flow allocation request. FLOW_REPLY contains the server's ephemeral key but no certificate (since client didn't send one).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.810564 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 180:
0x0000: 0000 00a2 0042 0040 0000 0000 0000 0000 .....B.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 00f1 766b 547c ............vkT|
0x0030: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0040: b694 e800 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0050: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0060: 0004 5f3c 6929 cca2 024a ae9f 9aa1 dfc2 .._<i)...J......
0x0070: a493 3ff3 ff58 b054 74dc d2e2 47fc 7c5b ..?..X.Tt...G.|[
0x0080: eff5 e129 72b4 de1e 7c09 bf8c fe38 5e8b ...)r...|....8^.
0x0090: b22e 59ed 6eb9 dfda 369d 691e 6e2c 122c ..Y.n...6.i.n,.,
0x00a0: 9936 0000 0000 .6....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00a2</code> || '''Length''' || 2 || 162 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0042</code> || '''SEID''' || 2 || 0x0042 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || Echo of client ID || Echoes client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e253 b694 e8</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x47-0xa1 || <code>30 5930...9936</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || Server's ECDHE P-384 public key (DER encoded)
|-
| 0xd1-0xd2 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd3-0xd4 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0042 is the new server-side flow endpoint
* Both keys are now exchanged; client and server can derive shared secret
* No authentication (no certificates) but encryption is negotiated
* Response indicates successful allocation

==== Packet 9: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after encryption keys are established. The payload is encrypted with the derived shared secret.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.815771 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0042 0060 a691 6d83 8446 cbeb ac95 c2eb .B.`..m..F......
0x0010: 4b42 e819 c67f 92c8 58d7 0641 d8a6 6e1f KB......X..A..n.
0x0020: fc90 feed ef55 b791 4fbd a832 74bd 8bed .....U..O..2t...
0x0030: 249c 4cee 0fc0 cec6 2f1b aec1 2428 bdbd $.L...../...$(..
0x0040: 36b5 01b5 1257 004e 6ed6 7ecd f0c7 7d11 6....W.Nn.~...}.
0x0050: 20ba e81b f43a 4de9 b141 1624 e1ba 0a84 .....:M..A.$....
0x0060: 74b1 9a9a t...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0042</code> || '''EID''' || 2 || 0x0042 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REQUEST (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>a691 6d83 8446 cbeb...74b1 9a9a</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* All 96 bytes of oping data (type, ID, timestamps, payload) are encrypted
* No plaintext oping headers visible; entire packet is ciphertext
* Flow IDs (0x0042) identify which encryption context to use
* Ping still works with encryption transparently

==== Packet 10: Encrypted ECHO_REPLY ====

'''Summary:''' Server receives encrypted ping request, decrypts it, and sends encrypted ECHO_REPLY.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.819574 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 c6ea 2222 5618 0268 b27e 9a91 .@.`..""V..h.~..
0x0010: f124 1f8d bccc 478c 26fe 9b13 b3cb 5398 .$....G.&.....S.
0x0020: 6869 3cdb 4928 510d 4de8 dc6a 3f3a 6a6d hi<.I(Q.M..j?:jm
0x0030: 6487 dcd8 c8cd 1a85 fba2 9ecd 3566 57d1 d...........5fW.
0x0040: 1c94 ac35 518e 8509 873a 3a5e 04d9 8ee2 ...5Q....::^....
0x0050: 9d74 2527 e425 5433 9d73 9ccd f56a 1f8d .t%'.%T3.s...j..
0x0060: f328 7237 .(r7
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REPLY (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>c6ea 2222 5618 0268...f328 7237</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* EID 0x0040 shows reply going back to client-side flow
* Ciphertext is different from request (different plaintext: type field differs)
* Both encrypted packets are 96 bytes (same size as Packet 9)
* Client receives encrypted reply, decrypts it, verifies ID and timestamps match request
* Encryption is transparent at application layer: oping works exactly as with plaintext flows

=== Packet Analysis: Test 3 - Authentication and encryption ===

==== Packet 11: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation request with encryption enabled. Sends ephemeral public key for ECDHE key exchange but no certificate (client is not authenticating in this tutorial). The management protocol now carries a valid allocated SEID (0x0040).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:58.827411 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a66 bb82 95fa ..f.i.._...f....
0x0050: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0060: c0d2 ad00 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 9dea c238 6732 4987 1cd4 7133 9614 .....8g2I...q3..
0x0090: 9d04 4fde 3f68 42f1 54fb 7ef3 88d0 ffe6 ..O.?hB.T.~.....
0x00a0: 7e01 432e 56c2 2d64 72c9 19fc b0cf 1eca ~.C.V.-dr.......
0x00b0: 689e 3536 771a 8041 726c 20e2 d9bb 3589 h.56w..Arl....5.
0x00c0: 86e7 0000 0000 ......
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (client flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ... 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier for Test 3
|-
| 0x5b-0x62 || <code>18 86a8 e37e c0d2 ad</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || Client not authenticating
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Ephemeral public key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 1306 ... 3589</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Client's ephemeral ECDHE public key for encryption negotiation
|-
| 0xc2-0xc3 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xc4-0xc5 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 - Same as Test 2 (Encrypted) because this is the same client session reusing the same allocated ID from the previous test
* No Certificate - <code>crt_len = 0x0000</code> because the client does not have authentication credentials; the server will authenticate instead
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> because encryption is enabled on the client
* No Signature - <code>sig_len = 0x0000</code> because client is not signing (no certificate to sign with)
* FLOW_REQ Message Type - Code field is 0x00, and service hash is present because FLOW_REQ always includes the service hash
* Timestamp Consistency - Same OAP ID and timestamp structure as Test 2, but with additional security handshake

==== Packet 12: FLOW_REPLY ====

'''Summary:''' Server responds to client's FLOW_REQ by sending FLOW_REPLY with its certificate for authentication, ephemeral public key for ECDHE encryption setup, and a digital signature proving ownership of the certificate. This is the full authentication response.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:39:58.828806 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 843:
0x0000: 0000 0339 0043 0040 0000 0000 0000 0000 ...9.C.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0066 bb82 95fa ...........f....
0x0030: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0040: d566 a002 2f30 8202 2b30 8201 b2a0 0302 .f../0..+0......
(... certificate and signature bytes ...)
0x0320: ef11 c358 f5d0 5cd7 3906 adf1 8a2c 9b25 ...X..\.9....,.%
0x0330: dc78 6050 ab61 3a3f 81c0 254b d193 7827 .x`P.a:?..%K..x'
0x0340: c0e9 38c7 e0d1 c517 d299 9992 07 ..8..........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0339</code> || '''Length''' || 2 || 825 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0043</code> || '''SEID''' || 2 || 0x0043 || Source Endpoint ID (server-side allocated flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (echoed back)
|-
| 0x3b-0x42 || <code>18 86a8 e37e d566 a0</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>022f</code> || '''Crt_len''' || 2 || 559 (0x022f) || Server certificate length: 559 bytes
|-
| 0x45-0x243 || <code>2f30 8202 2b ... 81c8 30</code> || '''Certificate''' || 559 || DER-encoded X.509 || Server's certificate (signed by intermediate CA)
|-
| 0x244-0x245 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Server's ephemeral public key length: 91 bytes
|-
| 0x246-0x2a0 || <code>30 5930 1306 ... 9936</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Server's ephemeral ECDHE public key
|-
| 0x2a4-0x2a5 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x2a6-0x2a7 || <code>0068</code> || '''Sig_len''' || 2 || 104 (0x0068) || Digital signature length: 104 bytes
|-
| 0x2a8-0x30f || <code>30 6602 3100 ... 07</code> || '''Signature''' || 104 || ECDSA signature (DER encoded) || Server's signature over OAP header proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0043 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from the FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Full Certificate - <code>crt_len = 0x022f (559)</code> carrying server's complete X.509 certificate signed by intermediate CA
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> with server's ECDHE public key for encryption
* Signature Included - <code>sig_len = 0x0068 (104)</code> containing ECDSA digital signature over the entire OAP header
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ to confirm association (included in signature, binding response to this specific client request)
* Large Payload - Total of 825 bytes due to certificate (559) + ephemeral key (91) + signature (104) + overhead
* Authentication Complete - Client verifies: (1) certificate against CA store, (2) signature over entire response ensures authenticity and integrity, (3) echoed ID binds response to this specific request, (4) timestamp prevents replay attacks

'''Summary:''' Server responds with its certificate for authentication, ephemeral public key for ECDHE encryption, and a digital signature proving ownership of the certificate.

==== Packet 13: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after authentication handshake. All application data is protected by encryption using the ephemeral keys established in Packets 11-12.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836485 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0043 0060 3bed 0b48 1be1 6930 cf3d dee9 .C.`.;..H..i0.=..
0x0010: 4fc9 774b 5d63 cc9b 5a34 6604 f9ac 1016 O.wK]c..Z4f.....
0x0020: 1c6d c9ac f80e dc89 31c1 9634 1a4f b2c7 .m......1..4.O..
0x0030: 4721 e402 8259 b0aa 8870 4566 33d1 9c18 G!...Y.. .pEf3...
0x0040: 06da 50c3 8b75 86b0 f240 d109 840e a6cd ..P..u...@......
0x0050: d115 77cb 5652 5bfb e6d5 0ca9 dbc3 d0b8 ..w.VR[.........
0x0060: 0058 fd19 .X..
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0043</code> || Client flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REQUEST data'''
|}

'''Key observations:'''
* No visible protocol structure - all application data appears as ciphertext
* Uses the same source/destination EID pair (0x0043 → 0x0060) established in the FLOW_REQ/FLOW_REPLY handshake
* Encryption is done using the ephemeral key (91 bytes) exchanged in Packet 11's OAP header
* Unlike Packets 11-12, this packet contains no certificate, public keys, or signatures
* The 110-byte encrypted data corresponds to the original oping ECHO_REQUEST message

==== Packet 14: Encrypted ECHO_REPLY ====

'''Summary:''' Server sends encrypted ping reply. Note that the flow identifiers swap, demonstrating bidirectional encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836930 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 d552 e100 e681 940c e35a 07d0 .@.`..........Z..
0x0010: a293 1d73 33a5 854e 0fce 4f4d 6655 267a ...s3..N..OMfU&z
0x0020: 3de2 663b 709d 739a a696 2ddd 7b34 28b8 =.f;p.s...-{4(...
0x0030: 5a98 eec2 52c6 4288 3885 ae16 e466 4181 Z...R.B.8...fA..
0x0040: f2d6 44c1 b51b 8728 58a4 7525 fb5e 3fd6 ..D...(X.u%.^?..
0x0050: 7e49 532a d2a5 bea7 55e9 c274 f1b2 0412 ~IS*....U..t....
0x0060: 73d4 6436 s.d6
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0040</code> || Client's inbound flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REPLY data'''
|}

'''Key observations:'''
* The EID in offset 0x00 is now 0x0040 (server's view of client's inbound flow)
* Uses the same ephemeral key material as Packet 13, but encryption direction is reversed
* Both packets use AES-GCM with keys derived from the ECDH exchange
* Timestamp 17:39:59.836930 is only 445 microseconds after Packet 13, indicating server-side processing
* The 110-byte encrypted ECHO_REPLY payload is the same size as the request
* All application data is protected by both authentication (X.509 + ECDSA) and encryption (AES)

=== Packet Analysis: Test 4 - Authentication, no encryption ===

==== Packet 15: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with authentication enabled but encryption disabled. This FLOW_REQ carries an OAP header but '''no ephemeral key''' since the client does not request encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:03.413372 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a8f a6ab 6ea7 ..f.i.._........
0x0050: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0060: 0de6 6100 0000 0000 0000 00 ..a.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... dc40</code> || '''QoS (Various)''' || 28 || Mixed ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e490 0de6 61</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key (no encryption)'''
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* No encryption enabled: ephemeral key absent (Eph_len = 0x0000)
* Client requests authentication only
* Server will respond with certificate + signature but no ephemeral key
* Packet is minimal compared to Packet 11 (Test 3) which includes 91-byte ephemeral key

==== Packet 16: FLOW_REPLY ====

'''Summary:''' Server accepts the authenticated (but not encrypted) flow allocation request. FLOW_REPLY contains the server's X.509 certificate and ECDSA signature for client authentication, but '''no ephemeral key''' since encryption is not being used.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:40:03.416675 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 751:
0x0000: 0000 02dd 0041 0040 0000 0000 0000 0000 .......A.@......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 008f a6ab 6ea7 ................
0x0030: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0040: 3754 a702 2f30 8202 2b30 8201 b2a0 0302 7T../0..+0......
0x0050: 0102 0202 1000 300a 0608 2a86 48ce 3d04 ......0...*.H.=.
(... certificate and signature bytes ...)
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>02dd</code> || '''Length''' || 2 || 733 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (Packet 15 echoed back)
|-
| 0x3b-0x42 || <code>fa18 86a8 e490 3754</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>a702</code> || '''Crt_len''' || 2 || 0x02a7 (679 decimal) || '''Certificate length: 679 bytes'''
|-
| 0x45-0x270 || <code>2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ...</code> || '''Certificate''' || 679 || DER-encoded X.509 || Server's certificate signed by intermediate CA
|-
| 0x271-0x272 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key''' (no encryption)
|-
| 0x273-0x274 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x275-0x276 || <code>0067</code> || '''Sig_len''' || 2 || 0x0067 (103 decimal) || '''ECDSA signature length: 103 bytes'''
|-
| 0x277-0x2dd || <code>3065 0230 75dc 5717 ... 83</code> || '''Signature''' || 103 || ECDSA signature (DER encoded) || Server's ECDSA signature proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0041 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from Packet 15 FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Certificate Field - <code>crt_len = 0x02a7 (679)</code> carrying server's X.509 certificate signed by intermediate CA
* Separate Signature Field - <code>sig_len = 0x0067 (103)</code> with ECDSA signature over entire OAP header
* No Ephemeral Key - <code>eph_len = 0x0000</code> since encryption is '''not''' being used in Test 4
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ (included in signature, binding response to this specific client request)
* Complete OAP Structure - Full OAP header with all standard fields, just without ephemeral key data
* Plaintext Data Exchange - After this FLOW_REPLY, all subsequent application data will be transmitted in plaintext (but authenticated via certificate + signature verification)

==== Packet 17: ECHO_REQUEST ====

'''Summary:''' Client sends plaintext ECHO_REQUEST data through the authenticated (but unencrypted) flow. The oping application's ping request is transmitted directly without encryption, relying on the earlier certificate+signature authentication for security.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.419664 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 8177 0000 .A.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Request (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number / message identifier
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Seconds component from CLOCK_REALTIME
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Nanoseconds component (0-999999999)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0041 → Server Flow - Data is directed to the server's endpoint ID allocated in Packet 16 FLOW_REPLY
* Plaintext Transmission - No encryption layer; oping payload is sent as-is (compare to Packet 13 which had encryption)
* Authenticated Flow - Although plaintext, this data travels on the authenticated flow established in Packet 16 (certificate + signature verified)
* Type = ECHO_REQUEST - 0x00000000 indicates client-to-server ping request
* ID = 0 - Sequence number for matching request/reply pairs
* Test 4 Characteristic - Demonstrates authenticated communication '''without''' encryption; application data is readable but cryptographically bound to the authenticated flow
* Contrast to Test 3 - Packet 13 (Test 3 encrypted ECHO_REQUEST) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

==== Packet 18: ECHO_REPLY ====

'''Summary:''' Server responds with plaintext ECHO_REPLY data, echoing back the client's request. This confirms successful bidirectional communication over the authenticated (but unencrypted) flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.420088 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 8177 0000 .@.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Reply (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (seconds)
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (nanoseconds)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Echoed probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0040 → Client Flow - Server responds to client's endpoint ID from Packet 15 FLOW_REQ
* Type = ECHO_REPLY - 0x00000001 indicates server-to-client response
* ID = 0 - Echoes the request sequence number, matching this response to the request
* Timestamps Echo Request - Both timestamp fields are copied from Packet 17 unchanged (8177 0000 0000 0000 and aa16 1c16 0000 0000)
* Plaintext Reply - No encryption; server's response payload is readable (compare to Packet 14 which had encryption)
* Authenticated Channel - Although plaintext, this reply is part of the authenticated flow; client can verify integrity through earlier certificate+signature
* Test 4 Completion - Demonstrates '''full bidirectional plaintext communication''' over an authenticated (but unencrypted) flow
* Contrast to Test 3 - Packet 14 (Test 3 encrypted ECHO_REPLY) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

Ouroboros Tutorial 06

2026-02-14T14:49:28Z

Dimitri: /* Test 2: No Authentication, With Encryption */

= Ouroboros Tutorial 06 - Authenticated Flows =

This tutorial demonstrates setting up and using authenticated flows in Ouroboros with certificate-based authentication.

The overall flow of authenticated flow allocation is

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

'''Tutorial Directory:''' This tutorial will execute in <code>/tmp/o7s-tut06/</code>. All configuration files, generated certificates, logs, and packet captures will be stored in this directory.

We create a complete PKI (Public Key Infrastructure):

* '''Root CA''' (<code>ca.tut.o7s</code>): Self-signed trust anchor
* '''Intermediate CA''' (<code>sign.tut.o7s</code>): Signed by root with pathlen:0 constraint
* '''Server Certificate''' (<code>sec.oping.tut.o7s</code>): Signed by intermediate CA

This tutorial uses ECDSA P-384 with SHA-384 hashing.

== Setting Up the Tutorial ==

To properly understand and debug the authenticated flows, this tutorial uses a debug build of Ouroboros with OAP protocol debugging enabled.

<syntaxhighlight lang="bash">
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
</syntaxhighlight>

When built with these options, the IRMd will output detailed OAP protocol information.

=== Configuration Files ===

The following three files should be created in the tutorial directory (<code>/tmp/o7s-tut06/</code>) before starting the tutorial:

'''tut06.conf''' - IRMd configuration

<syntaxhighlight lang="ini">
# Ouroboros Tutorial 06 - Authenticated Flows Configuration
# Uses system-installed certificates at /etc/ouroboros/security/

[name."sec.oping.tut.o7s"]
prog=["/usr/bin/oping"]
args=["--listen"]

[eth-dix.eth-dix-lo]
bootstrap="eth-dix-network"
dev="lo"
reg=["sec.oping.tut.o7s"]
</syntaxhighlight>

'''ca.tut.o7s.cnf''' - OpenSSL configuration for PKI generation

<syntaxhighlight lang="text">
# Unified OpenSSL Configuration for Ouroboros Tutorial 06
# Named CA sections: CA_root (signs intermediate), CA_intermediate (signs server)
# Usage: openssl ca -name CA_root -config ca.tut.o7s.cnf ...

[ req ]
default_bits = 384
default_keyfile = private/key.pem
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha384
x509_extensions = v3_ca

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name

countryName_default = BE
stateOrProvinceName_default = OVL
localityName_default = Ghent
organizationName_default = o7s

[ ca ]
default_ca = CA_root

[ CA_root ]
dir = ./pki/root
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.tut.o7s.crt.pem
private_key = $dir/private/ca.tut.o7s.key.pem
default_days = 3650
default_md = sha384
policy = policy_loose

[ CA_intermediate ]
dir = ./pki/sign
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/sign.tut.o7s.crt.pem
private_key = $dir/private/sign.tut.o7s.key.pem
default_days = 365
default_md = sha384
policy = policy_loose

[ policy_loose ]
commonName = supplied

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
</syntaxhighlight>

'''gen-pki.sh''' - PKI generation script

This script will:
1. Create the directory structure
2. Generate the root CA key and certificate
3. Generate the intermediate CA key and CSR
4. Sign the intermediate CA certificate
5. Generate the server certificate key and CSR
6. Sign the server certificate
7. Verify the complete certificate chain

<syntaxhighlight lang="bash">
#!/bin/bash
# Ouroboros Tutorial 06 - PKI Generation Script (Simplified)
# Generates: Root CA, Intermediate CA, and Server Certificate

set -e

if [ ! -f ca.tut.o7s.cnf ]; then
echo "ERROR: ca.tut.o7s.cnf not found"
exit 1
fi

mkdir -p pki/{root,sign,server}/{certs,private,csr}

# Root CA
openssl ecparam -genkey -name secp384r1 -out pki/root/private/ca.tut.o7s.key.pem 2>/dev/null
openssl req -new -x509 -sha384 -days 7300 \
-config ca.tut.o7s.cnf \
-key pki/root/private/ca.tut.o7s.key.pem \
-out pki/root/certs/ca.tut.o7s.crt.pem \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=ca.tut.o7s" 2>/dev/null

# Intermediate CA
openssl ecparam -genkey -name secp384r1 -out pki/sign/private/sign.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/sign/private/sign.tut.o7s.key.pem \
-out pki/sign/csr/sign.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sign.tut.o7s" 2>/dev/null

touch pki/root/index.txt
echo 1000 > pki/root/serial

openssl ca -name CA_root -config ca.tut.o7s.cnf \
-extensions v3_intermediate_ca -days 3650 -md sha384 -batch \
-in pki/sign/csr/sign.tut.o7s.csr \
-out pki/sign/certs/sign.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Server Certificate
openssl ecparam -genkey -name secp384r1 -out pki/server/private/sec.oping.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/server/private/sec.oping.tut.o7s.key.pem \
-out pki/server/csr/sec.oping.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sec.oping.tut.o7s" 2>/dev/null

touch pki/sign/index.txt
echo 1000 > pki/sign/serial

openssl ca -name CA_intermediate -config ca.tut.o7s.cnf \
-extensions server_cert -days 365 -md sha384 -batch \
-in pki/server/csr/sec.oping.tut.o7s.csr \
-out pki/server/certs/sec.oping.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Verify chain
openssl verify -CAfile pki/root/certs/ca.tut.o7s.crt.pem \
-untrusted pki/sign/certs/sign.tut.o7s.crt.pem \
pki/server/certs/sec.oping.tut.o7s.crt.pem > /dev/null 2>&1

echo "PKI generation complete."
</syntaxhighlight>

== Part 1: Running the Tutorial - Single Session with 4 Tests ==

This section demonstrates a single continuous session with one IRMd and tcpdump instance. The configuration file (<code>tut06.conf</code>) includes autostart for oping, so the server is ready immediately when IRMd starts.

First install the '''CA and Intermediate CA only''' to the system security directories. The server certificate will be installed later during Test 3 (authentication test):

<syntaxhighlight lang="bash">
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}

# Run the PKI generation script
cd /tmp/o7s-tut06
sudo chmod +x gen-pki.sh
sudo ./gen-pki.sh

# Install Root CA (trust anchor)
sudo cp pki/root/certs/ca.tut.o7s.crt.pem /etc/ouroboros/security/cacert/

# Install Intermediate CA (for certificate chain validation)
sudo cp pki/sign/certs/sign.tut.o7s.crt.pem /etc/ouroboros/security/untrusted/
</syntaxhighlight>

=== Running the Tutorial (3 Terminals) ===

In this tutorial, we run a single IRMd session with a concurrent tcpdump instance to capture it. We then run four oping client tests while the IRMd/tcpdump sessions are going, modifying the security configuration between tests. After the tests are complete, we can will down the IRMd and tcpdump sessions with Ctrl-C.

'''Terminal 1: Start tcpdump to capture all packets (runs continuously)'''

<syntaxhighlight lang="bash">
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
</syntaxhighlight>

'''Terminal 2: Start IRMd with debug output (runs continuously)'''

<syntaxhighlight lang="bash">
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
</syntaxhighlight>

'''Terminal 3: Run the tests'''

==== Test 1: No Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Verify directories are empty
sudo ls -la /etc/ouroboros/security/client/sec.oping.tut.o7s/*
sudo ls -la /etc/ouroboros/security/server/sec.oping.tut.o7s/*

# Run first ping test
echo "=== Test 1: No Authentication, No Encryption ==="
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 1: Client initiates plaintext flow allocation'''

<syntaxhighlight lang="text">
irmd/oap(DB): [60e824383b3fbd6a] KEX config: algo=none, mode=server-encap, cipher=none.
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:56 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 1: Server accepts and completes handshake'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' All OAP fields are <code><none></code> because no security is configured (except for the request hash in the response). Flow succeeds with plaintext communication.

==== Test 2: No Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run second ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 2: Client initiates flow with encryption enabled'''

<syntaxhighlight lang="text">
irmd/oap(II): Encryption enabled for sec.oping.tut.o7s.
irmd/oap(DB): [80fd6f9509a996b0] KEX config: algo=prime256v1, mode=server-encap, cipher=aes-256-gcm.
irmd/oap(DB): [80fd6f9509a996b0] Generated ephemeral prime256v1 keys (91 bytes).
irmd/oap(PP): OAP_HDR [80fd6f9509a996b0 @ 2026-02-14 14:09:38 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Key Exchange Data: [91 bytes] [Server encaps]
irmd/oap(PP): Cipher: aes-256-gcm
irmd/oap(PP): KDF: HKDF-sha256
irmd/oap(PP): Digest: sha256
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 2: Server receives and responds with ephemeral key'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Generated ephemeral keys for 33198.
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [3fa5ac1a91a23936] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
==33047== irmd(II): No certificate provided by sec.oping.tut.o7s.
==33047== reg/name(DB): Process 33198 accepting flows for sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Both client and server generate ephemeral keys (91 bytes each) for encryption. No certificates because authentication is not required. Encryption and authentication are independent.

==== Test 3: With Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Install server certificates and keys
sudo cp /tmp/o7s-tut06/pki/server/certs/sec.oping.tut.o7s.crt.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/crt.pem
sudo cp /tmp/o7s-tut06/pki/server/private/sec.oping.tut.o7s.key.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/key.pem

# enc.conf is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 3: Client initiates flow with encryption and server has certificate'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33500 to sec.oping.tut.o7s.
==33047== irmd(II): Encryption enabled for sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd(DB): Generated ephemeral keys for 33500.
==33047== irmd/oap(PP): OAP_HDR [3f89a905c0e5571b @ 2026-01-01 11:27:25 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Generated ephemeral keys for 33198.
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [3f89a905c0e5571b] -->
==33047== irmd/oap(PP): Certificate: [560 bytes]
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 3: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Loaded peer certificate for sec.oping.tut.o7s.
==33047== irmd(DB): Certificate matches name sec.oping.tut.o7s.
==33047== irmd(DB): Got public key from certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully verified peer certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully authenticated sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Full OAP handshake with certificate (560 bytes) + ephemeral keys (91 bytes) + signature (103 bytes). Client verifies server's certificate against CA store and confirms authentication success.

==== Test 4: With Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33642 to sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf does not exist.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211 @ 2026-01-01 11:27:34 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)'''

<syntaxhighlight lang="text">
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211] -->
==33047== irmd/oap(PP): Certificate: [560 bytes]
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 4: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Loaded peer certificate for sec.oping.tut.o7s.
==33047== irmd(DB): Certificate matches name sec.oping.tut.o7s.
==33047== irmd(DB): Got public key from certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully verified peer certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully authenticated sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Server sends certificate + signature for authentication, but NO ephemeral keys (plaintext data). Data exchanged without encryption even though authenticated. Demonstrates that authentication and encryption are independent mechanisms.

=== Stop the IRMd and tcpdump, clean up the tutorial files ===

Once all tests complete:

<syntaxhighlight lang="bash">
# Stop IRMd in Terminal 2 (Ctrl+C)
# Stop tcpdump in Terminal 1 (Ctrl+C)

# Clean up tutorial security files from system
sudo rm -f /etc/ouroboros/security/cacert/ca.tut.o7s.crt.pem
</syntaxhighlight>

== Part 2: PCAP Trace Analysis ==

After the tutorial, we now explain the trace in the tcpdump pcap file.

=== Protocol Overview ===

This section summarizes the four protocols that work together in the captured packet flow.

==== Ethernet DIX Frame with EID Header ====

Ouroboros extends the DIX frame with a flow identifier (EID - Endpoint Identifier) and length field.

{| class="wikitable"
|-
! Field !! Octets !! Size !! Description
|-
| Destination MAC || 0-5 || 6 bytes || Hardware address of destination
|-
| Source MAC || 6-11 || 6 bytes || Hardware address of source
|-
| EtherType || 12-13 || 2 bytes || Protocol identifier (0xA000 for Ouroboros)
|-
| EID || 14-15 || 2 bytes || Destination Endpoint Identifier
|-
| Length || 16-17 || 2 bytes || Payload length (needed because of runt frame padding)
|-
| Payload || 18+ || Variable || Frame data (up to MTU size)
|}

==== Ethernet Flow Allocator - Management Protocol ====

The Ethernet DIX management protocol handles flow allocation, setup, and teardown. All management frames use destination EID <code>0x0000</code>.

'''Management Frame Types:'''

{| class="wikitable"
|-
! Code !! Type !! Direction !! Service Hash !! Purpose
|-
| <code>0x00</code> || <code>FLOW_REQ</code> || Client → Server || ✓ Included || Request new flow allocation
|-
| <code>0x01</code> || <code>FLOW_REPLY</code> || Server → Client || – Not included || Respond to flow request (success/failure)
|-
| <code>0x02</code> || <code>NAME_QUERY_REQ</code> || Client → Server || ✓ Included || Query if a remote name is reachable
|-
| <code>0x03</code> || <code>NAME_QUERY_REPLY</code> || Server → Client || ✓ Included || Response to name query
|}

'''Note:''' The 32-byte service hash (SHA3-256) is appended after the management protocol header for NAME_QUERY_* and FLOW_REQ messages to identify which service is being queried or allocated. FLOW_REPLY does not include the service hash; the endpoints are already identified by the allocated EIDs (SEID/DEID) and the flow allocation ID in the OAP header (see below).

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| SEID || 0-1 || 2 bytes || Source Endpoint ID
|-
| DEID || 2-3 || 2 bytes || Destination Endpoint ID
|-
| Loss || 4-7 || 4 bytes || Acceptable packet loss (ppm)
|-
| Bandwidth || 8-15 || 8 bytes || Required bandwidth (bps)
|-
| BER || 16-19 || 4 bytes || Bit error rate (ppm)
|-
| Max Gap || 20-23 || 4 bytes || Maximum consecutive lost packets
|-
| Delay || 24-27 || 4 bytes || Maximum latency (ms)
|-
| Timeout || 28-31 || 4 bytes || Flow idle timeout (seconds)
|-
| Response || 32-35 || 4 bytes || Response code (0=success, negative=error)
|-
| In-Order || 36 || 1 byte || In-order delivery requirement (boolean)
|-
| Code || 37 || 1 byte || Message type (FLOW_REQ, FLOW_REPLY, etc.)
|-
| Availability || 38 || 1 byte || Availability status
|-
| Service hash || 39-61 || 32 bytes || SHA3-256 hash (optional, see above)
|}

==== Ouroboros Flow Allocation Protocol (OAP) ====

The Ouroboros Application Protocol (OAP) is the flow allocation and authentication protocol. It carries flow negotiation requests, responses, and authentication credentials. OAP frames are encapsulated as data payload over the management protocol.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| ID || 0-15 || 16 bytes || Unique flow allocation identifier
|-
| Timestamp || 16-23 || 8 bytes || Creation timestamp (UTC, seconds and microseconds)
|-
| Crt Length || 24-25 || 2 bytes || Certificate length (bytes)
|-
| Certificate || 26+ || Variable || X.509 certificate (DER encoded)
|-
| Eph Length || Variable || 2 bytes || Ephemeral public key length (bytes)
|-
| Ephemeral Key || Variable || Variable || ECDHE public key (DER/raw encoded)
|-
| Data Length || Variable || 2 bytes || Application data length (bytes)
|-
| Data || Variable || Variable || Piggybacked application-layer data
|-
| Sig Length || Variable || 2 bytes || Signature length (bytes)
|-
| Signature || Variable || Variable || Digital signature (ECDSA, DER encoded)
|}

==== Oping Application Protocol ====

The Ouroboros Ping (oping) application is a simple echo/reply protocol used to measure round-trip time and validate connectivity between applications. It implements a request/reply pattern similar to ICMP ping.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| Type || 0-3 || 4 bytes || Message type (ECHO_REQUEST=0 or ECHO_REPLY=1)
|-
| ID || 4-7 || 4 bytes || Sequence number / message identifier
|-
| Timestamp (seconds) || 8-15 || 8 bytes || Seconds when message was sent (CLOCK_REALTIME)
|-
| Timestamp (nanoseconds) || 16-23 || 8 bytes || Nanoseconds component of timestamp
|-
| Payload || 24+ || Variable || Application data (configurable size, default 64 bytes)
|}

'''Field Definitions:'''

* '''Type''' (4 bytes): Message type selector
** <code>0x00000000</code> (ECHO_REQUEST): Client-to-server ping request
** <code>0x00000001</code> (ECHO_REPLY): Server-to-client response

* '''ID''' (4 bytes): Sequence number for matching requests with replies. Incremented for each ping sent.

* '''Timestamp (seconds)''' (8 bytes): Network-byte-order 64-bit seconds component from when the ping was sent (CLOCK_REALTIME).

* '''Timestamp (nanoseconds)''' (8 bytes): Network-byte-order 64-bit nanoseconds component (0-999999999) for high-resolution timing.

* '''Payload''' (Variable): Application data echoed back by the server. Size is configurable (default 64 bytes, maximum 1500 bytes).

'''Usage:'''

* Client sends ECHO_REQUEST with current timestamp
* Server receives request and echoes back as ECHO_REPLY with the same ID and timestamps
* Client calculates RTT by comparing reception time with original timestamps
* Out-of-order detection by tracking sequence numbers (ID field)

=== Packet Analysis: Test 1 - No authentication/encryption ===

==== Packet 1: NAME_QUERY_REQ ====

'''Summary:''' Client sends a NAME_QUERY_REQ message to discover if the service <code>sec.oping.tut.o7s</code> is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.165639 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0002 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

==== Packet 2: NAME_QUERY_REPLY ====

'''Summary:''' Server responds to the NAME_QUERY_REQ by sending a NAME_QUERY_REPLY for the service hash.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.166073 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0003 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code> (echoed back)
|}

==== Packet 3: FLOW_REQ ====

'''Summary:''' Client initiates a flow allocation request (FLOW_REQ) with minimal OAP headers since no authentication or encryption is being used.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.167222 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a51 8a56 ff6f ..f.i.._...Q.V.o
0x0050: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e103 [...}....0w.....
0x0060: 3e52 3300 0000 0000 0000 00 >R3........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || -- || '''UNUSED'''
|-
| 0x24-0x27 || <code>0001 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload'''

The OAP payload starts at offset 0x4b (after management protocol + service hash):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e103 3e52 33</code> || '''Timestamp''' || 8 || Network order || Creation timestamp (seconds + microseconds)
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 (first allocated flow ID for this session)
* Service hash is carried in management protocol payload (32 bytes)
* OAP header is minimal: only ID and timestamp, no optional fields
* No certificate, ephemeral key, data, or signature in this initial request
* Client sends minimal OAP headers with no authentication or encryption setup at allocation time

==== Packet 4: FLOW_REPLY ====

'''Summary:''' Server responds to FLOW_REQ by sending FLOW_REPLY with a new DEID (destination endpoint ID 0x0041) to establish the allocated flow for data transfer.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:49.178732 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0041 0040 0000 0000 0000 0000 ...G.A.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0051 8a56 ff6f ...........Q.V.o
0x0030: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e13f [...}....0w....?
0x0040: a347 3800 0000 0000 0000 00 .G8........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server-side flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0|| Response code (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload'''

The OAP payload starts at offset 0x2b (no service hash in FLOW_REPLY):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Echo of client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e13f a347 38</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x47-0x48 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x49-0x4a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0041 is the newly allocated server-side flow endpoint
* DEID 0x0040 reflects the client's flow ID, creating a bidirectional mapping
* No service hash included (FLOW_REPLY only needs the EIDs to identify the flow)
* OAP echoes the client's ID and timestamp, confirming the flow allocation
* Response code 0x00000000 indicates success
* Both client and server now have their respective flow IDs (0x0040 and 0x0041) for data transfer
* Response code 0x00000000 indicates success

==== Packet 5: ECHO_REQUEST - Plaintext Data ====

'''Summary:''' Client sends an oping ECHO_REQUEST packet to the server using the allocated flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.180824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 7377 0000 .A.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Source Endpoint ID (server → client)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REQUEST Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number (first ping)
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Seconds component
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Nanoseconds component
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (default 64 bytes total - 24 byte header = 40 bytes data)
|}

'''Key observations:'''
* EID 0x0041 shows traffic from server-side flow ID
* This is the first ping request (ID = 0x00000000)
* Timestamp captures when the ping was sent (seconds in network order)
* Default oping payload is 64 bytes total; 24 bytes header + 40 bytes data

==== Packet 6: ECHO_REPLY - Plaintext Data ====

'''Summary:''' Server receives the ECHO_REQUEST and immediately sends back an ECHO_REPLY with the same ID and timestamps, echoing the client's message.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.181496 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 7377 0000 .@.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client ← server)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REPLY Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Echo of original seconds
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Echo of original nanoseconds
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (unchanged from request)
|}

'''Key observations:'''
* EID 0x0040 shows traffic from client-side flow ID receiving the reply
* Type field changed from 0x00000000 (REQUEST) to 0x00000001 (REPLY)
* ID, timestamps, and payload data are identical to the request (echoed back)
* Round-trip time can be calculated by comparing current time with echoed timestamp
* Ping succeeded on first attempt with minimal latency (~1 millisecond between timestamps)

=== Packet Analysis: Test 2 - No authentication, with encryption ===

==== Packet 7: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with encryption enabled. This FLOW_REQ carries an OAP header with an ephemeral ECDHE P-384 public key (91 bytes) for encryption setup.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.808158 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8af1 766b 547c ..f.i.._....vkT|
0x0050: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0060: 8b6c 9000 0000 5b30 5930 1306 072a 8648 .l....[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 c508 1c19 6106 b7e9 3074 57b9 bb16 ......a...0tW...
0x0090: 6959 4a55 81f9 169b cc79 fe10 a882 41fe iYJU.....y....A.
0x00a0: 0697 c9b4 f8f0 5562 7fa2 c7a0 a020 1ac6 ......Ub........
0x00b0: 939f 23ff b2fb 07a2 b747 aacc 474a 3dab ..#......G..GJ=.
0x00c0: 2598 0000 0000 %.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Mixed || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 ... 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e253 8b6c 90</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 ... 3dab 2598</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || ECDHE P-384 public key (DER encoded)
|-
| 0xd3-0xd4 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd5-0xd6 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* Encryption enabled: ephemeral key present (91 bytes)
* Client sends no certificate, allowing anonymous encryption setup
* No signature (unsigned OAP)
* Ephemeral key is ECDHE P-384 for key exchange

==== Packet 8: FLOW_REPLY ====

'''Summary:''' Server accepts the encrypted flow allocation request. FLOW_REPLY contains the server's ephemeral key but no certificate (since client didn't send one).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.810564 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 180:
0x0000: 0000 00a2 0042 0040 0000 0000 0000 0000 .....B.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 00f1 766b 547c ............vkT|
0x0030: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0040: b694 e800 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0050: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0060: 0004 5f3c 6929 cca2 024a ae9f 9aa1 dfc2 .._<i)...J......
0x0070: a493 3ff3 ff58 b054 74dc d2e2 47fc 7c5b ..?..X.Tt...G.|[
0x0080: eff5 e129 72b4 de1e 7c09 bf8c fe38 5e8b ...)r...|....8^.
0x0090: b22e 59ed 6eb9 dfda 369d 691e 6e2c 122c ..Y.n...6.i.n,.,
0x00a0: 9936 0000 0000 .6....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00a2</code> || '''Length''' || 2 || 162 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0042</code> || '''SEID''' || 2 || 0x0042 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || Echo of client ID || Echoes client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e253 b694 e8</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x47-0xa1 || <code>30 5930...9936</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || Server's ECDHE P-384 public key (DER encoded)
|-
| 0xd1-0xd2 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd3-0xd4 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0042 is the new server-side flow endpoint
* Both keys are now exchanged; client and server can derive shared secret
* No authentication (no certificates) but encryption is negotiated
* Response indicates successful allocation

==== Packet 9: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after encryption keys are established. The payload is encrypted with the derived shared secret.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.815771 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0042 0060 a691 6d83 8446 cbeb ac95 c2eb .B.`..m..F......
0x0010: 4b42 e819 c67f 92c8 58d7 0641 d8a6 6e1f KB......X..A..n.
0x0020: fc90 feed ef55 b791 4fbd a832 74bd 8bed .....U..O..2t...
0x0030: 249c 4cee 0fc0 cec6 2f1b aec1 2428 bdbd $.L...../...$(..
0x0040: 36b5 01b5 1257 004e 6ed6 7ecd f0c7 7d11 6....W.Nn.~...}.
0x0050: 20ba e81b f43a 4de9 b141 1624 e1ba 0a84 .....:M..A.$....
0x0060: 74b1 9a9a t...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0042</code> || '''EID''' || 2 || 0x0042 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REQUEST (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>a691 6d83 8446 cbeb...74b1 9a9a</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* All 96 bytes of oping data (type, ID, timestamps, payload) are encrypted
* No plaintext oping headers visible; entire packet is ciphertext
* Flow IDs (0x0042) identify which encryption context to use
* Ping still works with encryption transparently

==== Packet 10: Encrypted ECHO_REPLY ====

'''Summary:''' Server receives encrypted ping request, decrypts it, and sends encrypted ECHO_REPLY.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.819574 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 c6ea 2222 5618 0268 b27e 9a91 .@.`..""V..h.~..
0x0010: f124 1f8d bccc 478c 26fe 9b13 b3cb 5398 .$....G.&.....S.
0x0020: 6869 3cdb 4928 510d 4de8 dc6a 3f3a 6a6d hi<.I(Q.M..j?:jm
0x0030: 6487 dcd8 c8cd 1a85 fba2 9ecd 3566 57d1 d...........5fW.
0x0040: 1c94 ac35 518e 8509 873a 3a5e 04d9 8ee2 ...5Q....::^....
0x0050: 9d74 2527 e425 5433 9d73 9ccd f56a 1f8d .t%'.%T3.s...j..
0x0060: f328 7237 .(r7
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REPLY (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>c6ea 2222 5618 0268...f328 7237</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* EID 0x0040 shows reply going back to client-side flow
* Ciphertext is different from request (different plaintext: type field differs)
* Both encrypted packets are 96 bytes (same size as Packet 9)
* Client receives encrypted reply, decrypts it, verifies ID and timestamps match request
* Encryption is transparent at application layer: oping works exactly as with plaintext flows

=== Packet Analysis: Test 3 - Authentication and encryption ===

==== Packet 11: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation request with encryption enabled. Sends ephemeral public key for ECDHE key exchange but no certificate (client is not authenticating in this tutorial). The management protocol now carries a valid allocated SEID (0x0040).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:58.827411 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a66 bb82 95fa ..f.i.._...f....
0x0050: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0060: c0d2 ad00 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 9dea c238 6732 4987 1cd4 7133 9614 .....8g2I...q3..
0x0090: 9d04 4fde 3f68 42f1 54fb 7ef3 88d0 ffe6 ..O.?hB.T.~.....
0x00a0: 7e01 432e 56c2 2d64 72c9 19fc b0cf 1eca ~.C.V.-dr.......
0x00b0: 689e 3536 771a 8041 726c 20e2 d9bb 3589 h.56w..Arl....5.
0x00c0: 86e7 0000 0000 ......
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (client flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ... 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier for Test 3
|-
| 0x5b-0x62 || <code>18 86a8 e37e c0d2 ad</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || Client not authenticating
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Ephemeral public key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 1306 ... 3589</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Client's ephemeral ECDHE public key for encryption negotiation
|-
| 0xc2-0xc3 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xc4-0xc5 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 - Same as Test 2 (Encrypted) because this is the same client session reusing the same allocated ID from the previous test
* No Certificate - <code>crt_len = 0x0000</code> because the client does not have authentication credentials; the server will authenticate instead
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> because encryption is enabled on the client
* No Signature - <code>sig_len = 0x0000</code> because client is not signing (no certificate to sign with)
* FLOW_REQ Message Type - Code field is 0x00, and service hash is present because FLOW_REQ always includes the service hash
* Timestamp Consistency - Same OAP ID and timestamp structure as Test 2, but with additional security handshake

==== Packet 12: FLOW_REPLY ====

'''Summary:''' Server responds to client's FLOW_REQ by sending FLOW_REPLY with its certificate for authentication, ephemeral public key for ECDHE encryption setup, and a digital signature proving ownership of the certificate. This is the full authentication response.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:39:58.828806 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 843:
0x0000: 0000 0339 0043 0040 0000 0000 0000 0000 ...9.C.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0066 bb82 95fa ...........f....
0x0030: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0040: d566 a002 2f30 8202 2b30 8201 b2a0 0302 .f../0..+0......
(... certificate and signature bytes ...)
0x0320: ef11 c358 f5d0 5cd7 3906 adf1 8a2c 9b25 ...X..\.9....,.%
0x0330: dc78 6050 ab61 3a3f 81c0 254b d193 7827 .x`P.a:?..%K..x'
0x0340: c0e9 38c7 e0d1 c517 d299 9992 07 ..8..........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0339</code> || '''Length''' || 2 || 825 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0043</code> || '''SEID''' || 2 || 0x0043 || Source Endpoint ID (server-side allocated flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (echoed back)
|-
| 0x3b-0x42 || <code>18 86a8 e37e d566 a0</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>022f</code> || '''Crt_len''' || 2 || 559 (0x022f) || Server certificate length: 559 bytes
|-
| 0x45-0x243 || <code>2f30 8202 2b ... 81c8 30</code> || '''Certificate''' || 559 || DER-encoded X.509 || Server's certificate (signed by intermediate CA)
|-
| 0x244-0x245 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Server's ephemeral public key length: 91 bytes
|-
| 0x246-0x2a0 || <code>30 5930 1306 ... 9936</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Server's ephemeral ECDHE public key
|-
| 0x2a4-0x2a5 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x2a6-0x2a7 || <code>0068</code> || '''Sig_len''' || 2 || 104 (0x0068) || Digital signature length: 104 bytes
|-
| 0x2a8-0x30f || <code>30 6602 3100 ... 07</code> || '''Signature''' || 104 || ECDSA signature (DER encoded) || Server's signature over OAP header proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0043 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from the FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Full Certificate - <code>crt_len = 0x022f (559)</code> carrying server's complete X.509 certificate signed by intermediate CA
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> with server's ECDHE public key for encryption
* Signature Included - <code>sig_len = 0x0068 (104)</code> containing ECDSA digital signature over the entire OAP header
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ to confirm association (included in signature, binding response to this specific client request)
* Large Payload - Total of 825 bytes due to certificate (559) + ephemeral key (91) + signature (104) + overhead
* Authentication Complete - Client verifies: (1) certificate against CA store, (2) signature over entire response ensures authenticity and integrity, (3) echoed ID binds response to this specific request, (4) timestamp prevents replay attacks

'''Summary:''' Server responds with its certificate for authentication, ephemeral public key for ECDHE encryption, and a digital signature proving ownership of the certificate.

==== Packet 13: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after authentication handshake. All application data is protected by encryption using the ephemeral keys established in Packets 11-12.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836485 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0043 0060 3bed 0b48 1be1 6930 cf3d dee9 .C.`.;..H..i0.=..
0x0010: 4fc9 774b 5d63 cc9b 5a34 6604 f9ac 1016 O.wK]c..Z4f.....
0x0020: 1c6d c9ac f80e dc89 31c1 9634 1a4f b2c7 .m......1..4.O..
0x0030: 4721 e402 8259 b0aa 8870 4566 33d1 9c18 G!...Y.. .pEf3...
0x0040: 06da 50c3 8b75 86b0 f240 d109 840e a6cd ..P..u...@......
0x0050: d115 77cb 5652 5bfb e6d5 0ca9 dbc3 d0b8 ..w.VR[.........
0x0060: 0058 fd19 .X..
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0043</code> || Client flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REQUEST data'''
|}

'''Key observations:'''
* No visible protocol structure - all application data appears as ciphertext
* Uses the same source/destination EID pair (0x0043 → 0x0060) established in the FLOW_REQ/FLOW_REPLY handshake
* Encryption is done using the ephemeral key (91 bytes) exchanged in Packet 11's OAP header
* Unlike Packets 11-12, this packet contains no certificate, public keys, or signatures
* The 110-byte encrypted data corresponds to the original oping ECHO_REQUEST message

==== Packet 14: Encrypted ECHO_REPLY ====

'''Summary:''' Server sends encrypted ping reply. Note that the flow identifiers swap, demonstrating bidirectional encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836930 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 d552 e100 e681 940c e35a 07d0 .@.`..........Z..
0x0010: a293 1d73 33a5 854e 0fce 4f4d 6655 267a ...s3..N..OMfU&z
0x0020: 3de2 663b 709d 739a a696 2ddd 7b34 28b8 =.f;p.s...-{4(...
0x0030: 5a98 eec2 52c6 4288 3885 ae16 e466 4181 Z...R.B.8...fA..
0x0040: f2d6 44c1 b51b 8728 58a4 7525 fb5e 3fd6 ..D...(X.u%.^?..
0x0050: 7e49 532a d2a5 bea7 55e9 c274 f1b2 0412 ~IS*....U..t....
0x0060: 73d4 6436 s.d6
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0040</code> || Client's inbound flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REPLY data'''
|}

'''Key observations:'''
* The EID in offset 0x00 is now 0x0040 (server's view of client's inbound flow)
* Uses the same ephemeral key material as Packet 13, but encryption direction is reversed
* Both packets use AES-GCM with keys derived from the ECDH exchange
* Timestamp 17:39:59.836930 is only 445 microseconds after Packet 13, indicating server-side processing
* The 110-byte encrypted ECHO_REPLY payload is the same size as the request
* All application data is protected by both authentication (X.509 + ECDSA) and encryption (AES)

=== Packet Analysis: Test 4 - Authentication, no encryption ===

==== Packet 15: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with authentication enabled but encryption disabled. This FLOW_REQ carries an OAP header but '''no ephemeral key''' since the client does not request encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:03.413372 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a8f a6ab 6ea7 ..f.i.._........
0x0050: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0060: 0de6 6100 0000 0000 0000 00 ..a.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... dc40</code> || '''QoS (Various)''' || 28 || Mixed ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e490 0de6 61</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key (no encryption)'''
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* No encryption enabled: ephemeral key absent (Eph_len = 0x0000)
* Client requests authentication only
* Server will respond with certificate + signature but no ephemeral key
* Packet is minimal compared to Packet 11 (Test 3) which includes 91-byte ephemeral key

==== Packet 16: FLOW_REPLY ====

'''Summary:''' Server accepts the authenticated (but not encrypted) flow allocation request. FLOW_REPLY contains the server's X.509 certificate and ECDSA signature for client authentication, but '''no ephemeral key''' since encryption is not being used.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:40:03.416675 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 751:
0x0000: 0000 02dd 0041 0040 0000 0000 0000 0000 .......A.@......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 008f a6ab 6ea7 ................
0x0030: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0040: 3754 a702 2f30 8202 2b30 8201 b2a0 0302 7T../0..+0......
0x0050: 0102 0202 1000 300a 0608 2a86 48ce 3d04 ......0...*.H.=.
(... certificate and signature bytes ...)
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>02dd</code> || '''Length''' || 2 || 733 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (Packet 15 echoed back)
|-
| 0x3b-0x42 || <code>fa18 86a8 e490 3754</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>a702</code> || '''Crt_len''' || 2 || 0x02a7 (679 decimal) || '''Certificate length: 679 bytes'''
|-
| 0x45-0x270 || <code>2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ...</code> || '''Certificate''' || 679 || DER-encoded X.509 || Server's certificate signed by intermediate CA
|-
| 0x271-0x272 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key''' (no encryption)
|-
| 0x273-0x274 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x275-0x276 || <code>0067</code> || '''Sig_len''' || 2 || 0x0067 (103 decimal) || '''ECDSA signature length: 103 bytes'''
|-
| 0x277-0x2dd || <code>3065 0230 75dc 5717 ... 83</code> || '''Signature''' || 103 || ECDSA signature (DER encoded) || Server's ECDSA signature proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0041 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from Packet 15 FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Certificate Field - <code>crt_len = 0x02a7 (679)</code> carrying server's X.509 certificate signed by intermediate CA
* Separate Signature Field - <code>sig_len = 0x0067 (103)</code> with ECDSA signature over entire OAP header
* No Ephemeral Key - <code>eph_len = 0x0000</code> since encryption is '''not''' being used in Test 4
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ (included in signature, binding response to this specific client request)
* Complete OAP Structure - Full OAP header with all standard fields, just without ephemeral key data
* Plaintext Data Exchange - After this FLOW_REPLY, all subsequent application data will be transmitted in plaintext (but authenticated via certificate + signature verification)

==== Packet 17: ECHO_REQUEST ====

'''Summary:''' Client sends plaintext ECHO_REQUEST data through the authenticated (but unencrypted) flow. The oping application's ping request is transmitted directly without encryption, relying on the earlier certificate+signature authentication for security.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.419664 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 8177 0000 .A.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Request (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number / message identifier
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Seconds component from CLOCK_REALTIME
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Nanoseconds component (0-999999999)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0041 → Server Flow - Data is directed to the server's endpoint ID allocated in Packet 16 FLOW_REPLY
* Plaintext Transmission - No encryption layer; oping payload is sent as-is (compare to Packet 13 which had encryption)
* Authenticated Flow - Although plaintext, this data travels on the authenticated flow established in Packet 16 (certificate + signature verified)
* Type = ECHO_REQUEST - 0x00000000 indicates client-to-server ping request
* ID = 0 - Sequence number for matching request/reply pairs
* Test 4 Characteristic - Demonstrates authenticated communication '''without''' encryption; application data is readable but cryptographically bound to the authenticated flow
* Contrast to Test 3 - Packet 13 (Test 3 encrypted ECHO_REQUEST) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

==== Packet 18: ECHO_REPLY ====

'''Summary:''' Server responds with plaintext ECHO_REPLY data, echoing back the client's request. This confirms successful bidirectional communication over the authenticated (but unencrypted) flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.420088 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 8177 0000 .@.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Reply (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (seconds)
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (nanoseconds)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Echoed probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0040 → Client Flow - Server responds to client's endpoint ID from Packet 15 FLOW_REQ
* Type = ECHO_REPLY - 0x00000001 indicates server-to-client response
* ID = 0 - Echoes the request sequence number, matching this response to the request
* Timestamps Echo Request - Both timestamp fields are copied from Packet 17 unchanged (8177 0000 0000 0000 and aa16 1c16 0000 0000)
* Plaintext Reply - No encryption; server's response payload is readable (compare to Packet 14 which had encryption)
* Authenticated Channel - Although plaintext, this reply is part of the authenticated flow; client can verify integrity through earlier certificate+signature
* Test 4 Completion - Demonstrates '''full bidirectional plaintext communication''' over an authenticated (but unencrypted) flow
* Contrast to Test 3 - Packet 14 (Test 3 encrypted ECHO_REPLY) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

Ouroboros Tutorial 06

2026-02-14T14:46:17Z

Dimitri: /* Test 1: No Authentication, No Encryption */

= Ouroboros Tutorial 06 - Authenticated Flows =

This tutorial demonstrates setting up and using authenticated flows in Ouroboros with certificate-based authentication.

The overall flow of authenticated flow allocation is

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

'''Tutorial Directory:''' This tutorial will execute in <code>/tmp/o7s-tut06/</code>. All configuration files, generated certificates, logs, and packet captures will be stored in this directory.

We create a complete PKI (Public Key Infrastructure):

* '''Root CA''' (<code>ca.tut.o7s</code>): Self-signed trust anchor
* '''Intermediate CA''' (<code>sign.tut.o7s</code>): Signed by root with pathlen:0 constraint
* '''Server Certificate''' (<code>sec.oping.tut.o7s</code>): Signed by intermediate CA

This tutorial uses ECDSA P-384 with SHA-384 hashing.

== Setting Up the Tutorial ==

To properly understand and debug the authenticated flows, this tutorial uses a debug build of Ouroboros with OAP protocol debugging enabled.

<syntaxhighlight lang="bash">
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
</syntaxhighlight>

When built with these options, the IRMd will output detailed OAP protocol information.

=== Configuration Files ===

The following three files should be created in the tutorial directory (<code>/tmp/o7s-tut06/</code>) before starting the tutorial:

'''tut06.conf''' - IRMd configuration

<syntaxhighlight lang="ini">
# Ouroboros Tutorial 06 - Authenticated Flows Configuration
# Uses system-installed certificates at /etc/ouroboros/security/

[name."sec.oping.tut.o7s"]
prog=["/usr/bin/oping"]
args=["--listen"]

[eth-dix.eth-dix-lo]
bootstrap="eth-dix-network"
dev="lo"
reg=["sec.oping.tut.o7s"]
</syntaxhighlight>

'''ca.tut.o7s.cnf''' - OpenSSL configuration for PKI generation

<syntaxhighlight lang="text">
# Unified OpenSSL Configuration for Ouroboros Tutorial 06
# Named CA sections: CA_root (signs intermediate), CA_intermediate (signs server)
# Usage: openssl ca -name CA_root -config ca.tut.o7s.cnf ...

[ req ]
default_bits = 384
default_keyfile = private/key.pem
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha384
x509_extensions = v3_ca

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name

countryName_default = BE
stateOrProvinceName_default = OVL
localityName_default = Ghent
organizationName_default = o7s

[ ca ]
default_ca = CA_root

[ CA_root ]
dir = ./pki/root
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.tut.o7s.crt.pem
private_key = $dir/private/ca.tut.o7s.key.pem
default_days = 3650
default_md = sha384
policy = policy_loose

[ CA_intermediate ]
dir = ./pki/sign
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/sign.tut.o7s.crt.pem
private_key = $dir/private/sign.tut.o7s.key.pem
default_days = 365
default_md = sha384
policy = policy_loose

[ policy_loose ]
commonName = supplied

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
</syntaxhighlight>

'''gen-pki.sh''' - PKI generation script

This script will:
1. Create the directory structure
2. Generate the root CA key and certificate
3. Generate the intermediate CA key and CSR
4. Sign the intermediate CA certificate
5. Generate the server certificate key and CSR
6. Sign the server certificate
7. Verify the complete certificate chain

<syntaxhighlight lang="bash">
#!/bin/bash
# Ouroboros Tutorial 06 - PKI Generation Script (Simplified)
# Generates: Root CA, Intermediate CA, and Server Certificate

set -e

if [ ! -f ca.tut.o7s.cnf ]; then
echo "ERROR: ca.tut.o7s.cnf not found"
exit 1
fi

mkdir -p pki/{root,sign,server}/{certs,private,csr}

# Root CA
openssl ecparam -genkey -name secp384r1 -out pki/root/private/ca.tut.o7s.key.pem 2>/dev/null
openssl req -new -x509 -sha384 -days 7300 \
-config ca.tut.o7s.cnf \
-key pki/root/private/ca.tut.o7s.key.pem \
-out pki/root/certs/ca.tut.o7s.crt.pem \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=ca.tut.o7s" 2>/dev/null

# Intermediate CA
openssl ecparam -genkey -name secp384r1 -out pki/sign/private/sign.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/sign/private/sign.tut.o7s.key.pem \
-out pki/sign/csr/sign.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sign.tut.o7s" 2>/dev/null

touch pki/root/index.txt
echo 1000 > pki/root/serial

openssl ca -name CA_root -config ca.tut.o7s.cnf \
-extensions v3_intermediate_ca -days 3650 -md sha384 -batch \
-in pki/sign/csr/sign.tut.o7s.csr \
-out pki/sign/certs/sign.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Server Certificate
openssl ecparam -genkey -name secp384r1 -out pki/server/private/sec.oping.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/server/private/sec.oping.tut.o7s.key.pem \
-out pki/server/csr/sec.oping.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sec.oping.tut.o7s" 2>/dev/null

touch pki/sign/index.txt
echo 1000 > pki/sign/serial

openssl ca -name CA_intermediate -config ca.tut.o7s.cnf \
-extensions server_cert -days 365 -md sha384 -batch \
-in pki/server/csr/sec.oping.tut.o7s.csr \
-out pki/server/certs/sec.oping.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Verify chain
openssl verify -CAfile pki/root/certs/ca.tut.o7s.crt.pem \
-untrusted pki/sign/certs/sign.tut.o7s.crt.pem \
pki/server/certs/sec.oping.tut.o7s.crt.pem > /dev/null 2>&1

echo "PKI generation complete."
</syntaxhighlight>

== Part 1: Running the Tutorial - Single Session with 4 Tests ==

This section demonstrates a single continuous session with one IRMd and tcpdump instance. The configuration file (<code>tut06.conf</code>) includes autostart for oping, so the server is ready immediately when IRMd starts.

First install the '''CA and Intermediate CA only''' to the system security directories. The server certificate will be installed later during Test 3 (authentication test):

<syntaxhighlight lang="bash">
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}

# Run the PKI generation script
cd /tmp/o7s-tut06
sudo chmod +x gen-pki.sh
sudo ./gen-pki.sh

# Install Root CA (trust anchor)
sudo cp pki/root/certs/ca.tut.o7s.crt.pem /etc/ouroboros/security/cacert/

# Install Intermediate CA (for certificate chain validation)
sudo cp pki/sign/certs/sign.tut.o7s.crt.pem /etc/ouroboros/security/untrusted/
</syntaxhighlight>

=== Running the Tutorial (3 Terminals) ===

In this tutorial, we run a single IRMd session with a concurrent tcpdump instance to capture it. We then run four oping client tests while the IRMd/tcpdump sessions are going, modifying the security configuration between tests. After the tests are complete, we can will down the IRMd and tcpdump sessions with Ctrl-C.

'''Terminal 1: Start tcpdump to capture all packets (runs continuously)'''

<syntaxhighlight lang="bash">
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
</syntaxhighlight>

'''Terminal 2: Start IRMd with debug output (runs continuously)'''

<syntaxhighlight lang="bash">
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
</syntaxhighlight>

'''Terminal 3: Run the tests'''

==== Test 1: No Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Verify directories are empty
sudo ls -la /etc/ouroboros/security/client/sec.oping.tut.o7s/*
sudo ls -la /etc/ouroboros/security/server/sec.oping.tut.o7s/*

# Run first ping test
echo "=== Test 1: No Authentication, No Encryption ==="
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 1: Client initiates plaintext flow allocation'''

<syntaxhighlight lang="text">
irmd/oap(DB): [60e824383b3fbd6a] KEX config: algo=none, mode=server-encap, cipher=none.
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:56 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 1: Server accepts and completes handshake'''

<syntaxhighlight lang="text">
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:57 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: [48 bytes]
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''Key observations:''' All OAP fields are <code><none></code> because no security is configured (except for the request hash in the response). Flow succeeds with plaintext communication.

==== Test 2: No Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run second ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 2: Client initiates flow with encryption enabled'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33356 to sec.oping.tut.o7s.
==33047== irmd(II): Encryption enabled for sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd(DB): Generated ephemeral keys for 33356.
==33047== irmd/oap(PP): OAP_HDR [3fa5ac1a91a23936 @ 2026-01-01 11:27:15 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 2: Server receives and responds with ephemeral key'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Generated ephemeral keys for 33198.
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [3fa5ac1a91a23936] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
==33047== irmd(II): No certificate provided by sec.oping.tut.o7s.
==33047== reg/name(DB): Process 33198 accepting flows for sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Both client and server generate ephemeral keys (91 bytes each) for encryption. No certificates because authentication is not required. Encryption and authentication are independent.

==== Test 3: With Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Install server certificates and keys
sudo cp /tmp/o7s-tut06/pki/server/certs/sec.oping.tut.o7s.crt.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/crt.pem
sudo cp /tmp/o7s-tut06/pki/server/private/sec.oping.tut.o7s.key.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/key.pem

# enc.conf is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 3: Client initiates flow with encryption and server has certificate'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33500 to sec.oping.tut.o7s.
==33047== irmd(II): Encryption enabled for sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd(DB): Generated ephemeral keys for 33500.
==33047== irmd/oap(PP): OAP_HDR [3f89a905c0e5571b @ 2026-01-01 11:27:25 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Generated ephemeral keys for 33198.
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [3f89a905c0e5571b] -->
==33047== irmd/oap(PP): Certificate: [560 bytes]
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 3: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Loaded peer certificate for sec.oping.tut.o7s.
==33047== irmd(DB): Certificate matches name sec.oping.tut.o7s.
==33047== irmd(DB): Got public key from certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully verified peer certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully authenticated sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Full OAP handshake with certificate (560 bytes) + ephemeral keys (91 bytes) + signature (103 bytes). Client verifies server's certificate against CA store and confirms authentication success.

==== Test 4: With Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33642 to sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf does not exist.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211 @ 2026-01-01 11:27:34 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)'''

<syntaxhighlight lang="text">
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211] -->
==33047== irmd/oap(PP): Certificate: [560 bytes]
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 4: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Loaded peer certificate for sec.oping.tut.o7s.
==33047== irmd(DB): Certificate matches name sec.oping.tut.o7s.
==33047== irmd(DB): Got public key from certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully verified peer certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully authenticated sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Server sends certificate + signature for authentication, but NO ephemeral keys (plaintext data). Data exchanged without encryption even though authenticated. Demonstrates that authentication and encryption are independent mechanisms.

=== Stop the IRMd and tcpdump, clean up the tutorial files ===

Once all tests complete:

<syntaxhighlight lang="bash">
# Stop IRMd in Terminal 2 (Ctrl+C)
# Stop tcpdump in Terminal 1 (Ctrl+C)

# Clean up tutorial security files from system
sudo rm -f /etc/ouroboros/security/cacert/ca.tut.o7s.crt.pem
</syntaxhighlight>

== Part 2: PCAP Trace Analysis ==

After the tutorial, we now explain the trace in the tcpdump pcap file.

=== Protocol Overview ===

This section summarizes the four protocols that work together in the captured packet flow.

==== Ethernet DIX Frame with EID Header ====

Ouroboros extends the DIX frame with a flow identifier (EID - Endpoint Identifier) and length field.

{| class="wikitable"
|-
! Field !! Octets !! Size !! Description
|-
| Destination MAC || 0-5 || 6 bytes || Hardware address of destination
|-
| Source MAC || 6-11 || 6 bytes || Hardware address of source
|-
| EtherType || 12-13 || 2 bytes || Protocol identifier (0xA000 for Ouroboros)
|-
| EID || 14-15 || 2 bytes || Destination Endpoint Identifier
|-
| Length || 16-17 || 2 bytes || Payload length (needed because of runt frame padding)
|-
| Payload || 18+ || Variable || Frame data (up to MTU size)
|}

==== Ethernet Flow Allocator - Management Protocol ====

The Ethernet DIX management protocol handles flow allocation, setup, and teardown. All management frames use destination EID <code>0x0000</code>.

'''Management Frame Types:'''

{| class="wikitable"
|-
! Code !! Type !! Direction !! Service Hash !! Purpose
|-
| <code>0x00</code> || <code>FLOW_REQ</code> || Client → Server || ✓ Included || Request new flow allocation
|-
| <code>0x01</code> || <code>FLOW_REPLY</code> || Server → Client || – Not included || Respond to flow request (success/failure)
|-
| <code>0x02</code> || <code>NAME_QUERY_REQ</code> || Client → Server || ✓ Included || Query if a remote name is reachable
|-
| <code>0x03</code> || <code>NAME_QUERY_REPLY</code> || Server → Client || ✓ Included || Response to name query
|}

'''Note:''' The 32-byte service hash (SHA3-256) is appended after the management protocol header for NAME_QUERY_* and FLOW_REQ messages to identify which service is being queried or allocated. FLOW_REPLY does not include the service hash; the endpoints are already identified by the allocated EIDs (SEID/DEID) and the flow allocation ID in the OAP header (see below).

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| SEID || 0-1 || 2 bytes || Source Endpoint ID
|-
| DEID || 2-3 || 2 bytes || Destination Endpoint ID
|-
| Loss || 4-7 || 4 bytes || Acceptable packet loss (ppm)
|-
| Bandwidth || 8-15 || 8 bytes || Required bandwidth (bps)
|-
| BER || 16-19 || 4 bytes || Bit error rate (ppm)
|-
| Max Gap || 20-23 || 4 bytes || Maximum consecutive lost packets
|-
| Delay || 24-27 || 4 bytes || Maximum latency (ms)
|-
| Timeout || 28-31 || 4 bytes || Flow idle timeout (seconds)
|-
| Response || 32-35 || 4 bytes || Response code (0=success, negative=error)
|-
| In-Order || 36 || 1 byte || In-order delivery requirement (boolean)
|-
| Code || 37 || 1 byte || Message type (FLOW_REQ, FLOW_REPLY, etc.)
|-
| Availability || 38 || 1 byte || Availability status
|-
| Service hash || 39-61 || 32 bytes || SHA3-256 hash (optional, see above)
|}

==== Ouroboros Flow Allocation Protocol (OAP) ====

The Ouroboros Application Protocol (OAP) is the flow allocation and authentication protocol. It carries flow negotiation requests, responses, and authentication credentials. OAP frames are encapsulated as data payload over the management protocol.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| ID || 0-15 || 16 bytes || Unique flow allocation identifier
|-
| Timestamp || 16-23 || 8 bytes || Creation timestamp (UTC, seconds and microseconds)
|-
| Crt Length || 24-25 || 2 bytes || Certificate length (bytes)
|-
| Certificate || 26+ || Variable || X.509 certificate (DER encoded)
|-
| Eph Length || Variable || 2 bytes || Ephemeral public key length (bytes)
|-
| Ephemeral Key || Variable || Variable || ECDHE public key (DER/raw encoded)
|-
| Data Length || Variable || 2 bytes || Application data length (bytes)
|-
| Data || Variable || Variable || Piggybacked application-layer data
|-
| Sig Length || Variable || 2 bytes || Signature length (bytes)
|-
| Signature || Variable || Variable || Digital signature (ECDSA, DER encoded)
|}

==== Oping Application Protocol ====

The Ouroboros Ping (oping) application is a simple echo/reply protocol used to measure round-trip time and validate connectivity between applications. It implements a request/reply pattern similar to ICMP ping.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| Type || 0-3 || 4 bytes || Message type (ECHO_REQUEST=0 or ECHO_REPLY=1)
|-
| ID || 4-7 || 4 bytes || Sequence number / message identifier
|-
| Timestamp (seconds) || 8-15 || 8 bytes || Seconds when message was sent (CLOCK_REALTIME)
|-
| Timestamp (nanoseconds) || 16-23 || 8 bytes || Nanoseconds component of timestamp
|-
| Payload || 24+ || Variable || Application data (configurable size, default 64 bytes)
|}

'''Field Definitions:'''

* '''Type''' (4 bytes): Message type selector
** <code>0x00000000</code> (ECHO_REQUEST): Client-to-server ping request
** <code>0x00000001</code> (ECHO_REPLY): Server-to-client response

* '''ID''' (4 bytes): Sequence number for matching requests with replies. Incremented for each ping sent.

* '''Timestamp (seconds)''' (8 bytes): Network-byte-order 64-bit seconds component from when the ping was sent (CLOCK_REALTIME).

* '''Timestamp (nanoseconds)''' (8 bytes): Network-byte-order 64-bit nanoseconds component (0-999999999) for high-resolution timing.

* '''Payload''' (Variable): Application data echoed back by the server. Size is configurable (default 64 bytes, maximum 1500 bytes).

'''Usage:'''

* Client sends ECHO_REQUEST with current timestamp
* Server receives request and echoes back as ECHO_REPLY with the same ID and timestamps
* Client calculates RTT by comparing reception time with original timestamps
* Out-of-order detection by tracking sequence numbers (ID field)

=== Packet Analysis: Test 1 - No authentication/encryption ===

==== Packet 1: NAME_QUERY_REQ ====

'''Summary:''' Client sends a NAME_QUERY_REQ message to discover if the service <code>sec.oping.tut.o7s</code> is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.165639 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0002 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

==== Packet 2: NAME_QUERY_REPLY ====

'''Summary:''' Server responds to the NAME_QUERY_REQ by sending a NAME_QUERY_REPLY for the service hash.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.166073 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0003 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code> (echoed back)
|}

==== Packet 3: FLOW_REQ ====

'''Summary:''' Client initiates a flow allocation request (FLOW_REQ) with minimal OAP headers since no authentication or encryption is being used.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.167222 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a51 8a56 ff6f ..f.i.._...Q.V.o
0x0050: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e103 [...}....0w.....
0x0060: 3e52 3300 0000 0000 0000 00 >R3........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || -- || '''UNUSED'''
|-
| 0x24-0x27 || <code>0001 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload'''

The OAP payload starts at offset 0x4b (after management protocol + service hash):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e103 3e52 33</code> || '''Timestamp''' || 8 || Network order || Creation timestamp (seconds + microseconds)
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 (first allocated flow ID for this session)
* Service hash is carried in management protocol payload (32 bytes)
* OAP header is minimal: only ID and timestamp, no optional fields
* No certificate, ephemeral key, data, or signature in this initial request
* Client sends minimal OAP headers with no authentication or encryption setup at allocation time

==== Packet 4: FLOW_REPLY ====

'''Summary:''' Server responds to FLOW_REQ by sending FLOW_REPLY with a new DEID (destination endpoint ID 0x0041) to establish the allocated flow for data transfer.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:49.178732 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0041 0040 0000 0000 0000 0000 ...G.A.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0051 8a56 ff6f ...........Q.V.o
0x0030: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e13f [...}....0w....?
0x0040: a347 3800 0000 0000 0000 00 .G8........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server-side flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0|| Response code (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload'''

The OAP payload starts at offset 0x2b (no service hash in FLOW_REPLY):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Echo of client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e13f a347 38</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x47-0x48 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x49-0x4a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0041 is the newly allocated server-side flow endpoint
* DEID 0x0040 reflects the client's flow ID, creating a bidirectional mapping
* No service hash included (FLOW_REPLY only needs the EIDs to identify the flow)
* OAP echoes the client's ID and timestamp, confirming the flow allocation
* Response code 0x00000000 indicates success
* Both client and server now have their respective flow IDs (0x0040 and 0x0041) for data transfer
* Response code 0x00000000 indicates success

==== Packet 5: ECHO_REQUEST - Plaintext Data ====

'''Summary:''' Client sends an oping ECHO_REQUEST packet to the server using the allocated flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.180824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 7377 0000 .A.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Source Endpoint ID (server → client)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REQUEST Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number (first ping)
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Seconds component
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Nanoseconds component
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (default 64 bytes total - 24 byte header = 40 bytes data)
|}

'''Key observations:'''
* EID 0x0041 shows traffic from server-side flow ID
* This is the first ping request (ID = 0x00000000)
* Timestamp captures when the ping was sent (seconds in network order)
* Default oping payload is 64 bytes total; 24 bytes header + 40 bytes data

==== Packet 6: ECHO_REPLY - Plaintext Data ====

'''Summary:''' Server receives the ECHO_REQUEST and immediately sends back an ECHO_REPLY with the same ID and timestamps, echoing the client's message.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.181496 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 7377 0000 .@.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client ← server)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REPLY Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Echo of original seconds
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Echo of original nanoseconds
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (unchanged from request)
|}

'''Key observations:'''
* EID 0x0040 shows traffic from client-side flow ID receiving the reply
* Type field changed from 0x00000000 (REQUEST) to 0x00000001 (REPLY)
* ID, timestamps, and payload data are identical to the request (echoed back)
* Round-trip time can be calculated by comparing current time with echoed timestamp
* Ping succeeded on first attempt with minimal latency (~1 millisecond between timestamps)

=== Packet Analysis: Test 2 - No authentication, with encryption ===

==== Packet 7: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with encryption enabled. This FLOW_REQ carries an OAP header with an ephemeral ECDHE P-384 public key (91 bytes) for encryption setup.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.808158 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8af1 766b 547c ..f.i.._....vkT|
0x0050: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0060: 8b6c 9000 0000 5b30 5930 1306 072a 8648 .l....[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 c508 1c19 6106 b7e9 3074 57b9 bb16 ......a...0tW...
0x0090: 6959 4a55 81f9 169b cc79 fe10 a882 41fe iYJU.....y....A.
0x00a0: 0697 c9b4 f8f0 5562 7fa2 c7a0 a020 1ac6 ......Ub........
0x00b0: 939f 23ff b2fb 07a2 b747 aacc 474a 3dab ..#......G..GJ=.
0x00c0: 2598 0000 0000 %.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Mixed || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 ... 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e253 8b6c 90</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 ... 3dab 2598</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || ECDHE P-384 public key (DER encoded)
|-
| 0xd3-0xd4 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd5-0xd6 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* Encryption enabled: ephemeral key present (91 bytes)
* Client sends no certificate, allowing anonymous encryption setup
* No signature (unsigned OAP)
* Ephemeral key is ECDHE P-384 for key exchange

==== Packet 8: FLOW_REPLY ====

'''Summary:''' Server accepts the encrypted flow allocation request. FLOW_REPLY contains the server's ephemeral key but no certificate (since client didn't send one).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.810564 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 180:
0x0000: 0000 00a2 0042 0040 0000 0000 0000 0000 .....B.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 00f1 766b 547c ............vkT|
0x0030: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0040: b694 e800 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0050: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0060: 0004 5f3c 6929 cca2 024a ae9f 9aa1 dfc2 .._<i)...J......
0x0070: a493 3ff3 ff58 b054 74dc d2e2 47fc 7c5b ..?..X.Tt...G.|[
0x0080: eff5 e129 72b4 de1e 7c09 bf8c fe38 5e8b ...)r...|....8^.
0x0090: b22e 59ed 6eb9 dfda 369d 691e 6e2c 122c ..Y.n...6.i.n,.,
0x00a0: 9936 0000 0000 .6....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00a2</code> || '''Length''' || 2 || 162 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0042</code> || '''SEID''' || 2 || 0x0042 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || Echo of client ID || Echoes client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e253 b694 e8</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x47-0xa1 || <code>30 5930...9936</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || Server's ECDHE P-384 public key (DER encoded)
|-
| 0xd1-0xd2 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd3-0xd4 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0042 is the new server-side flow endpoint
* Both keys are now exchanged; client and server can derive shared secret
* No authentication (no certificates) but encryption is negotiated
* Response indicates successful allocation

==== Packet 9: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after encryption keys are established. The payload is encrypted with the derived shared secret.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.815771 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0042 0060 a691 6d83 8446 cbeb ac95 c2eb .B.`..m..F......
0x0010: 4b42 e819 c67f 92c8 58d7 0641 d8a6 6e1f KB......X..A..n.
0x0020: fc90 feed ef55 b791 4fbd a832 74bd 8bed .....U..O..2t...
0x0030: 249c 4cee 0fc0 cec6 2f1b aec1 2428 bdbd $.L...../...$(..
0x0040: 36b5 01b5 1257 004e 6ed6 7ecd f0c7 7d11 6....W.Nn.~...}.
0x0050: 20ba e81b f43a 4de9 b141 1624 e1ba 0a84 .....:M..A.$....
0x0060: 74b1 9a9a t...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0042</code> || '''EID''' || 2 || 0x0042 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REQUEST (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>a691 6d83 8446 cbeb...74b1 9a9a</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* All 96 bytes of oping data (type, ID, timestamps, payload) are encrypted
* No plaintext oping headers visible; entire packet is ciphertext
* Flow IDs (0x0042) identify which encryption context to use
* Ping still works with encryption transparently

==== Packet 10: Encrypted ECHO_REPLY ====

'''Summary:''' Server receives encrypted ping request, decrypts it, and sends encrypted ECHO_REPLY.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.819574 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 c6ea 2222 5618 0268 b27e 9a91 .@.`..""V..h.~..
0x0010: f124 1f8d bccc 478c 26fe 9b13 b3cb 5398 .$....G.&.....S.
0x0020: 6869 3cdb 4928 510d 4de8 dc6a 3f3a 6a6d hi<.I(Q.M..j?:jm
0x0030: 6487 dcd8 c8cd 1a85 fba2 9ecd 3566 57d1 d...........5fW.
0x0040: 1c94 ac35 518e 8509 873a 3a5e 04d9 8ee2 ...5Q....::^....
0x0050: 9d74 2527 e425 5433 9d73 9ccd f56a 1f8d .t%'.%T3.s...j..
0x0060: f328 7237 .(r7
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REPLY (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>c6ea 2222 5618 0268...f328 7237</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* EID 0x0040 shows reply going back to client-side flow
* Ciphertext is different from request (different plaintext: type field differs)
* Both encrypted packets are 96 bytes (same size as Packet 9)
* Client receives encrypted reply, decrypts it, verifies ID and timestamps match request
* Encryption is transparent at application layer: oping works exactly as with plaintext flows

=== Packet Analysis: Test 3 - Authentication and encryption ===

==== Packet 11: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation request with encryption enabled. Sends ephemeral public key for ECDHE key exchange but no certificate (client is not authenticating in this tutorial). The management protocol now carries a valid allocated SEID (0x0040).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:58.827411 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a66 bb82 95fa ..f.i.._...f....
0x0050: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0060: c0d2 ad00 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 9dea c238 6732 4987 1cd4 7133 9614 .....8g2I...q3..
0x0090: 9d04 4fde 3f68 42f1 54fb 7ef3 88d0 ffe6 ..O.?hB.T.~.....
0x00a0: 7e01 432e 56c2 2d64 72c9 19fc b0cf 1eca ~.C.V.-dr.......
0x00b0: 689e 3536 771a 8041 726c 20e2 d9bb 3589 h.56w..Arl....5.
0x00c0: 86e7 0000 0000 ......
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (client flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ... 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier for Test 3
|-
| 0x5b-0x62 || <code>18 86a8 e37e c0d2 ad</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || Client not authenticating
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Ephemeral public key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 1306 ... 3589</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Client's ephemeral ECDHE public key for encryption negotiation
|-
| 0xc2-0xc3 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xc4-0xc5 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 - Same as Test 2 (Encrypted) because this is the same client session reusing the same allocated ID from the previous test
* No Certificate - <code>crt_len = 0x0000</code> because the client does not have authentication credentials; the server will authenticate instead
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> because encryption is enabled on the client
* No Signature - <code>sig_len = 0x0000</code> because client is not signing (no certificate to sign with)
* FLOW_REQ Message Type - Code field is 0x00, and service hash is present because FLOW_REQ always includes the service hash
* Timestamp Consistency - Same OAP ID and timestamp structure as Test 2, but with additional security handshake

==== Packet 12: FLOW_REPLY ====

'''Summary:''' Server responds to client's FLOW_REQ by sending FLOW_REPLY with its certificate for authentication, ephemeral public key for ECDHE encryption setup, and a digital signature proving ownership of the certificate. This is the full authentication response.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:39:58.828806 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 843:
0x0000: 0000 0339 0043 0040 0000 0000 0000 0000 ...9.C.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0066 bb82 95fa ...........f....
0x0030: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0040: d566 a002 2f30 8202 2b30 8201 b2a0 0302 .f../0..+0......
(... certificate and signature bytes ...)
0x0320: ef11 c358 f5d0 5cd7 3906 adf1 8a2c 9b25 ...X..\.9....,.%
0x0330: dc78 6050 ab61 3a3f 81c0 254b d193 7827 .x`P.a:?..%K..x'
0x0340: c0e9 38c7 e0d1 c517 d299 9992 07 ..8..........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0339</code> || '''Length''' || 2 || 825 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0043</code> || '''SEID''' || 2 || 0x0043 || Source Endpoint ID (server-side allocated flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (echoed back)
|-
| 0x3b-0x42 || <code>18 86a8 e37e d566 a0</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>022f</code> || '''Crt_len''' || 2 || 559 (0x022f) || Server certificate length: 559 bytes
|-
| 0x45-0x243 || <code>2f30 8202 2b ... 81c8 30</code> || '''Certificate''' || 559 || DER-encoded X.509 || Server's certificate (signed by intermediate CA)
|-
| 0x244-0x245 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Server's ephemeral public key length: 91 bytes
|-
| 0x246-0x2a0 || <code>30 5930 1306 ... 9936</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Server's ephemeral ECDHE public key
|-
| 0x2a4-0x2a5 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x2a6-0x2a7 || <code>0068</code> || '''Sig_len''' || 2 || 104 (0x0068) || Digital signature length: 104 bytes
|-
| 0x2a8-0x30f || <code>30 6602 3100 ... 07</code> || '''Signature''' || 104 || ECDSA signature (DER encoded) || Server's signature over OAP header proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0043 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from the FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Full Certificate - <code>crt_len = 0x022f (559)</code> carrying server's complete X.509 certificate signed by intermediate CA
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> with server's ECDHE public key for encryption
* Signature Included - <code>sig_len = 0x0068 (104)</code> containing ECDSA digital signature over the entire OAP header
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ to confirm association (included in signature, binding response to this specific client request)
* Large Payload - Total of 825 bytes due to certificate (559) + ephemeral key (91) + signature (104) + overhead
* Authentication Complete - Client verifies: (1) certificate against CA store, (2) signature over entire response ensures authenticity and integrity, (3) echoed ID binds response to this specific request, (4) timestamp prevents replay attacks

'''Summary:''' Server responds with its certificate for authentication, ephemeral public key for ECDHE encryption, and a digital signature proving ownership of the certificate.

==== Packet 13: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after authentication handshake. All application data is protected by encryption using the ephemeral keys established in Packets 11-12.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836485 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0043 0060 3bed 0b48 1be1 6930 cf3d dee9 .C.`.;..H..i0.=..
0x0010: 4fc9 774b 5d63 cc9b 5a34 6604 f9ac 1016 O.wK]c..Z4f.....
0x0020: 1c6d c9ac f80e dc89 31c1 9634 1a4f b2c7 .m......1..4.O..
0x0030: 4721 e402 8259 b0aa 8870 4566 33d1 9c18 G!...Y.. .pEf3...
0x0040: 06da 50c3 8b75 86b0 f240 d109 840e a6cd ..P..u...@......
0x0050: d115 77cb 5652 5bfb e6d5 0ca9 dbc3 d0b8 ..w.VR[.........
0x0060: 0058 fd19 .X..
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0043</code> || Client flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REQUEST data'''
|}

'''Key observations:'''
* No visible protocol structure - all application data appears as ciphertext
* Uses the same source/destination EID pair (0x0043 → 0x0060) established in the FLOW_REQ/FLOW_REPLY handshake
* Encryption is done using the ephemeral key (91 bytes) exchanged in Packet 11's OAP header
* Unlike Packets 11-12, this packet contains no certificate, public keys, or signatures
* The 110-byte encrypted data corresponds to the original oping ECHO_REQUEST message

==== Packet 14: Encrypted ECHO_REPLY ====

'''Summary:''' Server sends encrypted ping reply. Note that the flow identifiers swap, demonstrating bidirectional encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836930 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 d552 e100 e681 940c e35a 07d0 .@.`..........Z..
0x0010: a293 1d73 33a5 854e 0fce 4f4d 6655 267a ...s3..N..OMfU&z
0x0020: 3de2 663b 709d 739a a696 2ddd 7b34 28b8 =.f;p.s...-{4(...
0x0030: 5a98 eec2 52c6 4288 3885 ae16 e466 4181 Z...R.B.8...fA..
0x0040: f2d6 44c1 b51b 8728 58a4 7525 fb5e 3fd6 ..D...(X.u%.^?..
0x0050: 7e49 532a d2a5 bea7 55e9 c274 f1b2 0412 ~IS*....U..t....
0x0060: 73d4 6436 s.d6
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0040</code> || Client's inbound flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REPLY data'''
|}

'''Key observations:'''
* The EID in offset 0x00 is now 0x0040 (server's view of client's inbound flow)
* Uses the same ephemeral key material as Packet 13, but encryption direction is reversed
* Both packets use AES-GCM with keys derived from the ECDH exchange
* Timestamp 17:39:59.836930 is only 445 microseconds after Packet 13, indicating server-side processing
* The 110-byte encrypted ECHO_REPLY payload is the same size as the request
* All application data is protected by both authentication (X.509 + ECDSA) and encryption (AES)

=== Packet Analysis: Test 4 - Authentication, no encryption ===

==== Packet 15: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with authentication enabled but encryption disabled. This FLOW_REQ carries an OAP header but '''no ephemeral key''' since the client does not request encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:03.413372 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a8f a6ab 6ea7 ..f.i.._........
0x0050: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0060: 0de6 6100 0000 0000 0000 00 ..a.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... dc40</code> || '''QoS (Various)''' || 28 || Mixed ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e490 0de6 61</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key (no encryption)'''
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* No encryption enabled: ephemeral key absent (Eph_len = 0x0000)
* Client requests authentication only
* Server will respond with certificate + signature but no ephemeral key
* Packet is minimal compared to Packet 11 (Test 3) which includes 91-byte ephemeral key

==== Packet 16: FLOW_REPLY ====

'''Summary:''' Server accepts the authenticated (but not encrypted) flow allocation request. FLOW_REPLY contains the server's X.509 certificate and ECDSA signature for client authentication, but '''no ephemeral key''' since encryption is not being used.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:40:03.416675 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 751:
0x0000: 0000 02dd 0041 0040 0000 0000 0000 0000 .......A.@......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 008f a6ab 6ea7 ................
0x0030: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0040: 3754 a702 2f30 8202 2b30 8201 b2a0 0302 7T../0..+0......
0x0050: 0102 0202 1000 300a 0608 2a86 48ce 3d04 ......0...*.H.=.
(... certificate and signature bytes ...)
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>02dd</code> || '''Length''' || 2 || 733 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (Packet 15 echoed back)
|-
| 0x3b-0x42 || <code>fa18 86a8 e490 3754</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>a702</code> || '''Crt_len''' || 2 || 0x02a7 (679 decimal) || '''Certificate length: 679 bytes'''
|-
| 0x45-0x270 || <code>2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ...</code> || '''Certificate''' || 679 || DER-encoded X.509 || Server's certificate signed by intermediate CA
|-
| 0x271-0x272 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key''' (no encryption)
|-
| 0x273-0x274 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x275-0x276 || <code>0067</code> || '''Sig_len''' || 2 || 0x0067 (103 decimal) || '''ECDSA signature length: 103 bytes'''
|-
| 0x277-0x2dd || <code>3065 0230 75dc 5717 ... 83</code> || '''Signature''' || 103 || ECDSA signature (DER encoded) || Server's ECDSA signature proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0041 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from Packet 15 FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Certificate Field - <code>crt_len = 0x02a7 (679)</code> carrying server's X.509 certificate signed by intermediate CA
* Separate Signature Field - <code>sig_len = 0x0067 (103)</code> with ECDSA signature over entire OAP header
* No Ephemeral Key - <code>eph_len = 0x0000</code> since encryption is '''not''' being used in Test 4
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ (included in signature, binding response to this specific client request)
* Complete OAP Structure - Full OAP header with all standard fields, just without ephemeral key data
* Plaintext Data Exchange - After this FLOW_REPLY, all subsequent application data will be transmitted in plaintext (but authenticated via certificate + signature verification)

==== Packet 17: ECHO_REQUEST ====

'''Summary:''' Client sends plaintext ECHO_REQUEST data through the authenticated (but unencrypted) flow. The oping application's ping request is transmitted directly without encryption, relying on the earlier certificate+signature authentication for security.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.419664 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 8177 0000 .A.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Request (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number / message identifier
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Seconds component from CLOCK_REALTIME
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Nanoseconds component (0-999999999)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0041 → Server Flow - Data is directed to the server's endpoint ID allocated in Packet 16 FLOW_REPLY
* Plaintext Transmission - No encryption layer; oping payload is sent as-is (compare to Packet 13 which had encryption)
* Authenticated Flow - Although plaintext, this data travels on the authenticated flow established in Packet 16 (certificate + signature verified)
* Type = ECHO_REQUEST - 0x00000000 indicates client-to-server ping request
* ID = 0 - Sequence number for matching request/reply pairs
* Test 4 Characteristic - Demonstrates authenticated communication '''without''' encryption; application data is readable but cryptographically bound to the authenticated flow
* Contrast to Test 3 - Packet 13 (Test 3 encrypted ECHO_REQUEST) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

==== Packet 18: ECHO_REPLY ====

'''Summary:''' Server responds with plaintext ECHO_REPLY data, echoing back the client's request. This confirms successful bidirectional communication over the authenticated (but unencrypted) flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.420088 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 8177 0000 .@.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Reply (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (seconds)
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (nanoseconds)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Echoed probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0040 → Client Flow - Server responds to client's endpoint ID from Packet 15 FLOW_REQ
* Type = ECHO_REPLY - 0x00000001 indicates server-to-client response
* ID = 0 - Echoes the request sequence number, matching this response to the request
* Timestamps Echo Request - Both timestamp fields are copied from Packet 17 unchanged (8177 0000 0000 0000 and aa16 1c16 0000 0000)
* Plaintext Reply - No encryption; server's response payload is readable (compare to Packet 14 which had encryption)
* Authenticated Channel - Although plaintext, this reply is part of the authenticated flow; client can verify integrity through earlier certificate+signature
* Test 4 Completion - Demonstrates '''full bidirectional plaintext communication''' over an authenticated (but unencrypted) flow
* Contrast to Test 3 - Packet 14 (Test 3 encrypted ECHO_REPLY) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

Ouroboros Tutorial 06

2026-02-14T14:42:30Z

Dimitri: /* Test 1: No Authentication, No Encryption */

= Ouroboros Tutorial 06 - Authenticated Flows =

This tutorial demonstrates setting up and using authenticated flows in Ouroboros with certificate-based authentication.

The overall flow of authenticated flow allocation is

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

'''Tutorial Directory:''' This tutorial will execute in <code>/tmp/o7s-tut06/</code>. All configuration files, generated certificates, logs, and packet captures will be stored in this directory.

We create a complete PKI (Public Key Infrastructure):

* '''Root CA''' (<code>ca.tut.o7s</code>): Self-signed trust anchor
* '''Intermediate CA''' (<code>sign.tut.o7s</code>): Signed by root with pathlen:0 constraint
* '''Server Certificate''' (<code>sec.oping.tut.o7s</code>): Signed by intermediate CA

This tutorial uses ECDSA P-384 with SHA-384 hashing.

== Setting Up the Tutorial ==

To properly understand and debug the authenticated flows, this tutorial uses a debug build of Ouroboros with OAP protocol debugging enabled.

<syntaxhighlight lang="bash">
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
</syntaxhighlight>

When built with these options, the IRMd will output detailed OAP protocol information.

=== Configuration Files ===

The following three files should be created in the tutorial directory (<code>/tmp/o7s-tut06/</code>) before starting the tutorial:

'''tut06.conf''' - IRMd configuration

<syntaxhighlight lang="ini">
# Ouroboros Tutorial 06 - Authenticated Flows Configuration
# Uses system-installed certificates at /etc/ouroboros/security/

[name."sec.oping.tut.o7s"]
prog=["/usr/bin/oping"]
args=["--listen"]

[eth-dix.eth-dix-lo]
bootstrap="eth-dix-network"
dev="lo"
reg=["sec.oping.tut.o7s"]
</syntaxhighlight>

'''ca.tut.o7s.cnf''' - OpenSSL configuration for PKI generation

<syntaxhighlight lang="text">
# Unified OpenSSL Configuration for Ouroboros Tutorial 06
# Named CA sections: CA_root (signs intermediate), CA_intermediate (signs server)
# Usage: openssl ca -name CA_root -config ca.tut.o7s.cnf ...

[ req ]
default_bits = 384
default_keyfile = private/key.pem
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha384
x509_extensions = v3_ca

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name

countryName_default = BE
stateOrProvinceName_default = OVL
localityName_default = Ghent
organizationName_default = o7s

[ ca ]
default_ca = CA_root

[ CA_root ]
dir = ./pki/root
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/ca.tut.o7s.crt.pem
private_key = $dir/private/ca.tut.o7s.key.pem
default_days = 3650
default_md = sha384
policy = policy_loose

[ CA_intermediate ]
dir = ./pki/sign
database = $dir/index.txt
serial = $dir/serial
new_certs_dir = $dir/certs
certificate = $dir/certs/sign.tut.o7s.crt.pem
private_key = $dir/private/sign.tut.o7s.key.pem
default_days = 365
default_md = sha384
policy = policy_loose

[ policy_loose ]
commonName = supplied

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
</syntaxhighlight>

'''gen-pki.sh''' - PKI generation script

This script will:
1. Create the directory structure
2. Generate the root CA key and certificate
3. Generate the intermediate CA key and CSR
4. Sign the intermediate CA certificate
5. Generate the server certificate key and CSR
6. Sign the server certificate
7. Verify the complete certificate chain

<syntaxhighlight lang="bash">
#!/bin/bash
# Ouroboros Tutorial 06 - PKI Generation Script (Simplified)
# Generates: Root CA, Intermediate CA, and Server Certificate

set -e

if [ ! -f ca.tut.o7s.cnf ]; then
echo "ERROR: ca.tut.o7s.cnf not found"
exit 1
fi

mkdir -p pki/{root,sign,server}/{certs,private,csr}

# Root CA
openssl ecparam -genkey -name secp384r1 -out pki/root/private/ca.tut.o7s.key.pem 2>/dev/null
openssl req -new -x509 -sha384 -days 7300 \
-config ca.tut.o7s.cnf \
-key pki/root/private/ca.tut.o7s.key.pem \
-out pki/root/certs/ca.tut.o7s.crt.pem \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=ca.tut.o7s" 2>/dev/null

# Intermediate CA
openssl ecparam -genkey -name secp384r1 -out pki/sign/private/sign.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/sign/private/sign.tut.o7s.key.pem \
-out pki/sign/csr/sign.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sign.tut.o7s" 2>/dev/null

touch pki/root/index.txt
echo 1000 > pki/root/serial

openssl ca -name CA_root -config ca.tut.o7s.cnf \
-extensions v3_intermediate_ca -days 3650 -md sha384 -batch \
-in pki/sign/csr/sign.tut.o7s.csr \
-out pki/sign/certs/sign.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Server Certificate
openssl ecparam -genkey -name secp384r1 -out pki/server/private/sec.oping.tut.o7s.key.pem 2>/dev/null
openssl req -new -sha384 \
-config ca.tut.o7s.cnf \
-key pki/server/private/sec.oping.tut.o7s.key.pem \
-out pki/server/csr/sec.oping.tut.o7s.csr \
-subj "/C=BE/ST=OVL/L=Ghent/O=o7s/CN=sec.oping.tut.o7s" 2>/dev/null

touch pki/sign/index.txt
echo 1000 > pki/sign/serial

openssl ca -name CA_intermediate -config ca.tut.o7s.cnf \
-extensions server_cert -days 365 -md sha384 -batch \
-in pki/server/csr/sec.oping.tut.o7s.csr \
-out pki/server/certs/sec.oping.tut.o7s.crt.pem 2>&1 | grep -E "Signature ok|Database updated" || true

# Verify chain
openssl verify -CAfile pki/root/certs/ca.tut.o7s.crt.pem \
-untrusted pki/sign/certs/sign.tut.o7s.crt.pem \
pki/server/certs/sec.oping.tut.o7s.crt.pem > /dev/null 2>&1

echo "PKI generation complete."
</syntaxhighlight>

== Part 1: Running the Tutorial - Single Session with 4 Tests ==

This section demonstrates a single continuous session with one IRMd and tcpdump instance. The configuration file (<code>tut06.conf</code>) includes autostart for oping, so the server is ready immediately when IRMd starts.

First install the '''CA and Intermediate CA only''' to the system security directories. The server certificate will be installed later during Test 3 (authentication test):

<syntaxhighlight lang="bash">
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}

# Run the PKI generation script
cd /tmp/o7s-tut06
sudo chmod +x gen-pki.sh
sudo ./gen-pki.sh

# Install Root CA (trust anchor)
sudo cp pki/root/certs/ca.tut.o7s.crt.pem /etc/ouroboros/security/cacert/

# Install Intermediate CA (for certificate chain validation)
sudo cp pki/sign/certs/sign.tut.o7s.crt.pem /etc/ouroboros/security/untrusted/
</syntaxhighlight>

=== Running the Tutorial (3 Terminals) ===

In this tutorial, we run a single IRMd session with a concurrent tcpdump instance to capture it. We then run four oping client tests while the IRMd/tcpdump sessions are going, modifying the security configuration between tests. After the tests are complete, we can will down the IRMd and tcpdump sessions with Ctrl-C.

'''Terminal 1: Start tcpdump to capture all packets (runs continuously)'''

<syntaxhighlight lang="bash">
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
</syntaxhighlight>

'''Terminal 2: Start IRMd with debug output (runs continuously)'''

<syntaxhighlight lang="bash">
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
</syntaxhighlight>

'''Terminal 3: Run the tests'''

==== Test 1: No Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Verify directories are empty
sudo ls -la /etc/ouroboros/security/client/sec.oping.tut.o7s/*
sudo ls -la /etc/ouroboros/security/server/sec.oping.tut.o7s/*

# Run first ping test
echo "=== Test 1: No Authentication, No Encryption ==="
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 1: Client initiates plaintext flow allocation'''

<syntaxhighlight lang="text">
irmd/oap(DB): [60e824383b3fbd6a] KEX config: algo=none, mode=server-encap, cipher=none.
irmd/oap(PP): OAP_HDR [60e824383b3fbd6a @ 2026-02-14 14:08:56 (UTC) ] -->
irmd/oap(PP): crt: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Cipher: <none>
irmd/oap(PP): KDF: <none>
irmd/oap(PP): Digest: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Req Hash: <none>
irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 1: Server accepts and completes handshake'''

<syntaxhighlight lang="text">
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [f1c3efe0833e2c76] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Signature: <none>
==33047== irmd(II): No certificate provided by sec.oping.tut.o7s.
==33047== reg/name(DB): Process 33198 accepting flows for sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' All OAP fields are <code><none></code> because no security is configured. Flow succeeds with plaintext communication.

==== Test 2: No Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run second ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 2: Client initiates flow with encryption enabled'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33356 to sec.oping.tut.o7s.
==33047== irmd(II): Encryption enabled for sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd(DB): Generated ephemeral keys for 33356.
==33047== irmd/oap(PP): OAP_HDR [3fa5ac1a91a23936 @ 2026-01-01 11:27:15 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 2: Server receives and responds with ephemeral key'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Generated ephemeral keys for 33198.
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [3fa5ac1a91a23936] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
==33047== irmd(II): No certificate provided by sec.oping.tut.o7s.
==33047== reg/name(DB): Process 33198 accepting flows for sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Both client and server generate ephemeral keys (91 bytes each) for encryption. No certificates because authentication is not required. Encryption and authentication are independent.

==== Test 3: With Authentication, With Encryption ====

<syntaxhighlight lang="bash">
# Install server certificates and keys
sudo cp /tmp/o7s-tut06/pki/server/certs/sec.oping.tut.o7s.crt.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/crt.pem
sudo cp /tmp/o7s-tut06/pki/server/private/sec.oping.tut.o7s.key.pem \
/etc/ouroboros/security/server/sec.oping.tut.o7s/key.pem

# enc.conf is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 3: Client initiates flow with encryption and server has certificate'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33500 to sec.oping.tut.o7s.
==33047== irmd(II): Encryption enabled for sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd(DB): Generated ephemeral keys for 33500.
==33047== irmd/oap(PP): OAP_HDR [3f89a905c0e5571b @ 2026-01-01 11:27:25 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Generated ephemeral keys for 33198.
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [3f89a905c0e5571b] -->
==33047== irmd/oap(PP): Certificate: [560 bytes]
==33047== irmd/oap(PP): Ephemeral Public Key: [91 bytes]
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 3: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Loaded peer certificate for sec.oping.tut.o7s.
==33047== irmd(DB): Certificate matches name sec.oping.tut.o7s.
==33047== irmd(DB): Got public key from certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully verified peer certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully authenticated sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Full OAP handshake with certificate (560 bytes) + ephemeral keys (91 bytes) + signature (103 bytes). Client verifies server's certificate against CA store and confirms authentication success.

==== Test 4: With Authentication, No Encryption ====

<syntaxhighlight lang="bash">
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf

# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
</syntaxhighlight>

'''IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)'''

<syntaxhighlight lang="text">
==33047== irmd(II): Allocating flow for 33642 to sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.conf does not exist.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/crt.pem does not exist.
==33047== irmd(II): No security info for sec.oping.tut.o7s.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211 @ 2026-01-01 11:27:34 (UTC) ] -->
==33047== irmd/oap(PP): Certificate: <none>
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: <none>
</syntaxhighlight>

'''IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)'''

<syntaxhighlight lang="text">
==33047== irmd(II): No certificate provided by <client>.
==33047== irmd/oap(PP): OAP_HDR [9b383e855577d211] -->
==33047== irmd/oap(PP): Certificate: [560 bytes]
==33047== irmd/oap(PP): Ephemeral Public Key: <none>
==33047== irmd/oap(PP): Data: <none>
==33047== irmd/oap(PP): Signature: [103 bytes]
</syntaxhighlight>

'''IRMd Output - Test 4: Client verifies certificate and authenticates'''

<syntaxhighlight lang="text">
==33047== irmd(DB): Loaded peer certificate for sec.oping.tut.o7s.
==33047== irmd(DB): Certificate matches name sec.oping.tut.o7s.
==33047== irmd(DB): Got public key from certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully verified peer certificate for sec.oping.tut.o7s.
==33047== irmd(II): Successfully authenticated sec.oping.tut.o7s.
</syntaxhighlight>

'''Key observations:''' Server sends certificate + signature for authentication, but NO ephemeral keys (plaintext data). Data exchanged without encryption even though authenticated. Demonstrates that authentication and encryption are independent mechanisms.

=== Stop the IRMd and tcpdump, clean up the tutorial files ===

Once all tests complete:

<syntaxhighlight lang="bash">
# Stop IRMd in Terminal 2 (Ctrl+C)
# Stop tcpdump in Terminal 1 (Ctrl+C)

# Clean up tutorial security files from system
sudo rm -f /etc/ouroboros/security/cacert/ca.tut.o7s.crt.pem
</syntaxhighlight>

== Part 2: PCAP Trace Analysis ==

After the tutorial, we now explain the trace in the tcpdump pcap file.

=== Protocol Overview ===

This section summarizes the four protocols that work together in the captured packet flow.

==== Ethernet DIX Frame with EID Header ====

Ouroboros extends the DIX frame with a flow identifier (EID - Endpoint Identifier) and length field.

{| class="wikitable"
|-
! Field !! Octets !! Size !! Description
|-
| Destination MAC || 0-5 || 6 bytes || Hardware address of destination
|-
| Source MAC || 6-11 || 6 bytes || Hardware address of source
|-
| EtherType || 12-13 || 2 bytes || Protocol identifier (0xA000 for Ouroboros)
|-
| EID || 14-15 || 2 bytes || Destination Endpoint Identifier
|-
| Length || 16-17 || 2 bytes || Payload length (needed because of runt frame padding)
|-
| Payload || 18+ || Variable || Frame data (up to MTU size)
|}

==== Ethernet Flow Allocator - Management Protocol ====

The Ethernet DIX management protocol handles flow allocation, setup, and teardown. All management frames use destination EID <code>0x0000</code>.

'''Management Frame Types:'''

{| class="wikitable"
|-
! Code !! Type !! Direction !! Service Hash !! Purpose
|-
| <code>0x00</code> || <code>FLOW_REQ</code> || Client → Server || ✓ Included || Request new flow allocation
|-
| <code>0x01</code> || <code>FLOW_REPLY</code> || Server → Client || – Not included || Respond to flow request (success/failure)
|-
| <code>0x02</code> || <code>NAME_QUERY_REQ</code> || Client → Server || ✓ Included || Query if a remote name is reachable
|-
| <code>0x03</code> || <code>NAME_QUERY_REPLY</code> || Server → Client || ✓ Included || Response to name query
|}

'''Note:''' The 32-byte service hash (SHA3-256) is appended after the management protocol header for NAME_QUERY_* and FLOW_REQ messages to identify which service is being queried or allocated. FLOW_REPLY does not include the service hash; the endpoints are already identified by the allocated EIDs (SEID/DEID) and the flow allocation ID in the OAP header (see below).

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| SEID || 0-1 || 2 bytes || Source Endpoint ID
|-
| DEID || 2-3 || 2 bytes || Destination Endpoint ID
|-
| Loss || 4-7 || 4 bytes || Acceptable packet loss (ppm)
|-
| Bandwidth || 8-15 || 8 bytes || Required bandwidth (bps)
|-
| BER || 16-19 || 4 bytes || Bit error rate (ppm)
|-
| Max Gap || 20-23 || 4 bytes || Maximum consecutive lost packets
|-
| Delay || 24-27 || 4 bytes || Maximum latency (ms)
|-
| Timeout || 28-31 || 4 bytes || Flow idle timeout (seconds)
|-
| Response || 32-35 || 4 bytes || Response code (0=success, negative=error)
|-
| In-Order || 36 || 1 byte || In-order delivery requirement (boolean)
|-
| Code || 37 || 1 byte || Message type (FLOW_REQ, FLOW_REPLY, etc.)
|-
| Availability || 38 || 1 byte || Availability status
|-
| Service hash || 39-61 || 32 bytes || SHA3-256 hash (optional, see above)
|}

==== Ouroboros Flow Allocation Protocol (OAP) ====

The Ouroboros Application Protocol (OAP) is the flow allocation and authentication protocol. It carries flow negotiation requests, responses, and authentication credentials. OAP frames are encapsulated as data payload over the management protocol.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| ID || 0-15 || 16 bytes || Unique flow allocation identifier
|-
| Timestamp || 16-23 || 8 bytes || Creation timestamp (UTC, seconds and microseconds)
|-
| Crt Length || 24-25 || 2 bytes || Certificate length (bytes)
|-
| Certificate || 26+ || Variable || X.509 certificate (DER encoded)
|-
| Eph Length || Variable || 2 bytes || Ephemeral public key length (bytes)
|-
| Ephemeral Key || Variable || Variable || ECDHE public key (DER/raw encoded)
|-
| Data Length || Variable || 2 bytes || Application data length (bytes)
|-
| Data || Variable || Variable || Piggybacked application-layer data
|-
| Sig Length || Variable || 2 bytes || Signature length (bytes)
|-
| Signature || Variable || Variable || Digital signature (ECDSA, DER encoded)
|}

==== Oping Application Protocol ====

The Ouroboros Ping (oping) application is a simple echo/reply protocol used to measure round-trip time and validate connectivity between applications. It implements a request/reply pattern similar to ICMP ping.

'''Frame Layout by Field:'''

{| class="wikitable"
|-
! Field !! Offset !! Size !! Description
|-
| Type || 0-3 || 4 bytes || Message type (ECHO_REQUEST=0 or ECHO_REPLY=1)
|-
| ID || 4-7 || 4 bytes || Sequence number / message identifier
|-
| Timestamp (seconds) || 8-15 || 8 bytes || Seconds when message was sent (CLOCK_REALTIME)
|-
| Timestamp (nanoseconds) || 16-23 || 8 bytes || Nanoseconds component of timestamp
|-
| Payload || 24+ || Variable || Application data (configurable size, default 64 bytes)
|}

'''Field Definitions:'''

* '''Type''' (4 bytes): Message type selector
** <code>0x00000000</code> (ECHO_REQUEST): Client-to-server ping request
** <code>0x00000001</code> (ECHO_REPLY): Server-to-client response

* '''ID''' (4 bytes): Sequence number for matching requests with replies. Incremented for each ping sent.

* '''Timestamp (seconds)''' (8 bytes): Network-byte-order 64-bit seconds component from when the ping was sent (CLOCK_REALTIME).

* '''Timestamp (nanoseconds)''' (8 bytes): Network-byte-order 64-bit nanoseconds component (0-999999999) for high-resolution timing.

* '''Payload''' (Variable): Application data echoed back by the server. Size is configurable (default 64 bytes, maximum 1500 bytes).

'''Usage:'''

* Client sends ECHO_REQUEST with current timestamp
* Server receives request and echoes back as ECHO_REPLY with the same ID and timestamps
* Client calculates RTT by comparing reception time with original timestamps
* Out-of-order detection by tracking sequence numbers (ID field)

=== Packet Analysis: Test 1 - No authentication/encryption ===

==== Packet 1: NAME_QUERY_REQ ====

'''Summary:''' Client sends a NAME_QUERY_REQ message to discover if the service <code>sec.oping.tut.o7s</code> is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.165639 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0002 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

==== Packet 2: NAME_QUERY_REPLY ====

'''Summary:''' Server responds to the NAME_QUERY_REQ by sending a NAME_QUERY_REPLY for the service hash.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.166073 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0000 0000 0000 0000 0000 0000 ...G............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0003 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a ..f.i.._...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0000</code> || '''SEID''' || 2 || 0x0000 || Source Endpoint ID ('''UNUSED''')
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>03</code> || '''Code''' || 1 || 0x03 || Message Type: NAME_QUERY_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code> (echoed back)
|}

==== Packet 3: FLOW_REQ ====

'''Summary:''' Client initiates a flow allocation request (FLOW_REQ) with minimal OAP headers since no authentication or encryption is being used.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:48.167222 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a51 8a56 ff6f ..f.i.._...Q.V.o
0x0050: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e103 [...}....0w.....
0x0060: 3e52 3300 0000 0000 0000 00 >R3........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || -- || '''UNUSED'''
|-
| 0x24-0x27 || <code>0001 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload'''

The OAP payload starts at offset 0x4b (after management protocol + service hash):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e103 3e52 33</code> || '''Timestamp''' || 8 || Network order || Creation timestamp (seconds + microseconds)
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 (first allocated flow ID for this session)
* Service hash is carried in management protocol payload (32 bytes)
* OAP header is minimal: only ID and timestamp, no optional fields
* No certificate, ephemeral key, data, or signature in this initial request
* Client sends minimal OAP headers with no authentication or encryption setup at allocation time

==== Packet 4: FLOW_REPLY ====

'''Summary:''' Server responds to FLOW_REQ by sending FLOW_REPLY with a new DEID (destination endpoint ID 0x0041) to establish the allocated flow for data transfer.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:49.178732 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 89:
0x0000: 0000 0047 0041 0040 0000 0000 0000 0000 ...G.A.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0051 8a56 ff6f ...........Q.V.o
0x0030: 5ba6 9d03 7da1 cfc3 0f30 7718 86a8 e13f [...}....0w....?
0x0040: a347 3800 0000 0000 0000 00 .G8........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0047</code> || '''Length''' || 2 || 71 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server-side flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0|| Response code (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload'''

The OAP payload starts at offset 0x2b (no service hash in FLOW_REPLY):

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77</code> || '''ID''' || 16 || 128-bit identifier || Echo of client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e13f a347 38</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || No ephemeral key
|-
| 0x47-0x48 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x49-0x4a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0041 is the newly allocated server-side flow endpoint
* DEID 0x0040 reflects the client's flow ID, creating a bidirectional mapping
* No service hash included (FLOW_REPLY only needs the EIDs to identify the flow)
* OAP echoes the client's ID and timestamp, confirming the flow allocation
* Response code 0x00000000 indicates success
* Both client and server now have their respective flow IDs (0x0040 and 0x0041) for data transfer
* Response code 0x00000000 indicates success

==== Packet 5: ECHO_REQUEST - Plaintext Data ====

'''Summary:''' Client sends an oping ECHO_REQUEST packet to the server using the allocated flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.180824 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 7377 0000 .A.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Source Endpoint ID (server → client)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REQUEST Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number (first ping)
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Seconds component
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Nanoseconds component
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (default 64 bytes total - 24 byte header = 40 bytes data)
|}

'''Key observations:'''
* EID 0x0041 shows traffic from server-side flow ID
* This is the first ping request (ID = 0x00000000)
* Timestamp captures when the ping was sent (seconds in network order)
* Default oping payload is 64 bytes total; 24 bytes header + 40 bytes data

==== Packet 6: ECHO_REPLY - Plaintext Data ====

'''Summary:''' Server receives the ECHO_REQUEST and immediately sends back an ECHO_REPLY with the same ID and timestamps, echoing the client's message.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:50.181496 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 7377 0000 .@.@........sw..
0x0010: 0000 0000 b03e e007 0000 0000 0000 0000 .....>..........
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client ← server)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Oping payload length
|}

'''Oping Application Protocol - ECHO_REPLY Payload'''

The oping payload starts at offset 0x04:

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>7377 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || 0x0000000000003773 || Echo of original seconds
|-
| 0x14-0x1b || <code>b03e e007 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || 0x0000000007e03eb0 || Echo of original nanoseconds
|-
| 0x1c-0x43 || <code>0000 0000 ... 0000 0000</code> || '''Payload''' || 40 || All zeros || Echo data (unchanged from request)
|}

'''Key observations:'''
* EID 0x0040 shows traffic from client-side flow ID receiving the reply
* Type field changed from 0x00000000 (REQUEST) to 0x00000001 (REPLY)
* ID, timestamps, and payload data are identical to the request (echoed back)
* Round-trip time can be calculated by comparing current time with echoed timestamp
* Ping succeeded on first attempt with minimal latency (~1 millisecond between timestamps)

=== Packet Analysis: Test 2 - No authentication, with encryption ===

==== Packet 7: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with encryption enabled. This FLOW_REQ carries an OAP header with an ephemeral ECDHE P-384 public key (91 bytes) for encryption setup.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.808158 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8af1 766b 547c ..f.i.._....vkT|
0x0050: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0060: 8b6c 9000 0000 5b30 5930 1306 072a 8648 .l....[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 c508 1c19 6106 b7e9 3074 57b9 bb16 ......a...0tW...
0x0090: 6959 4a55 81f9 169b cc79 fe10 a882 41fe iYJU.....y....A.
0x00a0: 0697 c9b4 f8f0 5562 7fa2 c7a0 a020 1ac6 ......Ub........
0x00b0: 939f 23ff b2fb 07a2 b747 aacc 474a 3dab ..#......G..GJ=.
0x00c0: 2598 0000 0000 %.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Mixed || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 ... 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e253 8b6c 90</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 ... 3dab 2598</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || ECDHE P-384 public key (DER encoded)
|-
| 0xd3-0xd4 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd5-0xd6 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* Encryption enabled: ephemeral key present (91 bytes)
* Client sends no certificate, allowing anonymous encryption setup
* No signature (unsigned OAP)
* Ephemeral key is ECDHE P-384 for key exchange

==== Packet 8: FLOW_REPLY ====

'''Summary:''' Server accepts the encrypted flow allocation request. FLOW_REPLY contains the server's ephemeral key but no certificate (since client didn't send one).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:53.810564 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 180:
0x0000: 0000 00a2 0042 0040 0000 0000 0000 0000 .....B.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 00f1 766b 547c ............vkT|
0x0030: fcb0 8fce 5d60 a01e e8be 0218 86a8 e253 ....]`.........S
0x0040: b694 e800 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0050: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0060: 0004 5f3c 6929 cca2 024a ae9f 9aa1 dfc2 .._<i)...J......
0x0070: a493 3ff3 ff58 b054 74dc d2e2 47fc 7c5b ..?..X.Tt...G.|[
0x0080: eff5 e129 72b4 de1e 7c09 bf8c fe38 5e8b ...)r...|....8^.
0x0090: b22e 59ed 6eb9 dfda 369d 691e 6e2c 122c ..Y.n...6.i.n,.,
0x00a0: 9936 0000 0000 .6....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00a2</code> || '''Length''' || 2 || 162 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0042</code> || '''SEID''' || 2 || 0x0042 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 || '''UNUSED'''
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 || '''UNUSED'''
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 || '''UNUSED'''
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>f1 766b 547c fcb0 8fce 5d60 a01e e8be 02</code> || '''ID''' || 16 || Echo of client ID || Echoes client's flow ID
|-
| 0x3b-0x42 || <code>18 86a8 e253 b694 e8</code> || '''Timestamp''' || 8 || Network order || Echoed timestamp
|-
| 0x43-0x44 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate
|-
| 0x45-0x46 || <code>005b</code> || '''Eph_len''' || 2 || 0x005b (91) || Ephemeral key length: 91 bytes
|-
| 0x47-0xa1 || <code>30 5930...9936</code> || '''Ephemeral Key''' || 91 || ECDHE P-384 || Server's ECDHE P-384 public key (DER encoded)
|-
| 0xd1-0xd2 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xd3-0xd4 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID 0x0042 is the new server-side flow endpoint
* Both keys are now exchanged; client and server can derive shared secret
* No authentication (no certificates) but encryption is negotiated
* Response indicates successful allocation

==== Packet 9: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after encryption keys are established. The payload is encrypted with the derived shared secret.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.815771 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0042 0060 a691 6d83 8446 cbeb ac95 c2eb .B.`..m..F......
0x0010: 4b42 e819 c67f 92c8 58d7 0641 d8a6 6e1f KB......X..A..n.
0x0020: fc90 feed ef55 b791 4fbd a832 74bd 8bed .....U..O..2t...
0x0030: 249c 4cee 0fc0 cec6 2f1b aec1 2428 bdbd $.L...../...$(..
0x0040: 36b5 01b5 1257 004e 6ed6 7ecd f0c7 7d11 6....W.Nn.~...}.
0x0050: 20ba e81b f43a 4de9 b141 1624 e1ba 0a84 .....:M..A.$....
0x0060: 74b1 9a9a t...
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0042</code> || '''EID''' || 2 || 0x0042 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REQUEST (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>a691 6d83 8446 cbeb...74b1 9a9a</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* All 96 bytes of oping data (type, ID, timestamps, payload) are encrypted
* No plaintext oping headers visible; entire packet is ciphertext
* Flow IDs (0x0042) identify which encryption context to use
* Ping still works with encryption transparently

==== Packet 10: Encrypted ECHO_REPLY ====

'''Summary:''' Server receives encrypted ping request, decrypts it, and sends encrypted ECHO_REPLY.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:54.819574 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 c6ea 2222 5618 0268 b27e 9a91 .@.`..""V..h.~..
0x0010: f124 1f8d bccc 478c 26fe 9b13 b3cb 5398 .$....G.&.....S.
0x0020: 6869 3cdb 4928 510d 4de8 dc6a 3f3a 6a6d hi<.I(Q.M..j?:jm
0x0030: 6487 dcd8 c8cd 1a85 fba2 9ecd 3566 57d1 d...........5fW.
0x0040: 1c94 ac35 518e 8509 873a 3a5e 04d9 8ee2 ...5Q....::^....
0x0050: 9d74 2527 e425 5433 9d73 9ccd f56a 1f8d .t%'.%T3.s...j..
0x0060: f328 7237 .(r7
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0060</code> || '''Length''' || 2 || 96 bytes || Encrypted payload length
|}

'''Oping Application Protocol - ECHO_REPLY (Encrypted)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x63 || <code>c6ea 2222 5618 0268...f328 7237</code> || '''Encrypted Data''' || 96 || Ciphertext || All 96 bytes encrypted
|}

'''Key observations:'''
* EID 0x0040 shows reply going back to client-side flow
* Ciphertext is different from request (different plaintext: type field differs)
* Both encrypted packets are 96 bytes (same size as Packet 9)
* Client receives encrypted reply, decrypts it, verifies ID and timestamps match request
* Encryption is transparent at application layer: oping works exactly as with plaintext flows

=== Packet Analysis: Test 3 - Authentication and encryption ===

==== Packet 11: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation request with encryption enabled. Sends ephemeral public key for ECDHE key exchange but no certificate (client is not authenticating in this tutorial). The management protocol now carries a valid allocated SEID (0x0040).

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:58.827411 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 212:
0x0000: 0000 00c2 0040 0000 0000 0001 0000 0000 .....@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a66 bb82 95fa ..f.i.._...f....
0x0050: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0060: c0d2 ad00 0000 5b30 5930 1306 072a 8648 ......[0Y0...*.H
0x0070: ce3d 0201 0608 2a86 48ce 3d03 0107 0342 .=....*.H.=....B
0x0080: 0004 9dea c238 6732 4987 1cd4 7133 9614 .....8g2I...q3..
0x0090: 9d04 4fde 3f68 42f1 54fb 7ef3 88d0 ffe6 ..O.?hB.T.~.....
0x00a0: 7e01 432e 56c2 2d64 72c9 19fc b0cf 1eca ~.C.V.-dr.......
0x00b0: 689e 3536 771a 8041 726c 20e2 d9bb 3589 h.56w..Arl....5.
0x00c0: 86e7 0000 0000 ......
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>00c2</code> || '''Length''' || 2 || 194 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (client flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || Destination Endpoint ID ('''UNUSED''')
|-
| 0x08-0x23 || <code>0000 ... d4c0</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || Response code ('''UNUSED''')
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>00</code> || '''Code''' || 1 || 0x00 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ... 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier for Test 3
|-
| 0x5b-0x62 || <code>18 86a8 e37e c0d2 ad</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || Client not authenticating
|-
| 0x65-0x66 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Ephemeral public key length: 91 bytes
|-
| 0x67-0xc1 || <code>30 5930 1306 ... 3589</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Client's ephemeral ECDHE public key for encryption negotiation
|-
| 0xc2-0xc3 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0xc4-0xc5 || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* SEID is 0x0040 - Same as Test 2 (Encrypted) because this is the same client session reusing the same allocated ID from the previous test
* No Certificate - <code>crt_len = 0x0000</code> because the client does not have authentication credentials; the server will authenticate instead
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> because encryption is enabled on the client
* No Signature - <code>sig_len = 0x0000</code> because client is not signing (no certificate to sign with)
* FLOW_REQ Message Type - Code field is 0x00, and service hash is present because FLOW_REQ always includes the service hash
* Timestamp Consistency - Same OAP ID and timestamp structure as Test 2, but with additional security handshake

==== Packet 12: FLOW_REPLY ====

'''Summary:''' Server responds to client's FLOW_REQ by sending FLOW_REPLY with its certificate for authentication, ephemeral public key for ECDHE encryption setup, and a digital signature proving ownership of the certificate. This is the full authentication response.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:39:58.828806 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 843:
0x0000: 0000 0339 0043 0040 0000 0000 0000 0000 ...9.C.@........
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 0066 bb82 95fa ...........f....
0x0030: 91a2 7bd3 bd60 1b3e 35f6 b918 86a8 e37e ..{..`.>5......~
0x0040: d566 a002 2f30 8202 2b30 8201 b2a0 0302 .f../0..+0......
(... certificate and signature bytes ...)
0x0320: ef11 c358 f5d0 5cd7 3906 adf1 8a2c 9b25 ...X..\.9....,.%
0x0330: dc78 6050 ab61 3a3f 81c0 254b d193 7827 .x`P.a:?..%K..x'
0x0340: c0e9 38c7 e0d1 c517 d299 9992 07 ..8..........
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0339</code> || '''Length''' || 2 || 825 bytes || Total payload length (excluding DIX header)
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0043</code> || '''SEID''' || 2 || 0x0043 || Source Endpoint ID (server-side allocated flow ID)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client's flow ID from FLOW_REQ)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || Default values || QoS parameters
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (echoed back)
|-
| 0x3b-0x42 || <code>18 86a8 e37e d566 a0</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>022f</code> || '''Crt_len''' || 2 || 559 (0x022f) || Server certificate length: 559 bytes
|-
| 0x45-0x243 || <code>2f30 8202 2b ... 81c8 30</code> || '''Certificate''' || 559 || DER-encoded X.509 || Server's certificate (signed by intermediate CA)
|-
| 0x244-0x245 || <code>005b</code> || '''Eph_len''' || 2 || 91 (0x005b) || Server's ephemeral public key length: 91 bytes
|-
| 0x246-0x2a0 || <code>30 5930 1306 ... 9936</code> || '''Ephemeral Key''' || 91 || ECDP-384 public key || Server's ephemeral ECDHE public key
|-
| 0x2a4-0x2a5 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x2a6-0x2a7 || <code>0068</code> || '''Sig_len''' || 2 || 104 (0x0068) || Digital signature length: 104 bytes
|-
| 0x2a8-0x30f || <code>30 6602 3100 ... 07</code> || '''Signature''' || 104 || ECDSA signature (DER encoded) || Server's signature over OAP header proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0043 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from the FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Full Certificate - <code>crt_len = 0x022f (559)</code> carrying server's complete X.509 certificate signed by intermediate CA
* Ephemeral Key Present - <code>eph_len = 0x005b (91)</code> with server's ECDHE public key for encryption
* Signature Included - <code>sig_len = 0x0068 (104)</code> containing ECDSA digital signature over the entire OAP header
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ to confirm association (included in signature, binding response to this specific client request)
* Large Payload - Total of 825 bytes due to certificate (559) + ephemeral key (91) + signature (104) + overhead
* Authentication Complete - Client verifies: (1) certificate against CA store, (2) signature over entire response ensures authenticity and integrity, (3) echoed ID binds response to this specific request, (4) timestamp prevents replay attacks

'''Summary:''' Server responds with its certificate for authentication, ephemeral public key for ECDHE encryption, and a digital signature proving ownership of the certificate.

==== Packet 13: Encrypted ECHO_REQUEST ====

'''Summary:''' Client sends encrypted ping request after authentication handshake. All application data is protected by encryption using the ephemeral keys established in Packets 11-12.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836485 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0043 0060 3bed 0b48 1be1 6930 cf3d dee9 .C.`.;..H..i0.=..
0x0010: 4fc9 774b 5d63 cc9b 5a34 6604 f9ac 1016 O.wK]c..Z4f.....
0x0020: 1c6d c9ac f80e dc89 31c1 9634 1a4f b2c7 .m......1..4.O..
0x0030: 4721 e402 8259 b0aa 8870 4566 33d1 9c18 G!...Y.. .pEf3...
0x0040: 06da 50c3 8b75 86b0 f240 d109 840e a6cd ..P..u...@......
0x0050: d115 77cb 5652 5bfb e6d5 0ca9 dbc3 d0b8 ..w.VR[.........
0x0060: 0058 fd19 .X..
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0043</code> || Client flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REQUEST data'''
|}

'''Key observations:'''
* No visible protocol structure - all application data appears as ciphertext
* Uses the same source/destination EID pair (0x0043 → 0x0060) established in the FLOW_REQ/FLOW_REPLY handshake
* Encryption is done using the ephemeral key (91 bytes) exchanged in Packet 11's OAP header
* Unlike Packets 11-12, this packet contains no certificate, public keys, or signatures
* The 110-byte encrypted data corresponds to the original oping ECHO_REQUEST message

==== Packet 14: Encrypted ECHO_REPLY ====

'''Summary:''' Server sends encrypted ping reply. Note that the flow identifiers swap, demonstrating bidirectional encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:39:59.836930 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 114:
0x0000: 0040 0060 d552 e100 e681 940c e35a 07d0 .@.`..........Z..
0x0010: a293 1d73 33a5 854e 0fce 4f4d 6655 267a ...s3..N..OMfU&z
0x0020: 3de2 663b 709d 739a a696 2ddd 7b34 28b8 =.f;p.s...-{4(...
0x0030: 5a98 eec2 52c6 4288 3885 ae16 e466 4181 Z...R.B.8...fA..
0x0040: f2d6 44c1 b51b 8728 58a4 7525 fb5e 3fd6 ..D...(X.u%.^?..
0x0050: 7e49 532a d2a5 bea7 55e9 c274 f1b2 0412 ~IS*....U..t....
0x0060: 73d4 6436 s.d6
</syntaxhighlight>

'''Ethernet DIX Frame Analysis:'''

{| class="wikitable"
|-
! Field !! Offset !! Length !! Value !! Description
|-
| Source EID || 0x00-0x01 || 2 bytes || <code>0x0040</code> || Client's inbound flow endpoint ID
|-
| Destination EID || 0x02-0x03 || 2 bytes || <code>0x0060</code> || Server flow endpoint ID
|-
| '''Encrypted Payload''' || '''0x04-0x71''' || '''110 bytes''' || '''Ciphertext''' || '''AES-encrypted oping ECHO_REPLY data'''
|}

'''Key observations:'''
* The EID in offset 0x00 is now 0x0040 (server's view of client's inbound flow)
* Uses the same ephemeral key material as Packet 13, but encryption direction is reversed
* Both packets use AES-GCM with keys derived from the ECDH exchange
* Timestamp 17:39:59.836930 is only 445 microseconds after Packet 13, indicating server-side processing
* The 110-byte encrypted ECHO_REPLY payload is the same size as the request
* All application data is protected by both authentication (X.509 + ECDSA) and encryption (AES)

=== Packet Analysis: Test 4 - Authentication, no encryption ===

==== Packet 15: FLOW_REQ ====

'''Summary:''' Client initiates flow allocation with authentication enabled but encryption disabled. This FLOW_REQ carries an OAP header but '''no ephemeral key''' since the client does not request encrypted communication.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:03.413372 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 121:
0x0000: 0000 0067 0040 0000 0000 0001 0000 0000 ...g.@..........
0x0010: 0000 0000 0000 0001 ffff ffff ffff ffff ................
0x0020: 0001 d4c0 0000 0000 0000 00ec f815 ad98 ................
0x0030: 3df6 bf81 fdc7 cb63 6eec 1563 6e60 5a94 =......cn..cn`Z.
0x0040: b1ad 66c1 690c 9e5f 9282 8a8f a6ab 6ea7 ..f.i.._........
0x0050: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0060: 0de6 6100 0000 0000 0000 00 ..a.....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>0067</code> || '''Length''' || 2 || 103 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0040</code> || '''SEID''' || 2 || 0x0040 || Source Endpoint ID (allocated flow ID)
|-
| 0x06-0x07 || <code>0000</code> || '''DEID''' || 2 || 0x0000 || '''UNUSED'''
|-
| 0x08-0x23 || <code>0000 ... dc40</code> || '''QoS (Various)''' || 28 || Mixed ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0 || '''UNUSED'''
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REQ
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|-
| 0x2b-0x4a || <code>ec f815 ad98 3df6 bf81...9282 8a</code> || '''Service Hash''' || 32 || SHA3-256 || Hash of <code>sec.oping.tut.o7s</code>
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x4b-0x5a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa</code> || '''ID''' || 16 || 128-bit identifier || Unique flow allocation identifier
|-
| 0x5b-0x62 || <code>18 86a8 e490 0de6 61</code> || '''Timestamp''' || 8 || Network order || Creation timestamp
|-
| 0x63-0x64 || <code>0000</code> || '''Crt_len''' || 2 || 0x0000 || No certificate in client request
|-
| 0x65-0x66 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key (no encryption)'''
|-
| 0x67-0x68 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x69-0x6a || <code>0000</code> || '''Sig_len''' || 2 || 0x0000 || No signature
|}

'''Key observations:'''
* No encryption enabled: ephemeral key absent (Eph_len = 0x0000)
* Client requests authentication only
* Server will respond with certificate + signature but no ephemeral key
* Packet is minimal compared to Packet 11 (Test 3) which includes 91-byte ephemeral key

==== Packet 16: FLOW_REPLY ====

'''Summary:''' Server accepts the authenticated (but not encrypted) flow allocation request. FLOW_REPLY contains the server's X.509 certificate and ECDSA signature for client authentication, but '''no ephemeral key''' since encryption is not being used.

'''Raw Data (abbreviated):'''

<syntaxhighlight lang="text">
17:40:03.416675 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 751:
0x0000: 0000 02dd 0041 0040 0000 0000 0000 0000 .......A.@......
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0001 008f a6ab 6ea7 ................
0x0030: ef89 68e1 ed1e 2ede 0919 fa18 86a8 e490 .h..............
0x0040: 3754 a702 2f30 8202 2b30 8201 b2a0 0302 7T../0..+0......
0x0050: 0102 0202 1000 300a 0608 2a86 48ce 3d04 ......0...*.H.=.
(... certificate and signature bytes ...)
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0000</code> || '''EID''' || 2 || 0x0000 || Destination Endpoint ID (management channel)
|-
| 0x02-0x03 || <code>02dd</code> || '''Length''' || 2 || 733 bytes || Total payload length
|}

'''Ethernet Flow Allocator - Management Protocol'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x05 || <code>0041</code> || '''SEID''' || 2 || 0x0041 || Source Endpoint ID (allocated server flow)
|-
| 0x06-0x07 || <code>0040</code> || '''DEID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x08-0x23 || <code>0000 ... 0000</code> || '''QoS (Various)''' || 28 || 0 ||
|-
| 0x24-0x27 || <code>0000 0000</code> || '''Response''' || 4 || 0x00000000 || Response code: 0 (success)
|-
| 0x28 || <code>00</code> || '''QoS (In-Order)''' || 1 || 0 ||
|-
| 0x29 || <code>01</code> || '''Code''' || 1 || 0x01 || Message Type: FLOW_REPLY
|-
| 0x2a || <code>00</code> || '''QoS (Availability)''' || 1 || 0x00 ||
|}

'''Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x2b-0x3a || <code>8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919</code> || '''ID''' || 16 || 128-bit identifier || '''Same ID as client's FLOW_REQ''' (Packet 15 echoed back)
|-
| 0x3b-0x42 || <code>fa18 86a8 e490 3754</code> || '''Timestamp''' || 8 || Network order || Server's timestamp
|-
| 0x43-0x44 || <code>a702</code> || '''Crt_len''' || 2 || 0x02a7 (679 decimal) || '''Certificate length: 679 bytes'''
|-
| 0x45-0x270 || <code>2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ...</code> || '''Certificate''' || 679 || DER-encoded X.509 || Server's certificate signed by intermediate CA
|-
| 0x271-0x272 || <code>0000</code> || '''Eph_len''' || 2 || 0x0000 || '''No ephemeral key''' (no encryption)
|-
| 0x273-0x274 || <code>0000</code> || '''Data_len''' || 2 || 0x0000 || No application data
|-
| 0x275-0x276 || <code>0067</code> || '''Sig_len''' || 2 || 0x0067 (103 decimal) || '''ECDSA signature length: 103 bytes'''
|-
| 0x277-0x2dd || <code>3065 0230 75dc 5717 ... 83</code> || '''Signature''' || 103 || ECDSA signature (DER encoded) || Server's ECDSA signature proving certificate ownership
|}

'''Key observations:'''
* SEID is 0x0041 - New server-side endpoint ID allocated for this authenticated flow
* DEID is 0x0040 - Client's flow ID from Packet 15 FLOW_REQ, establishing the bidirectional flow
* FLOW_REPLY Message Type - Code field is 0x01, '''no service hash''' (already identified in FLOW_REQ)
* Certificate Field - <code>crt_len = 0x02a7 (679)</code> carrying server's X.509 certificate signed by intermediate CA
* Separate Signature Field - <code>sig_len = 0x0067 (103)</code> with ECDSA signature over entire OAP header
* No Ephemeral Key - <code>eph_len = 0x0000</code> since encryption is '''not''' being used in Test 4
* Same OAP ID - Server echoes back the exact ID from client's FLOW_REQ (included in signature, binding response to this specific client request)
* Complete OAP Structure - Full OAP header with all standard fields, just without ephemeral key data
* Plaintext Data Exchange - After this FLOW_REPLY, all subsequent application data will be transmitted in plaintext (but authenticated via certificate + signature verification)

==== Packet 17: ECHO_REQUEST ====

'''Summary:''' Client sends plaintext ECHO_REQUEST data through the authenticated (but unencrypted) flow. The oping application's ping request is transmitted directly without encryption, relying on the earlier certificate+signature authentication for security.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.419664 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0041 0040 0000 0000 0000 0000 8177 0000 .A.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0041</code> || '''EID''' || 2 || 0x0041 || Destination Endpoint ID (server flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Request (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0000</code> || '''Type''' || 4 || 0x00000000 || Message type: ECHO_REQUEST
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Sequence number / message identifier
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Seconds component from CLOCK_REALTIME
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Nanoseconds component (0-999999999)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0041 → Server Flow - Data is directed to the server's endpoint ID allocated in Packet 16 FLOW_REPLY
* Plaintext Transmission - No encryption layer; oping payload is sent as-is (compare to Packet 13 which had encryption)
* Authenticated Flow - Although plaintext, this data travels on the authenticated flow established in Packet 16 (certificate + signature verified)
* Type = ECHO_REQUEST - 0x00000000 indicates client-to-server ping request
* ID = 0 - Sequence number for matching request/reply pairs
* Test 4 Characteristic - Demonstrates authenticated communication '''without''' encryption; application data is readable but cryptographically bound to the authenticated flow
* Contrast to Test 3 - Packet 13 (Test 3 encrypted ECHO_REQUEST) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

==== Packet 18: ECHO_REPLY ====

'''Summary:''' Server responds with plaintext ECHO_REPLY data, echoing back the client's request. This confirms successful bidirectional communication over the authenticated (but unencrypted) flow.

'''Raw Data:'''

<syntaxhighlight lang="text">
17:40:04.420088 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype Unknown (0xa000), length 82:
0x0000: 0040 0040 0000 0001 0000 0000 8177 0000 .@.@............
0x0010: 0000 0000 aa16 1c16 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0040: 0000 0000 ....
</syntaxhighlight>

'''Ethernet DIX Frame with EID Header'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x00-0x01 || <code>0040</code> || '''EID''' || 2 || 0x0040 || Destination Endpoint ID (client flow)
|-
| 0x02-0x03 || <code>0040</code> || '''Length''' || 2 || 64 bytes || Total application data length
|}

'''Application Data - Oping Echo Reply (Plaintext)'''

{| class="wikitable"
|-
! Offset !! Hex !! Field !! Size !! Value !! Notes
|-
| 0x04-0x07 || <code>0000 0001</code> || '''Type''' || 4 || 0x00000001 || Message type: ECHO_REPLY
|-
| 0x08-0x0b || <code>0000 0000</code> || '''ID''' || 4 || 0x00000000 || Echo of request sequence number
|-
| 0x0c-0x13 || <code>8177 0000 0000 0000</code> || '''Timestamp (seconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (seconds)
|-
| 0x14-0x1b || <code>aa16 1c16 0000 0000</code> || '''Timestamp (nanoseconds)''' || 8 || Network-byte-order 64-bit || Echoed request timestamp (nanoseconds)
|-
| 0x1c-0x43 || <code>0000 ... 0000</code> || '''Payload''' || 40 || Application data || Echoed probe payload (zero-filled for 64 bytes total)
|}

'''Key observations:'''
* EID Pair: 0x0040 → Client Flow - Server responds to client's endpoint ID from Packet 15 FLOW_REQ
* Type = ECHO_REPLY - 0x00000001 indicates server-to-client response
* ID = 0 - Echoes the request sequence number, matching this response to the request
* Timestamps Echo Request - Both timestamp fields are copied from Packet 17 unchanged (8177 0000 0000 0000 and aa16 1c16 0000 0000)
* Plaintext Reply - No encryption; server's response payload is readable (compare to Packet 14 which had encryption)
* Authenticated Channel - Although plaintext, this reply is part of the authenticated flow; client can verify integrity through earlier certificate+signature
* Test 4 Completion - Demonstrates '''full bidirectional plaintext communication''' over an authenticated (but unencrypted) flow
* Contrast to Test 3 - Packet 14 (Test 3 encrypted ECHO_REPLY) was 114 bytes with ciphertext; this packet is 82 bytes of plaintext
* Total Payload - 64 bytes total (4 + 4 + 8 + 8 + 40 bytes payload)

Rumba

2026-01-18T10:07:51Z

Dimitri: /* Install Rumba */

{{Under construction}} (see https://ouroboros.rocks/docs/tools/rumba/)

Rumba is a Python framework for setting up Ouroboros and RINA networks in a test environment that was developed during the [[History of Ouroboros#2016:_ARCFIRE_and_the_start_of_Ouroboros | ARCFIRE]] project. Its main objectives are to configure networks and to evaluate the impact of the architecture on configuration management and devops in computer and telecommunications networks. The original Rumba project page is [https://gitlab.com/ARCFIRE/Rumba here].

Rumba can quickly set up test networks for Ouroboros that are made up of many IPCPs and Layers. We keep a version on this site up-to-date with the Ouroboros prototype.

== Features ==

* easily define network topologies

* Support for different prototypes:
** Ouroboros<ref>Only Ouroboros is maintained in our git clone, it may not work anymore with rlite and IRATI.</ref>
** rlite
** IRATI

* create these networks using different possible environments:
** local PC (Ouroboros only)
** docker container
** virtual machine (qemu)
** [https://jfed.ilabt.imec.be/ jFed] testbeds

* script experiments

* rudimentary support for drawing these networks (using pydot)

== Install Rumba ==
We forked Rumba with the Ouroboros website, and you should get this forked version for use with Ouroboros.
It should work with most python versions, but I recommend using a recent version (currently >= Python3.9).

git clone https://ouroboros.rocks/git/rumba
cd rumba
# Recommended: create/enter python virtual environment (e.g. the same created for [[Ouroboros Metrics|InfluxDB & grafana]]), or to create one:
python -m venv ./venv
source venv/bin/activate
pip install --upgrade pip
# If not, then it will install system-wide (use sudo in that case)
pip install .
# OR, if you want all 3 extra features
pip install ".[NumpyAcceleration,graphs,visualizer]"

== Use Rumba ==
The Rumba model is heavily based on [[RINA]] terminology (since it was originally developed within a RINA research project). We will probably align the terminology in Rumba with Ouroboros in the near future. I will break down a typical Rumba experiment definition and show how to use Rumba in Python interactive mode. You can download the complete example experiment definition [https://{{SERVERNAME}}/docs/tools/rumba_example.py here]. The example uses the Ouroboros prototype, and we will run the setup on the local testbed since that is available on any machine and doesn’t require additional dependencies. We use the local testbed a lot for quick development testing and debugging. I will also show the experiment definition for the virtual wall server testbed at Ghent University as an example for researchers who have access to this testbed. If you have docker or qemu installed, feel free to experiment with these at your leisure.

If you want to test Ouroboros locally (no docker/qemu), then the only example script you can run without modification is:
python3 examples/scalingtime.py --prototype ouroboros local

==Notes==
<references />

Ouroboros Protocols

2026-01-08T20:54:14Z

Dimitri: /* Flow Allocation Protocol */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]

/*
* 0 1 2 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | | |
* + + |
* | | |
* + id (128 bits) + |
* | Unique flow allocation ID | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | | |
* + timestamp (64 bits) + |
* | UTC nanoseconds since epoch | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | crt_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + certificate (variable) + |
* | X.509 certificate, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* |F|R| kex_len (14 bits) | | | Signed
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | | Region
* + kex_data (variable) + |
* | public key (DER/raw) or ciphertext (KEM) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | cipher_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + cipher (variable) + |
* | symmetric cipher name (UTF-8) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | data_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + data (variable) + |
* | Piggybacked application data | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | sig_len (16 bits) | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
* | |
* + signature (variable) +
* | DSA signature over signed region |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*
* kex_len field bit layout:
* F (bit 15): Format - 0 = X.509 DER, 1 = Raw/Hybrid
* R (bit 14): Role - 0 = Server encaps, 1 = Client encaps
* (R is ignored for non-KEM algorithms)
* Bits 0-13: Length (0-16383 bytes)
*/
The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Ouroboros Protocols

2026-01-08T20:38:21Z

Dimitri: /* Flow Allocation Protocol */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]

/*
* 0 1 2 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | | |
* + + |
* | | |
* + id (128 bits) + |
* | Unique flow allocation ID | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | | |
* + timestamp (64 bits) + |
* | UTC nanoseconds since epoch | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | crt_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + certificate (variable) + |
* | X.509 certificate, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | kex_len (16 bits) | | | Signed
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | | Region
* + kex_data (variable) + |
* | public key, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | cipher_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + cipher (variable) + |
* | symmetric cipher name (UTF-8) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | data_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + data (variable) + |
* | Piggybacked application data | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | sig_len (16 bits) | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
* | |
* + signature (variable) +
* | DSA signature over signed region |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Ouroboros Protocols

2026-01-08T20:37:57Z

Dimitri: /* Flow Allocation Protocol */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]

/*
* 0 1 2 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | | |
* + + |
* | | |
* + id (128 bits) + |
* | Unique flow allocation ID | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | | |
* + timestamp (64 bits) + |
* | UTC nanoseconds since epoch | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | crt_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + certificate (variable) + |
* | X.509 certificate, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | kex_len (16 bits) | | | Signed
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | |
* + kex_data (variable) + |
* | public key, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | cipher_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + cipher (variable) + |
* | symmetric cipher name (UTF-8) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | data_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + data (variable) + |
* | Piggybacked application data | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | sig_len (16 bits) | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
* | |
* + signature (variable) +
* | DSA signature over signed region |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Ouroboros Protocols

2026-01-08T20:36:16Z

Dimitri: /* Flow Allocation Protocol */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | |
+ + |
| | |
+ id (128 bits) + |
| Unique flow allocation ID | |
+ + |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ timestamp (64 bits) + |
| UTC nanoseconds since epoch | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| crt_len (16 bits) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
| | |
+ + |
| certificate (variable) | |
+ X.509 certificate, DER encoded + |
| | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | eph_len (16 bits) | | Signed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Region
| | |
+ + |
| ephemeral_key (variable) | |
+ public key, DER encoded + |
| | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | data_len (16 bits) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ data (variable) + |
| Piggybacked application data | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | sig_len (16 bits) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| |
+ +
| signature (variable) |
+ DSA signature over signed region +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Ouroboros Protocols

2026-01-08T20:35:46Z

Dimitri: /* Data Transfer Protocol */

{{Under construction}}

The protocols in Ouroboros are designed with strong adherence to the principles of [https://en.wikipedia.org/wiki/Separation_of_concerns separation of concerns] and [https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy separation of mechanism and policy] in mind to prevent network ossification and protocol ossification from occuring.

There are 5 core protocols in Ouroboros.

== Data Transfer Protocol ==
Main page: [[Ouroboros Data Transfer Protocol]]

The Data Transfer Protocol resides in the [[Ouroboros Functional Layering|network forwarding layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .
</syntaxhighlight>

== Flow and Retransmission Control Protocol ==
Main page: [[Flow and Retransmission Control Protocol]]

The Flow and Retransmission Control Protocol resides in the [[Ouroboros Functional Layering|application end-to-end layer]].

<syntaxhighlight>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

== Flow Allocation Protocol ==
Main page: [[Ouroboros Flow Allocation Protocol]]
<pre>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | |
+ + |
| | |
+ id (128 bits) + |
| Unique flow allocation ID | |
+ + |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ timestamp (64 bits) + |
| UTC nanoseconds since epoch | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| crt_len (16 bits) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
| | |
+ + |
| certificate (variable) | |
+ X.509 certificate, DER encoded + |
| | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | eph_len (16 bits) | | Signed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Region
| | |
+ + |
| ephemeral_key (variable) | |
+ public key, DER encoded + |
| | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | data_len (16 bits) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ data (variable) + |
| Piggybacked application data | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | sig_len (16 bits) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| |
+ +
| signature (variable) |
+ DSA signature over signed region +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>

The Flow Allocation Protocol resides in the [[Ouroboros Functional Layering|network end-to-end layer]].

A comparison with TLS 1.3 (generated by Claude Opus 4.5 based on the O7s codebase): [[Flow Allocation vs TLS]]

== Connection Establishment Protocol ==
Main page: [[Ouroboros Connection Establishment Protocol]]

== Enrollment Protocol ==
Main page: [[Ouroboros Enrolment Protocol]]

The Enrollment protocol is best seen as one of the application protocols for IPCPs.

Ouroboros Flow Allocation Protocol

2026-01-07T00:02:49Z

Dimitri: /* Header */

{{Under construction}}

= Header =

<pre>
OAP Header Structure
====================

/*
* 0 1 2 3
* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | | |
* + + |
* | | |
* + id (128 bits) + |
* | Unique flow allocation ID | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | | |
* + timestamp (64 bits) + |
* | UTC nanoseconds since epoch | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | crt_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + certificate (variable) + |
* | X.509 certificate, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | eph_len (16 bits) | | | Signed
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Region
* | | |
* + ephemeral_key (variable) + |
* | public key, DER encoded | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | cipher_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + cipher (variable) + |
* | symmetric cipher name (UTF-8) | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
* | data_len (16 bits) | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |
* | | |
* + data (variable) + |
* | Piggybacked application data | |
* + + |
* | | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
* | sig_len (16 bits) | |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
* | |
* + signature (variable) +
* | DSA signature over signed region |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*/

Field Summary:
+---------------+----------+----------------------------------------+
| Field | Size | Description |
+---------------+----------+----------------------------------------+
| id | 16 bytes | Random 128-bit flow allocation ID |
| timestamp | 8 bytes | UTC time in nanoseconds (replay prot.) |
| crt_len | 2 bytes | Certificate length (0 = no auth) |
| certificate | variable | X.509 cert signed by CA (DER encoded) |
| eph_len | 2 bytes | Ephemeral key length (0 = no encrypt) |
| ephemeral_key | variable | DHE public key |
| cipher_len | 2 bytes | Cipher name length (0 = no cipher) |
| cipher | variable | Name of the cipher to use |
| data_len | 2 bytes | Application data length |
| data | variable | Piggybacked app data (future use) |
| sig_len | 2 bytes | Signature length (0 = unsigned) |
| signature | variable | Signature |
+---------------+----------+----------------------------------------+

Minimum header size: 16 + 8 + 2 + 2 + 2 + 2 + 2 = 34 bytes (no optional fields)

</pre>

= Operation =

When an application calls flow_alloc() to connect to a service or flow_accept() to receive incoming connections, the Ouroboros IRMd (IPC Resource Manager daemon) transparently handles all security operations on behalf of the application. The application simply provides a destination name (e.g., "sec.oping.tut.o7s") and receives back a flow descriptor for reading and writing data—it remains completely unaware of any underlying cryptography. During flow allocation, the IRMd on the client side constructs an OAP (Ouroboros Allocation Protocol) header containing a unique flow ID, timestamp, and optionally the client's X.509 certificate, an ephemeral DHE public key, and a digital signature. This OAP header travels inside the FLOW_REQ message to the server's IRMd, which can verify the client's certificate against its configured CA trust store and validate the signature. The server's IRMd then responds with its own OAP header in the FLOW_REPLY, containing its certificate, ephemeral public key, and signature. Both sides independently derive the same symmetric encryption key using DHE key agreement. Once the flow is established, the library layer (between the application and IRMd) automatically encrypts outgoing data and decrypts incoming data using this shared key—the application's flow_read() and flow_write() calls work identically whether encryption is enabled or not. This architecture applies uniformly to all flows regardless of their QoS characteristics: whether the underlying flow provides reliable ordered delivery (connection-oriented semantics) or best-effort delivery (connectionless semantics), the security handshake occurs during flow allocation, and the resulting symmetric key protects all subsequent data exchange. The security policy is entirely configuration-driven through certificate and key files in security, allowing system administrators to enforce authentication and encryption requirements without any application code changes.

<pre>
Client (IRMd) Server (IRMd)
| |
| 1. Load client cert/key |
| 2. Generate ephemeral keypair |
| 3. Build OAP_HDR (id, ts, crt, eph) |
| 4. Sign header with client key |
| |
|-------- FLOW_REQ (OAP_HDR) -------------> |
| |
| | 5. Load server cert/key
| | 6. Verify client cert against CA
| | 7. Verify client signature
| | 8. Generate ephemeral keypair
| | 9. Derive symmetric key (ECDHE)
| | 10. Build response OAP_HDR
| | 11. Sign with server key
| |
|<------- FLOW_REPLY (OAP_HDR) ------------ |
| |
| 12. Verify server cert against CA |
| 13. Verify server signature |
| 14. Derive symmetric key (ECDHE) |
| |
|===========================================|
| Encrypted data channel |
|===========================================|
</pre>

Definitions

2026-01-04T12:07:31Z

Dimitri: /* Routing, Forwarding and Flooding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing, Forwarding and Flooding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

'''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors (with the associated set of arcs <math>L(v)</math>) so that:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a connected subgraph of <math>G</math>; and
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs.

Equivalently, '''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(v_s, u) > d(v_s, v)</math> for any chosen distance function <math>d</math> on <math>G</math>.

In other words, '''FLOODING''' creates a connected tree rooted at <math>v_s</math> that reaches all (reachable) vertices in the network. Each vertex selects neighbors that are strictly farther from the source than itself, ensuring the flood propagates outward without backtracking.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be close to 0,<ref group="note">This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. Ouroboros estimates MPL based on the Layer characteristics. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live (v4) or Hop Limit (v6) decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref group="note">In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref group="note">This is similar in function to a UNIX file descriptor.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T12:05:03Z

Dimitri: /* Flow Identifiers */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing, Forwarding and Flooding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D</math>. This also proves it covers ''all'' algorithms, unless you find a path longer than the longest path...</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

'''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors (with the associated set of arcs <math>L(v)</math>) so that:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a connected subgraph of <math>G</math>; and
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs.

Equivalently, '''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(v_s, u) > d(v_s, v)</math> for any chosen distance function <math>d</math> on <math>G</math>.

In other words, '''FLOODING''' creates a connected tree rooted at <math>v_s</math> that reaches all (reachable) vertices in the network. Each vertex selects neighbors that are strictly farther from the source than itself, ensuring the flood propagates outward without backtracking.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be close to 0,<ref group="note">This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. Ouroboros estimates MPL based on the Layer characteristics. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live (v4) or Hop Limit (v6) decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref group="note">In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref group="note">This is similar in function to a UNIX file descriptor.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T12:01:30Z

Dimitri: /* Flow */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing, Forwarding and Flooding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D</math>. This also proves it covers ''all'' algorithms, unless you find a path longer than the longest path...</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

'''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors (with the associated set of arcs <math>L(v)</math>) so that:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a connected subgraph of <math>G</math>; and
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs.

Equivalently, '''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(v_s, u) > d(v_s, v)</math> for any chosen distance function <math>d</math> on <math>G</math>.

In other words, '''FLOODING''' creates a connected tree rooted at <math>v_s</math> that reaches all (reachable) vertices in the network. Each vertex selects neighbors that are strictly farther from the source than itself, ensuring the flood propagates outward without backtracking.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be close to 0,<ref group="note">This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. Ouroboros estimates MPL based on the Layer characteristics. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live (v4) or Hop Limit (v6) decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref group="note">In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T11:33:16Z

Dimitri: /* Routing, Forwarding and Flooding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing, Forwarding and Flooding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D</math>. This also proves it covers ''all'' algorithms, unless you find a path longer than the longest path...</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

'''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors (with the associated set of arcs <math>L(v)</math>) so that:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a connected subgraph of <math>G</math>; and
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs.

Equivalently, '''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(v_s, u) > d(v_s, v)</math> for any chosen distance function <math>d</math> on <math>G</math>.

In other words, '''FLOODING''' creates a connected tree rooted at <math>v_s</math> that reaches all (reachable) vertices in the network. Each vertex selects neighbors that are strictly farther from the source than itself, ensuring the flood propagates outward without backtracking.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be close to 0,<ref group="note">This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. Ouroboros estimates MPL based on the Layer characteristics. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live (v4) or Hop Limit (v6) decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T11:30:04Z

Dimitri: /* Routing, Forwarding and Flooding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing, Forwarding and Flooding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>. This also proves it covers ''all'' algorithms, unless you find a path longer than the longest path...</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

'''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors (with the associated set of arcs <math>L(v)</math>) so that:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a connected subgraph of <math>G</math>; and
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs.

Equivalently, '''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(v_s, u) > d(v_s, v)</math> for any chosen distance function <math>d</math> on <math>G</math>.

In other words, '''FLOODING''' creates a connected tree rooted at <math>v_s</math> that reaches all (reachable) vertices in the network. Each vertex selects neighbors that are strictly farther from the source than itself, ensuring the flood propagates outward without backtracking.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be close to 0,<ref group="note">This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. Ouroboros estimates MPL based on the Layer characteristics. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live (v4) or Hop Limit (v6) decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T11:19:59Z

Dimitri: /* Flow Bounds */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing, Forwarding and Flooding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

'''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors (with the associated set of arcs <math>L(v)</math>) so that:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a connected subgraph of <math>G</math>; and
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs.

Equivalently, '''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(v_s, u) > d(v_s, v)</math> for any chosen distance function <math>d</math> on <math>G</math>.

In other words, '''FLOODING''' creates a connected tree rooted at <math>v_s</math> that reaches all (reachable) vertices in the network. Each vertex selects neighbors that are strictly farther from the source than itself, ensuring the flood propagates outward without backtracking.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be close to 0,<ref group="note">This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. Ouroboros estimates MPL based on the Layer characteristics. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live (v4) or Hop Limit (v6) decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T11:13:10Z

Dimitri: /* Routing, Forwarding and Flooding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing, Forwarding and Flooding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

'''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors (with the associated set of arcs <math>L(v)</math>) so that:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a connected subgraph of <math>G</math>; and
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs.

Equivalently, '''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(v_s, u) > d(v_s, v)</math> for any chosen distance function <math>d</math> on <math>G</math>.

In other words, '''FLOODING''' creates a connected tree rooted at <math>v_s</math> that reaches all (reachable) vertices in the network. Each vertex selects neighbors that are strictly farther from the source than itself, ensuring the flood propagates outward without backtracking.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T11:09:00Z

Dimitri: /* Routing, Forwarding and Flooding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing, Forwarding and Flooding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

'''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors (with the associated set of arcs <math>L(v)</math>) so that:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a connected subgraph of <math>G</math>; and
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs.

Equivalently, '''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(v_s, u) > d(v_s, v)</math> for any chosen distance function <math>d</math> on <math>G</math>.

In other words, '''FLOODING''' creates a connected tree rooted at <math>v_s</math> that reaches all vertices in the network. Each vertex selects neighbors that are strictly farther from the source than itself, ensuring the flood propagates outward without backtracking.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T11:07:10Z

Dimitri: /* Routing and Forwarding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing, Forwarding and Flooding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors (with the associated set of arcs <math>L(v)</math>) so that:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a connected subgraph of <math>G</math>; and
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs.

Equivalently, '''FLOODING''' is any algorithm that, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(v_s, u) > d(v_s, v)</math> for any chosen distance function <math>d</math> on <math>G</math>.

In other words, '''FLOODING''' creates a connected tree rooted at <math>v_s</math> that reaches all vertices in the network. Each vertex selects neighbors that are strictly farther from the source than itself, ensuring the flood propagates outward without backtracking.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T11:03:36Z

Dimitri: /* Routing and Forwarding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T11:00:12Z

Dimitri: /* Interpretation of the formal definition */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing in Ouroboros ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T10:56:33Z

Dimitri: /* Interpretation of the formal definition */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing in Ouroboros ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Interpretation of the formal definition ===
The formal definition says that a routing algorithm is equivalent a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can not contain (permanent) loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T10:50:23Z

Dimitri: /* Formal Definition of Routing in Ouroboros */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing in Ouroboros ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Interpretation of the formal definition ===
The formal definition says that routing creates a tree-like structure where every node along any valid path selects one or more neighbors that are strictly "closer" to the destination than itself. This structure can contain multiple paths from source to destination, allowing routing solution that move different packets (or fragments) along different routes through the network. The key guarantee is that all these paths always make progress toward their destination and can never contain loops - think of it like water flowing downhill where it may split into multiple streams, but each stream always flows to a lower elevation and can never flow back uphill.

This definition is very broad "one or more neighbors" selection allows solutions that send duplicates, erasure coding packet fragments etc.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T10:40:30Z

Dimitri: /* Formal Definition of Routing in Ouroboros */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing in Ouroboros ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D.</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T10:31:37Z

Dimitri: /* Formal Definition of Routing in Ouroboros */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing in Ouroboros ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref group="note"> Proof of Equivalence: choose for <math>d</math> the length of the longest path between the corresponding vertices in <math>D</math>.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T10:29:13Z

Dimitri: /* Routing and Forwarding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

With routing we typically mean the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there are the '''hierarchical routing''' solutions. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref group="note">Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref group="note">Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. The reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing in Ouroboros ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref>Choose for d the length of the longest path between the corresponding vertices in D.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T10:24:23Z

Dimitri: /* Distance and Metrics */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

Routing is broadly defined as the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there is the '''hierarchical routing''' solution. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref>Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref>Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. As far as we know the definitions are original, although the reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref>Choose for d the length of the longest path between the corresponding vertices in D.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T10:20:51Z

Dimitri: /* Definitions: Flow, Routing, and Forwarding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref group="note">The weight of an edge is often called a ''metric'' in computer science literature (e.g. BGP metric). To avoid confusion, we use the term ''metric'' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref group="note">A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the ''geodesic'' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfill the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

Routing is broadly defined as the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there is the '''hierarchical routing''' solution. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref>Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref>Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. As far as we know the definitions are original, although the reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref>Choose for d the length of the longest path between the corresponding vertices in D.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T10:16:13Z

Dimitri: /* References */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. This section details a '''model''' and deals with (abstract) programs.
The graph definitions follow Dieter Jungnickel's excellent ''Graph, Networks and Algorithms''<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>.

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref>The weight of an edge is often called a '''metric''' in computer science literature. To avoid confusion, we will use the term '''metric''' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''<ref>A ''Hamiltonian cycle'' is a special case of a closed walk that includes every vertex in the graph exactly once. This is necessarily also a closed trail.</ref>.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the '''geodesic''' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfil the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

Routing is broadly defined as the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there is the '''hierarchical routing''' solution. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref>Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref>Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. As far as we know the definitions are original, although the reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref>Choose for d the length of the longest path between the corresponding vertices in D.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== Footnotes ==
<references group="note"/>

== References ==
<references/>

Definitions

2026-01-04T10:11:34Z

Dimitri: /* Definitions: Flow, Routing, and Forwarding */

Definitions

2026-01-04T10:00:40Z

Dimitri:

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. This section details a '''model''' and deals with (abstract) programs, it does not specify an implementation, and it should not be directly interpreted with respect to any particular implementation of a computing system or environment<ref>''...but approached with a blank mind, consciously refusing to try to link it with what is already familiar...'' (Dijkstra, 1988).</ref>. The definitions are taken from Dieter JungNickel's excellent textbook<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>

== Basic Graph Definitions ==

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref>The weight of an edge is often called a '''metric''' in computer science literature. To avoid confusion, we will use the term '''metric''' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the '''geodesic''' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfil the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

Routing is broadly defined as the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there is the '''hierarchical routing''' solution. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref>Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref>Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. As far as we know the definitions are original, although the reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref>Choose for d the length of the longest path between the corresponding vertices in D.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== References ==
<references/>

Definitions

2026-01-04T09:57:21Z

Dimitri: /* Definitions: Flow, Routing, and Forwarding */

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. This section details a '''model''' and deals with (abstract) programs, it does not specify an implementation, and it should not be directly interpreted with respect to any particular implementation of a computing system or environment<ref>''...but approached with a blank mind, consciously refusing to try to link it with what is already familiar...'' (Dijkstra, 1988).</ref>. The definitions are taken from the excellent textbook <ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref>

== Graphs and Networks ==

=== Basic Graph Definitions ===

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>. An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref>The weight of an edge is often called a '''metric''' in computer science literature. To avoid confusion, we will use the term '''metric''' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the '''geodesic''' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfil the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

Routing is broadly defined as the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there is the '''hierarchical routing''' solution. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref>Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref>Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. As far as we know the definitions are original, although the reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref>Choose for d the length of the longest path between the corresponding vertices in D.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== References ==
<references/>

Definitions

2026-01-04T09:31:26Z

Dimitri:

= Definitions: Flow, Routing, and Forwarding =

This document contains formal definitions used in the Ouroboros architecture. This section details a '''model''' and deals with (abstract) programs, it does not specify an implementation, and it should not be directly interpreted with respect to any particular implementation of a computing system or environment<ref>''...but approached with a blank mind, consciously refusing to try to link it with what is already familiar...'' (Dijkstra, 1988).</ref>. The definitions in this section may differ (even ever so slightly) from previously held notions of the term.

== Graphs and Networks ==

=== Basic Graph Definitions ===

A '''graph''' is a pair <math>G = (V, E)</math> consisting of a set of '''vertices''' <math>V</math> and a set of '''edges''' <math>E \subset V^2</math> of two-element subsets of <math>V</math>.<ref>Jungnickel, D. (2007). Graphs, Networks and Algorithms.</ref> An edge <math>e = (v_i,v_j)</math> has (distinct) end vertices <math>v_i</math> and <math>v_j</math>.

A '''directed graph''' or '''digraph''' is a pair <math>G = (V, A)</math> consisting of a set <math>V</math> of vertices and a set <math>A</math> of ordered pairs <math>(v_i, v_j)</math> (called '''arcs''') where <math>v_i \neq v_j</math>.

A '''network''' is a digraph <math>G = (V,A)</math> on which a mapping <math>w: A \to \mathbb{R}</math> from the edgeset to the reals is defined; the number <math>w(a)</math> is called the '''weight''' of the arc <math>a</math><ref>The weight of an edge is often called a '''metric''' in computer science literature. To avoid confusion, we will use the term '''metric''' only in its mathematical meaning.</ref>.

If <math>a = (v_i,v_j) \in A</math>, then <math>v_i</math> is '''adjacent''' to <math>v_j</math> and '''incident''' with <math>a</math>. The set of '''neighbors''' <math>N</math> of a vertex <math>v</math> is the set of vertices that are adjacent to <math>v</math>, where <math>N(v)</math> contains all <math>u \in V</math> such that <math>(v, u) \in A</math>.

=== Walks, Paths, and Cycles ===

A '''walk''' is a sequence of vertices <math>\mathcal{W} = (v_0, v_1, \dots , v_n)</math> so that <math>a_i = (v_{i-1},v_i) \in A , i = 1, \dots, n</math>. So each walk also implies a sequence of edges. We define the weight of a walk <math>\mathcal{W}</math> as the sum of the weights of its arcs, <math>w(\mathcal{W}) = \sum_{i=1}^n w(a_i)</math>.

If the '''source''' <math>v_0</math> and '''destination''' <math>v_n</math> are the same (<math>v_0 = v_n</math>), the walk is '''closed'''.

A walk where each of the arcs <math>a_i</math> is distinct is called a '''trail'''.

A '''path''' is a trail for which each of the <math>v_i</math> are distinct.

A '''closed trail''' for which the <math>v_i</math> are distinct is called a '''cycle'''.

A '''directed acyclic graph''' (DAG) is a digraph that does not contain any cycles.

If for every pair of vertices <math>v_s, v_d \in V</math> there is at least one path <math>\mathcal{P} = (v_s, \dots, v_d)</math>, we call the (di)graph '''connected'''.

=== Distance and Metrics ===

The distance function defined by the weight of the shortest path between two vertices in a network (or <math>\infty</math> if no such path exists) is called the '''geodesic''' distance.

A '''metric''' is a (distance) function <math>d: X^2 \to [0, +\infty)</math> fulfilling positivity, symmetry and triangle inequality:

<math>\forall x,y,z \in X: d(x, y) \geq 0 \land d(x,y) = d(y,x) \land d(x,z) \leq d(x,y) + d(y,z)</math>

A geodesic distance is in general not a metric since it doesn't always fulfil the positivity and symmetry requirements in a digraph.

== Routing and Forwarding ==

Routing is broadly defined as the process of selecting a path for traffic in a network. In computer science literature, there are two main groups of approaches to routing.

On the one hand there is the '''hierarchical routing''' solution. This is the approach taken in IP networks, where a set of subnetworks is defined using '''prefixes''' or '''subnet masks'''.<ref>RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan.</ref> A scalability issue with IP stems from not following the partial ordering implied by the subnetting in the delegation of IP addresses, causing fragmentation of the IP address space and making prefix aggregration in routers increasingly inefficient.<ref>Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. RFC 4984.</ref>

On the other hand we have '''geographic''' or '''geometric''' routing,<ref>Kuhn, F., Wattenhofer, R., and Zollinger, A. (2003). Worst-case optimal and average-case efficient geometric ad-hoc routing.</ref> where each node is assigned a coordinate so next hops can be calculated making use of the coordinates of the direct neighbors.<ref>Geographic coordinates are a compound name, consisting of latitudes and longitudes, but there is no order implied between these two coordinate spaces. Hence the partial ordering in our definition of an address.</ref>

The examples above illustrate that the concept of routing encompasses both the dissemination and gathering of information about the network, and the algorithms for calculation and selection of the paths. We will now define the concepts underpinning "routing" more formally. As far as we know the definitions are original, although the reasoning behind it is similar to the reasoning commonly used in formulating (integer) linear programming solutions to problems in graph theory.

=== Formal Definition of Routing ===

Let <math>G = (V, A)</math> be a network.

'''ROUTING''' is any algorithm that, given source and destination vertices <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors with the associated set of arcs <math>L(v)</math>, so that the following 4 conditions are met:

# The graph <math>D = (V', A') = (\cup_{v \in V}H(v), \cup_{v \in V}L(v))</math> is a directed acyclic subgraph of <math>G</math>;
# <math>v_s</math> is the only vertex in <math>D</math> with only outgoing arcs;
# <math>v_d</math> is the only vertex in <math>D</math> with only incoming arcs; and
# <math>A' = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

Equivalently,<ref>Choose for d the length of the longest path between the corresponding vertices in D.</ref> '''ROUTING''' is any algorithm that, given source and destination '''vertices''' <math>v_s</math> and <math>v_d</math>, for each vertex <math>v</math> in <math>V</math> returns a subset <math>H(v) \subseteq N(v)</math> of neighbors so that:

# <math>\forall u \in H(v): d(u, v_d) < d(v, v_d)</math> for any chosen distance function <math>d</math> on <math>G</math>; and
# <math>\cup_{v \in V} H(v) = \emptyset</math> if and only if there is no path <math>\mathcal{P}</math> between <math>v_s</math> and <math>v_d</math> in <math>G</math>.

In other words, either the distance function bounds the routing solution, or the routing solution bounds the distance function.

=== Formal Definition of Forwarding ===

We define '''FORWARDING''' as any algorithm that, for each vertex <math>v</math> in <math>V</math> returns the set of arcs <math>L(v)</math>. '''FORWARDING''' is often implemented as '''ROUTING''' with an additional edge selection step.

The necessary and sufficient condition for '''ROUTING''' is full knowledge of the graph <math>G = (V, A)</math> and a valid geodesic distance <math>d</math>. For a given vertex <math>v</math>, the necessary and sufficient set of information to obtain <math>L(v)</math> is knowledge of its neighbor set <math>N(v)</math> and the subset of the geodesic distances originating at its neighbors, <math>d_{v} \subset d: N(v) \times V \to \mathbb{R}</math>.

In less formal terms, '''ROUTING''' and '''FORWARDING''' provide a set of vertices and arcs, respectively, so that there are never loops if one travels to a next vertex or along an arc in the set. If implemented in a centralized way, '''ROUTING''' and '''FORWARDING''' roughly need to know the full network. When implemented in a distributed way, a node roughly needs to know its neighbors and the distances to the destination from itself and from all its neighbors.

The definitions above show what information needs to be disseminated in a network to allow '''FORWARDING'''. Let's assume that vertices know their neighbors or incident outgoing arcs, then what is needed is a dissemination procedure for the (geodesic) distance function <math>d</math>. This is implemented in a class of dissemination protocols, called '''link-state routing protocols'''.

== Flow ==

A '''flow''' is the abstraction of a collection of resources within a network layer that allow bidirectional communications using packets between two processes that are clients of this layer. A flow enables a point-to-point '''packet delivery service''' and can be viewed as a bidirectional pipe that has a number of observable quantities associated with it that describe the probability <math>p(S,t, \ldots) \in [0, 1]</math> of a packet of given size <math>S</math> being transferred within a certain period of time <math>[t_x, t_x + t]</math>. The maximum probability for error-free transfer depends on the '''packet-drop-rate''' (PDR) and '''bit-error-rate''' (BER) of the flow.

The Ouroboros architecture ensures that flows are '''content neutral''', i.e. the probability <math>p(S, t, \ldots)</math> above is independent of the bits that make up the packets sent along a flow.

=== Flow Characteristics ===

The '''delay''' or '''latency''' describes how long packets take to traverse the flow, and the variation on the delay is called '''jitter''', or more precisely, '''packet delay variation'''.<ref>RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM).</ref> The delay for a flow has four main components:

* '''Propagation''' delay
* '''Queuing''' delay
* '''Transmission''' delay
* '''Processing''' delay

=== Flow Bounds ===

There are 2 upper bounds:

* The '''Maximum Packet Lifetime''' (MPL) is the maximum amount of time that a packet can take to transfer over the flow
* The '''Maximum Packet Size''' (MPS) is the maximum length for a packet to be acceptable for transfer

In other words, the probability for a packet to arrive after MPL expires should be 0,<ref>This may be hard to guarantee with 100 percent certainty, so MPL should be large enough so that this probability is 0 in practice. IP has a bound on the Maximum Datagram Lifetime (MDL) via the Time-To-Live or Hop Limit decrement in each router to a maximum of 255 seconds (RFC 791), with a recommended value of 64 seconds (RFC 1700). In addition, TCP defines the Maximum Segment Lifetime (MSL) as 120s (RFC 793).</ref> and the probability for a packet to arrive that exceeds the MPS is equal to 0.

Similarly, there can be lower bounds such as Minimum Packet Lifetime (mPL) and Minimum Packet Size (mPS).

=== Flow Resources ===

The resources that make up a layer are finite, limiting the total number of packets that can traverse the network layer in a given period of time. Flows provide the mechanism to put a network layer fully in control of its own resources. The resources that constitute the flow can either be shared with other flows or dedicated (reserved) for this particular flow.

Other externally measureable quantities can be associated with a flow, such as bandwidth and load for flows with reserved resources. The probability function may depend on these quantities (e.g. if the load reaches a certain threshold, delay could increase).

=== Flow Identifiers ===

A flow endpoint is identified in a system by a '''flow ID''' (FID), which defines the '''layer boundary'''<ref>In this respect, a flow id is similar to an OSI '''Service Access Point''' (SAP) or RINA '''port id'''.</ref>. For security reasons, a process has no direct access to the flow, but rather accesses the flow through a '''Flow Descriptor''' (FD) to read and write from a flow. Flow identifiers are unique within the scope of a system, flow descriptors are unique within the scope of a process<ref>This is similar in function to a UNIX file descriptor. A UNIX kernel space implementation of Ouroboros would probably use file descriptors for flow descriptors.</ref>.

Flows are an important concept for enabling Quality-of-Service (QoS) in a layer.

== References ==
<references/>