vmario/fabaccess-bffh
1
0
Fork 0
mirror of https://gitlab.com/fabinfra/fabaccess/bffh.git synced 2025-02-22 15:52:53 +01:00
Code Issues Packages Projects Releases Wiki Activity

Cleanup: remove /docs dir because we put it to https://docs.fab-access.org

Browse Source
This commit is contained in:
Mario Voigt 2025-02-20 15:35:19 +01:00
parent c8f0337c1e
commit fdde8a933c
3 changed files with 0 additions and 174 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
docs/connection-state.dot
View File

@ -1,39 +0,0 @@
strict digraph connection {
Establish [label="TCP/SCTP connection established"];
Closed [label="TCP/SCTP connection closed"];
Open;
SASL;
Authenticated;
STARTTLS;
Encrypted;
Establish -> Open [label=open];
Open -> Closed [label=close];
Open -> SASL [label=auth];
SASL -> SASL [label=step];
// Authentication fails
SASL -> Closed [label=fails];
// Authentication succeeds
SASL -> Authenticated [label=successful];
Open -> STARTTLS [label=starttls];
// TLS wrapping succeeds
STARTTLS -> Encrypted [label=successful];
// TLS wrapping fails
STARTTLS -> Closed [label=fails];
Authenticated -> SASL_TLS [label=starttls];
SASL_TLS -> Closed [label=fails];
SASL_TLS -> AuthEnc [label=successful];
Encrypted -> TLS_SASL [label=auth];
TLS_SASL -> TLS_SASL [label=step];
TLS_SASL -> Closed [label=fails];
TLS_SASL -> AuthEnc [label=successful];
// Only authenticated connections may open RPC. For "unauth", use the `Anonymous` SASL method.
AuthEnc -> RPC [label=bootstrap];
Authenticated -> RPC [label=bootstrap];
}

42
docs/draft-fabaccess-protocol.md
View File

@ -1,42 +0,0 @@
# Stream initiation
In a session there are two parties: The initiating entity and the receiving
entity. This terminology does not refer to information flow but rather to the
side opening a connection respectively the one listening for connection
attempts.
In the currently envisioned use-case the initiating entity is a) a client
(i.e. interactive or batch/automated program) trying to interact in some way or
other with a server b) a server trying to exchange / request information
with/from another server (i.e. federating). The receiving entity however is
already a server.
Additionally the amount and type of clients is likely to be more diverse and
less up to date than the servers.
Conclusions I draw from this:
- Clients are more likely to implement an outdated version of the communication
protocol.
- The place for backwards-compatability should be the servers.
- Thus the client (initiating entity) should send the expected API version
first, the server then using that as a basis to decide with which API
version to answer.
# Stream negotiation
Since the receiving entity for a connection is responsible for the machines it
controls it imposes conditions for connecting either as client or as federating
server. At least every initiating entity is required to authenticate itself to
the receiving entity before attempting further actions or requesting
information. But a receiving entity can require other features, such as
transport layer encryption.
To this end a receiving entity informs the initiating entity about features that
it requires from the initiating entity before taking any further action and
features that are voluntary to negotiate but may improve qualities of the stream
(such as message compression)
A varying set of conditions implies negotiation needs to take place. Since
features potentially require a strict order (e.g. Encryption before
Authentication) negotiation has to be a multi-stage process. Further
restrictions are imposed because some features may only be offered after others
have been established (e.g. SASL authentication only becoming available after
encryption, EXTERNAL mechanism only being available to local sockets or
connections providing a certificate)

93
docs/state.dot
View File

@ -1,93 +0,0 @@
strict digraph state {
rank = 0
subgraph "cluster_internal_state" {
rank = 1
ctr = applied
start
[shape=doublecircle, label="BFFH"]
created
[label="Machine object created"];
start -> created;
created -> attach
[label="New state or loaded from disk"];
attach
[label="Attach actor", shape=box];
unapplied
[label="Unapplied"];
applied
[label="Applied"];
verified
[label="Verified"];
wait_apply
[label="Wait ∀ Actors", shape=box]
wait_verify
[label="Wait ∀ Actors", shape=box]
unapplied -> wait_apply -> applied;
applied -> wait_verify -> verified;
applied -> unapplied
[label="statechange received"];
verified -> unapplied
[label="statechange received"];
unapplied -> unapplied
[label="statechange received"];
unapplied -> attach -> unapplied;
applied -> attach -> unapplied;
verified -> attach -> unapplied;
}
subgraph "cluster_actor" {
rank = 1
center = actor_applied
actor_start
[shape=doublecircle, label="Actor"];
actor_fresh
[label="Actor was just constructed"];
actor_start -> actor_fresh;
actor_attached
[label="Attached"];
actor_unapplied
[label="Unapplied"];
actor_applied
[label="Applied"];
actor_verified
[label="Verified"];
wait_initial
[label="Recv", shape=box];
wait_state
[label="Recv", shape=box];
actor_fresh -> wait_initial -> actor_attached;
actor_attached -> actor_applied
[label="initialize/apply"];
actor_unapplied -> actor_applied
[label="apply"];
actor_applied -> actor_verified
[label="verify"];
actor_unapplied -> wait_state;
actor_applied -> wait_state;
actor_verified -> wait_state;
wait_state -> actor_unapplied;
}
attach -> wait_initial
[label="Send initial state to that actor", style=dotted]
unapplied -> wait_state
[label="Send new state to all actors", style=dotted];
actor_applied -> wait_apply
[label="Confirm apply", style=dotted];
actor_verified -> wait_verify
[label="Confirm verify", style=dotted];
}