| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Flow and Retransmission Control Protocol (FRCP) runs end-to-end
between two peers over a flow. It provides reliability, in-order
delivery, flow control, and liveness. Note that congestion avoidance
is orthogonal to FRCP and handled in the IPCP.
A fixed 16-octet header, network byte order, is prefixed to every FRCP
packet:
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
hcs is a CRC-16-CCITT-FALSE checksum over the PCI (and the stream
extension when present), verified before any flag-driven dispatch. A
single packet can simultaneously carry DATA + ACK + FC + RXM by OR-ing
flag bits. An optional CRC trailer covers the body on DATA when qs.ber
== 0, and on every SACK packet; an optional AEAD wrap (per-flow keys)
sits outermost.
Flag bits (MSB-first; bits 13..15 reserved, MUST be zero):
+------+--------+--------+----------------------------------------+
| Bit | Mask | Name | Meaning |
+------+--------+--------+----------------------------------------+
| 0 | 0x8000 | DATA | Carries caller payload |
| 1 | 0x4000 | DRF | Start of a fresh data run |
| 2 | 0x2000 | ACK | ackno field valid |
| 3 | 0x1000 | NACK | Pre-DRF nudge (seqno informational) |
| 4 | 0x0800 | FC | window field valid (rwe advertisement) |
| 5 | 0x0400 | RDVS | Rendezvous probe (window-closed) |
| 6 | 0x0200 | FFGM | First Fragment of a multi-fragment SDU |
| 7 | 0x0100 | LFGM | Last Fragment of a multi-fragment SDU |
| 8 | 0x0080 | RXM | Retransmission |
| 9 | 0x0040 | SACK | Block list follows in payload |
| 10 | 0x0020 | RTTP | RTT probe / echo (payload follows) |
| 11 | 0x0010 | KA | Keepalive |
| 12 | 0x0008 | FIN | End of stream marker |
| 13-15| -- | -- | Reserved (MUST be zero) |
+------+--------+--------+----------------------------------------+
(FFGM, LFGM) encodes the fragment role of a DATA packet (SCTP-style
B/E): 11=SOLE, 10=FIRST, 00=MID, 01=LAST. Each fragment carries its
own seqno; Retransmission recovers fragments individually, reassembly
runs at consume time. In stream mode FFGM/LFGM are unused; per-byte
position is carried by the stream extension below and end-of-stream is
signalled by FIN on a 0-byte DATA packet.
SACK payload (FRCT_ACK | FRCT_FC | FRCT_SACK):
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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... n_blocks pairs total ...
Each block describes a *present* (received) range strictly above the
cumulative ACK in the PCI ackno. D-SACK (RFC 2883) is signalled
in-band as block[0] - no flag bit, no extra framing - and consumed by
the RACK reo_wnd_mult scaler (RFC 8985 sec. 7.2).
RTTP payload (FRCT_RTTP only; 24 octets):
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream PCI extension (in_order == STREAM only; 8 octets after the base
PCI on every DATA packet):
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
start, end are monotonic 32-bit byte offsets; end - start equals the
on-wire payload length. Stream mode is negotiated at flow allocation;
the extension is present iff stream mode is in use, never on a
per-packet basis.
Service modes are an orthogonal (in_order, loss, ber) vector selected
at flow_alloc; the cubes above map to the axes:
+----------------+---------+------+-----+-----------------------+
| Cube | in_order| loss | ber | Engaged |
+----------------+---------+------+-----+-----------------------+
| qos_raw | 0 | 1 | 1 | Raw passthrough |
| qos_raw_safe | 0 | 1 | 0 | Raw + CRC trailer |
| qos_rt | 1 | 1 | 1 | FRCP, no FRTX, no CRC |
| qos_rt_safe | 1 | 1 | 0 | FRCP, no FRTX, CRC |
| qos_msg | 1 | 0 | 0 | FRCP + FRTX |
| qos_stream | 2 | 0 | 0 | FRCP + FRTX, stream |
+----------------+---------+------+-----+-----------------------+
in_order=0 sends raw datagrams with no PCI (UDP-equivalent);
in_order=1 engages FRCP with SDU framing; in_order=2 (stream) requires
loss=0 and is rejected otherwise. loss=0 engages the FRTX retransmit
machinery. ber=0 appends the CRC-32 trailer; QOS_DISABLE_CRC at build
time forces ber=1 for development. Encryption is a separate per-flow
attribute layered as an AEAD wrap outside the FRCP packet.
Heritage: delta-t (Watson 1981) supplies timer-based connection
management - no SYN/FIN handshake, the DRF marker, the t_mpl / t_a /
t_r timers. RINA (Day 2008) supplies the unified flow_alloc(name, qos,
...) primitive and the orthogonal QoS-cube axes. Loss detection
follows TCP/QUIC practice (RFCs 2018, 2883, 6582, 6298, 8985); RTT
probing is nonce-authenticated like QUIC PATH_CHALLENGE.
Adds oftp, a minimal file-transfer tool over an FRCP stream flow. The
client reads from stdin or --in FILE and writes through a
flow_alloc(qos_stream); the server (--listen) calls flow_accept and
writes to stdout or --out FILE. Both sides compute a CRC-64/NVMe over
the bytes they handle and print the result. The server rejects flows
whose negotiated qs.in_order != STREAM.
Two FRCP knobs are exposed via env vars on either side:
OFTP_FRCT_RTO_MIN fccntl FRCTSRTOMIN (ns)
OFTP_FRCT_STREAM_RING_SZ fccntl FRCTSRRINGSZ (octets)
The ocbr_client gains an OCBR_QOS env var to pick the cube the client
uses for flow_alloc; recognised values are raw, safe, rt, rt_safe,
msg, stream. Unknown values fall back to raw with a warning on
stderr. Without the env set behaviour is unchanged.
Removes the deprecated lib/timerwheel.c
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The IRMd will now check the user UID and GID for privileged access,
avoiding unprivileged users being able to disrupt all IPC (e.g. by
shm_open the single pool and corrupting its metadata).
Non-privileged users are now limited to a PUP (per-user pool) for
sending/receiving packets. It is still created by the IRMd, but owned
by the user (uid) with 600 permissions. It does not add additional
copies for local IPC between their own processes (i.e. over the local
IPCP), but packets between processes owned by a different user or
destined over the network (other IPCPs) will incur a copy when
crossing the PUP / PUP or the PUP / GSPP boundary.
Privileged users and users in the ouroboros group still have direct
access to the GSPP (globally shared private pool) for packet transfer
that will avoid additional copies when processing packets between
processes owned by different users and to the network.
This aligns the security model with UNIX trust domains defined by UID
and GID by leveraging file permission on the pools in shared memory.
┌─────────────────────────────────────────────────────────────┐
│ Source Pool │ Dest Pool │ Operation │ Copies │
├─────────────────────────────────────────────────────────────┤
│ GSPP │ GSPP │ Zero-copy │ 0 │
│ PUP.uid │ PUP.uid │ Zero-copy │ 0 │
│ PUP.uid1 │ PUP.uid2 │ memcpy() │ 1 │
│ PUP.uid │ GSPP │ memcpy() │ 1 │
│ GSPP │ PUP.uid │ memcpy() │ 1 │
└─────────────────────────────────────────────────────────────┘
This also renames the struct ai ("application instance") in dev.c to
struct proc (process).
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the flow encryption option (cypher_s) from the qosspec.
The configuration file is configured in the security options (default
/etc/ouroboros/security/). For this poc, encryption can be disabled
client or server side by putting an enc.cfg file. If that file is
present in the client folder, the client will require encryption. If
that file is present on the server side, the server will require
encryption and reject non-encrypted flows.
Encryption is now configured outside of any application control.
Example: /etc/ouroboros/security/client/oping/enc.cfg exists:
irmd(II): Encryption enabled for oping.
irmd(DB): File /etc/ouroboros/security/client/oping/crt.pem does not exist.
irmd(II): No security info for oping.
irmd(DB): Generated ephemeral keys for 87474.
irmd/oap(PP): OAP_HDR [caf203681d997941 @ 2025-09-02 17:08:05 (UTC) ] -->
irmd/oap(PP): Certificate: <none>
irmd/oap(PP): Ephemeral Public Key: [91 bytes]
irmd/oap(PP): Data: <none>
irmd/oap(PP): Signature: <none>
Example: /etc/ouroboros/security/client/oping/enc.cfg does not exist:
irmd(II): Allocating flow for 87506 to oping.
irmd(DB): File /etc/ouroboros/security/client/oping/enc.cfg does not exist.
irmd(DB): File /etc/ouroboros/security/client/oping/crt.pem does not exist.
irmd(II): No security info for oping.
irmd/oap(PP): OAP_HDR [e84bb9d7c3d9c002 @ 2025-09-02 17:08:30 (UTC) ] -->
irmd/oap(PP): Certificate: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Signature: <none>
Example: /etc/ouroboros/security/server/oping/enc.cfg exists:
irmd(II): Flow request arrived for oping.
irmd(DB): IPCP 88112 accepting flow 7 for oping.
irmd(II): Encryption enabled for oping.
irmd(DB): File /etc/ouroboros/security/server/oping/crt.pem does not exist.
irmd(II): No security info for oping.
irmd/oap(PP): OAP_HDR [3c717b3f31dff8df @ 2025-09-02 17:13:06 (UTC) ] <--
irmd/oap(PP): Certificate: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Signature: <none>
irmd(WW): Encryption required but no key provided.
The server side will pass the ECRYPT to the client:
$ oping -l
Ouroboros ping server started.
Failed to accept flow: -1008
$ oping -n oping -c 1
Failed to allocate flow: -1008.
Encryption on flows can now be changed at runtime without needing to
touch/reconfigure/restart the process.
Note: The ECRYPT result is passed on via the flow allocator responses
through the IPCP (discovered/fixed some endianness issues), but the
reason for rejecting the flow can be considered N+1 information... We
may move that information up into the OAP header at some point.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds initial implementation of peer authentication as part of
flow allocation. If credentials are not provided, this will be
accepted and logged as info that the flow is not authenticated.
Certificates and keys are passed as .pem files. The key file should
not be encrypted, else the IRMd will open a prompt for the password.
The default location for these .pem files is in
/etc/ouroboros/security. It is strongly recommended to make this
directory only accessible to root.
├── security
│ ├── cacert
│ │ └── ca.root.o7s.crt.pem
│ ├── client
│ │ ├── <name>
│ │ | ├── crt.pem
│ │ | └── key.pem
│ │ └── <name>
| | ├──...
| |
│ ├── server
│ │ ├── <name>
│ │ | ├── crt.pem
│ │ | └── key.pem
│ │ └── <name>
| | ├── ...
| |
│ └── untrusted
│ └── sign.root.o7s.crt.pem
Trusted root CA certificates go in the /cacert directory, untrusted
certificates for signature verification go in the /untrusted
directory. The IRMd will load these certificates at boot. The IRMd
will look for certificates in the /client and /server directories. For
each name a subdirectory can be added and the credentials in that
directory are used to sign the OAP header for flows at flow_alloc() on
the client side and flow_accept() on the server side.
These defaults can be changed at build time using the following
variables (in alphabetical order):
OUROBOROS_CA_CRT_DIR /etc/ouroboros/security/cacert
OUROBOROS_CLI_CRT_DIR /etc/ouroboros/security/client
OUROBOROS_SECURITY_DIR /etc/ouroboros/security
OUROBOROS_SRV_CRT_DIR /etc/ouroboros/security/server
OUROBOROS_UNTRUSTED_DIR /etc/ouroboros/security/untrusted
The directories for the names can also be configured at IRMd boot
using the configuraton file and at runtime when a name is created
using the "irm name create" CLI tool. The user needs to have
permissions to access the keyfile and certificate when specifying the
paths with the "irm name create" CLI tool.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
|
