Ouroboros - User contributions [en]

Flow and Retransmission Control Protocol

2026-05-25T17:48:52Z

Zen:

{{DISPLAYTITLE:FRCP - Flow and Retransmission Control Protocol}}

Flow and Retransmission Control Protocol (FRCP) is one of the five
[[Ouroboros Protocols]] that define how the network operates.

FRCP runs end-to-end between two peers over a flow. It delivers
reliability, in-order delivery, flow control, and liveness.
Congestion Control (CC) is not in FRCP - that lives in the IPC
Process (IPCP) Congestion Avoidance (CA) policies, orthogonal to
FRCP. Flow allocation, naming, and IPCP lifecycle are handled by
the IPC Resource Manager daemon (IRMd).

FRCT (Flow and Retransmission Control Task) is the libouroboros
implementation of FRCP; the task lives in <code>src/lib/frct.c</code>. The
remainder of this document describes the FRCP wire protocol and the
behaviour FRCT realises. Code symbols retain the <code>FRCT_</code> prefix
(<code>FRCT_DATA</code>, <code>FRCT_RXM</code>, ...) because they belong to the implementing
task; this document references them verbatim.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <code>BCP</code> 14 (Best
Current Practice; RFC 2119, RFC 8174) when, and only when, they
appear in all capitals.

== Notation ==

;<code>u32</code>, <code>u8</code>
:Unsigned 32-bit / 8-bit integers (kernel-C style).
;<code>ns</code>
:Nanoseconds.

Modular sequence-number comparators (32-bit, modulo 2^32):

;<code>before(a, b)</code>
:<code>(int32_t)(a - b) < 0</code>
;<code>after(a, b)</code>
:<code>before(b, a)</code>

Used throughout for <code>ackno</code> / <code>seqno</code> ordering checks.

Round-Trip Time (RTT) abbreviations used throughout:

;<code>SRTT</code>
:Smoothed RTT estimate (RFC 6298).
;<code>mdev</code>
:Mean deviation of RTT (Linux variance estimator).
;<code>EWMA</code>
:Exponentially Weighted Moving Average.
;<code>RTO</code>
:Retransmission Timeout, <code>max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code>.

Timer-bound symbols <code>t_a</code> (a-timer, ACK delay) and <code>t_r</code> (r-timer,
retransmission window) are defined in [[#8. Retransmission|Section 8]]; <code>t_mpl</code> (Maximum
Packet Lifetime) is introduced in [[#2.1. Per-flow state|Section 2.1]] (the <code>inact</code> field)
with heritage in [[#15. Heritage and adopted techniques|Section 15]].

Wire-format diagrams follow the IETF convention: bit 0 is the
leftmost (most significant) bit and fields are in network byte
order unless stated otherwise.

__TOC__

== 1. Wire format ==

=== 1.1. PCI header ===

Fixed 16-octet base Protocol-Control Information (PCI) header
prefixed to every FRCP packet (RFC convention: bit 0 leftmost,
most-significant bit first). All multi-byte fields are in network byte order. DATA packets on
stream-mode flows carry an additional 8-octet extension (see
[[#1.5. Stream PCI extension|Section 1.5]]); SACK and RTTP carry their own payloads after the
base PCI.

<syntaxhighlight lang="text">
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 | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>flags</code>
:feature/type bitmap (see [[#1.2. Flag bits|Section 1.2]]).
;<code>hcs</code>
:CRC-16-CCITT-FALSE Header Check Sequence (HCS) over <code>flags</code> + <code>window</code> + <code>seqno</code> + <code>ackno</code> (+ stream extension when present); the two octets of the <code>hcs</code> field itself are omitted from the CRC input. Verified on receive before any flag-driven dispatch.
;<code>window</code>
:receiver-advertised right window edge (valid iff FC).
;<code>seqno</code>
:per-flow sequence number.
;<code>ackno</code>
:cumulative Acknowledgement (ACK) (valid iff ACK).

A single packet can simultaneously carry DATA + ACK + FC (Flow
Control) + RXM (Retransmission) by ORing flag bits; the PCI
multiplexes control on the same wire frame in the spirit of SCTP
chunk bundling (RFC 9260 sec. 6.10) and QUIC frame multiplexing
(RFC 9000 sec. 12.4). DATA-bearing packets carry the caller's
payload after the PCI; SACK (Selective Acknowledgement) and RTTP
(Round-Trip Time Probe) carry their own typed payloads after the
PCI.

Optional framing (per-flow, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]]). On the wire, the
order from inside out is:

{| class="wikitable"
! Layer !! Scope
|-
| <code>[ PCI + body ]</code>
| The FRCP packet.
|-
| <code>[ PCI + body + CRC-32 ]</code>
| CRC-32 covers the body only (PCI is in HCS); appended iff <code>qs.ber == 0</code> on DATA, or on every SACK packet.
|-
| <code>[ AEAD-wrap of above ]</code>
| Iff Authenticated Encryption with Associated Data (AEAD) is enabled.
|}

* HCS in the PCI covers the header fields on every packet and is verified before any flag-driven dispatch.
* The CRC-32 trailer (IEEE 802.3 / zlib reflected polynomial <code>0xEDB88320</code>, init <code>0xFFFFFFFF</code>, xor-out <code>0xFFFFFFFF</code>) covers the body on DATA when <code>qs.ber == 0</code> and on every SACK packet. The PCI is not under the CRC (Cyclic Redundancy Check) because the HCS already protects it. It is appended before AEAD encryption and therefore rides inside the AEAD wrap when both are active; the AEAD tag (~2^-128 forgery probability) dominates the CRC (~2^-32) for integrity in that mode but the CRC trailer is currently retained.
* When encryption is enabled, the entire (possibly-CRC'd) FRCP packet is wrapped with AEAD inside the shared-memory packet buffer (<code>spb</code>, <code>struct ssm_pk_buff</code>); the packet grows by the AEAD overhead, namely a leading nonce / Initialization Vector (IV) of <code>headsz</code> bytes (<code>crypt_get_ivsz</code>) and a trailing authentication tag of <code>tailsz</code> bytes (<code>crypt_get_tagsz</code>).

Both CRC and AEAD are layered around the FRCP wire format and are not visible to the FRCP machinery itself.

=== 1.2. Flag bits ===

Flag bits are numbered most-significant-bit first to match the wire
diagram (bit numbering per [[#1.1. PCI header|Section 1.1]]; bit 0 is the MSB of the
16-bit <code>flags</code> field and lands at wire-position 0 in network byte
order). Bits 13..15 are reserved and MUST be transmitted as zero.

{| class="wikitable"
! Bit !! Mask !! Name !! Meaning
|-
| 0 || <code>0x8000</code> || <code>DATA</code> || Carries caller payload
|-
| 1 || <code>0x4000</code> || <code>DRF</code> || Data Run Flag: start of a fresh run
|-
| 2 || <code>0x2000</code> || <code>ACK</code> || Acknowledgement: <code>ackno</code> field valid
|-
| 3 || <code>0x1000</code> || <code>NACK</code> || Negative ACK; <code>seqno = arrival_seqno-1</code>
|-
| 4 || <code>0x0800</code> || <code>FC</code> || Flow Control: <code>window</code> field valid (<code>rwe</code>)
|-
| 5 || <code>0x0400</code> || <code>RDVS</code> || Rendezvous probe (window-closed)
|-
| 6 || <code>0x0200</code> || <code>FFGM</code> || First Fragment (role bit 0; see below)
|-
| 7 || <code>0x0100</code> || <code>LFGM</code> || Last Fragment (role bit 1; see below)
|-
| 8 || <code>0x0080</code> || <code>RXM</code> || Retransmission
|-
| 9 || <code>0x0040</code> || <code>SACK</code> || Selective ACK block list in payload
|-
| 10 || <code>0x0020</code> || <code>RTTP</code> || RTT Probe / echo (payload follows)
|-
| 11 || <code>0x0010</code> || <code>KA</code> || Keepalive
|-
| 12 || <code>0x0008</code> || <code>FIN</code> || End-of-stream marker (stream mode)
|-
| 13-15 || -- || -- || Reserved (MUST be zero)
|}

The (<code>FFGM</code>, <code>LFGM</code>) pair encodes the fragment role of a DATA-bearing
Service Data Unit (SDU), SCTP-style begin/end flags (RFC 9260
sec. 3.3.1):

{| class="wikitable"
! FFGM !! LFGM !! Role
|-
| 1 || 1 || Sole / un-fragmented SDU (begin AND end)
|-
| 1 || 0 || First fragment of a multi-fragment SDU
|-
| 0 || 0 || Middle fragment
|-
| 0 || 1 || Last fragment
|}

Each fragment is carried in its own FRCP packet with its own <code>seqno</code>;
FRTX (the FRCT Retransmission service mode, see [[#2.2. Service modes (orthogonal axes)|Section 2.2]])
recovers individual fragments via the normal Retransmission Timeout
(RTO) / SACK / Recent Acknowledgement (RACK, RFC 8985) path. The
receiver reassembles the SDU at consume time once the contiguous
[FIRST .. LAST] run has fully arrived. On non-DATA packets the role
bits are unused and MUST be transmitted as zero.

In stream mode (<code>qos.service == SVC_STREAM</code>, see [[#16. Stream-mode flows|Section 16]]) there are
no SDU boundaries to encode, so <code>FFGM</code> and <code>LFGM</code> are unused and MUST
be transmitted as zero. End-of-stream uses a dedicated bit (<code>FIN</code>,
bit 12) carried on a 0-byte DATA packet, emitted at write-half close
(<code>fccntl</code> to <code>FLOWFRDONLY</code>), during linger drain, and at <code>flow_dealloc</code>;
emission is idempotent (first call wins). After contiguous delivery
of the FIN-bearing slot, the receiver latches <code>byte_fin</code> at the FIN's
start offset; <code>flow_read</code> returns 0 (end-of-file, <code>EOF</code>) once buffered
bytes have been drained up to <code>byte_fin</code>. Per-byte position is
carried by the [start, end) extension ([[#1.5. Stream PCI extension|Section 1.5]]).

=== 1.3. SACK payload ===

A SACK packet has the <code>FRCT_ACK | FRCT_FC | FRCT_SACK</code> flag bits set
(bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI, the
payload is a 2-octet block count (network byte order), 2 octets of
padding to 4-byte align the block list, then <code>n_blocks</code> pairs of
32-bit start/end seqnos describing ''present'' (received) ranges
above the cumulative ACK.

<syntaxhighlight lang="text">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_blocks | padding (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
</syntaxhighlight>

<code>n_blocks <= SACK_MAX_BLOCKS</code> (2048). The per-flow effective cap is
further bounded by <code>(frag_mtu - PCI - 4) / 8</code> blocks per packet; SACK
packets carry no stream extension, so PCI here is the 16-octet base
header even on stream-mode flows.

Wire invariant: every block produced by the receiver, except an
optional leading Duplicate SACK (D-SACK) block as described below,
describes a range strictly above the cumulative ACK carried in the
PCI <code>ackno</code> field (<code>after(start[i], ackno)</code>). This makes the D-SACK
convention below unambiguous; the receiver-side builder MUST
preserve it.

Duplicate SACK (D-SACK, RFC 2883) is signalled in-band: no flag
bit, no extra framing. Modular seqno arithmetic uses the
<code>before()</code> / <code>after()</code> comparators defined in the Notation block.

Encoding. When a duplicate is observed the receiver arms a
single-slot pending report (<code>dsack_seqno</code> + <code>dsack_valid</code>,
latest-wins across multiple arms before the next emit). On the
next outbound SACK the receiver prepends <code>block[0] = [dsack_seqno,
dsack_seqno + 1)</code> - always a one-<code>seqno</code> range - and clears the
flag. The three arm sites are listed in [[#10. Cumulative + selective ACK|Section 10]]; case-1 sites
yield <code>dsack_seqno < rcv_cr.lwe</code> (the next <code>pci.ackno</code>), and the
case-2 site (<code>rq_accept</code> conflict) yields <code>dsack_seqno</code> in
<code>[rcv_cr.lwe, rcv_cr.rwe)</code>.

Detection. The sender classifies <code>block[0]</code> by its relation to
<code>pci.ackno</code>:

;case 1 (RFC 2883 sec. 4.1.1, full duplicate)
:<code>before(blocks[0].start, pci.ackno)</code> AND <code>pci.ackno - blocks[0].start <= MAX_DSACK_LAG</code> (<code>== RQ_SIZE</code>). The lag bound rejects stale or spoofed reports beyond one receive window.
;case 2 (RFC 2883 sec. 4.1.2, partial duplicate)
:<code>blocks[0]</code> is a sub-range (with at least one endpoint differing) of some <code>blocks[i>0]</code> - i.e. the same packet's remaining SACK blocks already describe the duplicated <code>seqno</code> as received.

On detect, the sender:

* bumps <code>reo_wnd_mult</code> by 1, capped at <code>REO_WND_MULT_MAX</code> (= 20), per RFC 8985 sec. 6.2 step 4;
* snapshots <code>dsack_lwe_snap = snd_cr.lwe</code>, resetting the 16-cum-ACK halving counter so the multiplier doesn't decay while D-SACK evidence is still arriving;
* excludes <code>block[0]</code> from the gap-marking loop (<code>n_real = n - 1</code>), so a D-SACK alone never enters NewReno-careful recovery (see [[#8. Retransmission|Section 8]]); only non-D-SACK blocks count as gaps.

The <code>reo_wnd_mult</code> halving cadence (once per 16 cumulatively-ACK'd
seqnos since the most-recent D-SACK arrival or halve event) and
the reset-to-1 on a HoL RTO fire are both per the same RFC 8985
clause. The clamp-and-skip path in the regular SACK-mark loop is
incidentally idempotent on any leftover case-1 or case-2 block
(<code>start < snd_cr.lwe</code> clamps to <code>snd_cr.lwe</code> and the inner loop
skips <code>k == snd_cr.lwe</code>; case-2 re-NULLs slots already marked
received by later blocks), so block[0] is harmless even when fed
to the loop.

=== 1.4. RTTP payload ===

An RTTP (Round-Trip Time Probe) packet has only the <code>FRCT_RTTP</code> flag
set (bit numbering per [[#1.1. PCI header|Section 1.1]]). Following the 16-octet PCI,
the payload is 24 octets (packed):

<syntaxhighlight lang="text">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| probe_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| echo_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ nonce (16 octets, echoed verbatim) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>probe_id</code>
:sender counter, 0 on reply, 0 reserved.
;<code>echo_id</code>
:peer's <code>probe_id</code>, 0 on outbound probe.
;<code>nonce</code>
:random, echoed unmodified, memcmp'd to defeat spoof.

=== 1.5. Stream PCI extension ===

A stream-mode flow (<code>qos.service == SVC_STREAM</code>) carries an extra
8-octet extension after the 16-octet base PCI on every DATA packet
(bit numbering per [[#1.1. PCI header|Section 1.1]]):

<syntaxhighlight lang="text">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</syntaxhighlight>

;<code>start</code>
:octet offset of the first payload byte in the stream.
;<code>end</code>
:octet offset one past the last payload byte; <code>end - start</code> equals the on-wire payload length.

Total stream-mode PCI for DATA packets is 24 octets (16 base + 8
extension); control packets (SACK, RTTP, bare ACK, KA, etc.) retain
the 16-octet base PCI. Stream mode MUST be negotiated at flow
allocation; the extension is present iff stream mode is in use,
never on a per-packet basis. Both peers MUST treat <code>start</code>/<code>end</code> as
monotonic 32-bit byte offsets; when a slot reaches the head of the
contiguous run with <code>start</code> not equal to the prior packet's <code>end</code> the
slot is silently dropped at delivery time ([[#16. Stream-mode flows|Section 16]]) rather
than rejected at stash.

This is the QUIC STREAM-frame reassembly model (RFC 9000 sec. 19.8):
each packet carries its packet <code>seqno</code> (this PCI's <code>seqno</code> field) and a
separate stream byte position (<code>start</code>/<code>end</code>). Separating the two
avoids TCP's conflation of packet identity with byte position which
forces Karn's algorithm for Round-Trip Time (RTT) sampling (no RTT
sample on retransmits, RFC 6298 sec. 3); FRCP applies the
Karn-equivalent gate via a combination of per-packet <code>FRCT_RXM</code>,
per-slot <code>SND_RTX</code> flags, and a sample-fence <code>rtt_lwe</code> (see [[#2.1. Per-flow state|Section 2.1]]
and [[#12. RTT estimation|Section 12]]). FRCP's fixed-32-bit <code>start</code>/<code>end</code> wrap at 4 GiB of
wire bytes, narrower than QUIC's 62-bit varint offset (cf. RFC 9000
sec. 16); the on-wire wrap is handled by the same modular <code>before()</code>
/ <code>after()</code> comparators ([[#1.3. SACK payload|Section 1.3]]) FRCP uses for seqnos, which
remain unambiguous as long as the in-flight byte window stays
strictly under 2 GiB (the half-range of the signed-int32 difference
in <code>before()</code>). The default per-flow ring is 1 MiB; the
implementation caps <code>ring_sz</code> at 128 MiB (<code>FRCT_STREAM_RING_SZ_MAX</code>),
well below the 2 GiB half-range bound. The runtime byte counters
exposed via FUSE (Filesystem in Userspace) in the Ouroboros
Resource Information Base (RIB, a virtual-filesystem introspection
bridge) are platform <code>size_t</code> and do not wrap on 64-bit hosts.

== 2. Per-flow state and service modes ==

=== 2.1. Per-flow state ===

Each flow keeps a sender control record and a receiver control
record:

;<code>lwe</code> : <code>u32</code>
:snd: oldest unacked <code>seqno</code> (cumulative ACK boundary as seen by sender); rcv: next in-order <code>seqno</code> expected
;<code>rwe</code> : <code>u32</code>
:snd: peer-advertised right window edge; rcv: locally-advertised right window edge
;<code>cflags</code> : <code>u8</code>
:per-direction feature flags: retransmission (<code>FRCTFRTX</code>), receiver flow control (<code>FRCTFRESCNTL</code>), linger-on-close (<code>FRCTFLINGER</code>); see <code><ouroboros/fccntl.h></code>
;<code>seqno</code> : <code>u32</code>
:snd: next <code>seqno</code> to send; rcv: force-ACK trigger - set on a stale or dup DATA so the next <code>ack_snd</code> emits a fresh cumulative ACK
;<code>ackno</code> : <code>u32</code>
:snd: <code>seqno</code> counter for standalone ACK-bearing control packets (delayed ACK, SACK, final ACK on dealloc); not bumped on piggybacked ACK riding a DATA packet (which uses the DATA <code>seqno</code>). Used by wire-dup ACK detection; rcv: incoming-ACK dedup tracker
;<code>act</code> : <code>ns</code>
:last activity (used by inactivity / DRF)
;<code>inact</code> : <code>ns</code>
:inactivity threshold; sender = <code>3*mpl + a + r + 1s</code>, receiver = <code>2*mpl + a + r + 1s</code>. <code>mpl</code> is the Maximum Packet Lifetime (delta-t terminology; see [[#15. Heritage and adopted techniques|Section 15]]); <code>a</code> and <code>r</code> are the FRCT a-timer and r-timer bounds (see [[#8. Retransmission|Section 8]]). The asymmetry is load-bearing for pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

The sender holds a per-slot ring <code>snd_slots[RQ_SIZE]</code> keyed by
<code>(seqno mod RQ_SIZE)</code>. Each slot tracks its retransmit entry (<code>rxm</code>),
last-send timestamp, and retransmit flag bits: <code>SND_RTX</code> (a
retransmit is pending or has fired, gates the next RTT sample
under Karn) and <code>SND_FAST_RXM</code> (one-shot fast-retransmit staged for
this loss event).

The receiver holds a parallel reorder ring <code>rcv_slots[RQ_SIZE]</code>
(referred to as <code>rq[]</code> in prose) holding stashed out-of-order
packet-buffer indexes; both FRTX and best-effort flows share this
path. The invariant <code>rwe - lwe <= RQ_SIZE</code> holds: on each consume
the receiver advances <code>rwe</code> by the consumed count, capping the
receive window at <code>RQ_SIZE</code> <code>seqno</code> slots.

A separate fence variable <code>rtt_lwe</code> is bumped on every retransmit
(timer-fire, SACK-driven, fast-rxm, NACK-driven) and on every
<code>seqno_rotate</code> ([[#4. Sequence-number rotation (DRF)|Section 4]]) to mark the <code>seqno</code> range whose RTT samples
MUST be discarded.

=== 2.2. Service modes (orthogonal axes) ===

FRCP exposes its wire features as a vector of independent QoS
axes selected at flow allocation time. All flows go through the
same <code>flow_alloc(name, qos, ...)</code> primitive; the <code>qosspec_t</code> passed
in determines which protocol machinery engages on the wire. This
contrasts with the POSIX BSD socket model where TCP and UDP
require different socket types (<code>SOCK_STREAM</code> / <code>SOCK_DGRAM</code>).

The axes:

;<code>service</code>
:0 = unordered (no FRCP engagement: raw datagrams, no PCI on the wire, UDP-equivalent at this layer); 1 = message-ordered (FRCP engaged; SDU boundaries preserved across fragmentation); 2 = stream (byte-oriented, no SDU boundaries; FRTX required)
;<code>loss</code>
:0 = lossless service requested: FRTX retransmit machinery engages ([[#8. Retransmission|Section 8]]); MUST be 0 for <code>service=2</code>. Non-zero = best-effort, FRTX off.
;<code>ber</code>
:Bit Error Rate tolerance. 0 = error-free service requested: a CRC trailer is appended after the body of DATA packets and verified on receive (added / checked outside the FRCP PCI; see [[#1.1. PCI header|Section 1.1]]). Non-zero = peer accepts errors; trailer omitted. SACK control packets carry a CRC32 trailer regardless of <code>ber</code>; the <code>ber</code> gate applies to DATA only.
;<code>timeout</code>
:Peer-timeout (ms); 0 disables the keepalive timer. Independent of FRCP engagement.

Encryption is a separate per-flow attribute set at flow setup;
when enabled it wraps the FRCP packet (PCI + body, plus the CRC
trailer if any) under AEAD, expanding the <code>spb</code> by <code>headsz</code> + <code>tailsz</code>
octets (nonce / tag). The CRC trailer is currently kept inside
the AEAD wrap (see [[#1.1. PCI header|Section 1.1]]).

Reachable combinations exported by <code>include/ouroboros/qos.h</code>:

{| class="wikitable"
! Cube !! <code>service</code> !! <code>loss</code> !! <code>ber</code> !! Engaged
|-
| <code>qos_raw</code> || 0 || 1 || 1 || Raw passthrough
|-
| <code>qos_raw_safe</code> || 0 || 1 || 0 || Raw + CRC trailer
|-
| <code>qos_rt</code> || 1 || 1 || 1 || FRCP, no FRTX, no CRC
|-
| <code>qos_rt_safe</code> || 1 || 1 || 0 || FRCP, no FRTX, CRC
|-
| <code>qos_msg</code> || 1 || 0 || 0 || FRCP + FRTX
|-
| <code>qos_stream</code> || 2 || 0 || 0 || FRCP + FRTX, stream
|}

Forced couplings actually enforced by the public API:

* <code>service == SVC_STREAM</code> (2) requires <code>loss == 0</code>; <code>flow_alloc</code> / <code>flow_accept</code> reject the pair otherwise with <code>-EINVAL</code>.
* FRTX requires FRCP engagement (<code>service != SVC_RAW</code>); requesting <code>loss = 0</code> with <code>service = SVC_RAW</code> is structurally a no-op because no <code>frcti</code> is created.
* The <code>QOS_DISABLE_CRC</code> build flag globally forces <code>ber = 1</code>. Note: this flag defaults to ON, so default builds ship with CRC disabled until <code>QOS_DISABLE_CRC</code> is set to OFF.

Caveat: the API does NOT force <code>ber = 0</code> when <code>service != SVC_RAW</code>.
<code>qos_rt</code> has <code>service = SVC_MESSAGE</code> with <code>ber = 1</code>, which means the PCI
itself is not CRC-protected on that cube; the HCS ([[#1.1. PCI header|Section 1.1]])
remains the only integrity check on the header.

The FRCP-no-FRTX regime (<code>service = SVC_MESSAGE</code>, <code>loss > 0</code>) is meaningful
and live: sequence numbering, in-order delivery, flow-control
advertisement, KA, DRF rotation, and SDU fragmentation /
reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]) all run. Lost packets are dropped
rather than retransmitted; a permanently-lost mid-fragment is
dropped via skip-past-gap once a later SDU is visible in the
reorder ring.

== 3. Protocol parameters ==

{| class="wikitable"
! Parameter !! Value !! Role
|-
| <code>RQ_SIZE</code> || compile-time, power of 2 (default 128) || Slot ring / rcv window width
|-
| <code>START_WINDOW</code> || compile-time, power of 2 (default 128) || Initial <code>rwe-lwe</code> after rotate
|-
| <code>RTO_MIN</code> || <code>MAX(250 us build-tunable, 1<<RXMQ_RES)</code>; per-flow via <code>fccntl</code> (<code>FRCTSRTOMIN</code>). Default ~1 ms with <code>RXMQ_RES=20</code>. || RTO floor; also floored at the retransmit-wheel resolution (~1 ms by default).
|-
| <code>MAX_RTO_MUL</code> || 20 || Backoff shift cap
|-
| RACK window <code>R</code> || <code>MIN(reo_wnd_mult * min_RTT/4, SRTT)</code> with <code>MIN_REORDER_NS = 250 us</code> floor; <code>reo_wnd_mult</code> scales on D-SACK, cap 20 || Reorder window; per RFC 8985 sec. 6.2; <code>reo_wnd_mult</code> per sec. 6.2 step 4
|-
| <code>MIN_RTT_WIN_NS</code> || 300 s (5 min, Linux <code>tcp_min_rtt_wlen</code>) || <code>min_RTT</code> windowed re-anchor
|-
| <code>REO_WND_MULT_MAX</code> || 20 (RFC 8985 sec. 6.2 step 4) || <code>reo_wnd_mult</code> cap
|-
| <code>REO_DECAY_PKTS</code> || 16 (RFC 8985 sec. 6.2 step 4 / <code>RACK.reo_wnd_persist</code>) || Fresh-ACK'd seq count per halving
|-
| <code>MAX_DSACK_LAG</code> || <code>RQ_SIZE</code> || D-SACK sanity cap
|-
| <code>RTT_QUARANTINE</code> || 32 (<code>seqno</code> steps) || NewReno gate pad
|-
| SACK rate-limit || <code>SACK_MIN_GAP_NS</code> (250 us, fixed) || Min SACK gap
|-
| <code>SACK_MAX_BLOCKS</code> || 2048 (wire cap; per-flow capped at <code>(frag_mtu-PCI-4)/8</code>) || Per-SACK block cap
|-
| <code>SACK_RXM_MAX</code> || 32 || Per-pass staged retransmit cap
|-
| <code>DUP_THRESH</code> || 3 (RFC 8985 default) || Hybrid fast-rxm trigger ([[#8. Retransmission|Section 8]])
|-
| <code>MDEV_MUL</code> || 2 (build-tunable via <code>FRCT_RTO_MDEV_MULTIPLIER</code>) || <code>mdev</code> shift in <code>RTO = srtt + (mdev << MDEV_MUL)</code>
|-
| RTTP nonce || 16 octets || Echoed verbatim
|-
| <code>RTTP_RING</code> || 8 || In-flight probes
|-
| RTT clamp || <code>16 * srtt</code> || Probe-sample upper bound (ACK-derived RTT samples gated by Karn / recovery only)
|-
| Cold-probe cadence || 100 ms (rx-driven; see [[#12. RTT estimation|Section 12]]) || Pre-<code>srtt</code> RTTP rate
|-
| <code>DELT_RDV</code> || 100 ms || RDVS emit cadence
|-
| <code>MAX_RDV</code> || 1 s || RDVS give-up
|-
| Delayed-ACK fire || <code>2 * TICTIME</code> (<code>TICTIME</code> = FRCT tick granularity, default 5 ms; <code>2*TICTIME = 10 ms</code> by default) || Fired after the first in-order DATA arrival; tick is build-tunable
|-
| NACK send cooldown || <code>srtt</code> when an <code>srtt</code> sample exists, else 100 ms || Pre-DRF NACK rate-limit
|-
| <code>MAX_SDU</code> || 1 MiB || Max reassembled SDU; configurable per flow
|}

The per-flow fragment Maximum Transmission Unit (MTU) is computed
at flow setup from the lower IPCP's mtu minus encryption
<code>headsz</code> / <code>tailsz</code> and CRC trailer; there is no FRCT-level default or
environment-variable override.

== 4. Sequence-number rotation (DRF) ==

The DRF (Data Run Flag) bit on an outbound packet means "this is
the start of a fresh data run" and is set whenever the sender has
nothing in flight (<code>snd_cr.seqno == snd_cr.lwe</code>).

Independently of that, if the sender has been idle longer than
<code>snd_cr.inact</code> AND the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>),
<code>seqno_rotate()</code> rolls a random new <code>seqno</code> before the send and
resets

<syntaxhighlight lang="text">
snd_cr.seqno = random()
snd_cr.lwe = snd_cr.seqno
snd_cr.rwe = snd_cr.seqno + START_WINDOW
rtt_lwe = snd_cr.seqno
in_recovery = false (recovery state, see Section 8)
recovery_high = snd_cr.seqno
</syntaxhighlight>

The receiver, on observing rcv-side inactivity
(<code>now - rcv_cr.act > rcv_cr.inact</code>), requires a DRF on the next
DATA packet; otherwise it replies with a rate-limited NACK (see
below). Non-DATA control packets pass through without the DRF
requirement (no impact on receiver state). On DRF the receiver releases the <code>rq[]</code> slots and
rebases

<syntaxhighlight lang="text">
rcv_cr.lwe = seqno
rcv_cr.rwe = seqno + RQ_SIZE
rcv_cr.seqno = seqno
</syntaxhighlight>

If the inactive packet has DATA but no DRF, a rate-limited NACK is
fired back to the sender (cooldown per [[#3. Protocol parameters|Section 3]]); non-DATA stale
arrivals fall through to normal processing (no NACK, no drop).

== 5. Send path ==

# If the SDU exceeds <code>(frag_mtu - data_hdr_len)</code>, the caller (<code>dev.c</code>) fans it out into <code>ceil(count / (frag_mtu - data_hdr_len))</code> fragments, each emitted via <code>frcti_snd</code> as its own DATA packet with a per-fragment role ([[#7.2. Fragmentation and reassembly|Section 7.2]]); both FRTX and best-effort flows fragment. Raw flows (no FRCP engagement, <code>qos.service == SVC_RAW</code>) carry no PCI and return <code>-EMSGSIZE</code> for any SDU larger than one packet at the layer below. An SDU that fits in a single packet is sent as SOLE. <code>frcti_snd</code> reserves PCI head room; sets DATA, plus DRF when the pipe is empty (<code>snd_cr.seqno == snd_cr.lwe</code>).
# <code>seqno_rotate()</code> if past sender inactivity and the pipe is empty ([[#4. Sequence-number rotation (DRF)|Section 4]]).
# Advertise FC (<code>pci.window = frcti_advert_rwe(frcti)</code>, i.e. <code>rcv_cr.rwe</code> clamped to <code>rcv_cr.lwe + ring_seq_cap</code> in stream mode) when the receiver side is recent: <code>now - rcv_cr.act < rcv_cr.inact</code>.
# Reliable mode (FRTX): leave <code>snd_cr.lwe</code> where it is; reset the slot at <code>RQ_SLOT(seqno)</code> (<code>snd_slots[p].time = now</code>, <code>snd_slots[p].flags = 0</code>); queue an <code>rxm_entry</code> (saves a packet copy, arms a wheel timer at <code>now + (rto << rto_mul)</code>). Piggyback ACK (<code>pci.ackno = rcv_cr.lwe</code>) while the a-timer for the most recent received DATA packet has not yet expired (<code>now - rcv_cr.act <= t_a</code>); on piggyback, set <code>rcv_cr.seqno = rcv_cr.lwe</code> so the next delayed-ACK fire is suppressed. See [[#8. Retransmission|Section 8]] for <code>t_a</code> / <code>t_r</code> semantics.
# Best-effort mode (no FRTX): advance <code>snd_cr.lwe</code> immediately (<code>snd_cr.lwe = snd_cr.lwe + 1</code>, <code>snd_cr.rwe = snd_cr.lwe + RQ_SIZE</code>); no retransmit state. No send-side RTT probe is armed in this mode (<code>rtt_probe_arm</code> requires an in-flight <code>seqno</code>, which best-effort never has); the rx-driven cold seeder in <code>frcti_rcv</code> is the only probe path.
# In reliable mode, optionally arm an RTT probe ([[#12. RTT estimation|Section 12]]).

== 6. Receive path ==

=== 6.1. Early-exit dispatch ===

Keepalive (KA), RTT probe (RTTP), pre-DRF NACK, and rendezvous
(RDVS) packets short-circuit out of <code>frcti_rcv</code> before the locked
main path; each handler takes its own lock internally.

<syntaxhighlight lang="text">
incoming packet
|
v
+---------+
| KA? |---yes--> ka_rcv ; return
+---------+
|no
v
+---------+
| RTTP? |---yes--> rttp_rcv; return
+---------+
|no
v
+---------+
| NACK? |---yes--> nack_rcv; return (see Section 9)
+---------+
|no
v
+---------+
| RDVS? |---yes--> rdv_rcv ; return (reply bare FC, ackno=0)
+---------+
|no
v
acquire wrlock; enter locked main path
</syntaxhighlight>

;<code>KA</code>
:refresh <code>t_ka_rcv</code>, honour piggybacked ACK.
;<code>RTTP</code>
:probe (echo back nonce) or echo (verify nonce, sample RTT).
;<code>NACK</code>
:pre-DRF, sender-side handler. See [[#9. Pre-DRF NACK|Section 9]].
;<code>RDVS</code>
:reply with a bare FC packet (<code>ackno = 0</code>); <code>rdlock</code> only.

=== 6.2. Locked main path ===

Steps below run with the per-flow <code>frcti.lock</code> held for writing
(<code>pthread_rwlock_wrlock</code>) unless noted.

;<code>rcv_inact_check</code>
:Only meaningful when the receive side is stale. On DRF (Data Run Flag): release <code>rq[]</code> slots, rebase <code>rcv_cr</code>, continue. On stale DATA without DRF: fire a pre-DRF NACK if cooldown allows ([[#9. Pre-DRF NACK|Section 9]]), then discard the packet; on cooldown, drop without sending a NACK (a pending cumulative ACK from <code>drop_packet</code> may still go out). Non-DATA, non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; pure-DRF stale arrivals fall through after the DRF rebase branch.

;DATA-only act refresh
:Refresh <code>rcv_cr.act</code> only when <code>FRCT_DATA</code> is set, so that non-DATA packets never block the next DRF rebase.

;Wire-dup gate
:Before flag-driven dispatch, drop wire-duplicate ACKs and wire-duplicate DATA (<code>is_dup_ack</code> / <code>is_dup_data</code>). The DATA check is bypassed for <code>FRCT_RXM</code>-bearing arrivals so the piggybacked ACK / SACK / FC carried on a retransmitted DATA at an already-ACK'd <code>seqno</code> is still applied; the stale-in-window branch below then drops the packet.

;<code>ACK</code>
:Drop ACKs whose <code>ackno</code> falls outside <code>(snd_cr.lwe, snd_cr.seqno]</code>. If <code>ackno == snd_cr.lwe</code> (non-advancing cumulative ACK), drive RACK fast-retransmit consideration ([[#8. Retransmission|Section 8]]). Otherwise advance <code>snd_cr.lwe = ackno</code>, collapse <code>rto_mul</code> to 0 (Karn-gated by <code>SND_RTX</code> on the just-acknowledged slot, the old head-of-line), reset <code>dup_thresh</code> to 0, update <code>t_latest_ack</code> to the send-time of the slot at <code>ackno-1</code> (consumed by RACK and SACK below), decay <code>reo_wnd_mult</code> per RFC 8985 sec. 6.2 step 4, exit NewReno-careful recovery (see [[#8. Retransmission|Section 8]]) on <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code>, and feed an RTT sample if eligible ([[#12. RTT estimation|Section 12]]).

;<code>SACK</code>
:Walk the block list. For each block (a present range above <code>lwe</code>) NULL out <code>snd_slots[k].rxm</code>, clear the slot's per-send flags, and advance <code>t_latest_ack</code> to the latest send-time covered (the Forward Acknowledgement / fack equivalent, Mathis & Mahdavi 1996); the first block whose start clamps to <code>snd_cr.lwe</code> skips this fack update so that a head-of-line clamp does not falsely advance fack. For un-SACKed gaps below <code>hi_sacked</code>, stage a retransmit per slot that is (1) still owned (<code>rxm != NULL</code>), (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK reorder window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (the RFC 8985 sec. 6.2 hybrid trigger). Mark the slot <code>SND_FAST_RXM</code> and NULL the <code>rxm</code> at stage time. Capped at <code>SACK_RXM_MAX</code> staged retransmits per receive pass; what's left rides the next SACK.

;<code>FC</code>
:Bump <code>snd_cr.rwe</code> (clamped to <code>lwe + RQ_SIZE</code>, never shrinks) and mark window open.

;<code>DATA</code>
:Bounds-check <code>seqno</code> against window. On stale-dup (<code>seqno < rcv_cr.lwe</code>), set <code>rcv_cr.seqno = seqno</code> to force a fresh ACK on the next <code>ack_snd</code>, then drop. On accept: both FRTX and best-effort stash the packet-buffer index into <code>rq[seqno mod RQ_SIZE]</code>. Fragments stash unchanged - the role bits are inspected only at consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]). On out-of-order arrival, build a SACK reply if not rate-limited (per [[#3. Protocol parameters|Section 3]]) and not deduplicated against the previous <code>(rcv_cr.lwe, n_blocks)</code> pair; D-SACK reports always bypass the dedup. If both rate-limit and dedup suppress the reply, neither SACK nor delayed-ACK fires (the sender picks up the gap on its next ACK). On in-order arrival, arm the delayed-ACK timer.

;<code>drop_packet</code> exit
:Releases the per-packet shared-memory buffer (<code>spb</code>), then calls <code>ack_snd</code> synchronously after the <code>spb</code> release to surface any pending cumulative ACK.

== 7. Read path and reassembly ==

=== 7.1. Read path ===

<code>flow_read</code> returns a full reassembled SDU (Service Data Unit) via
<code>frcti_consume</code> on every FRCP SDU-mode flow (FRTX or best-effort);
stream-mode is covered in [[#16. Stream-mode flows|Section 16]]. An incomplete head-of-line
(HoL) run yields <code>-EAGAIN</code>; an oversized run yields <code>-EMSGSIZE</code> (the
run is dropped so the flow does not stall). On best-effort flows,
a permanently-lost mid-fragment is dropped as soon as a later
complete SDU becomes visible in the ring ([[#7.2. Fragmentation and reassembly|Section 7.2]] skip-past-
gap).

Raw flows carry no <code>frcti</code>, so <code>flow_read</code> returns the next pending
packet-buffer index directly, with no role-bit inspection. (Raw
service is selected via <code>qos.service == SVC_RAW</code> at flow allocation,
which suppresses <code>frcti</code> creation.)

<code>frcti_pdu_ready</code> is the no-advance peek used by <code>fevent</code> (the
Ouroboros flow-event multiplexer, the <code>poll(2)</code>-equivalent on
flows). It returns ready only when the head-of-line run is
complete and the lead packet (a Protocol Data Unit, here one FRCP
packet) is present at <code>rcv_cr.rwe - RQ_SIZE</code>; any other state
(including the best-effort skip-past-gap case) returns not ready,
and <code>frcti_consume</code> is left to drop the broken prefix and re-
inspect.

=== 7.2. Fragmentation and reassembly ===

Send side (<code>flow_write_frag</code>). An SDU larger than
<code>(frag_mtu - PCI)</code> is split into <code>ceil(count / (frag_mtu - PCI))</code>
fragments; each fragment is its own FRCP packet with its own
<code>seqno</code> and a per-fragment role flag pair ([[#1.2. Flag bits|Section 1.2]]). Roles are
assigned at emit time:

{| class="wikitable"
! i !! Role
|-
| <code>n=1</code> || <code>SOLE</code>
|-
| <code>i=0</code> || <code>FIRST</code>
|-
| <code>i=n-1</code> || <code>LAST</code>
|-
| else || <code>MID</code>
|}

A mid-loop allocation or transmit failure may yield a partial
write: the call returns the bytes already enqueued (<code>off > 0</code>) or
the underlying error (<code>off == 0</code>). Best-effort flows fragment
identically; on the receiver, a partial run with a permanently-
lost fragment is dropped when a later complete SDU is visible in
the ring (see skip-past-gap below). Raw flows carry no PCI and
refuse anything larger than the layer's user MTU (<code>-EMSGSIZE</code>).

Wire-level recovery is fragment-agnostic on FRTX flows: each
fragment's <code>seqno</code> flows through SACK / RACK / RTO / NACK exactly
as for a SOLE DATA packet, and reassembly does not re-enter the
loss-detection path. Best-effort flows run the same <code>seqno</code>
machinery (DRF, FC, ACK piggyback, pre-DRF NACK emit) but queue
no <code>rxm</code> state at the sender, so a lost MID is unrecoverable;
skip-past-gap handles it (below).

Receive side. Fragments stash into <code>rq[seqno]</code> unchanged; role bits
are read only at consume time. <code>frag_run_inspect</code>, called from
<code>frcti_consume</code>, walks the ring starting at the oldest still-
undelivered <code>seqno</code> <code>base = rcv_cr.rwe - RQ_SIZE</code> (equal to <code>rcv_cr.lwe</code>
only when no partial run is in progress; during a partial run <code>lwe</code>
has already advanced past <code>base</code>). It produces one of three
outcomes:

{| class="wikitable"
! Outcome !! Cause
|-
| <code>DELIVER (n)</code>
| <code>rq[base]=SOLE</code> (<code>n=1</code>), or <code>rq[base]=FIRST</code> and a <code>LAST</code> follows in slots <code>[base+1..base+n-1]</code> with all intermediate roles in <code>{MID,FIRST,LAST}</code> contiguous.
|-
| <code>DROP (n)</code>
| <code>rq[base]</code> is <code>MID</code> or <code>LAST</code> without a preceding <code>FIRST</code> (<code>n=1</code>); a <code>FIRST..[non-LAST]..new-FIRST</code> or new-<code>SOLE</code> mid-run (drop the broken prefix with <code>n</code> = run length minus 1, so the new <code>FIRST</code>/<code>SOLE</code> stays); or, on best-effort flows, a gap at <code>base</code> with a <code>FIRST</code>/<code>SOLE</code> later in the ring (drop up to the new run start).
|-
| <code>NOT_READY</code>
| <code>rq[base]</code> absent or <code>FIRST..[non-LAST]</code> with no later <code>FIRST</code>/<code>SOLE</code> in the ring (FRTX waits for retx; best-effort waits for arrival).
|}

<code>DELIVER</code> triggers <code>frag_gather</code>: a scatter-gather <code>memcpy</code> of the <code>n</code>
consecutive fragments at <code>rq[base..base+n-1]</code> directly into the
caller's buffer; each per-packet shared-memory buffer (<code>spb</code>) is
released and <code>rwe</code> advances by <code>n</code>. <code>lwe</code> was already advanced
incrementally as each contiguous fragment arrived; <code>frag_gather</code>
only restores the fixed-width invariant <code>rwe == lwe + RQ_SIZE</code>.
No intermediate reassembly buffer is allocated.

<code>DROP</code> advances <code>rwe</code> past the broken prefix (releasing the <code>spb</code>s)
and pulls <code>lwe</code> up to the new trailing edge if needed; the next
consume retries from the new <code>base</code>. Oversize or arithmetically
overflowing delivery (sum of fragment lengths > <code>max_rcv_sdu</code>, sum
> caller's buffer, or running-sum overflow) also drops the run
with <code>-EMSGSIZE</code>.

Skip-past-gap (best-effort only). On FRTX, a gap in the run means
"waiting for retransmit" and <code>frag_run_inspect</code> returns <code>NOT_READY</code>.
On best-effort flows the gap is permanent, so <code>frag_run_inspect</code>
scans forward in the ring for the next <code>FIRST</code> or <code>SOLE</code>; if one is
visible within <code>RQ_SIZE</code>, it returns <code>DROP</code> for the broken prefix and
the consume loop retries at the new <code>lwe</code>. Memory hold is bounded
by <code>RQ_SIZE</code>; the partial releases on the next consume call once a
later complete run exists. Voice-like flows (one <code>SOLE</code> per SDU)
see no extra wait: any later <code>SOLE</code> makes the prior gap droppable
immediately.

The choice to defer reassembly to consume time keeps the receive
path zero-copy: fragments stay in the shared-memory ring until
the application pulls, and the SDU lands directly in the caller's
buffer.

== 8. Retransmission ==

FRCP is bounded by two delta-t-derived timers (Watson 1981, see
[[#15. Heritage and adopted techniques|Section 15]]):

* <code>t_a</code> (a-timer): upper bound on ACK delay. An ACK for a received DATA packet MUST NOT be emitted after <code>t_a</code> of receipt; an attempt to send an ACK after the a-timer has expired is suppressed.
* <code>t_r</code> (r-timer): upper bound on retransmission. A given DATA packet MUST NOT be retransmitted after <code>t_r</code> has elapsed since its first send (<code>t0</code>); when the bound is hit, the flow is declared down (raising the Ouroboros asynchronous flow condition <code>ACL_FLOWDOWN</code>, which marks the flow dead to both endpoints) rather than retransmitted again.

Each in-flight FRTX <code>seqno</code> owns one <code>rxm_entry</code>, armed in a hashed
timing wheel; the wheel deadline is the slot's next eligible
retransmit time.

;RTO timer
:On fire (<code>rxm_due</code>), re-emit with <code>FRCT_RXM</code>, mark <code>SND_RTX</code> (Karn-suppress next ACK's RTT sample), and (for the head-of-line (HoL) slot only) bump <code>rto_mul</code> up to <code>MAX_RTO_MUL</code>. Wheel deadline is <code>t_send + (rto << rto_mul)</code>. Re-armed unless consumed. The RTO timer also clears <code>SND_FAST_RXM</code> (re-arming fast-retransmit eligibility), resets <code>reo_wnd_mult</code> to 1 on a HoL fire (RFC 8985 sec. 6.2 step 4 reset clause), and marks the flow <code>ACL_FLOWDOWN</code> if its <code>frct_tx</code> call fails.

;r-timer guard
:Before any retransmit attempt, check <code>(now - t0)</code> against <code>t_r</code>. If exceeded, the slot is no longer eligible for retransmit. Only the RTO timer (<code>rxm_due</code>) treats r-timer expiry as terminal: it marks the flow <code>ACL_FLOWDOWN</code> (peer unreachable). Fast-retransmit, SACK-driven retransmit, and NACK-driven head-of-line re-emit silently skip aged-out slots and defer the flow-down decision to the next RTO fire.

;Fast retransmit (hybrid trigger, RFC 8985 sec. 6.2)
:On a non-advancing cumulative ACK with the scoreboard advanced, fire one fast retransmit when EITHER (a) the head-of-line slot's latest send is older than the RACK reorder window <code>R</code> ([[#3. Protocol parameters|Section 3]]) and not yet aged out, OR (b) the SACK <code>dup-thresh</code> count above <code>snd_cr.lwe</code> reaches <code>DUP_THRESH</code> (= 3, RFC 8985 sec. 6.2 step 4). Fires at most once per non-advancing cumulative-ACK value, gated by <code>rack_fired_lwe</code> (the <code>snd_cr.lwe</code> at which fast-retransmit last fired). Set <code>SND_FAST_RXM</code> on the slot (one-shot per-slot gate) and enter NewReno-style careful recovery (see NewReno below in this section).
:The RACK reorder window <code>R</code> uses the RFC 8985 sec. 6.2 form <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor. Before the first RTT sample seeds <code>min_rtt</code>, <code>R</code> falls back to <code>MIN(reo_wnd_mult * SRTT / 4, SRTT)</code>, still floored at <code>MIN_REORDER_NS</code> (consistent with the windowed-minimum fallback described in [[#12. RTT estimation|Section 12]]). <code>min_rtt</code> is a windowed minimum over the last <code>MIN_RTT_WIN_NS</code> = 5 min of RTT samples (matches the Linux <code>tcp_min_rtt_wlen</code> default) so a route change to a longer path eventually re-anchors the reorder window without relying on <code>reo_wnd_mult</code> growth alone.

;SACK-driven retransmit
:For each gap below <code>hi_sacked</code> whose slot is (1) still owned, (2) not already <code>SND_FAST_RXM</code>, (3) not aged out past <code>t_r</code>, and (4) either outside the RACK window <code>R</code> OR with <code>dup_thresh >= DUP_THRESH</code> (same hybrid as fast-retransmit, see [[#6.2. Locked main path|Section 6.2]]), re-emit. Each SACK-driven retransmit re-arms a fresh <code>rxm</code> so a lost retransmit can still be recovered by its own RTO timer.

;NewReno
:On entry, <code>recovery_high = snd_cr.seqno + RTT_QUARANTINE</code>. Exit when <code>ackno >= recovery_high</code> or <code>ackno == snd_cr.seqno</code> (the latter means everything sent has been acknowledged). <code>seqno_rotate</code> also clears recovery.

== 9. Pre-DRF NACK ==

The two sides have different inactivity thresholds (<code>snd_cr.inact > rcv_cr.inact</code>), so a receiver can detect "stale data run" before the sender's own DRF logic kicks in. NACK is the receiver-driven nudge that asks the sender to re-transmit the head of the run.

;Send (<code>frcti_nack_snd</code>, called by <code>frcti_rcv</code> when <code>rcv_inact_check</code> returns <code>FRCT_INACT_NEED_NACK</code>)
:When an incoming DATA packet has no DRF and rcv-side activity is older than <code>rcv_cr.inact</code>, the receiver emits a bare packet with <code>flags = FRCT_NACK</code> and <code>seqno = arrival_seqno - 1</code> (informational only, not consulted by the receive handler). The cooldown in [[#3. Protocol parameters|Section 3]] rate-limits the burst. Non-DATA non-DRF arrivals bypass <code>rcv_inact_check</code> entirely; non-DATA DRF still rebases via the DRF branch.

;Receive (<code>frcti_nack_rcv</code>)
:Dispatched in the early-exit branch ([[#6.1. Early-exit dispatch|Section 6.1]]), before <code>rcv_inact_check</code>. The sender copies the head-of-line (HoL) <code>rxm</code> packet, marks the slot <code>SND_RTX | SND_FAST_RXM</code> (Karn-suppress next ACK, one-shot fast-rxm gate), sets <code>rtt_lwe = snd_cr.lwe + 1</code>, and re-emits via <code>fast_rxm_send</code> with <code>FRCT_RXM</code> and a refreshed <code>ackno</code>. The original <code>rxm_entry</code> and its RTO timer are left armed - the NACK emit is additive to the normal retransmit machinery, not a replacement. No-op if nothing is in flight, the HoL slot has aged past <code>t_r</code>, or the HoL <code>rxm</code> pointer has been cleared by SACK or RACK.

NACK has exactly one role: lost first-of-run (DRF) packet recovery. Until the DRF packet arrives, the receiver cannot rebase its window, so any subsequent in-flight packets look stale to the receiver. The NACK fires the moment a stale receiver sees DATA without DRF, telling the sender to re-emit the head-of-line (DRF) packet at NACK-cooldown latency rather than waiting for the initial RTO (which is the configured default until <code>srtt</code> is seeded by the first probe round-trip). Mid-stream loss is NOT NACK-driven; it is recovered by the sender's RTO, fast retransmit, and SACK-driven retransmit paths ([[#8. Retransmission|Section 8]]) only.

The existing <code>rxm_entry</code> and its RTO timer are left armed on a NACK re-emit, so the RTO path remains the eventual fallback.

== 10. Cumulative + selective ACK ==

Cumulative ACK is <code>ackno = rcv_cr.lwe</code>. On out-of-order arrival the
receiver also emits a SACK packet ([[#1.3. SACK payload|Section 1.3]]) whose payload lists
''present'' blocks above <code>lwe</code> (analogous to TCP SACK / QUIC ACK
ranges). SACKs are rate-limited per [[#3. Protocol parameters|Section 3]] and suppressed when
neither <code>lwe</code> nor block count has changed since the last SACK.

D-SACK reports (RFC 2883) are emitted in-band as <code>block[0]</code> of an
otherwise normal SACK frame (see [[#1.3. SACK payload|Section 1.3]] for the encoding).
Two receiver triggers arm a pending D-SACK report (single-slot,
latest-wins):

* DATA arrival with <code>seqno < rcv_cr.lwe</code>, both wire-dup (no RXM, <code>is_dup_data</code> path) and retransmit (RXM, post-FC branch) (RFC 2883 sec. 4.1.1, full duplicate)
* <code>rq_accept</code> conflict, slot already occupied in <code>[lwe, rwe)</code> (RFC 2883 sec. 4.1.2, partial duplicate)

When a D-SACK is pending and the standard scoreboard SACK would be
suppressed by dedup or rate-limit, the report is emitted as a
stand-alone SACK frame through the normal <code>ack_snd</code> path; when a
D-SACK report is pending the path bypasses dedup and the <code>TICTIME</code>
rate-limit, but the a-timer suppression on rcv inactivity still
applies.

Bare ACKs are deferred via a per-flow delayed-ACK timer (one in
flight at a time, atomic test-and-set dedup; fires per [[#3. Protocol parameters|Section 3]]
after the first in-order arrival). Suppressed if (1) no new
<code>seqno</code>, (2) rcv side is inactive (older than <code>t_a</code>), or (3) the
sender just sent within <code>TICTIME</code>. A pending D-SACK ride-through
bypasses (1) and (3); the a-timer gate (2) is unconditional.

== 11. Flow control ==

The receiver advertises <code>rwe</code> in every FC field. The sender treats
its <code>snd_cr.rwe</code> as the absolute right edge: when
<code>snd_cr.seqno >= snd_cr.rwe</code> the window is closed and <code>flow_write</code>
yields. While closed, the sender periodically emits RDVS
(rendezvous) packets (cadence <code>DELT_RDV</code>); the receiver replies with
a bare FC packet (<code>ackno = 0</code>) that reopens the window. Once the
window has been closed for longer than <code>MAX_RDV</code> the sender stops
emitting RDVS but does not tear the flow down - the writer keeps
blocking until either a peer-driven FC arrives or the KA
(keepalive) / r-timer marks the flow.

<code>rwe</code> is clamped to <code>lwe + RQ_SIZE</code> on receipt and MUST NOT shrink:
a backward <code>rwe</code> is silently clamped to the current <code>snd_cr.rwe</code>;
the FC packet still reopens the window.

== 12. RTT estimation ==

Active RTTP probes ([[#1.4. RTTP payload|Section 1.4]]) carry a 32-bit <code>probe_id</code> (0
reserved) and a 16-byte random nonce echoed verbatim - defends
against spoofed replies. A ring of <code>RTTP_RING</code> in-flight probes is
kept; an echo whose <code>(id, nonce)</code> doesn't match the ring slot is
dropped. A single RTTP sample is clamped to <code>RTT_CLAMP_MUL * srtt</code>
(compile-time <code>RTT_CLAMP_MUL = 16</code>) once <code>srtt</code> is seeded; the first
cold-probe sample feeds <code>rtt_update</code> raw.

Probe arming gates:

;Cold (no <code>srtt</code> yet)
:the receive path arms at most one probe per 100 ms via <code>frcti_rcv_probe</code> (<code>PROBE_DUE_COLD</code>); arming requires an incoming packet. Active send-path arming bails while <code>srtt == 0</code>.
;Warm (<code>rtt_probe_arm</code>, called from <code>frcti_snd</code>)
:outstanding data (<code>snd_cr.seqno > snd_cr.lwe</code>), AND at least <code>2 * srtt</code> since <code>t_rcv_rtt</code> (last RTT receive of any kind), AND at least <code>srtt</code> since <code>t_snd_probe</code> (last probe emit).

Sample feeds either Linux's asymmetric <code>mdev</code> estimator
(<code>FRCT_LINUX_RTT_ESTIMATOR</code>, default ON) or RFC 6298 symmetric EWMA
(compile option). <code>srtt</code> is floored at 10 ms when seeded from a
hint, at 1 us after every update (including the first seeding
sample); <code>mdev</code> floored at 100 ns.

:<code>RTO = max(rto_min, 2 * srtt, srtt + (mdev << MDEV_MUL))</code>

(the <code>2 * srtt</code> floor is an FRCT addition not in RFC 6298).
Effective wheel deadline capped per [[#3. Protocol parameters|Section 3]].

ACK-derived samples (<code>frcti_ack_rcv</code> -> <code>rtt_sample_eligible</code>), beyond
the cum-ACK advance gate in <code>frcti_ack_rcv</code> (<code>ackno > lwe</code> and
<code>ackno <= seqno</code>), require all of: not in recovery; ACK packet does
not carry <code>FRCT_RXM</code>; HoL slot's <code>SND_RTX</code> bit clear; slot's <code>rxm</code>
pointer non-NULL (not SACK-consumed); <code>lwe</code> not below the <code>rtt_lwe</code>
fence; <code>srtt</code> already seeded by an RTTP probe. There is no ACK-only
seeding.

Every eligible sample also feeds <code>RACK.min_RTT</code> (RFC 8985 sec. 6.2)
via a windowed minimum: replace whenever the sample is strictly
smaller OR more than <code>MIN_RTT_WIN_NS</code> (5 min, matches Linux
<code>tcp_min_rtt_wlen</code>) has elapsed since the current min was set. The
downward branch is immediate (faster path picked up at once); the
upward branch is gated on the window (a transient queue burst does
not poison the estimate, but a sustained route change to a longer
path re-anchors <code>min_RTT</code> after at most one window). Seeded from
<code>rtt_hint</code> at <code>rtt_init</code>; 0 acts as the unset sentinel and the base
in <code>rack_reorder_window</code> falls back from <code>min_RTT</code> to <code>SRTT</code> (so
<code>R = mult * SRTT/4</code>, capped at <code>SRTT</code>, floored at <code>MIN_REORDER_NS</code>)
until the first sample. See [[#6.2. Locked main path|Section 6.2]].

== 13. Liveness (keepalive) ==

When <code>qs.timeout > 0</code> a per-flow KA (keepalive) timer is armed.
Arming uses <code>rcv_cr.act</code> for the deadline computation:

:<code>deadline = min(snd_act + qs.timeout/4, rcv_act + qs.timeout)</code>

(clamped to <code>now + qs.timeout/4</code> if already past). The timer fires
either on sender idleness (to send a KA) or on receiver idleness
(to declare the peer dead). On fire (<code>ka_snd</code>) the peer-dead test
uses <code>max(rcv_cr.act, t_ka_rcv)</code> so a recent KA reply counts even
when no DATA has arrived:

* If <code>now - max(rcv_cr.act, t_ka_rcv) > qs.timeout</code>, mark the flow <code>ACL_FLOWPEER</code> and notify the per-process flow-event set (<code>proc.fqset</code>) with <code>FLOW_PEER</code>.
* Else if <code>snd_idle > qs.timeout/4</code>, emit a bare <code>KA | ACK</code> (<code>ackno = rcv_cr.lwe</code>) and re-arm.
* Else just re-arm.

Note: <code>rx_rb</code> and <code>tx_rb</code> are the receive and transmit shared-memory
ring buffers. The r-timer raises <code>ACL_FLOWDOWN</code> on both (route is
broken); keepalive raises <code>ACL_FLOWPEER</code> on <code>rx_rb</code> only and notifies
the flow-event set (peer is silent, writer keeps <code>tx_rb</code> usable) -
distinct ACLs. <code>qs.timeout == 0</code> disables keepalive entirely; a
silent peer crash is then undetected.

== 14. Linger / teardown ==

On <code>flow_dealloc</code>, <code>frcti_dealloc</code> computes a grace timeout

:<code>max(rcv_cr.act + rcv_cr.inact, snd_cr.act + snd_cr.inact) - now</code>

(floored at 0 and converted to seconds) and returns it; <code>flow_dealloc</code>
forwards this to the IRMd as the dealloc grace. The IRMd, not FRCT,
performs the wait. Before computing the timeout, FRCT may emit a
final ACK when <code>rcv_cr.lwe != rcv_cr.seqno</code> (the peer has not been
told the most recent cumulative ACK) AND the rcv side has been
active within <code>t_a</code> (a-timer not aged out).

<code>FRCTFLINGER</code> is honoured only when <code>snd_cr.lwe < edge</code>, where <code>edge =
snd_fin_seqno</code> after FIN has been sent in stream mode and
<code>snd_cr.seqno</code> otherwise (data or FIN still in flight). The drain
itself runs in <code>flow_dealloc</code>'s <code>while (FRCTI_LINGERING)</code> loop, not in
<code>frcti_dealloc</code>.

The fd is single-reader / single-writer (documented in the
manpages). <code>flow_write</code> pumps <code>rx_rb</code> on every call (via
<code>flow_wait_window</code> -> <code>flow_drain_rx_nb</code>) and additionally blocks on
<code>rx_rb</code> when the send window is closed. A pure-writer thread thus
consumes ACKs without a dedicated reader.

== 15. Heritage and adopted techniques ==

Delta-t (Watson, 1981) is the primary heritage; FRCP descends from
the delta-t protocol family via the Recursive InterNetwork
Architecture (RINA; Day, "Patterns in Network Architecture", 2008,
ch. 9). Timer-based connection management
(no SYN/FIN handshake, per-flow state born on first DATA and
reclaimed after <code>t_mpl + a + r</code> of silence), the DRF marker, and the
<code>t_mpl</code> / <code>t_a</code> / <code>t_r</code> timers all come from delta-t. See Watson,
"Timer-Based Mechanisms in Reliable Transport Protocol Connection
Management", Computer Networks 5 (1981).

The unified <code>flow_alloc(name, qos, ...)</code> primitive and its
multi-axis QoS-cube argument ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) also come from RINA
(Day 2008, ch. 6; Grasa et al., "IRATI: investigating RINA as an
alternative to TCP/IP", Computer Networks 92 (2015)) - reliability,
ordering, CRC presence, and encryption are flow attributes, not
separate sockets or protocols.

The table below summarises additional adopted techniques and their
references.

{| class="wikitable"
! FRCP mechanism !! Heritage !! Reference / note
|-
| Random new <code>seqno</code> on <code>seqno_rotate</code> || TCP ISN || RFC 6528 (Gont & Bellovin, 2012). QUIC PN-space reset (RFC 9000 sec. 12.3) is a structural analogue.
|-
| Cumulative ACK, left-window-edge advance || TCP || RFC 793 / RFC 9293
|-
| Receive window with non-shrink rule || TCP || RFC 793 sec. 3.7 / RFC 9293 sec. 3.8.6; RFC 1122 sec. 4.2.2.16 for the explicit non-shrink prohibition
|-
| Modular <code>seqno</code> arithmetic (<code>before</code>/<code>after</code> helpers) || TCP || RFC 793 sec. 3.3 / RFC 9293 sec. 3.4
|-
| Selective ACK block list || TCP || RFC 2018 (Mathis et al., 1996). Encoded as a typed FRCP packet rather than a TCP option, so framing is closer to QUIC ACK frames. D-SACK (RFC 2883) carried in-band as <code>block[0]</code>; see [[#1.3. SACK payload|Section 1.3]].
|-
| NewReno-careful recovery with <code>recovery_high</code> gate || TCP || RFC 6582 (Henderson et al., 2012); QUIC builds on the same model in RFC 9002 sec. 7.3.2. Cwnd half absent (CC in IPCP).
|-
| RACK reordering window for fast retransmit || TCP || RFC 8985 (Cheng et al., 2021). FRCP <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> with a <code>MIN_REORDER_NS = 250 us</code> floor against <code>srtt</code> collapse; matches RFC 8985 sec. 6.2 and Linux <code>tcp_rack_reo_wnd</code>. DSACK-driven <code>reo_wnd_mult</code> (sec. 6.2 step 4) is adopted; see [[#1.3. SACK payload|Section 1.3]] for the wire encoding. The hybrid RACK-or-<code>DUP_THRESH</code> trigger from RFC 8985 sec. 6.2 step 4 is adopted ([[#8. Retransmission|Section 8]]). QUIC's analogue in RFC 9002 sec. 6.1.2 uses <code>max(srtt, latest_rtt)</code> as the base.
|-
| Karn's algorithm: no RTT sample on retransmits, RTO-collapse freeze || TCP || Karn & Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 1987; RFC 6298 sec. 3.
|-
| RTO formula <code>RTO = max(RTO_MIN, srtt + (mdev << MDEV_MUL))</code> || TCP || RFC 6298 (Paxson et al., 2011). <code>RTO_MIN</code> = 250 us is below RFC 6298 sec. 2.4's 1 s SHOULD-floor - a recursive-layer choice.
|-
| Linux asymmetric <code>mdev</code> estimator (default) || Linux kernel || <code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code>; the <code>if(delta<0) m>>=3</code> dampening is a kernel divergence from RFC 6298. RFC 6298 EWMA available behind a compile flag.
|-
| Delayed ACK with rate suppression || TCP || RFC 813 (Clark, 1982); RFC 1122 sec. 4.2.3.2; RFC 5681 sec. 4.2. Single-deadline coalescing rather than "ack-every-other-segment".
|-
| Zero-window-probe / persist-timer analogue (RDVS) || TCP || RFC 1122 sec. 4.2.2.17 / RFC 9293 sec. 3.8.6.1. RDVS solicits an FC reply, distinct from QUIC <code>DATA_BLOCKED</code> (RFC 9000 sec. 19.12), which is one-way notification. <code>MAX_RDV</code> give-up departs from TCP.
|-
| Multiplexed control on a single PCI || SCTP / QUIC || SCTP chunk bundling (RFC 9260 sec. 6.10); QUIC frame multiplexing (RFC 9000 sec. 12.4). Cleaner fit than TCP's separate-flag-bits design.
|-
| ACK ranges as multiple discontiguous acked blocks || QUIC || QUIC ACK frame (RFC 9000 sec. 19.3). FRCP SACK is conceptually QUIC-frame-shaped even though encoded as absolute <code>[start,end]</code> pairs.
|-
| Nonce-authenticated active RTT / liveness probing (RTTP) || QUIC <code>PATH_CHALLENGE</code> || <code>PATH_CHALLENGE</code> / <code>PATH_RESPONSE</code> (RFC 9000 sec. 8.2, sec. 19.17, sec. 19.18). WebRTC ICE consent-freshness (RFC 7675) is the same pattern. QUIC's nonce is 8 octets; FRCP chooses 16.
|-
| Probing distinct from keepalive || QUIC || KA timer answers "peer alive?", RTTP answers "path measurable?", as in QUIC PING (RFC 9000 sec. 19.2) vs <code>PATH_CHALLENGE</code>.
|-
| Bare KA + ACK keepalive packets || QUIC / SCTP || QUIC PING (RFC 9000 sec. 19.2); SCTP HEARTBEAT / HEARTBEAT-ACK (RFC 9260 sec. 8.3). SCTP HEARTBEAT also carries an opaque echoed blob, structurally similar to FRCP RTTP.
|-
| (<code>FFGM</code>, <code>LFGM</code>) fragment-role bits ([[#7.2. Fragmentation and reassembly|Section 7.2]]) || SCTP || RFC 9260 sec. 3.3.1 DATA chunk B/E bits encode the same four states (<code>B+E=SOLE</code>, <code>B-only=FIRST</code>, neither=<code>MID</code>, <code>E-only=LAST</code>). Each fragment carries its own <code>seqno</code>/TSN and is independently retransmitted.
|-
| Stream byte-offset reassembly (Sections [[#1.5. Stream PCI extension|1.5]], [[#16. Stream-mode flows|16]]) || QUIC || QUIC STREAM frame (RFC 9000 sec. 19.8) uses Offset + Length varints; FRCP uses fixed 32-bit <code>start</code> / <code>end</code>. One stream per flow vs QUIC's many streams multiplexed.
|-
| FIN end-of-stream marker (Sections [[#1.2. Flag bits|1.2]], [[#16. Stream-mode flows|16]]) || TCP / QUIC || TCP FIN flag (RFC 9293 sec. 3.1) closes one half of the byte stream; QUIC STREAM frame FIN bit (RFC 9000 sec. 19.8) does the same per stream with an immutable final-size invariance (RFC 9000 sec. 4.5: the final size is fixed once observed). FRCP's FIN consumes one packet <code>seqno</code> (not one byte of stream space) and is idempotent on the sender side.
|-
| Stream byte-credit flow control ([[#16. Stream-mode flows|Section 16]]) || QUIC || <code>MAX_STREAM_DATA</code> (RFC 9000 sec. 4.1, sec. 19.10). FRCP projects a per-flow byte budget onto the <code>seqno</code>-space <code>rwe</code>. Single stream per flow collapses QUIC's <code>MAX_DATA</code> / <code>MAX_STREAM_DATA</code> distinction.
|-
| Header protection (encrypted seqnos) || QUIC || QUIC RFC 9001 sec. 5.4 applies header protection on top of AEAD to mask the packet number. FRCP's per-flow AEAD wrap ([[#16. Stream-mode flows|Section 16]]) is wider: it encrypts the entire PCI including <code>seqno</code> because the IPCP below already routes, so no destination connection-ID needs to stay in clear (cf. RFC 9000 sec. 5.2).
|-
| Two-bit fragment role polarity || SCTP || The (<code>FFGM</code>, <code>LFGM</code>) pair follows SCTP B/E (begin = 1 / end = 1) rather than IPv4 MF (RFC 791 sec. 3.2), which has the inverse polarity (MF = 1 means NOT last).
|-
| Orthogonal reliability / ordering axes ([[#2.2. Service modes (orthogonal axes)|Section 2.2]]) || SCTP || PR-SCTP (RFC 3758, per-message partial reliability) and SCTP DATA U-bit (RFC 9260 sec. 3.3.1, per-message unordered) are the closest precedents for decoupling reliability from ordering; FRCP sets them per-flow rather than per-message.
|-
| Orthogonal CRC (<code>qs.ber == 0</code>) || UDP-Lite || RFC 3828 (Larzon et al., 2004) lets the sender pick a per-packet Checksum Coverage and the receiver enforce a locally configured minimum (no in-band negotiation; sec. 3.1, sec. 3.3). FRCP gates a full CRC trailer on <code>qs.ber == 0</code> at flow setup. Contrast TCP / SCTP (mandatory checksum) and QUIC (AEAD subsumes CRC).
|-
| Setup-time service negotiation || DCCP / SCTP / QUIC || DCCP Service Codes (RFC 4340 sec. 8.1.2, RFC 5595); SCTP INIT parameters (RFC 9260 sec. 3.3.2); QUIC transport parameters (RFC 9000 sec. 7.4). All negotiate service properties at connection setup; only RINA's QoS cube exposes them as an orthogonal vector.
|}

=== 15.1. Original to FRCP (no clean prior art) ===

* Pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]): receiver-driven nudge exploiting <code>snd_cr.inact > rcv_cr.inact</code>. Closest analogues are SCTP Gap Ack Blocks (RFC 9260 sec. 3.3.4) and DCCP Ack Vector (RFC 4340 sec. 11.4) - both let the receiver describe gaps to the sender, but neither targets the cross-epoch / pre-DRF case.
* <code>MAX_RDV</code> window-probe give-up: neither TCP (persist-timer probes until application or R2 abort, RFC 9293 sec. 3.8.6.1) nor QUIC has an explicit FC-give-up counter. A recursive-network choice: outer layers can drop the flow.
* Skip-past-gap reassembly ([[#7.2. Fragmentation and reassembly|Section 7.2]]): SCTP fragments and reassembles every flow regardless of reliability/ordering, using its own per-stream reassembly queue; QUIC fragments via STREAM offsets. FRCP fragments best-effort flows too, but the receiver drops the broken prefix the moment a later run-start (<code>FIRST</code> or <code>SOLE</code> role) is visible inside the <code>RQ_SIZE</code>-wide reorder ring - no IP-frag-style timeout, no SCTP-style explicit abort. If no later run-start arrives within the ring, <code>frag_run_inspect</code> returns <code>NOT_READY</code> and the partial run keeps its slots; the next inspect retries. The trade-off: a permanently-lost <code>MID</code> in a long isolated run holds slots until either a later <code>FIRST</code>/<code>SOLE</code> appears in the ring or the writer stops, at which point the slots are reclaimed on flow teardown.
* Reassembly deferred to consume time ([[#7.2. Fragmentation and reassembly|Section 7.2]]), message mode only (<code>qos.service == SVC_MESSAGE</code>): SCTP (RFC 9260 sec. 6.9), QUIC (RFC 9000 sec. 2.2), and TCP (RFC 9293) all hold reassembly state at the receive boundary. FRCP message-mode leaves fragments in the shared-memory ring until <code>flow_read</code> pulls and lands the SDU directly in the caller's buffer. Stream mode ([[#16. Stream-mode flows|Section 16]]) uses the standard QUIC-style direct ring placement on receive and does not defer. The optimisation is enabled by the Shared-Memory Subsystem (SSM) packet-buffer ring (see <code>struct ssm_pk_buff</code> at [[#1.1. PCI header|Section 1.1]]); the analogue is OS-level scatter-gather I/O (<code>recvmsg+iovec</code>), not a transport-layer prior art.
* TLP-equivalent tail-loss recovery (RFC 8985 sec. 7; RFC 9002 sec. 6.2): FRCP does not emit an explicit Tail Loss Probe packet, but the same goal is met implicitly by RACK loss detection ([[#8. Retransmission|Section 8]]) firing on a non-advancing cumulative ACK once the head-of-line slot ages past the RACK reorder window <code>R = MIN(reo_wnd_mult * min_RTT / 4, SRTT)</code> - well below <code>RTO = max(2 * SRTT, SRTT + (mdev << MDEV_MUL))</code>. A receiver-driven nudge is also available via the pre-DRF NACK ([[#9. Pre-DRF NACK|Section 9]]).

=== 15.2. Not adopted ===

* Slow start, congestion window (cwnd), Additive Increase / Multiplicative Decrease (AIMD), NewReno cwnd inflation. Congestion control lives in the IPCP CA policies and is driven by Explicit Congestion Notification (ECN, RFC 3168).
* Nagle / silly-window-syndrome (SWS) avoidance (RFC 896, RFC 1122 sec. 4.2.3.4). (Deferred work, not adopted in the current spec.)
* TCP Timestamps (RFC 7323) / Protection Against Wrapped Sequences (PAWS) - RTT measurement uses RTTP, not per-segment timestamps. A peer-supplied timestamp echoed on every ACK lets a malicious peer drive the <code>srtt</code> estimate arbitrarily low, collapsing the RTO and triggering a self-inflicted retransmit storm. RTTP confines RTT measurement to nonce-authenticated probe round-trips, where a forged echo is rejected before it can reach the estimator.
* ECN (Explicit Congestion Notification) response inside FRCP (consumed by IPCP Congestion Avoidance / CA).
* IP-style fragment-offset reassembly (RFC 791 sec. 3.2; RFC 8200 sec. 4.5). Message-mode FRCP relies on the FRCT <code>rq[]</code> reorder ring keyed by <code>seqno</code> (shared by FRTX and best-effort flows) to put fragments back in order; no separate offset field is needed and no IP-style hole-list reassembly buffer is kept. Stream-mode FRCP does carry <code>[start, end)</code> byte offsets ([[#1.5. Stream PCI extension|Section 1.5]]) for direct ring placement on receive.
* QUIC STREAM offset+length framing on ''every'' flow (RFC 9000 sec. 19.8). Message-mode FRCP uses the SCTP-style B/E flag-bit encoding (<code>FFGM</code>/<code>LFGM</code>) and skips the offsets; stream-mode FRCP adopts the QUIC offset model (heritage table above).

== 16. Stream-mode flows ==

When a flow is allocated with <code>qos.service == SVC_STREAM</code> both peers
switch to byte-stream semantics, layered on top of the FRTX reorder
machinery already described in Sections [[#6. Receive path|6]]-[[#8. Retransmission|8]].

=== 16.1. Send ===

The sender splits the caller's octets into chunks of at most
<code>(frag_mtu - base PCI - stream PCI extension)</code> octets (Sections [[#1.1. PCI header|1.1]]
and [[#1.5. Stream PCI extension|1.5]]). Each chunk is one DATA packet with its own <code>seqno</code> and a
<code>[start, end)</code> byte range copied from a monotonic stream counter.
In stream mode <code>FFGM</code> and <code>LFGM</code> are unused and MUST be transmitted as
zero; the per-byte position is carried by the <code>[start, end)</code>
extension instead.

End-of-stream is signalled with a 0-byte DATA packet that has <code>FIN</code>
(bit 12) set, emitted on the FIN triggers listed in [[#1.2. Flag bits|Section 1.2]]
(WR-half close, <code>flow_dealloc</code>, and any other path that yields the
final byte). The sender MUST emit at most one FIN per flow; its
<code>[start, end)</code> MUST equal <code>[final-byte, final-byte)</code> (i.e., empty
interval at the final byte position; final-size invariance,
analogous to QUIC RFC 9000 sec. 4.5). Idempotency is enforced by
an <code>snd_fin_sent</code> guard.

=== 16.2. Receive ===

On arrival the receiver places the payload directly into a per-flow
byte-indexed receive ring of width <code>ring_sz</code> (octets) at the position
indicated by <code>start</code>, with a two-segment <code>memcpy</code> across the ring
boundary if needed. Receipt is recorded in the FRTX reorder
machinery ([[#6.2. Locked main path|Section 6.2]]) augmented with the packet's <code>start</code>, <code>end</code>, and
FIN bit per slot. When a packet's <code>[start, end)</code> front-overlaps
bytes already at or below the byte high-water mark, the overlap is
trimmed before placement so the same byte is never written twice.
After stashing, the receiver advances <code>lwe</code> and the byte high-water
mark across any newly-contiguous prefix. Each slot advanced MUST
satisfy <code>start == the last-delivered slot's end</code>; a slot whose
<code>start</code> does not equal that <code>end</code> is silently dropped at delivery time
(the <code>seqno</code> is consumed, no stream bytes contributed) and the high-
water mark does not advance past it. The stream byte-stream
stalls at that point - there is no flow-tear-down on mismatch.
This filters spliced or off-path-injected slots that fall in
window without strong cryptographic authentication.

A FIN slot marks end-of-stream at advance time only if its byte
position equals the last-delivered slot's <code>end</code>; otherwise the FIN
is ignored and the corresponding <code>seqno</code> occupies a slot but
contributes no stream bytes. No packet buffer is held after the
ring copy.

=== 16.3. Read ===

<code>flow_read</code> returns up to <code>count</code> octets from the contiguous prefix
<code>[next, high-water)</code>, where <code>next</code> is the byte the application has
already consumed up to and <code>high-water</code> is the rightmost contiguous
byte received. When the stream is fully drained AND end-of-stream
(EOS) was observed (<code>next == EOS</code> byte position), <code>flow_read</code> returns
0 (<code>EOF</code>) - the same shape POSIX <code>read(2)</code> uses on TCP after a peer
FIN.

=== 16.4. Flow control ===

ACK / SACK / RACK / RTO machinery is unchanged; the FRTX reorder
ring is reused as a per-<code>seqno</code> received-bitmap. Let <code>per_pkt =
(frag_mtu - base PCI - stream PCI extension)</code>, the maximum stream-
byte payload one DATA packet can carry ([[#16.1. Send|Section 16.1]]). The
receive window advertised in FC is clamped so the byte window
(<code>ring_sz</code>) cannot be overrun: the <code>seqno</code>-space <code>rwe</code> is at most
<code>rcv_cr.lwe + ring_sz / per_pkt</code>.

This is the QUIC byte-credit flow-control model
(<code>MAX_STREAM_DATA</code>, RFC 9000 sec. 4.1 and sec. 19.10) projected onto
<code>seqno</code> space. With one stream per flow there is no <code>MAX_DATA</code> /
<code>MAX_STREAM_DATA</code> distinction. Receiver-side silly-window-syndrome
(SWS) avoidance (RFC 9293 sec. 3.8.6.2.2) is achieved by combining
the consume-time <code>rwe</code> bump with the global non-shrink rule from
[[#11. Flow control|Section 11]].

=== 16.5. Security considerations ===

Threat model. An attacker that can observe (on-path passive) or
predict (off-path blind) the flow's seqnos and byte offsets on an
unencrypted stream flow can inject DATA or FIN at any in-window
position. The in-line consistency checks above (<code>start</code> == prior
<code>end</code> on advance; FIN MUST be 0-byte; FIN MUST sit at the final
byte position) realise the spirit of RFC 5961's "sequence-window
plus exact-position match for control bits" without an explicit
challenge-ACK probe; they make a few specific blind attack shapes
harder but are not cryptographic authentication. This is
comparable to TCP without the TCP Authentication Option (TCP-AO,
RFC 5925), tighter than a
pre-RFC-5961 TCP stack, and roughly equivalent to a modern
RFC 5961 stack against blind off-path injection - none of these
help once the attacker can sniff. TLS over TCP (RFC 8446)
encrypts only the TCP payload and leaves TCP seqnos, ACKs, FIN,
and RST in the clear, so TLS does NOT defend against TCP-header-
level injection; QUIC (RFC 9000) hides packet numbers under
header protection (RFC 9001 sec. 5.4), so this specific weakness
does not apply to QUIC.

Mitigation: AEAD. When the flow has encryption enabled the
recommended AEAD ciphers (AES-GCM, RFC 5288; or ChaCha20-Poly1305,
RFC 8439) wrap the entire FRCP packet on the wire - PCI, stream
extension, body, and the CRC trailer when <code>ber == 0</code> - under a
per-flow symmetric key derived from the flow's own key exchange
([[#1.1. PCI header|Section 1.1]]). The AEAD tag (~2^-128 forgery probability)
dominates the CRC (~2^-32) for integrity in this mode but the CRC
trailer is currently retained inside the wrap (see [[#1.1. PCI header|Section 1.1]]).
Implementations MUST NOT rely on the security properties below
when a non-AEAD cipher (e.g. AES-CTR alone) is negotiated; non-
AEAD modes provide confidentiality only and the threat-model
claims do not hold.

With an AEAD cipher in use, seqnos, byte offsets, and the FIN bit
are both authenticated and confidential. Against an off-path or
on-path-passive attacker this is:

* Stronger than TCP+TLS (TCP header in the clear).
* Stronger than TCP+TCP-AO (header authenticated but visible).
* Comparable to IPsec ESP transport mode (RFC 4303), which similarly authenticates and encrypts the upper-layer header plus payload, and to QUIC packet protection (RFC 9001 sec. 5), with the difference that QUIC must leave the destination connection ID in the clear for routing whereas FRCP relies on the IPCP below for delivery and can therefore encrypt its entire PCI.

Keying granularity. Ouroboros flow allocation runs key exchange (<code>kex</code>) per flow, so each <code>flow_alloc</code> yields independent symmetric keys. This is finer-grained than QUIC (per-connection, RFC 9001, where one handshake covers all multiplexed streams) and finer-grained than typical IPsec deployment (per-host-pair Security Associations, SAs). Forward secrecy follows from the <code>kex</code> when an ephemeral Diffie-Hellman exchange (DHE), or a hybrid mode (classical DH + post-quantum Key Encapsulation Mechanism / KEM), is selected.

Replay protection. The AEAD layer itself does NOT carry an explicit anti-replay window (unlike IPsec ESP, RFC 4303 sec. 3.4.3, or DTLS, RFC 9147 sec. 4.5.1). For FRCP-engaged flows the <code>seqno</code>-space duplicate-suppression in [[#6.2. Locked main path|Section 6.2]] rejects replayed
DATA after the AEAD strips the wrap, because the AEAD authenticates the <code>seqno</code> and a replay re-presents an old <code>seqno</code> that is then discarded either as a duplicate (still inside the receive window or as outside the receive window, depending on how far <code>lwe</code> has advanced since the original packet was delivered. RAW (<code>qos.service == SVC_RAW</code>) flows have no FRCP layer and therefore no replay protection at the AEAD layer either; deployments that need replay rejection on RAW flows SHOULD use SVC_MESSAGE.

Layering. The AEAD wrap sits below FRCP on the data path, so RAW best-effort flows (<code>qos.service == SVC_RAW</code>, the UDP-equivalent service of [[#2.2. Service modes (orthogonal axes)|Section 2.2]]) inherit the same per-flow integrity + confidentiality scope as FRCP-engaged flows - whatever the process and FRCP (if any) put on the wire is what the AEAD authenticates. No DTLS-equivalent layering is required for confidentiality and integrity; replay protection above AEAD is a separate concern as noted above.

== 17. References ==

This section lists the IETF documents, published works, and
source-code references cited inline elsewhere in this document.
IETF documents are cited inline as "RFC NNNN sec. X.Y"; books,
journal papers, and source-code references are cited inline by
author and year (or by file and function name) and are listed
here for convenience.

=== 17.1. IETF documents ===

;[RFC 791]
:J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
;[RFC 793]
:J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. Obsoleted by RFC 9293.
;[RFC 813]
:D. D. Clark, "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982.
;[RFC 896]
:J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
;[RFC 1122]
:R. Braden (ed.), "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
;[RFC 2018]
:M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
;[RFC 2119]
:S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
;[RFC 2883]
:S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
;[RFC 3758]
:R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
;[RFC 3828]
:L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson (ed.), G. Fairhurst (ed.), "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
;[RFC 4303]
:S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
;[RFC 4340]
:E. Kohler, M. Handley, S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
;[RFC 5288]
:J. Salowey, A. Choudhury, D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
;[RFC 5595]
:G. Fairhurst, "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
;[RFC 5681]
:M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
;[RFC 5925]
:J. Touch, A. Mankin, R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
;[RFC 5961]
:A. Ramaiah, R. Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
;[RFC 6298]
:V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
;[RFC 6528]
:F. Gont, S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, February 2012. Obsoletes RFC 1948.
;[RFC 6582]
:T. Henderson, S. Floyd, A. Gurtov, Y. Nishida, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 6582, April 2012.
;[RFC 7323]
:D. Borman, B. Braden, V. Jacobson, R. Scheffenegger (ed.), "TCP Extensions for High Performance", RFC 7323, September 2014.
;[RFC 7675]
:M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, October 2015.
;[RFC 8174]
:B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
;[RFC 8200]
:S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, July 2017.
;[RFC 8439]
:Y. Nir, A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018.
;[RFC 8446]
:E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
;[RFC 8985]
:Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, February 2021.
;[RFC 9000]
:J. Iyengar (ed.), M. Thomson (ed.), "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021.
;[RFC 9001]
:M. Thomson (ed.), S. Turner (ed.), "Using TLS to Secure QUIC", RFC 9001, May 2021.
;[RFC 9002]
:J. Iyengar (ed.), I. Swett (ed.), "QUIC Loss Detection and Congestion Control", RFC 9002, May 2021.
;[RFC 9147]
:E. Rescorla, H. Tschofenig, N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022.
;[RFC 9260]
:R. Stewart, M. Tuexen, K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, June 2022. Obsoletes RFC 4960.
;[RFC 9293]
:W. Eddy (ed.), "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022. Obsoletes RFC 793 and several follow-ons; updates RFC 1122 and others.

=== 17.2. Books and journal papers ===

;[Day08]
:J. Day, "Patterns in Network Architecture: A Return to Fundamentals", Prentice Hall, 2008.
;[Grasa15]
:E. Grasa et al., "IRATI: investigating RINA as an alternative to TCP/IP", Computer Networks, Vol. 92, December 2015.
;[KP87]
:P. Karn, C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", ACM SIGCOMM, August 1987.
;[Wat81]
:R. W. Watson, "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management", Computer Networks, Vol. 5, 1981.

=== 17.3. Source-code references ===

;[Linux-RTT]
:<code>tcp_rtt_estimator()</code> in <code>net/ipv4/tcp_input.c</code> of the Linux kernel, defining the asymmetric <code>mdev</code> variance update used as FRCP's default RTT estimator ([[#12. RTT estimation|Section 12]]). Line-stable browseable copy at https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c.

[[Category:Protocols]]
[[Category:Ouroboros internals]]

Ouroboros Tutorial 06

2026-02-09T14:43:31Z

Zen: changing enc.cfg to enc.conf

= 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">
==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.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 [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>
</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)

Ouroboros Tutorial 06

2026-02-09T14:41:49Z

Zen: /* 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">
==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>
</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.cfg 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.cfg

# 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.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>
</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-07T20:31:44Z

Zen: /* Part 1: Running the Tutorial - Single Session with 4 Tests */

= 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">
==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>
</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.cfg

# 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.cfg 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.cfg

# 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.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>
</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-07T20:31:11Z

Zen: /* Part 1: Running the Tutorial - Single Session with 4 Tests */

= 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 PK 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">
==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>
</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.cfg

# 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.cfg 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.cfg

# 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.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>
</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 Prototype

2025-08-13T23:46:13Z

Zen:

{{Under construction}}

The Ouroboros prototype is a user-space decentralized packet network implementation based on an overhauled [[Ouroboros Model| networking model]]. It is being developed in C for POSIX operating systems.

This prototype is very much a work in progress.

On this page are instructions for installing the prototype. Once done, head to the [[Ouroboros Tutorials | tutorials]] section. The [https://ouroboros.rocks/docs old documentation website] is still available for reference, but only this wiki is maintained.

= Install the Prototype =

The prototype consists of the '''library''', which provides the core Application Programming Interfaces (Unicast API and Broadcast API), the functions of the [[Ouroboros Functional Layering | application end-to-end layer]] and various functions used by the other components in the prototype; the IPC Resource Management daemon '''IRMd''', which is the core component for administering Ouroboros; the '''IPCPs''' that actually forward packets and make up the (peer-to-peer) packet network; and a collection of '''tools''', of which the most important is the IPC Resource Management (IRM) Command Line Interface (CLI) for management and some basic tools for demo purposes. In addition, there is an [[Rumba | orchestration framework]] for setting up experiments and an [[Ouroboros metrics | InfluxDB exporter]] for observability. The prototype is written in C, but we provide some APIs for other popular languages, currently [[pyOuroboros | Python]] and [[OuroboRs | Rust]].

== Requirements ==

Ouroboros builds on most POSIX compliant systems. Below you will find instructions for GNU/Linux, FreeBSD and OS X. On Windows 10, you can build Ouroboros using the [https://learn.microsoft.com/en-us/windows/wsl/install Linux Subsystem for Windows].

== Get Ouroboros ==

You can clone Ouroboros using the command line from its website or, if you prefer you can clone and/or fork from our [https://github.com/dstaesse/ouroboros Github], [https://codeberg.org/o7s/ouroboros Codeberg], or [https://bitbucket.org/dstaesse/ouroboros BitBucket] mirrors.

<syntaxhighlight>
$ git clone https://ouroboros.rocks/git/ouroboros
$ git clone git://ouroboros.rocks/ouroboros
$ git clone https://github.com/dstaesse/ouroboros
$ git clone https://codeberg.org/o7s/ouroboros
</syntaxhighlight>

Another option is downloading a [https://{{SERVERNAME}}/cgit/ouroboros snapshot] tarball and extracting it.
Optional repositories are [[pyOuroboros]], a Python wrapper to write Ouroboros programs in Python, and [[Ouroboros metrics | ouroboros-metrics]] that contains an [https://influxdb.com InfluxDB] exporter.

== Dependencies ==

To build Ouroboros, you need cmake, google protocol buffers installed in addition to a C compiler (gcc or clang) and make.

On GNU/Linux you will need either libgcrypt (≥ 1.7.0) or libssl if your glibc is older than version 2.25.

On OS X, you will need homebrew. [https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/ConfiguringSystemIntegrityProtection/ConfiguringSystemIntegrityProtection.html Disable System Integrity Protection] during the installation and/or removal of Ouroboros.

Optionally, you can also install libgcrypt, libssl (to enable encryption), fuse 2.x (to enable exporting internal metrics), and dnsutils (to enable use of a DynDNS server to be used as a naming directory for a UDP layer). Setting up a DNS server (e.g. bind) is out of scope of this installation guide.

=== Debian/Ubuntu Linux ===

$ apt-get install git protobuf-c-compiler cmake
$ apt-get install libgcrypt20-dev libssl-dev libfuse-dev dnsutils cmake-curses-gui

If during the build process cmake complains that the Protobuf C compiler is required but not found, and you installed the protobuf-c-compiler package, you will also need this:

$ apt-get install libprotobuf-c-dev

=== Arch Linux ===

$ pacman -S git protobuf-c cmake
$ pacman -S libgcrypt openssl fuse dnsutils

=== FreeBSD 11/12/13/14 ===

$ pkg install git protobuf-c cmake
$ pkg install libgcrypt openssl fusefs-libs bind-tools

=== Mac OS X 10/11/12/13/14 ===

$ brew install git protobuf-c cmake
$ brew install libgcrypt openssl

On mac OS X, you may also need to add /usr/local/include/ to your build path (e.g. when compiling with libtomlc99):

$ export C_INCLUDE_PATH=/usr/local/include

There is a known issue with homebrew and protobuf-c 1.5.0.4:
https://github.com/Homebrew/homebrew-core/issues/168501
https://github.com/protobuf-c/protobuf-c/pull/711

A confirmed workaround is to replace "protoc-c" with "protoc" in the build.cmake scripts for the following components before running make:
libouroboros-common
libouroboros-irm
ipcpd-unicast

== Configuration file support ==

It is highly recommended you install [https://github.com/cktan/tomlc99 libtomlc99] ''before'' building O7s to enable configuration file support.

=== GNU/Linux and mac OS X ===

git clone https://github.com/cktan/tomlc99
cd tomlc99
make && sudo make install

=== FreeBSD ===

The tomlc99 makefiles contain directives specific to GNU make. You will need to install and use gmake instead of make:

pkg install gmake

git clone https://github.com/cktan/tomlc99
cd tomlc99
gmake && sudo gmake install

== Installation instructions ==

=== Arch Linux ===

Ouroboros is available as an [https://aur.archlinux.org/packages/ouroboros-git AUR package], which will install all dependencies (except configfile support) and a Release build from the master branch. To enable configfile support, install tomlc99 before building this AUR package.

=== From source ===

When installing from source, go to the cloned git repository or extract the tarball and enter the main directory. We recommend creating a build directory inside this directory.
Run cmake providing the path to where you cloned the Ouroboros repository. Assuming you created the build directory inside the repository directory, the following commands build and install O7s:

$ cd <path/to/ouroboros/repo>
$ mkdir build && cd build
$ cmake .. # optional: configure build parameters
$ make && sudo make install

== Running the unit tests ==

To compile and run the unit tests, do

$ make check

Note that "make test" will only try to run the tests, not compile the necessary sources and may result in errors.

== Build configuration parameters ==

At compile time, there are a number of parameters that can be tweaked, for instance to enable debug logging, enable various sanitizers, to increase performance or decrease memory consumption. You can find a full list on the [[Ouroboros Build Parameters]] page.

== Remove Ouroboros ==

To uninstall Ouroboros, simply execute the following command from your build directory:

$ sudo make uninstall

Ouroboros Prototype

2024-10-17T18:30:54Z

Zen: /* Get Ouroboros */

{{Under construction}}

The Ouroboros prototype is a user-space decentralized packet network implementation based on an overhauled [[Ouroboros Model| networking model]]. It is being developed in C for POSIX operating systems.

This prototype is very much a work in progress.

On this page are instructions for installing the prototype. Once done, head to the [[Ouroboros Tutorials | tutorials]] section. The [https://ouroboros.rocks/docs old documentation website] is still available for reference, but only this wiki is maintained.

= Install the Prototype =

The prototype consists of the '''library''', which provides the core Application Programming Interfaces (Unicast API and Broadcast API), the functions of the [[Ouroboros Functional Layering | application end-to-end layer]] and various functions used by the other components in the prototype; the IPC Resource Management daemon '''IRMd''', which is the core component for administering Ouroboros; the '''IPCPs''' that actually forward packets and make up the (peer-to-peer) packet network; and a collection of '''tools''', of which the most important is the IPC Resource Management (IRM) Command Line Interface (CLI) for management and some basic tools for demo purposes. In addition, there is an [[Rumba | orchestration framework]] for setting up experiments and an [[Ouroboros metrics | InfluxDB exporter]] for observability. The prototype is written in C, but we provide some APIs for other popular languages, currently [[pyOuroboros | Python]] and [[OuroboRs | Rust]].

== Requirements ==

Ouroboros builds on most POSIX compliant systems. Below you will find instructions for GNU/Linux, FreeBSD and OS X. On Windows 10, you can build Ouroboros using the [https://learn.microsoft.com/en-us/windows/wsl/install Linux Subsystem for Windows].

== Get Ouroboros ==

You can clone Ouroboros using the command line from its website or, if you prefer you can clone and/or fork from our [https://github.com/dstaesse/ouroboros Github] or [https://bitbucket.org/dstaesse/ouroboros BitBucket] mirrors.

<syntaxhighlight>
$ git clone https://ouroboros.rocks/git/ouroboros
$ git clone git://ouroboros.rocks/ouroboros
$ git clone https://github.com/dstaesse/ouroboros
</syntaxhighlight>

Another option is downloading a [https://{{SERVERNAME}}/cgit/ouroboros snapshot] tarball and extracting it.
Optional repositories are [[pyOuroboros]], a Python wrapper to write Ouroboros programs in Python, and [[Ouroboros metrics | ouroboros-metrics]] that contains an [https://influxdb.com InfluxDB] exporter.

== Dependencies ==

To build Ouroboros, you need cmake, google protocol buffers installed in addition to a C compiler (gcc or clang) and make.

On GNU/Linux you will need either libgcrypt (≥ 1.7.0) or libssl if your glibc is older than version 2.25.

On OS X, you will need homebrew. [https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/ConfiguringSystemIntegrityProtection/ConfiguringSystemIntegrityProtection.html Disable System Integrity Protection] during the installation and/or removal of Ouroboros.

Optionally, you can also install libgcrypt, libssl (to enable encryption), fuse (to enable exporting internal metrics), and dnsutils (to enable use of a DynDNS server to be used as a naming directory for a UDP layer). Setting up a DNS server (e.g. bind) is out of scope of this installation guide.

=== Debian/Ubuntu Linux ===

$ apt-get install git protobuf-c-compiler cmake
$ apt-get install libgcrypt20-dev libssl-dev libfuse-dev dnsutils cmake-curses-gui

If during the build process cmake complains that the Protobuf C compiler is required but not found, and you installed the protobuf-c-compiler package, you will also need this:

$ apt-get install libprotobuf-c-dev

=== Arch Linux ===

$ pacman -S git protobuf-c cmake
$ pacman -S libgcrypt openssl fuse dnsutils

=== FreeBSD 11/12/13/14 ===

$ pkg install git protobuf-c cmake
$ pkg install libgcrypt openssl fusefs-libs bind-tools

=== Mac OS X 10/11/12/13/14 ===

$ brew install git protobuf-c cmake
$ brew install libgcrypt openssl

On mac OS X, you may also need to add /usr/local/include/ to your build path (e.g. when compiling with libtomlc99):

$ export C_INCLUDE_PATH=/usr/local/include

There is a known issue with homebrew and protobuf-c 1.5.0.4:
https://github.com/Homebrew/homebrew-core/issues/168501
https://github.com/protobuf-c/protobuf-c/pull/711

A confirmed workaround is to replace "protoc-c" with "protoc" in the build.cmake scripts for the following components before running make:
libouroboros-common
libouroboros-irm
ipcpd-unicast

== Configuration file support ==

It is highly recommended you install [https://github.com/cktan/tomlc99 libtomlc99] ''before'' building O7s to enable configuration file support.

=== GNU/Linux and mac OS X ===

git clone https://github.com/cktan/tomlc99
cd tomlc99
make && sudo make install

=== FreeBSD ===

The tomlc99 makefiles contain directives specific to GNU make. You will need to install and use gmake instead of make:

pkg install gmake

git clone https://github.com/cktan/tomlc99
cd tomlc99
gmake && sudo gmake install

== Installation instructions ==

=== Arch Linux ===

Ouroboros is available as an [https://aur.archlinux.org/packages/ouroboros-git AUR package], which will install all dependencies (except configfile support) and a Release build from the master branch. To enable configfile support, install tomlc99 before building this AUR package.

=== From source ===

When installing from source, go to the cloned git repository or extract the tarball and enter the main directory. We recommend creating a build directory inside this directory.
Run cmake providing the path to where you cloned the Ouroboros repository. Assuming you created the build directory inside the repository directory, the following commands build and install O7s:

$ cd <path/to/ouroboros/repo>
$ mkdir build && cd build
$ cmake .. # optional: configure build parameters
$ make && sudo make install

== Running the unit tests ==

To compile and run the unit tests, do

$ make check

Note that "make test" will only try to run the tests, not compile the necessary sources and may result in errors.

== Build configuration parameters ==

At compile time, there are a number of parameters that can be tweaked, for instance to enable debug logging, enable various sanitizers, to increase performance or decrease memory consumption. You can find a full list on the [[Ouroboros Build Parameters]] page.

== Remove Ouroboros ==

To uninstall Ouroboros, simply execute the following command from your build directory:

$ sudo make uninstall

Ouroboros Prototype

2024-10-07T13:01:40Z

Zen: removed https link to git

{{Under construction}}

The Ouroboros prototype is a user-space decentralized packet network implementation based on an overhauled [[Ouroboros Model| networking model]]. It is being developed in C for POSIX operating systems.

This prototype is very much a work in progress.

On this page are instructions for installing the prototype. Once done, head to the [[Ouroboros Tutorials | tutorials]] section. The [https://ouroboros.rocks/docs old documentation website] is still available for reference, but only this wiki is maintained.

= Install the Prototype =

The prototype consists of the '''library''', which provides the core Application Programming Interfaces (Unicast API and Broadcast API), the functions of the [[Ouroboros Functional Layering | application end-to-end layer]] and various functions used by the other components in the prototype; the IPC Resource Management daemon '''IRMd''', which is the core component for administering Ouroboros; the '''IPCPs''' that actually forward packets and make up the (peer-to-peer) packet network; and a collection of '''tools''', of which the most important is the IPC Resource Management (IRM) Command Line Interface (CLI) for management and some basic tools for demo purposes. In addition, there is an [[Rumba | orchestration framework]] for setting up experiments and an [[Ouroboros metrics | InfluxDB exporter]] for observability. The prototype is written in C, but we provide some APIs for other popular languages, currently [[pyOuroboros | Python]] and [[OuroboRs | Rust]].

== Requirements ==

Ouroboros builds on most POSIX compliant systems. Below you will find instructions for GNU/Linux, FreeBSD and OS X. On Windows 10, you can build Ouroboros using the [https://learn.microsoft.com/en-us/windows/wsl/install Linux Subsystem for Windows].

== Get Ouroboros ==

You can clone Ouroboros using the command line from its website or, if you prefer you can clone and/or fork from our [https://github.com/dstaesse/ouroboros Github] or [https://bitbucket.org/dstaesse/ouroboros BitBucket] mirrors.

<syntaxhighlight>
$ git clone git://ouroboros.rocks/ouroboros
$ git clone https://github.com/dstaesse/ouroboros
</syntaxhighlight>

Another option is downloading a [https://{{SERVERNAME}}/cgit/ouroboros snapshot] tarball and extracting it.
Optional repositories are [[pyOuroboros]], a Python wrapper to write Ouroboros programs in Python, and [[Ouroboros metrics | ouroboros-metrics]] that contains an [https://influxdb.com InfluxDB] exporter.

== Dependencies ==

To build Ouroboros, you need cmake, google protocol buffers installed in addition to a C compiler (gcc or clang) and make.

On GNU/Linux you will need either libgcrypt (≥ 1.7.0) or libssl if your glibc is older than version 2.25.

On OS X, you will need homebrew. [https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/ConfiguringSystemIntegrityProtection/ConfiguringSystemIntegrityProtection.html Disable System Integrity Protection] during the installation and/or removal of Ouroboros.

Optionally, you can also install libgcrypt, libssl (to enable encryption), fuse (to enable exporting internal metrics), and dnsutils (to enable use of a DynDNS server to be used as a naming directory for a UDP layer). Setting up a DNS server (e.g. bind) is out of scope of this installation guide.

=== Debian/Ubuntu Linux ===

$ apt-get install git protobuf-c-compiler cmake
$ apt-get install libgcrypt20-dev libssl-dev libfuse-dev dnsutils cmake-curses-gui

If during the build process cmake complains that the Protobuf C compiler is required but not found, and you installed the protobuf-c-compiler package, you will also need this:

$ apt-get install libprotobuf-c-dev

=== Arch Linux ===

$ pacman -S git protobuf-c cmake
$ pacman -S libgcrypt openssl fuse dnsutils

=== FreeBSD 11/12/13/14 ===

$ pkg install git protobuf-c cmake
$ pkg install libgcrypt openssl fusefs-libs bind-tools

=== Mac OS X 10/11/12/13/14 ===

$ brew install git protobuf-c cmake
$ brew install libgcrypt openssl

On mac OS X, you may also need to add /usr/local/include/ to your build path (e.g. when compiling with libtomlc99):

$ export C_INCLUDE_PATH=/usr/local/include

There is a known issue with homebrew and protobuf-c 1.5.0.4:
https://github.com/Homebrew/homebrew-core/issues/168501
https://github.com/protobuf-c/protobuf-c/pull/711

A confirmed workaround is to replace "protoc-c" with "protoc" in the build.cmake scripts for the following components before running make:
libouroboros-common
libouroboros-irm
ipcpd-unicast

== Configuration file support ==

It is highly recommended you install [https://github.com/cktan/tomlc99 libtomlc99] ''before'' building O7s to enable configuration file support.

=== GNU/Linux and mac OS X ===

git clone https://github.com/cktan/tomlc99
cd tomlc99
make && sudo make install

=== FreeBSD ===

The tomlc99 makefiles contain directives specific to GNU make. You will need to install and use gmake instead of make:

pkg install gmake

git clone https://github.com/cktan/tomlc99
cd tomlc99
gmake && sudo gmake install

== Installation instructions ==

=== Arch Linux ===

Ouroboros is available as an [https://aur.archlinux.org/packages/ouroboros-git AUR package], which will install all dependencies (except configfile support) and a Release build from the master branch. To enable configfile support, install tomlc99 before building this AUR package.

=== From source ===

When installing from source, go to the cloned git repository or extract the tarball and enter the main directory. We recommend creating a build directory inside this directory.
Run cmake providing the path to where you cloned the Ouroboros repository. Assuming you created the build directory inside the repository directory, the following commands build and install O7s:

$ cd <path/to/ouroboros/repo>
$ mkdir build && cd build
$ cmake .. # optional: configure build parameters
$ make && sudo make install

== Running the unit tests ==

To compile and run the unit tests, do

$ make check

Note that "make test" will only try to run the tests, not compile the necessary sources and may result in errors.

== Build configuration parameters ==

At compile time, there are a number of parameters that can be tweaked, for instance to enable debug logging, enable various sanitizers, to increase performance or decrease memory consumption. You can find a full list on the [[Ouroboros Build Parameters]] page.

== Remove Ouroboros ==

To uninstall Ouroboros, simply execute the following command from your build directory:

$ sudo make uninstall

Ouroboros Frequently Asked Questions

2024-02-19T23:04:09Z

Zen:

Ouroboros is a project with the capacity to make fundamental changes to the way we share information in the digital world. When encountering this project for the first time, plenty of people have questions: what it is, how it works, and how it compares to other projects. This is where you'll find the answers to some of the most common questions.

== Q: How does Ouroboros compare to [Tor, CJDNS, I2P, Wireguard, etc.]? ==
A: The goal of Ouroboros is to tackle problems in the world of information transfer by re-establishing network architecture at a system level.

As such, comparing Ouroboros to projects which rely on existing network architecture (IP/TCP, TLS, DNS) is akin to comparing a concrete foundation to a pre-existing structure. It is possible to move these structures onto the foundation (or build new ones!), but it is ineffective to compare Ouroboros to any existent networking protocol before any practical implementations have been built.

Until implementations exist which properly leverage the capacity of Ouroboros as an infrastructure, it is difficult to make a comparison to the specific use cases addressed by existing network paradigms.