Felix Walter 2dcf3b35d9 aap2: Secure the control of the storage and BDMs through AAP 2.0 ... With the addition of the storage agent and the compat. BDM we have the issue that two new agents accept configuration through bundles, which cannot check that those bundles come from trustworthy sources. In the past we restricted contact configuration messages to local clients and performed an "EID spoofing detection" so that we could check the source EID - if it is the same as the local node ID, we allowed the configuration bundle to be processed. With AAPv2 and potentially more security-relevant components (such as BDMs) appearing in the future, we need a new mechanism. The idea behind the implemented mechanism is to reuse the existing AAP 2.0 shared-secret authentication that is applied for BDMs themselves also for sending configuration messages: We add the possibility to register an AAP 2.0 RPC agent (one that sends commands *toward* uD3TN) with the "dispatch" authorization flag. This client can then request a special flag to be added when sending bundles. The new flag is only added internally by uD3TN to its in-memory data structure and is delivered to all internal agents as well as AAP 2.0 clients receiving the marked bundles. Those agents and clients (such as the sqlite/storage agent) can then easily check for the flag to be present and thus determine whether the bundle comes from an authenticated and authorized source. Note: The `adu_flags` field for the BundleADU AAP 2.0 message is now a `repeated` field to represent the option of multiple flags being present (Protobuf does not support bit fields for this purpose). Fixes: #187 Signed-off-by: Felix Walter <felix.walter@d3tn.com>		2024-06-26 10:23:17 +02:00
..
aap2	aap2: Secure the control of the storage and BDMs through AAP 2.0	2024-06-26 10:23:17 +02:00
agents/storage	sqlite: Remove destination EID from compund bundle ID	2024-06-21 10:36:30 +02:00