@@ -0,0 +12,4 @@
+The CTF platform should be designed so that a multitude of requirements regarding challenges and usage is considered.
+When designing the platform, we for now only consider jeopardy-style CTFs (no attack-defense-style CTFs)
+
+### Users and Authentication

@@ -0,0 +14,4 @@
+
+### Users and Authentication
+
+Users must be able to log in to the platform via any OIDC-compatible IdP.

@@ -0,0 +15,4 @@
+### Users and Authentication
+
+Users must be able to log in to the platform via any OIDC-compatible IdP.
+Users must be able to create and join teams with an invite-link or token.

@@ -0,0 +19,4 @@
+The platform must support both competitions for teams and individuals.
+The entity that is credited for the scores is called an Account.
+For integration with other services (like Discord bots and support), the user and account must have secret tokens that can be used to prove access to the user and account.
+

@@ -0,0 +17,4 @@
+Users must be able to log in to the platform via any OIDC-compatible IdP.
+Users must be able to create and join teams with an invite-link or token.
+The platform must support both competitions for teams and individuals.
+The entity that is credited for the scores is called an Account.

@@ -0,0 +27,4 @@
+Challenges are the main part of the platform. Challenges consist of one or more flags.
+Flags must be customizable (=flag instancing) to the account so that cheating can be detected more easily. But hard-coded flags must also be supported.
+
+#### Prerequisites

@@ -0,0 +29,4 @@
+
+#### Prerequisites
+
+It must be possible to allow accessing challenges only after a set of other challenges were completed. It must not be possible to gain information about challenges that are not unlocked.

@@ -0,0 +60,4 @@
+* Challenge IP and Ports as well as a hint to what this kind of service is (maybe a short description)
+  Exposing information like ports and IP must be possible for all types of interactive challenges.
+
+### Networking

@@ -0,0 +62,4 @@
+
+### Networking
+
+As challenges of also require fiddling with the network, the platform must support a variety of different network operations starting at ISO / OSI layer 2 to allow for challenges that, e.g., require ARP spoofing.

@@ -0,0 +93,4 @@
+The exact interface has yet to be defined as it must be common functionality subset across orchestrators (or provide an extension point).
+Examples for orchestrators are a Kubernetes orchestrator or a Docker orchestrator.
+
+### User-Environment

@@ -0,0 +77,4 @@
+#### VPN Access
+
+Some challenges cannot be solved without having access to the internal network.
+Therefore, access to the isolated challenge network "playground" is necessary were users can interact with challenges as they wish.

@@ -0,0 +105,4 @@
+
+* TODO: Updating the base image
+
+### Scoring

@@ -0,0 +124,4 @@
+#### Notifications
+
+The administrators should be able to post global notifications and notifications regarding specific challenges.
+The user must be able to acknowledge these notifications.

@@ -0,0 +139,4 @@
+
+## Non-Functional
+
+Apart from functional requirements, we collected a set of non-functional requirements that make working with the platform (TODO: find word).

@@ -0,0 +11,4 @@
+## Implementation
+
+The implementation can happen with [OVN](https://www.ovn.org/en/).
+There, we can have a central database (with ``northd`` and `southd`).

@@ -0,0 +37,4 @@
+L2TP/IPsec provides another well-supported VPN solution that can be configured from the major operating systems (even with GUI!).
+For the built-in VPN solution, we could provide config files (profiles on macOS or a config for importing with `nmtui`) for simple configuration.  
+The issue is that L2TP, despite it's name, only tunnels [PPP](https://en.wikipedia.org/wiki/Point-to-Point_Protocol).
+It seems hard to tunnel all Ethernet frames via the interface.

@@ -0,0 +42,4 @@
+### L2TPv3
+
+A solution to the layer 2 problem would be [L2TPv3](https://datatracker.ietf.org/doc/html/rfc3931).
+However, being standardized in 2005, it still has no support in major operating systems but in some of the enterprise swtiches only.

@@ -0,0 +125,4 @@
+
+Starting challenges must be an automated process in case of interactive isolated challenges.
+Challenges can consist of multiple services that interact with one another.
+As CTFs and the number of interactive challenges differs in size, there should be multiple different orchestration services that take the responsibility to start and stop challenges in virtual environments.

@@ -0,0 +152,4 @@
+The platform must support score groups.
+Score groups are a mechanism for multiple, completely independent groups to participate in a competition without interfering with each other.
+Examples are age groups where only specific age groups are eligible for winning prices.
+Scoreboards should be visible for all score groups.

@@ -0,0 +59,4 @@
+### Custom commands
+
+It could also be possible to provide commands that tunnel a user to a jump host that is provided by the platform.
+One disadvantage of this approach is that it only work for a limited number of OSs and can cause confusion.

@@ -0,0 +68,4 @@
+The platform must support the following (not exhaustive) list of challenge types:
+
+* Interactive Challenges
+  * Isolated Challenges: Multiple independent instances of challenges can be started, once per account (i.e., team or user). These have their own state.

@@ -0,0 +147,4 @@
+
+* TODO: Updating the base image
+
+### Scoring

@@ -0,0 +14,4 @@
+
+### Users and Authentication
+
+Users must be able to log in to the platform via one of these (mutually exclusive) options:

@@ -0,0 +193,4 @@
+
+### Setup
+
+The setup should be reasonably easy and straightforward. Having to debug multiple different applications and integrations to get started is a blocker for users.

@@ -0,0 +133,4 @@
+The exact interface has yet to be defined as it must be common functionality subset across orchestrators (or provide an extension point).
+Examples for orchestrators are a Kubernetes orchestrator or a Docker orchestrator.
+
+As we want to allow re-using infrastructure for orchestration (from our experience, it is quite painful to manage multiple Kubernetes instances for different settings), orchestrators must be able to orchestrate for multiple CTFs / APIs.

@@ -0,0 +180,4 @@
+Larger setups for multiple hundred to thousands of participants may need another setup routine.
+All components must be containerized, although containers may need access to host resources directly (such as the host's network).
+
+It should be possible for the API to support multiple CTFs.

@@ -0,0 +61,4 @@
+
+#### Stepping
+
+Challenges should be available in steps, i.e., if a challenge requires multiple steps to solve, the author should be able to “unlock” new descriptions after each step, depending on how much info the author wants to give.

@@ -0,0 +58,4 @@
+
+### Custom commands
+
+It could also be possible to provide commands that tunnel a user to a jump host that is provided by the platform.