A Bird's-Eye View on Security Considerations in RFCs

The paper examines security considerations explicitly discussed in RFCs published by the IETF. Four research questions were examined. The answers to these four RQs can be consecutively summarized as follows:

1. The clear majority (over 90%) of the RFCs observed have complied with RFC 1543 by providing explicit sections for security considerations. However, only a very small minority have used the standardized keywords, such as MUST and SHOULD, originally specified in RFC 2119 from 1997. Indirectly, this observation indicates that security considerations have seldom been specified as explicit requirements. The lack of keywords used in the sections for security considerations is noteworthy also because the use of keywords in RFCs has generally grown since 2001 [26]. Their use has been recommended also for security considerations [46], but, according to the results, to no avail.

2. There are a few heavily referenced RFCs, although generally the RFC-to-RFC reference network is sparse. Particularly the protocols and associated RFCs for TLS stand out in terms of inward references they have gathered from other RFCs.

3. The volume of references peaked between circa mid-1990s to mid-2010s, and the heavily referenced RFCs are mostly quite recent. The result is interesting in a sense that the contrary could have been expected. In other words, the fundamental, the core RFCs published prior to mid-1990s could have been hypothesized to gather more references. The earlier point about TLS may explain also this longitudinal result.

4. The topics in the sections for security considerations are mostly protocol-specific instead of being about general, protocol-agnostic security topics, such as those related to denial of service attacks, authentication and authorization, or key management. With the exceptions of three general topics about network security in general, security specifications, and routing, the longitudinal evolution of the topics also tend to reflect the time periods during which the specific protocols were actively designed and standardized.

Improvements to AI Systems:

1. Automated Security-Requirement Compliance Checker for Standards Documents

• Train a model to detect whether security consideration sections in technical standards (e.g., RFCs) use normative keywords (MUST, SHOULD, etc.) versus descriptive language.

• The improved AI can automatically flag drafts or proposed standards where security guidance is non-normative, enabling standards bodies to enforce stronger security requirements before publication.

2. Security-Topic Trend Analyzer for Protocol Evolution

• Use the paper’s finding that security topics are protocol-specific and time-bound to build an AI that maps security discussions in standards to specific protocols and eras.

• The improved AI can predict emerging security gaps in new protocols by comparing their security sections against historical topic distributions, alerting designers to missing general topics (e.g., DoS, key management) that are underrepresented.

3. Reference-Network-Based Security Dependency Mapper

• Leverage the sparse reference network and the centrality of TLS-related RFCs to create an AI that identifies critical dependencies between security standards.

• The improved AI can automatically generate a risk-ranked list of standards that, if updated or deprecated, would have the highest downstream security impact—enabling proactive maintenance of the most referenced security protocols.

4. Keyword-Gap Detector for Security Specifications

• Build a classifier that distinguishes between security sections that are actionable (using normative keywords) versus those that are merely informational.

• The improved AI can scan new or updated RFCs and recommend where to insert MUST/SHOULD statements, directly addressing the paper’s finding that over 90% of RFCs lack such keywords in security sections.

5. Longitudinal Security-Topic Forecasting Model

• Using the observed peak in references (mid-1990s to mid-2010s) and the recency of heavily referenced RFCs, train a temporal model that predicts which current security topics will become foundational in the next decade.

• The improved AI can help standards organizations allocate resources to emerging protocols that are likely to gather many future references, ensuring early security hardening.

6. Cross-Protocol Security Gap Analyzer

• Since security topics are mostly protocol-specific, create an AI that clusters security sections by protocol family and identifies missing general security themes (e.g., authentication, authorization) within each cluster.

• The improved AI can automatically recommend cross-cutting security controls for new protocols by comparing them to the three general topics found in the paper (network security, security specifications, routing).

Request for comments (RFCs) are Internet standards, memorandums, and related technical documents about core Internet protocols made via and released by the Internet Engineering Task Force (IETF). In the early 1990s each RFC was required to have a section for security considerations. The present work examines these sections. According to the empirical results, (1) over 90% of the RFCs sampled have discussed security explicitly in these sections, (2) although mandatory security requirements have only seldom-if ever-been imposed. Furthermore, (3) the RFC-to-RFC reference network specific to the security consideration sections is sparse, although a few RFCs and their security consideration sections are heavily referenced. In addition, (4) the volume of references peaked during a period from circa mid-1990s to mid-2010s. Regarding the topics discussed in the sections, (5) these do not represent general security issues, such as spoofing or eavesdropping; rather, the topics mostly reflect distinct security issues specific to distinct protocols. With the exceptions of network security in general, security specifications, and routing, (6) also the longitudinal evolution of the topics is protocol-specific. As the subject matter has not been previously examined, these empirical results fill a gap in the standardization literature.