CNA Disclosure Policy

Reporting a vulnerability

We strongly encourage you to report potential security vulnerabilities to our security e-mail contact first, before disclosing them in a public forum.

Only use the security contact to report (and manage the process of fixing) undisclosed security vulnerabilities in FRRouting. We cannot accept regular bug reports or other security-related queries at these addresses. We will ignore mail sent to these addresses that does not relate to an undisclosed security problem in the FRRouting project.

Also note that the FRRouting security team handles vulnerabilities in the FRRouting project, not the NetDEF / FRRouting CI Infrastructure services. Send reports of vulnerabilities in the NetDEF Infrastructure or CI Services to to security@netdef.org. (This includes issues with any netdef.org or frrouting.org websites.)

The general security contact address for FRRouting is: security@lists.frrouting.org. This is a private mailing list that accepts mail from anyone. Only FRRouting community members tasked with handling security reports are subscribed. Requests to subscribe will be rejected.

Please send one plain-text, unencrypted, email for each vulnerability you are reporting. Please don’t batch unrelated reports, as this creates ambiguity later since the initial mail can no longer be used to identify a report. We may ask you to resubmit your report if you send it as an image, movie, HTML, or PDF attachment when you could as easily describe it with plain text.

Please include in your report

  • A detailed description of the vulnerability
  • The product and version affected
  • Steps to reproduce (if possible)
  • Potential impact.

For issues with particularly high impact (in particular remote code execution), please contact us and we will reply with a PGP key so the report can be encrypted.

Scope

  • FRRouting

    Only FRRouting at this time. This excludes dependencies like rtrlib or libyang. But if unsure on component then feel free to report to us and we’ll let you know.

Out of scope

Only security issues based on a release are treated as a CVE. We will welcome reports on security issues on he frrouting master (our development branch), but if the bug doesn’t exist in a release, then we will treat this as a normal bug and not a CVE.

For issues in a forked repository, distribution package, or product shipping FRRouting (e.g. Cumulus Linux, SONiC), please confirm that the same bug exist in our releases. If not, then please report to the maintainer of the fork or distribution package.

We will issue CVEs for old versions if they seem relevant, but please be aware that we generally not provide fixes for software that is no longer supported.

Not all bugs are vulnerabilities. We use a common understanding of Internet-connected multi-user computers and protocols where some of the user accounts may have privileges. Because of this, our idea of what constitutes a vulnerability may not match definitions used by other organizations. We cannot promise every issue reported to us as a security vulnerability will be handled as one; when we differ, we will endeavor to explain our reasoning.

Security Vulnerabilities in the FRRouting CI / Testing Infrastructure or NetDEF CI / Infrastructure are not part of the CNA as we are using various products by other vendors. Please request a CVE ID for any issues there from the appropriate vendor. However, we appreciate any security notification to security@netdef.org for issues and we are happy to help you to get to the right contact for such issues.

Responsible Disclosure Commitment

NetDEF and the FRRouting community is committed to working with the security community to protect our users and products. We will not pursue legal action against individuals who report vulnerabilities responsibly and in good faith, in accordance with this policy.

What to expect from us

  • Acknowledgement

    We will acknowledge receipt of your report within 5 business days

  • Initial assessment

    We will provide an initial evaluation of the report within 10 business days

  • Status updates

    We will keep you informed of the remediation process at key stages

  • Coordination

    If the issue is confirmed as a vulnerability, we will coordinate with you regarding public disclosure, giving appropriate credit if desired

  • Confidentiality

    We ask that you do not disclose information about the vulnerability publicly until we have confirmed and addressed it.

The CNA scope is limited as noted earlier in this document.

Disclosure timelines

  • Day 0 (report received):

    We acknowledge receipt within 5 business days

  • Within 30 days:

    We aim to provide confirmation of the vulnerability, an assessment of its impact, and a remediation plan or timeline

  • Within 90 days:

    Our target is to release a fix, patch, or mitigation. In some cases, this may take longer; if so, we will keep the reporter informed

  • Public disclosure:

    We will coordinate with the reporter to disclose the vulnerability responsibly once a fix is available, or after 90 days from confirmation if no fix is yet released (following industry best practices).