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>
This moves all definitions from config.h to individual header files and
makes them configurable (i.e., does not define when already defined).
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
The tests treated the linked bundle list as array (whereas it was
intended to check the payload data array instead) and used sizeof()
wrongly for determining the count of elements.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>
This adds a custom header that does explicitly not include the Unity
wrappers for malloc, free, etc. by defining the guard used by that header
file. This way we can remove the wrappers provided via the linker
altogether.
Signed-off-by: Felix Walter <felix.walter@d3tn.com>