Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Miscellaneous small improvements for socktap, btp and geonet #106

Closed
wants to merge 7 commits into from

Conversation

glmax
Copy link
Contributor

@glmax glmax commented Feb 24, 2020

This PR is a collection of different small improvements for btp, geonet, socktap.

  • BTP: Added hooks can now be removed again.
  • GN: The security report is only initialized when the security entity has actually been invoked.
  • Socktap:
    • Applications can be disabled again (combined with the BTP change, one can close ports in both directions).
    • Status messages are assembled separately and then printed to std::cout as one string.
    • AA certificates provided via commandline are put into the certificate cache so if other stations use the same AA, the certificate does not need to be requested from them.
    • New command line parameter to control MIB parameter ItnGnSnDecapResultHandling.
    • Make the SecurityEntity parameter of RouterContext's constructor a pointer to conform with the interface/requirements of Router.

This is especially important when receiving messages signed by a ticket
from the same authorization authority because then the AA certificate
is requested in the next CAM although it is already known because
it has been provided via the command line.
The class Router's setter for its security_entity member needs a
pointer to a SecurityEntity which may as well be nullptr. With this in
mind, RouterContext should also only deal with a pointer. This way,
if no security is wanted/needed, one does not have to create a dummy
SecurityEntity just to satisfy RouterContext's interface.
According to the GN standard, the GN indication's field security_report
shall be set to the corresponding value returned by the security entity
in SN-DECAP.confirm. For packets without a secure header, SN-DECAP is
never invoked, so security_report should not be initialized.

This way, since Vanetza uses a boost::optional for that field, the
upper layers can directly tell whether a packet had a secure header
without guessing from the other security-related indication fields.
std::cout << "sent packet to " << request.destination << " (" << bytes_sent << " bytes)\n";
std::ostringstream ostream;
ostream << "sent packet to " << request.destination << " (" << bytes_sent << " bytes)\n";
std::cout << ostream.str();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this beneficial? From my point of view, this causes an additional memory allocation and thus this should be justifiable.

Copy link
Contributor Author

@glmax glmax Feb 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When Vanetza shares stdout with other threads that manipulate the flags for stdout, it can happen (although rarely and unpredictable) that the std::hex flag set in the streaming operator overload of MacAddress is not properly cleared. One could probably move the special treatment to the streaming operator overload.

If you don't see that as a problem Socktap/Vanetza should care about, feel free to omit this commit.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, but socktap is not multi-threaded ;-) If this is going to change, we will need some more sophisticated logging anyway.

@@ -398,7 +398,6 @@ void Router::indicate_basic(IndicationContextBasic& ctx)
indicate_secured(ctx, *basic);
} else if (basic->next_header == NextHeaderBasic::Common) {
if (!m_mib.itsGnSecurity || SecurityDecapHandling::Non_Strict == m_mib.itsGnSnDecapResultHandling) {
indication.security_report = security::DecapReport::Unsigned_Message,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, security_report is not optional in geonet::DataIndication though EN 302 636-4-1 says so. Why do you think that Unsigned_Message is unsuitable?

Copy link
Contributor Author

@glmax glmax Feb 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry, that commit/change needs to be moved to #105. There, security_report is made optional because of EN 302 636-4-1 and EN 302 636-5-1.

Apart from that, please have a look at the explanation in the commit message. Essentially, the security report is the report from the security entity which is never invoked for packets without secure header.

@@ -144,6 +148,7 @@ int main(int argc, const char** argv)
for (auto& chain_path : vm["certificate-chain"].as<std::vector<std::string> >()) {
auto chain_certificate = security::load_certificate_from_file(chain_path);
chain.push_back(chain_certificate);
cert_cache.insert(chain_certificate);

// Only add root certificates to trust store, so certificate requests are visible for demo purposes.
Copy link
Contributor Author

@glmax glmax Feb 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding this comment and the change above: Demonstrating certificate requests by using tickets signed by different AAs is a cleaner way and closer to the use of this feature in the real world.

If you want to keep this need for a request for the own AA certificate as a demo feature, I would propose that it is off by default and can be activated via a command line option.

@riebl
Copy link
Owner

riebl commented Feb 28, 2020

Merged except for "status message as single string" and the not-yet optional security_report.

@riebl riebl closed this Feb 28, 2020
@glmax glmax deleted the misc branch February 28, 2020 16:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants