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

A Bird’s-Eye View on Security Considerations in RFCs Jukka Ruohonena,∗, Qusai Ramadana a University of Southern Denmark, Sønderborg, Denmark

Abstract

arXiv:2608.09865v1 [cs.CR] 10 Aug 2026

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. Keywords: Internet protocols, network protocols, network security, standards, standardization, security specifications

1. Introduction The Internet’s early design philosophy emphasized multiplexing, reliability, heterogeneity of networks and hosts, distributed management, cost-effectiveness, scalability, and accountability [12]. Security was not an explicit concern. It was only later on, in the 1990s, when security started to appear as a design principle in conjunction with the end-to-end architectural design principle [10]. It was also in the early 1990s when all RFCs were mandated to have explicit sections for discussing any and all security considerations that a new protocol, memorandum, or other technical document might carry [43]. The present work examines these explicit security considerations. What do they say? What security domains and concepts are pronounced? Which RFCs are highly referenced in terms of security? Are security requirements imposed? These motivating questions can be formalized into the following four research questions (RQs): • RQ.1: How many RFCs have explicitly acknowledged security considerations, and are IETF’s standardized keywords for requirements used in these? • RQ.2: How many RFCs are central references in terms of explicitly acknowledged security considerations? • RQ.3: When were the central RFC references published; how has the referencing evolved over time? ∗ Corresponding author.

Email address: juk@mmmi.sdu.dk (Jukka Ruohonen) Preprint submitted to Elsevier

• RQ.4: What are the main topics discussed in the explicitly acknowledged security considerations of RFCs, and how have the topics evolved over time? As soon discussed in the opening Section 2, these and related questions have neither been asked nor answered previously. Though, before continuing, a clarifying remark is required about the questions: even though the security considerations sections can be viewed as a proxy for how security considerations are documented within the IETF, the results should not be interpreted as characterizing the complete security reasoning or discussions that took place during protocol design and standardization work. Rather, they characterize how security considerations have been documented in RFCs. Then, after presenting the dataset examined in Section 3, the methods are elaborated in Section 4. The empirical results are subsequently presented in Section 5. The conclusion, including the answers to the research questions, is presented in the last Section 6. It also provides a brief discussion about limitations, practical implications, and further research directions. 2. Background and Related Work The IETF and its history have been extensively studied, including with respect to RFCs and the work practices for standardization around them [13, 44]. Of the existing work, particularly noteworthy is the research on the adoption of protocols and the adoption challenges sometimes encountered [24, 26]. Although security surely is a chalAugust 11, 2026

lenge for the Internet and its protocols, it may paradoxically not be a challenge for the adoption of new protocols.

3. Data 3.1. Retrieval The data was collected on 15 March 2026 from the IETF’s online archive.1 In practice, the collection involved a loop i = 1, . . . , m with which both obsoleted RFCs and RFCs in-force were retrieved sequentially. For instance: when i = 2000, the corresponding RFC was retrieved from the archive as a rfc2000.html file. To ease parsing, the files were retrieved in the hypertext markup language format. Given the data collection date, the maximum was set to m = 10, 000 because the exact amount of RFCs was not explicitly known at the time of data collection. Although the IETF indeed uses sequential numbers for RFCs, a few older ones were not available from the archive; in total, 290 such cases were recorded during the retrieval. This amount includes also a few RFCs that were not yet published at the time of the data collection; RFC 9939 is the latest request for comments observed.

As an informational RFC from the late 2000s noted, protocols “with security flaws may still become wildly successful provided that they are extensible enough to allow the flaws to be addressed in subsequent revisions” [42]. The RFC further contemplated that security vulnerabilities “do not seem to limit initial success, since vulnerabilities often become interesting to attackers only after the protocol becomes widely deployed enough to become a useful target” [42]. Rather analogous reasoning is behind a so-called popularity hypothesis in software security [37]. In fact, implicitly, one finds analogous reasoning already from the very first RFC 1 released in 1969; “there will be a period of very light usage until the community of users experiments with the network and begins to depend upon it” [14]. When it comes to security, the later “experimentation” since the 1990s was not necessarily what was envisioned in the late 1960s—even though the point about experimentation in itself certainly stood the test of time.

3.2. Parsing The analysis is based on the specific security considerations section that was first introduced in RFC 1543. According to this RFC from 1993, all “RFCs must contain a section near the end of the document that discusses the security considerations of the protocol or procedures that are the main topic of the RFC” [43]. In total, 1, 1270 RFCs did not have such a section, which is understandable due to the looping from the very first RFC that was published as early as 1969. When the downloading errors are further excluded, the analysis operates with n = 8, 440 RFCs having explicit sections for security considerations. Thus, given the numbers mentioned, m = 290 + 1, 270 + n. However, having a standardized section for security considerations does not mean that security is always addressed in the RFCs. This point is also why the RQs emphasize the adjective explicit in conjunction with the security considerations. Regarding RQ.1, two simple parsing rules are used: a RFC’s section for security considerations is taken to lack explicit security consideration in case (a) the section’s length is less than thirty characters or (b) any of the strings in Table 1 appear anywhere in the section. The latter part of RQ.1 needs a brief comment too. Although RFC 8174 clarified that the IETF’s standardized keywords for requirements, including with respect to cases such as MAY, MUST, and MUST NOT, should only be considered when spelled in capital letters [23], lower-cased matches are counted for the eleven keywords specified in the RFC mentioned. The reason is simple: none of the RFCs sampled specified even a single upper-cased keyword in their sections for security considerations. It should be remarked that only the security sections are parsed. If used, the parsing includes subsections present in the main security considerations section; see [3] for an

Furthermore, somewhat similar sentiments have been expressed by academic researchers having been involved at the IETF’s standardization; the Internet’s “protocols are a convoluted mess, patched together to solve numerous short-term issues”, but this state of affairs “is expected and normal” [45, p. 6]. However, when it comes to security-specific techniques, practices, and standards, adoption challenges have frequently been discussed in the literature [34, 38]. The IETF’s protocols for the Internet are not an exception. The domain name system is a good example; despite various new security improvements, adoption of them has been slow and various sophisticated attacks continue [39, 47]. Although patching is possible and even a normal practice with Internet protocols, a strong argument can thus be raised that with security, in particular, diligence early on may well pay off. Fixing things later on can be difficult and costly. Finally, it is worth pinpointing a few works that are related through methodology. In particular, the citations in RFCs and the keywords used in them have been examined also previously [25, 26], including with network analysis [17] used also in the present work. However: to the best of the authors’ knowledge based on thorough but still non-systematic literature searches, none of the methodologically related previous works have explicitly concentrated on the security considerations expressed in RFCs. There are some implicitly related works that have analyzed these in distinct domains such as Internet-of-things [28]. Also the IETF’s work on privacy has been surveyed [16]. Again, however, neither have these contextually related works considered the security considerations as a whole. Therefore, the present work fills a gap in existing research.

1 https://www.rfc-editor.org/rfc/

2

measures: weighted in-degree centrality, betweenness centrality, and closeness centrality. All are well-known centrality measures needing no particular elaboration; details and definitions are available from the literature [15, 22]. The only exception is the weighted in-degree centrality for which a concept of strength has sometimes been used as a synonym [5]. An example clarifies things: if a given RFC only received references from a single another RFC but this referencing RFC made ten references to the receiving RFC, the weighted in-degree (strength) of the referenced RFC is ten (and not one, as would be the case with unweighted in-degree). To also recall: all references between the RFCs observed refer to those made within their standardized security consideration sections. In general, only the weighted in-degree centrality conveys a straightforward interpretation: for a given RFC, it is the count of references made to the RFC in the security consideration sections of other RFCs. Thus, it can be interpreted in a similar vein than citations of scientific publications. Although some interpretation guidance is available also for the other two centrality measures in scientific citation networks [1, 15], it is difficult to transfer them to the RFC context. Thus, the answer to RQ.2 is sought by focusing primarily on the weighted in-degree centrality and secondarily on those other two centrality measures correlated with the weighted in-degree centrality values. Because many networks are scale-free, meaning that their degree distributions tend to follow a power law, Spearman’s rank correlation coefficient has been recommend over the Pearson’s product-moment correlation coefficient [40]. It is thus adopted for evaluating the correlations between the three centrality measures. To help answering to RQ.2 and RQ.3, a cutoff point is required. Again due to the scale-free nature of many networks, a scree test [11], or a scree plot, which is commonly used dimension reduction computations, has been adopted for determining suitable cutoff points for centrality values [20, 21]. Although somewhat subjective, a scree plot is thus used for sharpening the answers to RQ.2 and RQ.3.

Table 1: Strings for the Absence of Explicit Security Considerations “this document does not impact the security” “security is not explicitly discussed in this” “Security is not discussed in this” “Security is not addressed in this” “Security is not directly addressed by this” “Security is not discussed directly in this” “Security isses are not discussed in this” “Security issues are not discussed in this” “Security issues are not addressed in this” “Security issues are not considered in this” “Security concerns are not addressed in this” “Security considerations are not addressed here” “Security considerations are not addressed in this” “Security considerations are not discussed in this” “Security issues are not directly discussed in this” “Security issues are not discussed in detail in this” “Security issues are not explicitly discussed in this” “Security issues are not specifically addressed in this” “Security issues are not substantially discussed in this” “This RFC does not discuss security issues” “This RFC does not address issues of security” “This document does not affect the security issues” “This document does not alter the security properties” “This update does not change the security considerations” “This memo does not directly address security issues” “This document does not discuss security considerations” “This document does not introduce additional security requirements” “This document does not raise any additional security issue” “Security and Liability issues are not discussed in this”

example about such cases. However, those RFCs are not fully assessed that have placed their security discussions into appendices that are then referenced in the brief security sections; see [31] for an example. Nor are references followed. In other words, a RFC whose section for security considerations references other RFCs is parsed only in terms of what is explicitly written in the section. These choices are sensible because attempting to cover complex within-RFC and between-RFC referencing would presumably increase a probability of parsing errors.

4. Methods 4.1. Network Analysis Network (graph) analysis is used for answering to RQ.2. Like with citation networks in science, a weighted and directed network is used; vertices refer to RFCs and edges to references between them. More specifically, a vertex in the network means that a given RFC either referenced other RFCs in its section for security considerations or the RFC was referenced by other RFCs in their own sections for security considerations. Thus, the network is specific to RFCs; other references, including references to other standards, are excluded. Also within-RFC references are excluded; hence, there are no self-loops in the weighted and directed network. Analogously to citations in science, edge weights denote reference counts. It should also be remarked that the RFCs without explicit security considerations (cf. RQ.1) are included in the network insofar as they referenced other RFCs or were referenced by other RFCs. The wording in RQ.2 and RQ.3 about central references is approached with three conventional network centrality

4.2. Topic Modeling The topic modeling is conducted with BERTopic [18]. It uses transformers and class-based term frequency-inverse document frequency (c-TF-IDF) weights. When compared to the conventional latent Dirichlet allocation method for topic modeling [8], BERTopic is beneficial due to its leverage of sentence embeddings that often yield semantically richer and more coherent topic groupings [2]. Although RFCs are technical documents, they exhibit a considerable lexical diversity through the use of specialized terminology, synonyms, abbreviations, and related concepts. This lexical diversity makes BERTopic well-suited for clustering a heterogeneous corpus such as the security considerations sections of RFCs. With respect to the second part of RQ.4, the implementation used [18, 19] also allows effortless longitudinal evaluation. 3

With respect to computational details, the number of topics was restricted to t = 20. As is common in topic modeling [33], the choice was made primarily based on human interpretability of the topics according to the tokens in them and their probabilities used as weights. In addition, perplexity values were secondarily evaluated; lower values are better [48]. Each topic was specified to have at least five tokens. For longitudinal modeling, evolutionary tuning was used. These configurations notwithstanding, the default parameters of the implementation were used. Regarding pre-processing, (1) the sections for security considerations were tokenized according to white space and punctuation characters. Then, (2) after lower-casing the tokens, (3) only alphabetical tokens recognized as nouns were included. In addition, (4) tokens with lengths less than three characters or over twenty characters were excluded alongside stopwords. Finally, (5) a few stopwords were excluded.2 The tokens were finally (6) lemmatized into their English dictionary forms whenever possible. A small qualitative cross-check was done by the authors about the interpretation and labeling of the topics extracted. Namely: after the first author had labeled and interpreted the topics, including writing of Subsection 5.3, the second author was asked to evaluate the labels and interpretations. All disagreements were recorder. Both authors were further asked to independently rank each topic with respect to its coherence and interpretability with a scale from zero (extremely incoherent and impossible to interpret) to ten (highly coherent and easy to interpret). Regarding the initial labeling and interpretation made by the first author, when in doubt, the qualitative assessment required was aided by searching the corpus for the given nouns and then reading what they were about. This search-based aid was necessary because many of the tokens are about technical terms, including abbreviations. The other author was instructed to do the same. He was also given the complete topic groupings instead of the shortened summaries presented in the paper.

Table 2: Correlations (Spearman) Between the Centrality Measures

1. 2. 3.

Weighted in-degree Betweenness Closeness

1. 1.00 0.53 0.13

2. 0.53 1.00 0.21

3. 0.13 0.21 1.00

Figure 1: The RFC-to-RFC Reference Network (sizes of vertices scaled by their weighted in-degrees)

However, a similar conclusion does not apply with respect to the IETF’s standardized keywords. As was already noted in Subsection 3.2, not a single upper-cased keyword appears in the security sections. With lowercased matching, which may contain also false positives, the order is: 18 occurrences of “should”, 14 matches of “shall”, 7 cases of “must”, 3 occurrences of “should not”, and 2 matches of “must not”. Given these numbers and the guidelines [23], it can be concluded that the security considerations have seldom contained strict so-called MoSCoW-style [27] requirement specifications for security.

5. Results 5.1. Explicit Security Considerations and Keywords The results are presented by going through the RQs consecutively. Thus, regarding RQ.1, the two parsing rules caught only 779 cases without explicit security considerations despite the existence of the standardized section for security considerations. Given that 779/n×100 ≈ 9.2%, it can be concluded that explicit security considerations are generally well-represented in the RFCs sampled.

5.2. Network Analysis Results Turning to RQ.2, it can be started by noting that the RFC-to-RFC referencing network is sparse. In fact, its density—the ratio of edges to the theoretical maximum number of edges—is only 0.0004. In other words, many RFCs have neither referenced other RFCs nor having been referenced by other RFCs. However, as seen from the visualization in Fig. 1, a few of the RFCs have been heavily referenced. Before continuing to elaborate these RFCs and the visualization further, the correlations between the three centrality measures should be assessed. These are shown in Table 2. As can be seen, the weighted in-degrees only correlate fairly with the betweenness centrality values. Thus, as per the discussion in Subsection 4.1, the

2 In addition to the stopwords present in the library used for the pre-processing [30], the following custom stopwords were excluded: amount, document, dot, end, far, get, going, like, make, med, name, none, note, paper, part, pose, publication, rfc, regard, section, set, single, sub, thus, take, us, usage, use, user, using, and well. These custom stopwords were excluded because they made the topic groupings more incoherent and harder to interpret. In addition, it should be remarked that the library categorizes also tokens it does not recognize grammatically as nouns; abbreviations are a good example.

4

Weighted in-degree centrality RFC 8446 RFC 5246 RFC 6241 RFC 3261 RFC 8040 RFC 8341 RFC 3550 RFC 3711 RFC 6242 RFC 5920 RFC 4301 RFC 4086 RFC 5440 RFC 3986 RFC 5280 RFC 4303 RFC 3315 RFC 5310 RFC 3473 RFC 3748 RFC 5304 RFC 7285 RFC 7432 RFC 3579 RFC 2865

Betweenness centrality RFC 3552 RFC 7525 RFC 2817 RFC 8040 RFC 3748 RFC 3579 RFC 7230 RFC 7011 RFC 9325 RFC 5082 RFC 4960 RFC 2616 RFC 7252 RFC 5890 RFC 4033 RFC 2518 RFC 8402 RFC 5101 RFC 5920 RFC 3711 RFC 3473 RFC 5988 RFC 3985 RFC 8205 RFC 6733

Not in both plots In both rankings 0

50

100

150

Not in both plots In both rankings 0

200

Weighted in-degree

400

600

800 1000

Betweenness

Figure 2: Top-25 Referenced RFCs According to Two Centrality Measures

Weighted in-degree centrality

Betweenness centrality 4

Threshold

2.5

Threshold

3

1.5

Density

Density

2.0 252 RFCs above the threshold

1.0

723 RFCs above the threshold

2 1

0.5 0.0

0 0

1

2

3

4

5

0

log(centrality + 1)

1

2

3

4

5

6

7

log(centrality + 1)

Figure 3: Distributions of the Weighted In-degree and Betweenness Centrality Values

betweenness centrality is taken alongside the weighted indegrees for further examination.

place in the betweenness centrality ranking shown in the right-hand side plot of Fig. 2. In general, however, there are only six RFCs that appear in both top-25 centrality rankings. This observation further supports the choice to include the betweenness centrality measure to accompany the weighted in-degree values for constructing the sample.

Yet, to continue briefly with the weighted in-degrees, the two largest, almost equally sized vertices in Fig. 1 denote RFCs for the transport layer security (TLS) protocol versions 1.2 and 1.3. Given the fundamental nature of the TLS for the whole Internet’s security, the two topmost places in terms of the weighted in-degree ranking in Fig. 2 are hardly surprising. The third and fourth places in the left-hand side plot of the figure are worth also explicitly mentioning: these are specifications for the network configuration protocol (NETCONF) and the session initiation protocol (SIP), released in 2011 and 2002, respectively. The fifth place is taken by RFC 8040 [7], which is also about NETCONF. This RFC 8040 takes also the fourth

The highest ranked RFC in terms of the betweenness centrality values is also worth mentioning; it is RFC 3552, which is no more and no less than about guidelines for writing the standardized sections for security considerations [32]. This result aligns with the notion of betweenness centrality as a measure on how frequently a vertex appears in the shortest paths between other nodes. In other words, it could indeed be seen as something central through which generic RFC security information passes. 5

Weighted in-degree centrality

Mean Median

5

10000

600

4

Sum

Average

Sum Cumulative sum

800

3

8000 6000

400

4000

2

200

2000

1

0

0

0 1980

1992

2003

2014

2025

1980

Betweenness centrality

2014

2025

15

30000

Sum Cumulative sum

2000

25000

1500

Sum

Average

2003

Betweenness centrality Mean Median

20

1992

10

20000 15000

1000

10000 5

500

0

0 1980

1992

2003

2014

2025

Cumulative sum

6

Cumulative sum

Weighted in-degree centrality

5000 0 1980

1992

2003

2014

2025

Figure 4: Weighted In-degree and Betweenness Centrality Across Publication Years

However, the rankings are not particularly relevant for answering to RQ.2. In this regard, Fig. 3 displays the empirical probability distributions of the two centrality measure values. Both are long-tailed but both also indicate relatively interpretable cutoff points regarding their tails and hence the most central RFCs. A total of 975 RFCs exceed the thresholds shown in the figure’s two plots. Of these, 113 are duplicates and thus the heuristic answer to RQ.2 can be conveyed as a share 862/n × 100 = 10.2%. Even with the subjectivity involved with scree plots, the answer seems generally sensible also in terms of Fig. 1.

5.3. Topic Modeling Results The choice of t = 20 provides a good starting point for presenting the topic modeling results. While, as said, interpretability was the primary criterion, also the perplexity values shown in Fig. 5 support the choice. Thus, the 20 topics extracted and the top-12 nouns in each of them are shown in Fig. 6. The scalar c at the bottom-right corner of the figure’s each plot refers to the mean of the interpretability and coherence rankings done by the two authors independently and blinded from each other. As can be observed, the values are generally high; interpretability and coherence were generally perceived as being suitable. In fact, the minimum value is as high as 7.5. Furthermore, no disagreements were recorded between the two authors.

Regarding RQ.3, a further point to deduce from Fig. 2 is that many of the top-ranked RFCs are quite recent, relatively speaking—keeping in mind the earlier remark about the first RFC being from 1969. The four visualizations in Fig. 4 shed further light. By focusing on the weighted indegrees for brevity, the two upper plots indicate that the volume of references peaked during a period circa from mid-1990s to mid-2010s. When focusing on the top-left plot in the figure, it can also be concluded that the average reference amounts started to decline already around 2005. Therefore, much of the growth trends in the top-right plot are explained by the top-referenced RFCs in the earlier Fig. 2. A further point is that the security-specific referencing trends differ from those reported for all references, which tended to exhibit a slowly increasing trend between 2001 and 2020 with about ten to fifteen RFC-specific references [26, Fig. 7]. With these results and interpretations, the topic modeling results can be presented next.

Perplexity

2.10 2.05 2.00 1.95 1.90 5

10

15

20

25

30

35

40

45

50

Number of topics

Figure 5: Perplexity Values

Before continuing, it should be noted that the top-12 nouns do not convey all information that was used for the labeling of the topics. For instance, the label for the eight topic cannot be easily deduced from the tokens shown in Fig. 6. Although not visible in the top-12 rankings, the 6

1. Network security #1 security attack network authentication protocol message data server client information access service

c=9 0.000

0.010

0.020

c = 8.5 0.00

0.05

0.10

0.15

3. Routing lsas ospf link advertisement extension effect mac security computation mechanism plane issue

0.20

4. Instant messaging

c = 10 0.00

0.10

0.20

xmpp sip presence gateway see msrp messaging rsvp amplification message subscription stanza

0.30

c = 10 0.00

0.10

0.20

0.30

Probability

Probability

Probability

Probability

5. Compression

6. Label switching

7. Calendaring

8. Virtual private networks

compression length compress data princeton article header schc payload consideration information university

c=8 0.00

2. Security specifications consideration security apply specification issue ldp resolution procedure iteration introduces bit number

0.05

0.10

0.15

0.20

mpls multipath traffic load node leaf exercise redistribution traceroute responder origination propagation

0.25

calendar webdav caldav availability webnfs time distribution filesystem component xml server specification

c=9 0.00

0.05

0.10

0.15

0.20

c = 10 0.00

0.05

0.10

label egress srgbs pe space node lsp allocation backup method add option

0.15

c = 7.5 0.0

0.1

0.2

0.3

0.4

Probability

Probability

Probability

Probability

9. Registration data

10. Network security #2

11. Symmetric-key cryptography

12. Routing parameters

rdap geofeed besides source file consideration retains property security tl reduces bootstrap

c=8 0.0

0.2

0.4

0.6

0.8

gcm tag aria problem rfcs time security length context analysis consideration result

c = 7.5 0.0

0.1

0.2

0.3

0.4

0.5

c = 9.5 0.0

0.1

0.2

0.3

diversity xro subobjects boundary path computation nsis concern route addition issue exchange

0.4

c = 7.5 0.0

0.4

0.8

1.2

Probability

Probability

Probability

Probability

13. Public key cryptography

14. Code execution

15. Certificate revocation

16. Locator/ID separation

establishment pair cryptography suite signature performance employment key employ pki consideration curve

c = 10 0.0

loop format detect line create path apply hop source header threat node

0.1

0.2

0.3

script fileinto action sieve change invocation flag loop site redirect mailbox message

0.4

c = 7.5 0.0

Probability

c=9 0.0 0.1 0.2 0.3 0.4 0.5 0.6

Probability

0.2

0.4

0.6

c = 10 0.0

0.1

Probability

17. Web tokens introspection jwt typ claim access token prevent resource server authorization jwts substitution

ocsp response nonce extension request replay copy status certificate configurable indicate value

0.10

0.20

0.4

0.0

0.1

0.30

Probability

0.1

0.2

0.3

Probability

Figure 6: The Top-12 Tokens in Each Twenty Topics

7

0.3

0.4

0.5

20. IETF

c = 10 0.0

0.2

Probability

19. Printing ldap printer schema entry spooler intruder guidance supply print protect administrator attribute

c=8 0.00

0.3

c=8

Probability

18. Broadcasting broadcast radio encryption ipsec ssh channel mikey mtk ssl link tl traffic

0.2

lisp mapping rig database entry infrastructure facilitates lig protect access property information

0.4

0.5

volunteer organization meeting month affiliation leadership eligibility community chance investigation capture attendee

c = 10 0.0

0.1

0.2

0.3

Probability

0.4

1991

protocols were actively developed and standardized.

1992 1994 1996

6. Conclusion and Discussion

1997 1998 2000

6.1. Conclusion

2001

The paper examined 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:

2002 2003 2004 2005 2006 2007 2008

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.

2009 2011 2012 2013 2015 2016 2017 2019 2020 2021 2022 2023 2024 2025 1

2

3

4

5

6

7

8

9

10 11 12 13 14 15 16 17 18 19 20 Topic

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.

Figure 7: Annual Presence of the Topics

topic contains the tokens evpn and mvpn. Given that these are lower-cased abbreviations for Ethernet VPN, where VPN stands for Virtual Private Network, and Mobile VPN, the topic was labeled to represent VPNs. Then, there are four generic topics: the topics 1 and 10 are about network security general, the topic 2 is about terminology typical to the sections for security considerations, and the topic 20 is about organizational matters related to IETF and RFC drafting. As further seen from Fig. 7, the first topic is the only one occurring throughout the time period observed. Also the second and third topics mostly occur each year. This observation is understandable because the topics 1 and 2 are generic, whereas the topic 3 is about routing, which is a core functionality of the Internet, including with respect to security. With the exception of the four generic topics and the two topics representing cryptography, the topics do not seem to represent distinct security issues, such as denial of service attacks, security issues with encapsulation and fragmentation, spoofing, data injection, tampering, traffic analysis, authentication and authorization, reconnaissance, eavesdropping, data injection, replaying, firewall traversal, issues with network address translation, key management insecurities, deprecated protocols, or something else. Rather—and with respect to RQ.4, the topics seem to reflect distinct security issues in distinct protocols. Excluding the first three topics already noted, also the longitudinal evolution of the topics visualized in Fig. 7 can be interpreted to reflect the time periods when the

3. The volume of references peaked between circa mid1990s 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. 6.2. Limitations A notable yet still hypothetical limitation relates to potential parsing errors. As was noted in Subsection 3.2, complex within-RFC and across-RFC referencing, including the use of appendices, is another notable limitation. That said, there is a trade-off between these two limitations; by trying to cover sections referenced, parsing errors 8

would have likely increased. As always with text mining, the topic modeling results can be acknowledged to also present only a coarse picture of the actual security considerations discussed in the RFCs. To address this limitation, qualitative research can be recommended for further work.

Engineering Task Force (IETF), available online in March 2026: https://datatracker.ietf.org/doc/html/rfc4187. [4] Bach, J. (2023). The Challenge of “Good Enough” Software. A modified version of an article that appeared in the American Programmer magazine, available online in April 2026: https://www.satisfice.com/download/ the-challenge-of-good-enough-software. [5] Barrat, A., Barthélemy, M., Pastor-Satorras, R., and Vespignani, A. (2004). The Architecture of Complex Weighted Networks. Proceedings of the National Academy of Sciences of the United States of America, 101(11):3747–3752. [6] Bhatia, M., Manral, V., and Lindem, A. (2014). Supporting Authentication Trailer for OSPFv3. Request for Comments: 7166, Internet Engineering Task Force (IETF), available online in March 2026: https://datatracker.ietf.org/doc/html/rfc7166. [7] Bierman, A., Bjorklund, M., and Watsen, K. (2018). RESTCONF Protocol. Request for Comments: 8040, Internet Engineering Task Force (IETF), available online in March 2026: https://datatracker.ietf.org/doc/html/rfc8040. [8] Blei, D. M. (2012). Probabilistic Topic Models. Communications of the ACM, 55(4):77–84. [9] Boyes, H. and Higgins, M. D. (2024). An Overview of Information and Cyber Security Standards. Journal of ICT Standardization, 12(1):95–134. [10] Carpenter, B. E. (1996). Architectural Principles of the Internet. Request for Comments: 1958, Internet Engineering Task Force (IETF), available online in March 2026: https:// datatracker.ietf.org/doc/html/rfc1958. [11] Cattell, R. B. (1966). The Scree Test for the Number of Factors. Multivariate Behavioral Research, 1(2):245–276. [12] Clark, D. D. (1988). The Design Philosophy of the DARPA Internet Protocols. In Symposium Proceedings on Communications Architectures and Protocols (SIGCOMM 1988), pages 106–114, Stanford. ACM. [13] Coleman, L. (2013). “We Reject: Kings, Presidents, and Voting”: Internet Community Autonomy in Managing the Growth of the Internet. Journal of Information Technology & Politics, 10(2):171–189. [14] Crocker, S. (1969). Host Software. Request for Comments: 1, Internet Engineering Task Force (IETF), available online in March 2026: https://datatracker.ietf.org/doc/html/rfc1. [15] Diallo, S. Y., Lynch, C. J., Gore, R., and Padilla, J. J. (2016). Identifying Key Papers Within a Journal via Network Centrality Measures. Scientometrics, 107:1005–1020. [16] Dikshit, P., Sengupta, J., and Bajpa, V. (2023). Recent Trends on Privacy-Preserving Technologies under Standardization at the IETF. ACM SIGCOMM Computer Communication Review, 53(2):22–30. [17] Gencer, M. (2012). The Evolution of IETF Standards and their Production. International Journal of IT Standards and Standardization Research, 10(1):17–33. [18] Grootendorst, M. (2022). BERTopic: Neural Topic Modeling With a Class-Based TF-IDF Procedure. Archived manuscript, available online in June 2026: https://doi.org/10.48550/arXiv. 2203.05794. [19] Grootendorst, M. (2024). BERTopic. Available online in June 2026: https://maartengr.github.io/BERTopic/index. html#visualizations. [20] Himelboim, I. and Golan, G. J. (2019). A Social Networks Approach to Viral Advertising: The Role of Primary, Contextual, and Low Influencers. Social Media + Society, 5(3):1–13. [21] Himelboim, I., Smith, M. A., Rainie, L., Shneiderman, B., and Espina, C. (2017). Classifying Twitter Topic-Networks Using Social Network Analysis. Social Media + Society, 3(1):1–13. [22] Landherr, A., Friedl, B., and Heidemann, J. (2010). A Critical Review of Centrality Measures in Social Networks. Business & Information Systems Engineering, 2:371–385. [23] Leiba, B. (2017). Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. Request for Comments: 8174, Internet Engineering Task Force (IETF), available online in March 2026: https://datatracker.ietf.org/doc/html/rfc8174.

6.3. Closing Remarks With respect to RFCs and the IETF in general, the observation about protocol-centered security topics is a positive finding in a sense that repetition and duplication are seldom needed. After all, on one hand, there already exists a RFC for a glossary of security terminology [41]. On the other hand, it could also be argued that a survey RFC could be drafted for summarizing the distinct protocolspecific security issues and presenting the big picture. Another idea would be to contemplate whether the “pluginstyle” standardization strategy used with some RFCs [35] might fit also into the security context. Given what was said in the preceding Subsection 6.2, better and more robust meta-data could also be hoped for. This point is familiar also from other tangentially related contexts [36]. Many security standards have been seen as ambiguous [9, 29]. The same criticism applies also to RFCs whose sometimes ambiguous requirements have been seen as a source of security issues of various kinds [46]. As was discussed in the previous Subsection 2, it may be possible to fix ambiguity issues later on, but even then, the fixes, patches, and extensions should be unambiguous even in case the original RFCs were not. Further qualitative research is required for deducing whether and how ambiguous the security considerations expressed really are. Such line of research would align well with another topic worth investigating, the IETF’s standardization philosophy. The 1990s architectural principles for the Internet, as specified in RFC 1958 [10], emphasized the so-called “principle of good enough” that has been adopted also for software engineering [4]. For instance, it was written that in “many cases it is better to adopt an almost complete solution now, rather than to wait until a perfect solution can be found” [10]. The security “mechanism described herein is not perfect and does not need to be perfect”, as one RFC noted [6]. With these quotations in mind, further research is needed about the fundamental question; about whether the sections for security considerations have actually helped at improving security of the Internet. References [1] Abbasi, A. and Altmann, J. (2011). On the Correlation Between Research Performance and Social Network Analysis Measures Applied to Research Collaboration Networks. In Proceedings of the 44th Hawaii International Conference on System Sciences, pages 1–10, Kauai. IEEE. [2] Alsulami, M. M. (2026). A Topic-Aware Evaluation of ChatGPT’s Semantic Alignment With Community Answers Using BERTScore and BERTopic. PeerJ Computer Science, 12:e3446. [3] Arkko, J. and Haverinen, H. (2006). Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA). Request for Comments: 4187, Internet

9

[24] Levä, T. and Suomi, H. (2013). Techno-Economic Feasibility Analysis of Internet Protocols: Framework and Tools. Computer Standards & Interfaces, 36:76–88. [25] Lin, J.-W., Lin, Y.-T., and Leu, F.-Y. (2023). Case Study in Generating RFC Maps of IETF Standards. In Proceedings of the 18th International Conference on Advances on Broad-Band and Wireless Computing, Communication and Applications (BWCCA 2023), pages 228–237, Daegu. Springer. [26] McQuistin, S., Karan, M., Khare, P., Perkins, C., Tyson, G., Purver, M., Healey, P., Iqbal, W., Qadir, J., and Castro, I. (2021). Characterising the IETF Through the Lens of RFC Deployment. In Proceedings of the 21st ACM Internet Measurement Conference (IMC 2021), pages 137–149. ACM. [27] Miranda, E. (2011). Time Boxing Planning: Buffered Moscow Rules. ACM SIGSOFT Software Engineering Notes, 36(6):1–5. [28] Morabito, R. and Jimenez, J. (2020). IETF Protocol Suite for the Internet of Things: Overview and Recent Advancements. IEEE Communications Standards Magazine, 4(2):41–49. [29] Moyón, F., Méndez, D., Beckers, K., and Klepper, S. (2021). Using Process Models to Understand Security Standards. In Proceedings of the 47th International Conference on Current Trends in Theory and Practice of Computer Science (SOFSEM 2021), pages 458–471, Bolzano-Bozen. Springer. [30] NLTK (2025). The Natural Language Toolkit (NLTK). Version 3.9.2. Available online in June 2026: http://www.nltk.org. [31] Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. Request for Comments: 8446, Internet Engineering Task Force (IETF), available online in March 2026: https://datatracker.ietf.org/doc/html/rfc8446. [32] Rescorla, E. and Korver, B. (1993). Guidelines for Writing RFC Text on Security Considerations. Request for Comments: 3552, Internet Engineering Task Force (IETF), available online in March 2026: https://datatracker.ietf.org/doc/html/rfc3552. [33] Rijcken, E., Kaymak, U., Scheepers, F., Zervanou, P. M. K., and Spruitw, M. (2022). Topic Modeling for Interpretable Text Classification From EHRs. Frontiers in Big Data, 5:1–11. [34] Ruohonen, J. (2025). SoK: The Design Paradigm of Safe and Secure Defaults. Journal of Information Security and Applications, 90:103989. [35] Ruohonen, J. (2026a). A Tale of the “Well-Known Standard”. Computer, 59(8):91–93. [36] Ruohonen, J. (2026b). Has Complexity of EU Law Increased? Computer Law & Security Review, 62:1–9. [37] Ruohonen, J. and Ramadan, Q. (2025). The Popularity Hypothesis in Software Security: A Large-Scale Replication with PHP Packages. Archived manuscript, available online in March 2026:

https://doi.org/10.48550/arXiv.2502.16670. [38] Ruohonen, J., Sierszecki, K., and Tiwari, A. (2026). A Measurement Study on the Adoption of Pledges and Unveils in the OpenBSD Operating System. In Proceedings of the IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER 2026), pages 1–6, Limassol. IEEE. [39] Schmid, G. (2021). Thirty Years of DNS Insecurity: Current Issues and Perspectives. IEEE Communications Surveys & Tutorials, 23(4):2429–2459. [40] Shao, C., Cui, P., Xun, P., Peng, Y., and Jiang, X. (2018). Rank Correlation Between Centrality Metrics in Complex Networks: An Empirical Study. Open Physics, 16(1):1009–1023. [41] Shirey, R. W. (2000). Internet Security Glossary. Request for Comments: 2828, Internet Engineering Track Force (IETF), available online in June 2026: https://datatracker.ietf.org/doc/ html/rfc2828. [42] Thaler, D. and Aboba, B. (2008). What Makes for a Successful Protocol? Request for Comments: 5218, Internet Engineering Task Force (IETF), available online in March 2026: https://datatracker.ietf.org/doc/html/rfc5218. [43] Waitzman, D. (1993). Instructions to RFC Authors. Request for Comments: 1543, Internet Engineering Task Force (IETF), available online in March 2026: https://datatracker.ietf.org/ doc/html/rfc1543. [44] Welzl, M., Oepen, S., Jaskula, C., Griwodz, C., and Islam, S. (2021). Collaboration in the IETF: An Initial Analysis of Two Decades in Email Discussions. ACM SIGCOMM Computer Communication Review, 51(3):29–32. [45] Welzl, M., Ott, J., Perkins, C., Islam, S., and Kutscher, D. (2023). How not to IETF: Lessons Learned From Failed Standardization Attempts. In Proceedings of the IEEE International Conference on Pervasive Computing and Communications Workshops and other Affiliated Events (PerCom Workshops 2023), pages 427–432, Atlanta. IEEE. [46] White, R. (2021). The Insecurity of Ambiguous Standards. CircleID, available online in March 2026: https://circleid.com/ posts/20210330-the-insecurity-of-ambiguous-standards/. [47] Yajima, M., Chiba, D., Yoneya, Y., and Mori, T. (2021). Measuring Adoption of DNS Security Mechanisms with CrossSectional Approach. In Proceedings of the IEEE Global Communications Conference (GLOBECOM), pages 1–6, Madrid. IEEE. [48] Zhao, W., Chen, J. J., Perkins, R., Liu, Z., Ge, W., Ding, Y., and Zou, W. (2015). A Heuristic Approach to Determine an Appropriate Number of Topics in Topic Modeling. BMC Bioinformatics, 16(Suppl 1):1–10.

10

Related documents

• A Survey of the Interaction between Security Protocols and Transport Services#399419
• Security of public machines in a library (Information Services & Security)#68842
• Security Mechanisms for the Internet#445775
• Cryptographic Protection of TCP Streams (tcpcrypt)#262433
• Securely Available Credentials Protocol#141959