Ouroboros Tutorial 06
Jump to navigation
Jump to search
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
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 |
|===========================================|
Tutorial Directory: This tutorial will execute in /tmp/o7s-tut06/. 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 (
ca.tut.o7s): Self-signed trust anchor - Intermediate CA (
sign.tut.o7s): Signed by root with pathlen:0 constraint - Server Certificate (
sec.oping.tut.o7s): 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.
cd /path/to/ouroboros
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Debug -DDEBUG_PROTO_OAP=ON ..
make -j$(nproc)
sudo make install
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 (/tmp/o7s-tut06/) before starting the tutorial:
tut06.conf - IRMd configuration
# 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"]
ca.tut.o7s.cnf - OpenSSL configuration for PKI generation
# 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
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
#!/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."
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 (tut06.conf) 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):
sudo mkdir -p /etc/ouroboros/security/{cacert,untrusted,server/sec.oping.tut.o7s,client/sec.oping.tut.o7s}
# 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/
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)
sudo tcpdump -i lo -n -A -v -U -w /tmp/o7s-tut06/tut06.pcap "ether proto 0xa000"
Terminal 2: Start IRMd with debug output (runs continuously)
cd /tmp/o7s-tut06
sudo irmd --config tut06.conf --stdout 2>&1 | tee /tmp/o7s-tut06/irmd.log
Terminal 3: Run the tests
Test 1: No Authentication, No Encryption
# 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
IRMd Output - Test 1: Client initiates plaintext flow allocation
==33047== irmd(II): Allocating flow for 33266 to sec.oping.tut.o7s.
==33047== irmd(DB): File /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.cfg 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 [f1c3efe0833e2c76 @ 2026-01-01 11:27:09 (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>
IRMd Output - Test 1: Server accepts and completes handshake
==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.
Key observations: All OAP fields are <none> because no security is configured. Flow succeeds with plaintext communication.
Test 2: No Authentication, With Encryption
# Enable encryption for client only
sudo touch /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.cfg
# Run second ping test
oping -n sec.oping.tut.o7s -c 1
IRMd Output - Test 2: Client initiates flow with encryption enabled
==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>
IRMd Output - Test 2: Server receives and responds with ephemeral key
==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.
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
# 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.cfg is still in place from Test 2
oping -n sec.oping.tut.o7s -c 1
IRMd Output - Test 3: Client initiates flow with encryption and server has certificate
==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>
IRMd Output - Test 3: Server responds with certificate + ephemeral key + signature
==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]
IRMd Output - Test 3: Client verifies certificate and authenticates
==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.
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
# Remove encryption config but keep certificates
sudo rm -f /etc/ouroboros/security/client/sec.oping.tut.o7s/enc.cfg
# Run fourth ping test
oping -n sec.oping.tut.o7s -c 1
IRMd Output - Test 4: Client initiates plaintext flow (no encryption file)
==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.cfg 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>
IRMd Output - Test 4: Server responds with certificate + signature (no ephemeral key)
==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]
IRMd Output - Test 4: Client verifies certificate and authenticates
==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.
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:
# 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
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.
| 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 0x0000.
Management Frame Types:
| Code | Type | Direction | Service Hash | Purpose |
|---|---|---|---|---|
0x00 |
FLOW_REQ |
Client → Server | ✓ Included | Request new flow allocation |
0x01 |
FLOW_REPLY |
Server → Client | – Not included | Respond to flow request (success/failure) |
0x02 |
NAME_QUERY_REQ |
Client → Server | ✓ Included | Query if a remote name is reachable |
0x03 |
NAME_QUERY_REPLY |
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:
| 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:
| 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:
| 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
0x00000000(ECHO_REQUEST): Client-to-server ping request0x00000001(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 sec.oping.tut.o7s is available. This is a broadcast discovery query sent because the service is not yet known for the flow allocation process.
Raw Data:
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.._...
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 0047 |
Length | 2 | 71 bytes | Total payload length |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0000 |
SEID | 2 | 0x0000 | Source Endpoint ID (UNUSED) |
| 0x06-0x07 | 0000 |
DEID | 2 | 0x0000 | Destination Endpoint ID (UNUSED) |
| 0x08-0x23 | 0000 ... 0000 |
QoS (Various) | 28 | 0 | UNUSED |
| 0x24-0x27 | 0000 0000 |
Response | 4 | 0 | Response code (UNUSED) |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | UNUSED |
| 0x29 | 03 |
Code | 1 | 0x03 | Message Type: NAME_QUERY_REQ |
| 0x2a | 00 |
QoS (Availability) | 1 | 0x00 | UNUSED |
| 0x2b-0x4a | ec f815 ad98 3df6 bf81...9282 8a |
Service Hash | 32 | SHA3-256 | Hash of sec.oping.tut.o7s
|
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:
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.._...
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 0047 |
Length | 2 | 71 bytes | Total payload length |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0000 |
SEID | 2 | 0x0000 | Source Endpoint ID (UNUSED) |
| 0x06-0x07 | 0000 |
DEID | 2 | 0x0000 | Destination Endpoint ID (UNUSED) |
| 0x08-0x23 | 0000 ... 0000 |
QoS (Various) | 28 | 0 | UNUSED |
| 0x24-0x27 | 0000 0000 |
Response | 4 | 0 | Response code |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | UNUSED |
| 0x29 | 03 |
Code | 1 | 0x03 | Message Type: NAME_QUERY_REPLY |
| 0x2a | 00 |
QoS (Availability) | 1 | 0x00 | UNUSED |
| 0x2b-0x4a | ec f815 ad98 3df6 bf81...9282 8a |
Service Hash | 32 | SHA3-256 | Hash of sec.oping.tut.o7s (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:
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........
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 0067 |
Length | 2 | 103 bytes | Total payload length |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0040 |
SEID | 2 | 0x0040 | Source Endpoint ID (allocated flow ID) |
| 0x06-0x07 | 0000 |
DEID | 2 | 0x0000 | UNUSED |
| 0x08-0x23 | 0000 ... 0000 |
QoS (Various) | 28 | -- | UNUSED |
| 0x24-0x27 | 0001 0000 |
Response | 4 | 0 | UNUSED |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | UNUSED |
| 0x29 | 00 |
Code | 1 | 0x00 | Message Type: FLOW_REQ |
| 0x2a | 00 |
QoS (Availability) | 1 | 0x00 | UNUSED |
| 0x2b-0x4a | ec f815 ad98 3df6 bf81...9282 8a |
Service Hash | 32 | SHA3-256 | Hash of sec.oping.tut.o7s
|
Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload
The OAP payload starts at offset 0x4b (after management protocol + service hash):
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x4b-0x5a | 51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77 |
ID | 16 | 128-bit identifier | Unique flow allocation identifier |
| 0x5b-0x62 | 18 86a8 e103 3e52 33 |
Timestamp | 8 | Network order | Creation timestamp (seconds + microseconds) |
| 0x63-0x64 | 0000 |
Crt_len | 2 | 0x0000 | No certificate |
| 0x65-0x66 | 0000 |
Eph_len | 2 | 0x0000 | No ephemeral key |
| 0x67-0x68 | 0000 |
Data_len | 2 | 0x0000 | No application data |
| 0x69-0x6a | 0000 |
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:
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........
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 0047 |
Length | 2 | 71 bytes | Total payload length |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0041 |
SEID | 2 | 0x0041 | Source Endpoint ID (allocated server-side flow ID) |
| 0x06-0x07 | 0040 |
DEID | 2 | 0x0040 | Destination Endpoint ID (client's flow ID from FLOW_REQ) |
| 0x08-0x23 | 0000 ... 0000 |
QoS (Various) | 28 | 0 | UNUSED |
| 0x24-0x27 | 0000 0000 |
Response | 4 | 0 | Response code (success) |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | UNUSED |
| 0x29 | 01 |
Code | 1 | 0x01 | Message Type: FLOW_REPLY |
| 0x2a | 00 |
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):
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x2b-0x3a | 51 8a56 ff6f 5ba6 9d03 7da1 cfc3 0f30 77 |
ID | 16 | 128-bit identifier | Echo of client's flow ID |
| 0x3b-0x42 | 18 86a8 e13f a347 38 |
Timestamp | 8 | Network order | Echoed timestamp |
| 0x43-0x44 | 0000 |
Crt_len | 2 | 0x0000 | No certificate |
| 0x45-0x46 | 0000 |
Eph_len | 2 | 0x0000 | No ephemeral key |
| 0x47-0x48 | 0000 |
Data_len | 2 | 0x0000 | No application data |
| 0x49-0x4a | 0000 |
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:
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 ....
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0041 |
EID | 2 | 0x0041 | Source Endpoint ID (server → client) |
| 0x02-0x03 | 0040 |
Length | 2 | 64 bytes | Oping payload length |
Oping Application Protocol - ECHO_REQUEST Payload
The oping payload starts at offset 0x04:
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x07 | 0000 0000 |
Type | 4 | 0x00000000 | Message type: ECHO_REQUEST |
| 0x08-0x0b | 0000 0000 |
ID | 4 | 0x00000000 | Sequence number (first ping) |
| 0x0c-0x13 | 7377 0000 0000 0000 |
Timestamp (seconds) | 8 | 0x0000000000003773 | Seconds component |
| 0x14-0x1b | b03e e007 0000 0000 |
Timestamp (nanoseconds) | 8 | 0x0000000007e03eb0 | Nanoseconds component |
| 0x1c-0x43 | 0000 0000 ... 0000 0000 |
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:
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 ....
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0040 |
EID | 2 | 0x0040 | Destination Endpoint ID (client ← server) |
| 0x02-0x03 | 0040 |
Length | 2 | 64 bytes | Oping payload length |
Oping Application Protocol - ECHO_REPLY Payload
The oping payload starts at offset 0x04:
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x07 | 0000 0001 |
Type | 4 | 0x00000001 | Message type: ECHO_REPLY |
| 0x08-0x0b | 0000 0000 |
ID | 4 | 0x00000000 | Echo of request sequence number |
| 0x0c-0x13 | 7377 0000 0000 0000 |
Timestamp (seconds) | 8 | 0x0000000000003773 | Echo of original seconds |
| 0x14-0x1b | b03e e007 0000 0000 |
Timestamp (nanoseconds) | 8 | 0x0000000007e03eb0 | Echo of original nanoseconds |
| 0x1c-0x43 | 0000 0000 ... 0000 0000 |
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:
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 %.....
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 00c2 |
Length | 2 | 194 bytes | Total payload length |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0040 |
SEID | 2 | 0x0040 | Source Endpoint ID |
| 0x06-0x07 | 0000 |
DEID | 2 | 0x0000 | UNUSED |
| 0x08-0x23 | 0000 ... d4c0 |
QoS (Various) | 28 | Mixed | UNUSED |
| 0x24-0x27 | 0000 ... 0000 |
Response | 4 | 0 | UNUSED |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | UNUSED |
| 0x29 | 00 |
Code | 1 | 0x00 | Message Type: FLOW_REQ |
| 0x2a | 00 |
QoS (Availability) | 1 | 0x00 | UNUSED |
| 0x2b-0x4a | ec f815 ad98 3df6 bf81...9282 8a |
Service Hash | 32 | SHA3-256 | Hash of sec.oping.tut.o7s
|
Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Ephemeral Key
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x4b-0x5a | f1 766b 547c fcb0 8fce 5d60 a01e e8be 02 |
ID | 16 | 128-bit identifier | Unique flow allocation identifier |
| 0x5b-0x62 | 18 86a8 e253 8b6c 90 |
Timestamp | 8 | Network order | Creation timestamp |
| 0x63-0x64 | 0000 |
Crt_len | 2 | 0x0000 | No certificate in client request |
| 0x65-0x66 | 005b |
Eph_len | 2 | 0x005b (91) | Ephemeral key length: 91 bytes |
| 0x67-0xc1 | 30 5930 ... 3dab 2598 |
Ephemeral Key | 91 | ECDHE P-384 | ECDHE P-384 public key (DER encoded) |
| 0xd3-0xd4 | 0000 |
Data_len | 2 | 0x0000 | No application data |
| 0xd5-0xd6 | 0000 |
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:
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....
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 00a2 |
Length | 2 | 162 bytes | Total payload length |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0042 |
SEID | 2 | 0x0042 | Source Endpoint ID (allocated server flow) |
| 0x06-0x07 | 0040 |
DEID | 2 | 0x0040 | Destination Endpoint ID (client flow) |
| 0x08-0x23 | 0000 ... 0000 |
QoS (Various) | 28 | 0 | UNUSED |
| 0x24-0x27 | 0000 0000 |
Response | 4 | 0x00000000 | Response code: 0 (success) |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | UNUSED |
| 0x29 | 01 |
Code | 1 | 0x01 | Message Type: FLOW_REPLY |
| 0x2a | 00 |
QoS (Availability) | 1 | 0x00 | UNUSED |
Ouroboros Allocation Protocol (OAP) - FLOW_REPLY with Ephemeral Key
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x2b-0x3a | f1 766b 547c fcb0 8fce 5d60 a01e e8be 02 |
ID | 16 | Echo of client ID | Echoes client's flow ID |
| 0x3b-0x42 | 18 86a8 e253 b694 e8 |
Timestamp | 8 | Network order | Echoed timestamp |
| 0x43-0x44 | 0000 |
Crt_len | 2 | 0x0000 | No certificate |
| 0x45-0x46 | 005b |
Eph_len | 2 | 0x005b (91) | Ephemeral key length: 91 bytes |
| 0x47-0xa1 | 30 5930...9936 |
Ephemeral Key | 91 | ECDHE P-384 | Server's ECDHE P-384 public key (DER encoded) |
| 0xd1-0xd2 | 0000 |
Data_len | 2 | 0x0000 | No application data |
| 0xd3-0xd4 | 0000 |
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:
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...
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0042 |
EID | 2 | 0x0042 | Destination Endpoint ID (server flow) |
| 0x02-0x03 | 0060 |
Length | 2 | 96 bytes | Encrypted payload length |
Oping Application Protocol - ECHO_REQUEST (Encrypted)
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x63 | a691 6d83 8446 cbeb...74b1 9a9a |
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:
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
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0040 |
EID | 2 | 0x0040 | Destination Endpoint ID (client flow) |
| 0x02-0x03 | 0060 |
Length | 2 | 96 bytes | Encrypted payload length |
Oping Application Protocol - ECHO_REPLY (Encrypted)
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x63 | c6ea 2222 5618 0268...f328 7237 |
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:
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 ......
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 00c2 |
Length | 2 | 194 bytes | Total payload length (excluding DIX header) |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0040 |
SEID | 2 | 0x0040 | Source Endpoint ID (client flow ID) |
| 0x06-0x07 | 0000 |
DEID | 2 | 0x0000 | Destination Endpoint ID (UNUSED) |
| 0x08-0x23 | 0000 ... d4c0 |
QoS (Various) | 28 | Default values | QoS parameters |
| 0x24-0x27 | 0000 0000 |
Response | 4 | 0 | Response code (UNUSED) |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | |
| 0x29 | 00 |
Code | 1 | 0x00 | Message Type: FLOW_REQ |
| 0x2a | 00 |
QoS (Availability) | 1 | 0x00 | |
| 0x2b-0x4a | ec f815 ... 8a |
Service Hash | 32 | SHA3-256 | Hash of sec.oping.tut.o7s
|
Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload with Encryption Setup
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x4b-0x5a | 66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9 |
ID | 16 | 128-bit identifier | Unique flow allocation identifier for Test 3 |
| 0x5b-0x62 | 18 86a8 e37e c0d2 ad |
Timestamp | 8 | Network order | Creation timestamp |
| 0x63-0x64 | 0000 |
Crt_len | 2 | 0x0000 | Client not authenticating |
| 0x65-0x66 | 005b |
Eph_len | 2 | 91 (0x005b) | Ephemeral public key length: 91 bytes |
| 0x67-0xc1 | 30 5930 1306 ... 3589 |
Ephemeral Key | 91 | ECDP-384 public key | Client's ephemeral ECDHE public key for encryption negotiation |
| 0xc2-0xc3 | 0000 |
Data_len | 2 | 0x0000 | No application data |
| 0xc4-0xc5 | 0000 |
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 -
crt_len = 0x0000because the client does not have authentication credentials; the server will authenticate instead - Ephemeral Key Present -
eph_len = 0x005b (91)because encryption is enabled on the client - No Signature -
sig_len = 0x0000because 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):
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..........
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 0339 |
Length | 2 | 825 bytes | Total payload length (excluding DIX header) |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0043 |
SEID | 2 | 0x0043 | Source Endpoint ID (server-side allocated flow ID) |
| 0x06-0x07 | 0040 |
DEID | 2 | 0x0040 | Destination Endpoint ID (client's flow ID from FLOW_REQ) |
| 0x08-0x23 | 0000 ... 0000 |
QoS (Various) | 28 | Default values | QoS parameters |
| 0x24-0x27 | 0000 0000 |
Response | 4 | 0x00000000 | Response code: 0 (success) |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | |
| 0x29 | 01 |
Code | 1 | 0x01 | Message Type: FLOW_REPLY |
| 0x2a | 00 |
QoS (Availability) | 1 | 0x00 |
Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Full Authentication
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x2b-0x3a | 66 bb82 95fa 91a2 7bd3 bd60 1b3e 35f6 b9 |
ID | 16 | 128-bit identifier | Same ID as client's FLOW_REQ (echoed back) |
| 0x3b-0x42 | 18 86a8 e37e d566 a0 |
Timestamp | 8 | Network order | Server's timestamp |
| 0x43-0x44 | 022f |
Crt_len | 2 | 559 (0x022f) | Server certificate length: 559 bytes |
| 0x45-0x243 | 2f30 8202 2b ... 81c8 30 |
Certificate | 559 | DER-encoded X.509 | Server's certificate (signed by intermediate CA) |
| 0x244-0x245 | 005b |
Eph_len | 2 | 91 (0x005b) | Server's ephemeral public key length: 91 bytes |
| 0x246-0x2a0 | 30 5930 1306 ... 9936 |
Ephemeral Key | 91 | ECDP-384 public key | Server's ephemeral ECDHE public key |
| 0x2a4-0x2a5 | 0000 |
Data_len | 2 | 0x0000 | No application data |
| 0x2a6-0x2a7 | 0068 |
Sig_len | 2 | 104 (0x0068) | Digital signature length: 104 bytes |
| 0x2a8-0x30f | 30 6602 3100 ... 07 |
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 -
crt_len = 0x022f (559)carrying server's complete X.509 certificate signed by intermediate CA - Ephemeral Key Present -
eph_len = 0x005b (91)with server's ECDHE public key for encryption - Signature Included -
sig_len = 0x0068 (104)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:
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..
Ethernet DIX Frame Analysis:
| Field | Offset | Length | Value | Description |
|---|---|---|---|---|
| Source EID | 0x00-0x01 | 2 bytes | 0x0043 |
Client flow endpoint ID |
| Destination EID | 0x02-0x03 | 2 bytes | 0x0060 |
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:
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
Ethernet DIX Frame Analysis:
| Field | Offset | Length | Value | Description |
|---|---|---|---|---|
| Source EID | 0x00-0x01 | 2 bytes | 0x0040 |
Client's inbound flow endpoint ID |
| Destination EID | 0x02-0x03 | 2 bytes | 0x0060 |
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:
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.....
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 0067 |
Length | 2 | 103 bytes | Total payload length |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0040 |
SEID | 2 | 0x0040 | Source Endpoint ID (allocated flow ID) |
| 0x06-0x07 | 0000 |
DEID | 2 | 0x0000 | UNUSED |
| 0x08-0x23 | 0000 ... dc40 |
QoS (Various) | 28 | Mixed | |
| 0x24-0x27 | 0000 0000 |
Response | 4 | 0 | UNUSED |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | |
| 0x29 | 01 |
Code | 1 | 0x01 | Message Type: FLOW_REQ |
| 0x2a | 00 |
QoS (Availability) | 1 | 0x00 | |
| 0x2b-0x4a | ec f815 ad98 3df6 bf81...9282 8a |
Service Hash | 32 | SHA3-256 | Hash of sec.oping.tut.o7s
|
Ouroboros Allocation Protocol (OAP) - FLOW_REQ Payload (No Encryption)
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x4b-0x5a | 8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 fa |
ID | 16 | 128-bit identifier | Unique flow allocation identifier |
| 0x5b-0x62 | 18 86a8 e490 0de6 61 |
Timestamp | 8 | Network order | Creation timestamp |
| 0x63-0x64 | 0000 |
Crt_len | 2 | 0x0000 | No certificate in client request |
| 0x65-0x66 | 0000 |
Eph_len | 2 | 0x0000 | No ephemeral key (no encryption) |
| 0x67-0x68 | 0000 |
Data_len | 2 | 0x0000 | No application data |
| 0x69-0x6a | 0000 |
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):
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 ...)
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0000 |
EID | 2 | 0x0000 | Destination Endpoint ID (management channel) |
| 0x02-0x03 | 02dd |
Length | 2 | 733 bytes | Total payload length |
Ethernet Flow Allocator - Management Protocol
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x05 | 0041 |
SEID | 2 | 0x0041 | Source Endpoint ID (allocated server flow) |
| 0x06-0x07 | 0040 |
DEID | 2 | 0x0040 | Destination Endpoint ID (client flow) |
| 0x08-0x23 | 0000 ... 0000 |
QoS (Various) | 28 | 0 | |
| 0x24-0x27 | 0000 0000 |
Response | 4 | 0x00000000 | Response code: 0 (success) |
| 0x28 | 00 |
QoS (In-Order) | 1 | 0 | |
| 0x29 | 01 |
Code | 1 | 0x01 | Message Type: FLOW_REPLY |
| 0x2a | 00 |
QoS (Availability) | 1 | 0x00 |
Ouroboros Allocation Protocol (OAP) - FLOW_REPLY Payload with Certificate and Signature (No Ephemeral Key)
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x2b-0x3a | 8f a6ab 6ea7 ef89 68e1 ed1e 2ede 0919 |
ID | 16 | 128-bit identifier | Same ID as client's FLOW_REQ (Packet 15 echoed back) |
| 0x3b-0x42 | fa18 86a8 e490 3754 |
Timestamp | 8 | Network order | Server's timestamp |
| 0x43-0x44 | a702 |
Crt_len | 2 | 0x02a7 (679 decimal) | Certificate length: 679 bytes |
| 0x45-0x270 | 2f30 8202 2b30 8201 b2a0 0302 ... (DER certificate) ... |
Certificate | 679 | DER-encoded X.509 | Server's certificate signed by intermediate CA |
| 0x271-0x272 | 0000 |
Eph_len | 2 | 0x0000 | No ephemeral key (no encryption) |
| 0x273-0x274 | 0000 |
Data_len | 2 | 0x0000 | No application data |
| 0x275-0x276 | 0067 |
Sig_len | 2 | 0x0067 (103 decimal) | ECDSA signature length: 103 bytes |
| 0x277-0x2dd | 3065 0230 75dc 5717 ... 83 |
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 -
crt_len = 0x02a7 (679)carrying server's X.509 certificate signed by intermediate CA - Separate Signature Field -
sig_len = 0x0067 (103)with ECDSA signature over entire OAP header - No Ephemeral Key -
eph_len = 0x0000since 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:
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 ....
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0041 |
EID | 2 | 0x0041 | Destination Endpoint ID (server flow) |
| 0x02-0x03 | 0040 |
Length | 2 | 64 bytes | Total application data length |
Application Data - Oping Echo Request (Plaintext)
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x07 | 0000 0000 |
Type | 4 | 0x00000000 | Message type: ECHO_REQUEST |
| 0x08-0x0b | 0000 0000 |
ID | 4 | 0x00000000 | Sequence number / message identifier |
| 0x0c-0x13 | 8177 0000 0000 0000 |
Timestamp (seconds) | 8 | Network-byte-order 64-bit | Seconds component from CLOCK_REALTIME |
| 0x14-0x1b | aa16 1c16 0000 0000 |
Timestamp (nanoseconds) | 8 | Network-byte-order 64-bit | Nanoseconds component (0-999999999) |
| 0x1c-0x43 | 0000 ... 0000 |
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:
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 ....
Ethernet DIX Frame with EID Header
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x00-0x01 | 0040 |
EID | 2 | 0x0040 | Destination Endpoint ID (client flow) |
| 0x02-0x03 | 0040 |
Length | 2 | 64 bytes | Total application data length |
Application Data - Oping Echo Reply (Plaintext)
| Offset | Hex | Field | Size | Value | Notes |
|---|---|---|---|---|---|
| 0x04-0x07 | 0000 0001 |
Type | 4 | 0x00000001 | Message type: ECHO_REPLY |
| 0x08-0x0b | 0000 0000 |
ID | 4 | 0x00000000 | Echo of request sequence number |
| 0x0c-0x13 | 8177 0000 0000 0000 |
Timestamp (seconds) | 8 | Network-byte-order 64-bit | Echoed request timestamp (seconds) |
| 0x14-0x1b | aa16 1c16 0000 0000 |
Timestamp (nanoseconds) | 8 | Network-byte-order 64-bit | Echoed request timestamp (nanoseconds) |
| 0x1c-0x43 | 0000 ... 0000 |
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)