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>
- Implement management of FIB and BDM agents:
* add administrative secret which is required for registering FIB and
BDM agents
* allow registering reverse-direction agents for TX/RX of ADUs when
passing the admin secret
* add cmdline option to pass the admin secret via an env variable
* make administrative secret optional in debug builds
- Register agents by number, as FIB and BDM agents may not have a sink
ID. Numbers are allocated by the agent_register function.
- Remove global state, add function to de-allocate everything.
- Add comprehensive unit tests.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
Depending on the selected bundle_filter, bundles can now be deleted
using either a metadata filter or a unique CompoundBundleId.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
Add a timeout to the push operation to prevent infinite blocking when
pushing into the agent_queue. If the push operation fails, an error is
returned.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
- Introduces a CompoundBundleId to filter exactly one bundle
- Filter bundles either by their ID or selected metadata
- Transfer the entire StorageCall object to the CLA via the agent queue
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
To eliminate potential race conditions where rows are deleted before the
CLA processes them, the select statement is moved from the agent to the
CLA and everything is wrapped in a transaction to read all or nothing.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
The SQLiteAgent enables SQLiteCLA to read packages from the database and
return them to μD3TN. For this purpose, the SQLiteAgent writes commands
to the queue that SQLiteCLA is waiting for.
The SQLiteAgent itself can be controlled by protobuf messages that
describe which action is to be applied to which set of bundles.
Currently the operations "Push" and "Delete" are implemented and a
filter based on a destination EID pattern.
Signed-off-by: Maximilian Nitsch <maximilian.nitsch@d3tn.com>
