idnits 2.17.00 (12 Aug 2021)
/tmp/idnits24122/draft-irtf-pearg-numeric-ids-history-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document date (27 January 2022) is 107 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460)
** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200)
** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941)
** Obsolete normative reference: RFC 2073 (Obsoleted by RFC 2374)
** Obsolete normative reference: RFC 2374 (Obsoleted by RFC 3587)
** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373)
** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981)
** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513)
** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323)
-- Obsolete informational reference (is this intentional?): RFC 5157
(Obsoleted by RFC 7707)
== Outdated reference: draft-ietf-6man-rfc4941bis has been published as RFC
8981
== Outdated reference: draft-ietf-opsec-ipv6-host-scanning has been
published as RFC 7707
== Outdated reference: draft-ietf-6man-stable-privacy-addresses has been
published as RFC 7217
== Outdated reference: draft-ietf-6man-ipv6-address-generation-privacy has
been published as RFC 7721
== Outdated reference: draft-ietf-6man-default-iids has been published as
RFC 8064
== Outdated reference: A later version (-07) exists of
draft-gont-numeric-ids-sec-considerations-06
== Outdated reference: A later version (-08) exists of
draft-irtf-pearg-numeric-ids-generation-07
== Outdated reference: draft-ietf-6man-rfc2460bis has been published as RFC
8200
-- Duplicate reference: draft-ietf-ntp-refid-updates, mentioned in
'I-D.ietf-ntp-refid-updates', was also mentioned in 'Gont-NTP'.
-- Obsolete informational reference (is this intentional?): RFC 1948
(Obsoleted by RFC 6528)
== Outdated reference: A later version (-05) exists of
draft-eddy-rfc793bis-04
-- Duplicate reference: RFC1948, mentioned in 'OpenBSD-TCP-ISN-H', was also
mentioned in 'RFC1948'.
-- Obsolete informational reference (is this intentional?): RFC 1948 (ref.
'OpenBSD-TCP-ISN-H') (Obsoleted by RFC 6528)
== Outdated reference: draft-ietf-ntp-port-randomization has been published
as RFC 9109
== Outdated reference: draft-ietf-6man-predictable-fragment-id has been
published as RFC 7739
Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Research Task Force (IRTF) F. Gont
3 Internet-Draft EdgeUno
4 Intended status: Informational I. Arce
5 Expires: 31 July 2022 Quarkslab
6 27 January 2022
8 Unfortunate History of Transient Numeric Identifiers
9 draft-irtf-pearg-numeric-ids-history-09
11 Abstract
13 This document analyzes the timeline of the specification and
14 implementation of different types of "transient numeric identifiers"
15 used in IETF protocols, and how the security and privacy properties
16 of such protocols have been affected as a result of it. It provides
17 empirical evidence that advice in this area is warranted. This
18 document is a product of the Privacy Enhancement and Assessment
19 Research Group (PEARG) in the IRTF.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at https://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on 31 July 2022.
38 Copyright Notice
40 Copyright (c) 2022 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents (https://trustee.ietf.org/
45 license-info) in effect on the date of publication of this document.
46 Please review these documents carefully, as they describe your rights
47 and restrictions with respect to this document.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
53 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4
54 4. Issues with the Specification of Transient Numeric
55 Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5
56 4.1. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . 6
57 4.2. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . 10
58 4.3. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . 12
59 4.4. NTP Reference IDs (REFIDs) . . . . . . . . . . . . . . . 15
60 4.5. Transport Protocol Ephemeral Port Numbers . . . . . . . . 15
61 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
66 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
67 9.2. Informative References . . . . . . . . . . . . . . . . . 21
68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
70 1. Introduction
72 Networking protocols employ a variety of transient numeric
73 identifiers for different protocol objects, such as IPv4 and IPv6
74 Fragment Identifiers [RFC0791] [RFC8200], IPv6 Interface Identifiers
75 (IIDs) [RFC4291], transport protocol ephemeral port numbers
76 [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC0793], and DNS
77 Transaction IDs (TxIDs) [RFC1035]. These identifiers typically have
78 specific interoperability requirements (e.g. uniqueness during a
79 specified period of time), and associated failure severities when
80 such requirements are not met
81 [I-D.irtf-pearg-numeric-ids-generation].
83 For more than 30 years, a large number of implementations of the TCP/
84 IP protocol suite have been subject to a variety of attacks, with
85 effects ranging from Denial of Service (DoS) or data injection, to
86 information leakages that could be exploited for pervasive monitoring
87 [RFC7258]. The root cause of these issues has been, in many cases,
88 poor selection of transient numeric identifiers, usually as a result
89 of insufficient or misleading specifications.
91 For example, implementations have been subject to security or privacy
92 issues resulting from:
94 * Predictable IPv4 or IPv6 Fragment Identifiers (see e.g.
95 [Sanfilippo1998a], [RFC6274], and [RFC7739])
97 * Predictable IPv6 IIDs (see e.g. [RFC7721], [RFC7707], and
98 [RFC7217])
100 * Predictable transport protocol ephemeral port numbers (see e.g.
101 [RFC6056] and [Silbersack2005])
103 * Predictable TCP Initial Sequence Numbers (ISNs) (see e.g.
104 [Morris1985], [Bellovin1989], and [RFC6528])
106 * Predictable DNS TxIDs (see e.g. [Arce1997] and [Klein2007])
108 These examples indicate that when new protocols are standardized or
109 implemented, the security and privacy properties of the associated
110 transient numeric identifiers tend to be overlooked, and
111 inappropriate algorithms to generate such identifiers (i.e. that
112 negatively affect the security or privacy properties of the protocol)
113 are either suggested in the specification or selected by
114 implementers.
116 This document contains a non-exhaustive timeline of the specification
117 and vulnerability disclosures related to some sample transient
118 numeric identifiers, including other work that has led to advances in
119 this area. This analysis indicates that:
121 * Vulnerabilities associated with the inappropriate generation of
122 transient numeric identifiers have affected protocol
123 implementations for an extremely long period of time.
125 * Such vulnerabilities, even when addressed for a given protocol
126 version, were later reintroduced in new versions or new
127 implementations of the same protocol.
129 * Standardization efforts that discuss and provide advice in this
130 area can have a positive effect on protocol specifications and
131 protocol implementations.
133 While it is generally possible to identify an algorithm that can
134 satisfy the interoperability requirements for a given transient
135 numeric identifier, this document provides empirical evidence that
136 doing so without negatively affecting the security or privacy
137 properties of the aforementioned protocols is non-trivial. Other
138 related documents ([I-D.irtf-pearg-numeric-ids-generation] and
139 [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this
140 area, as motivated by the present document.
142 This document represents the consensus of the Privacy Enhancement and
143 Assessment Research Group (PEARG).
145 2. Terminology
147 Transient Numeric Identifier:
148 A data object in a protocol specification that can be used to
149 definitely distinguish a protocol object (a datagram, network
150 interface, transport protocol endpoint, session, etc) from all
151 other objects of the same type, in a given context. Transient
152 numeric identifiers are usually defined as a series of bits, and
153 represented using integer values. These identifiers are typically
154 dynamically selected, as opposed to statically-assigned numeric
155 identifiers (see e.g. [IANA-PROT]). We note that different
156 identifiers may have additional requirements or properties
157 depending on their specific use in a protocol. We use the term
158 "transient numeric identifier" (or simply "numeric identifier" or
159 "identifier" as short forms) as a generic term to refer to any
160 data object in a protocol specification that satisfies the
161 identification property stated above.
163 The terms "constant IID", "stable IID", and "temporary IID" are to be
164 interpreted as defined in [RFC7721].
166 3. Threat Model
168 Throughout this document, we assume an attacker does not have
169 physical or logical access to the system(s) being attacked, and that
170 the attacker can only observe traffic explicitly directed to the
171 attacker. For example, an attacker cannot observe traffic
172 transferred between a sender and the receiver(s) of a target
173 protocol, but may be able to interact with any of these entities,
174 including by e.g. sending any traffic to them to sample transient
175 numeric identifiers employed by the target systems when communicating
176 with the attacker.
178 For example, when analyzing vulnerabilities associated with TCP
179 Initial Sequence Numbers (ISNs), we consider the attacker is unable
180 to capture network traffic corresponding to a TCP connection between
181 two other hosts. However, we consider the attacker is able to
182 communicate with any of these hosts (e.g., establish a TCP connection
183 with any of them), to e.g. sample the TCP ISNs employed by these
184 systems when communicating with the attacker.
186 Similarly, when considering host-tracking attacks based on IPv6
187 interface identifiers, we consider an attacker may learn the IPv6
188 address employed by a victim node if e.g. the address becomes exposed
189 as a result of the victim node communicating with an attacker-
190 operated server. Subsequently, an attacker may perform host-tracking
191 by probing a set of target addresses composed by a set of target
192 prefixes and the IPv6 interface identifier originally learned by the
193 attacker. Alternatively, an attacker may perform host tracking if
194 e.g. the victim node communicates with an attacker-operated server as
195 it moves from one location to another, those exposing its configured
196 addresses. We note that none of these scenarios requires the
197 attacker observe traffic not explicitly directed to the attacker.
199 4. Issues with the Specification of Transient Numeric Identifiers
201 While assessing protocol specifications regarding the use of
202 transient numeric identifiers, we have found that most of the issues
203 discussed in this document arise as a result of one of the following
204 conditions:
206 * Protocol specifications that under-specify the requirements for
207 their transient numeric identifiers
209 * Protocol specifications that over-specify their transient numeric
210 identifiers
212 * Protocol implementations that simply fail to comply with the
213 specified requirements
215 A number of protocol specifications have simply overlooked the
216 security and privacy implications of transient numeric identifiers.
217 Examples of them are the specification of TCP ephemeral ports in
218 [RFC0793], the specification of TCP sequence numbers in [RFC0793], or
219 the specification of the DNS TxID in [RFC1035].
221 On the other hand, there are a number of protocol specifications that
222 over-specify some of their associated transient numeric identifiers.
223 For example, [RFC4291] essentially overloads the semantics of IPv6
224 Interface Identifiers (IIDs) by embedding link-layer addresses in the
225 IPv6 IIDs, when the interoperability requirement of uniqueness could
226 be achieved in other ways that do not result in negative security and
227 privacy implications [RFC7721]. Similarly, [RFC2460] suggested the
228 use of a global counter for the generation of Fragment Identification
229 values, when the interoperability properties of uniqueness per {Src
230 IP, Dst IP} could be achieved with other algorithms that do not
231 result in negative security and privacy implications [RFC7739].
233 Finally, there are protocol implementations that simply fail to
234 comply with existing protocol specifications. For example, some
235 popular operating systems (notably Microsoft Windows) still fail to
236 implement transport protocol ephemeral port randomization, as
237 recommended in [RFC6056].
239 The following subsections document the timelines for a number of
240 sample transient numeric identifiers, that illustrate how the problem
241 discussed in this document has affected protocols from different
242 layers over time. These sample transient numeric identifiers have
243 different interoperability requirements and failure severities (see
244 Section 6 of [I-D.irtf-pearg-numeric-ids-generation]), and thus are
245 considered to be representative of the problem being analyzed in this
246 document.
248 4.1. IPv4/IPv6 Identification
250 This section presents the timeline of the Identification field
251 employed by IPv4 (in the base header) and IPv6 (in Fragment Headers).
252 The reason for presenting both cases in the same section is to make
253 it evident that while the Identification value serves the same
254 purpose in both IPv4 and IPv6, the work and research done for the
255 IPv4 case did not affect IPv6 specifications or implementations.
257 The IPv4 Identification is specified in [RFC0791], which specifies
258 the interoperability requirements for the Identification field: the
259 sender must choose the Identification field to be unique for a given
260 source address, destination address, and protocol, for the time the
261 datagram (or any fragment of it) could be alive in the internet. It
262 suggests that a node may keep "a table of Identifiers, one entry for
263 each destination it has communicated with in the last maximum packet
264 lifetime for the internet", and suggests that "since the Identifier
265 field allows 65,536 different values, hosts may be able to simply use
266 unique identifiers independent of destination". The above has been
267 interpreted numerous times as a suggestion to employ per-destination
268 or global counters for the generation of Identification values.
269 While [RFC0791] does not suggest any flawed algorithm for the
270 generation of Identification values, the specification omits a
271 discussion of the security and privacy implications of predictable
272 Identification values. This has resulted in many IPv4
273 implementations generating predictable fragment Identification values
274 by means of a global counter, at least at some point in time.
276 The IPv6 Identification was originally specified in [RFC1883]. It
277 serves the same purpose as its IPv4 counterpart, with the only
278 difference residing in the length of the corresponding field, and
279 that while the IPv4 Identification field is part of the base IPv4
280 header, in the IPv6 case it is part of the Fragment header (which may
281 or may not be present in an IPv6 packet). [RFC1883] states, in
282 Section 4.5, that the Identification must be different than that of
283 any other fragmented packet sent recently (within the maximum likely
284 lifetime of a packet) with the same Source Address and Destination
285 Address. Subsequently, it notes that this requirement can be met by
286 means of a wrap-around 32-bit counter that is incremented each time a
287 packet must be fragmented, and that it is an implementation choice
288 whether to use a global or a per-destination counter. Thus, the
289 implementation of the IPv6 Identification is similar to that of the
290 IPv4 case, with the only difference that in the IPv6 case the
291 suggestions to use simple counters is more explicit. [RFC2460] was
292 the first revision of the core IPv6 specification, and maintained the
293 same text for the specification of the IPv6 Identification field.
294 [RFC8200], the second revision of the core IPv6 specification,
295 removes the suggestion from [RFC2460] to use a counter for the
296 generation of IPv6 Identification values, and points to [RFC7739] for
297 sample algorithms for their generation.
299 September 1981:
300 [RFC0791] specifies the interoperability requirements for IPv4
301 Identification value, but does not perform a vulnerability
302 assessment of this transient numeric identifier.
304 December 1995:
305 [RFC1883], the first specification of the IPv6 protocol, is
306 published. It suggests that a counter be used to generate the
307 IPv6 Identification value, and notes that it is an implementation
308 choice whether to maintain a single counter for the node or
309 multiple counters, e.g., one for each of the node's possible
310 source addresses, or one for each active (source address,
311 destination address) combination.
313 December 1998:
314 [Sanfilippo1998a] finds that predictable IPv4 Identification
315 values (generated by most popular implementations) can be
316 leveraged to count the number of packets sent by a target node.
317 [Sanfilippo1998b] explains how to leverage the same vulnerability
318 to implement a port-scanning technique known as dumb/idle scan. A
319 tool that implements this attack is publicly released.
321 December 1998:
322 [RFC2460], a revision of the IPv6 specification, is published,
323 obsoleting [RFC1883]. It maintains the same specification of the
324 IPv6 Identification field as its predecessor ([RFC1883]).
326 December 1998:
327 OpenBSD implements randomization of the IPv4 Identification field
328 [OpenBSD-IPv4-ID].
330 November 1999:
331 [Sanfilippo1999] discusses how to leverage predictable IPv4
332 Identification to uncover the rules of a number of firewalls.
334 November 1999:
335 [Bellovin2002] explains how the IPv4 Identification field can be
336 exploited to count the number of systems behind a NAT.
338 September 2002:
339 [Fyodor2002] explains how to implement a stealth port-scanning
340 technique by leveraging nodes that employ predictable IPv4
341 Identification values.
343 October 2003:
344 OpenBSD implements randomization of the IPv6 Identification field
345 [OpenBSD-IPv6-ID].
347 December 2003:
348 [Zalewski2003] explains a technique to perform TCP data injection
349 attack based on predictable IPv4 identification values which
350 requires less effort than TCP injection attacks performed with
351 bare TCP packets.
353 November 2005:
354 [Silbersack2005] discusses shortcoming in a number of techniques
355 to mitigate predictable IPv4 Identification values.
357 October 2007:
358 [Klein2007] describes a weakness in the pseudo random number
359 generator (PRNG) in use for the generation of the IP
360 Identification by a number of operating systems.
362 June 2011:
363 [Gont2011] describes how to perform idle scan attacks in IPv6.
365 November 2011:
366 Linux mitigates predictable IPv6 Identification values
367 [RedHat2011] [SUSE2011] [Ubuntu2011].
369 December 2011:
370 [draft-gont-6man-predictable-fragment-id-00] describes the
371 security implications of predictable IPv6 Identification values,
372 and possible mitigations. This document has the Intended Status
373 of "Standards Track", with the intention to formally update
374 [RFC2460], to introduce security and privacy requirements on IPv6
375 Identification values.
377 May 2012:
378 [Gont2012] notes that some major IPv6 implementations still employ
379 predictable IPv6 Identification values.
381 March 2013:
382 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but
383 changes the track to "BCP" (while still formally updating
384 [RFC2460]), publishing the resulting document as
385 [draft-ietf-6man-predictable-fragment-id-00].
387 June 2013:
388 A patch that implements IPv6-based idle-scan in nmap is submitted
389 [Morbitzer2013].
391 December 2014:
392 The 6man WG changes the Intended Status of
393 [draft-ietf-6man-predictable-fragment-id-01] to "Informational"
394 and publishes it as [draft-ietf-6man-predictable-fragment-id-02].
395 As a result, it no longer formally updates [RFC2460].
397 June 2015:
398 [draft-ietf-6man-predictable-fragment-id-08] notes that some
399 popular host and router implementations still employ predictable
400 IPv6 Identification values.
402 February 2016:
403 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id])
404 analyzes the security and privacy implications of predictable IPv6
405 Identification values, and provides guidance for selecting an
406 algorithm to generate such values. However, being published with
407 the Intended Status of "Informational", it does not formally
408 update [RFC2460].
410 June 2016:
411 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the
412 suggestion from RFC2460 to use a counter for the generation of
413 IPv6 Identification values, but does not perform a vulnerability
414 assessment of the generation of IPv6 Identification values.
416 July 2017:
417 [I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200],
418 obsoleting [RFC2460], and pointing to [RFC7739] for sample
419 algorithms for the generation of IPv6 Fragment Identification
420 values.
422 June 2019:
423 [IPID-DEV] notes that the IPv6 ID generators of two popular
424 operating systems are flawed.
426 4.2. TCP Initial Sequence Numbers (ISNs)
428 [RFC0793] suggests that the choice of the ISN of a connection is not
429 arbitrary, but aims to reduce the chances of a stale segment from
430 being accepted by a new incarnation of a previous connection.
431 [RFC0793] suggests the use of a global 32-bit ISN generator that is
432 incremented by 1 roughly every 4 microseconds. However, as a matter
433 of fact, protection against stale segments from a previous
434 incarnation of the connection is enforced by preventing the creation
435 of a new incarnation of a previous connection before 2*MSL have
436 passed since a segment corresponding to the old incarnation was last
437 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This
438 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept
439 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are
440 monotonically increasing across connections, many stacks (e.g.,
441 4.2BSD-derived) use the ISN of an incoming SYN segment to perform
442 "heuristics" that enable the creation of a new incarnation of a
443 connection while the previous incarnation is still in the TIME-WAIT
444 state (see p. 945 of [Wright1994]). This avoids an interoperability
445 problem that may arise when a node establishes connections to a
446 specific TCP end-point at a high rate [Silbersack2005].
448 The interoperability requirements for TCP ISNs are probably not as
449 clearly spelled out as one would expect. Furthermore, the suggestion
450 of employing a global counter in [RFC0793] negatively affects the
451 security and privacy properties of the protocol.
453 September 1981:
454 [RFC0793], suggests the use of a global 32-bit ISN generator,
455 whose lower bit is incremented roughly every 4 microseconds.
456 However, such an ISN generator makes it trivial to predict the ISN
457 that a TCP instance will use for new connections, thus allowing a
458 variety of attacks against TCP.
460 February 1985:
461 [Morris1985] was the first to describe how to exploit predictable
462 TCP ISNs for forging TCP connections that could then be leveraged
463 for trust relationship exploitation.
465 April 1989:
466 [Bellovin1989] discussed the security considerations for
467 predictable ISNs (along with a range of other protocol-based
468 vulnerabilities).
470 February 1995:
471 [Shimomura1995] reported a real-world exploitation of the attack
472 described in 1985 (ten years before) in [Morris1985].
474 May 1996:
475 [RFC1948] was the first IETF effort, authored by Steven Bellovin,
476 to address predictable TCP ISNs. The same concept specified in
477 this document for TCP ISNs was later proposed for TCP ephemeral
478 ports [RFC6056], TCP Timestamps, and eventually even IPv6
479 Interface Identifiers [RFC7217].
481 July 1996:
482 OpenBSD implements TCP ISN randomization based on random
483 increments (please see Appendix A.2 of
484 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-I].
486 December 2000:
487 OpenBSD implements TCP ISN randomization using simple
488 randomization (please see Section 7.1 of
489 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-R].
491 March 2001:
492 [Zalewski2001] provides a detailed analysis of statistical
493 weaknesses in some ISN generators, and includes a survey of the
494 algorithms in use by popular TCP implementations.
496 May 2001:
497 Vulnerability advisories [CERT2001] [USCERT2001] are released
498 regarding statistical weaknesses in some ISN generators, affecting
499 popular TCP/IP implementations.
501 March 2002:
502 [Zalewski2002] updates and complements [Zalewski2001]. It
503 concludes that "while some vendors [...] reacted promptly and
504 tested their solutions properly, many still either ignored the
505 issue and never evaluated their implementations, or implemented a
506 flawed solution that apparently was not tested using a known
507 approach" [Zalewski2002].
509 June 2007:
510 OpenBSD implements TCP ISN randomization based on the algorithm
511 specified in [RFC1948] (currently obsoleted by [RFC6528]) for the
512 TCP endpoint that performs the active open, while keeping the
513 simple randomization scheme for the endpoint performing the
514 passive open [OpenBSD-TCP-ISN-H]. This provides monotonically-
515 increasing ISNs for the client side (allowing the BSD heuristics
516 to work as expected), while avoiding any patterns in the ISN
517 generation for the server side.
519 February 2012:
520 [RFC6528], published 27 years after Morris' original work
521 [Morris1985], formally updates [RFC0793] to mitigate predictable
522 TCP ISNs.
524 August 2014:
525 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP
526 protocol specification, incorporates the algorithm specified in
527 [RFC6528] as the recommended algorithm for TCP ISN generation.
529 4.3. IPv6 Interface Identifiers (IIDs)
531 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC
532 [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section
533 focuses on Interface Identifiers resulting from SLAAC.
535 The Interface Identifier of stable (traditional) IPv6 addresses
536 resulting from SLAAC have traditionally resulted in the underlying
537 link-layer address being embedded in the IID.At the time, employing
538 the underlying link-layer address for the IID was seen as a
539 convenient way to obtain a unique address. However, recent awareness
540 about the security and privacy properties of this approach [RFC7707]
541 [RFC7721] has led to the replacement of this flawed scheme with an
542 alternative one [RFC7217] [RFC8064] that does not negatively affect
543 the security and privacy properties of the protocol.
545 January 1997:
546 [RFC2073] specifies the syntax of IPv6 global addresses (referred
547 to as "An IPv6 Provider-Based Unicast Address Format" at the
548 time), consistent with the IPv6 addressing architecture specified
549 in [RFC1884]. Hosts are recommended to "generate addresses using
550 link-specific addresses as Interface ID such as 48 bit IEEE-802
551 MAC addresses".
553 July 1998:
554 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address
555 Format" (obsoleting [RFC2373]) changing the size of the Interface
556 ID to 64 bits, and specifies that that IIDs must be constructed in
557 IEEE EUI-64 format. How such identifiers are constructed becomes
558 specified in the appropriate "IPv6 over " specification such
559 as "IPv6 over Ethernet".
561 January 2001:
562 [RFC3041] recognizes the problem of network activity correlation,
563 and specifies temporary addresses. Temporary addresses are to be
564 used along with stable addresses.
566 August 2003:
567 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure
568 historic. The syntax and recommendations for the traditional
569 stable IIDs remain unchanged, though.
571 February 2006:
572 [RFC4291] is published as the latest "IP Version 6 Addressing
573 Architecture", requiring the IIDs of the traditional (stable)
574 autoconfigured addresses to employ the Modified EUI-64 format.
575 The details of constructing such interface identifiers are defined
576 in the appropriate "IPv6 over " specifications.
578 March 2008:
579 [RFC5157] provides hints regarding how patterns in IPv6 addresses
580 could be leveraged for the purpose of address scanning.
582 December 2011:
583 [draft-gont-6man-stable-privacy-addresses-00] notes that the
584 traditional scheme for generating stable addresses allows for
585 address scanning, and also does not prevent active node tracking.
586 It also specifies an alternative algorithm meant to replace IIDs
587 based on Modified EUI-64 format identifiers.
589 November 2012:
590 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a
591 working group item (as
592 [draft-ietf-6man-stable-privacy-addresses-00]). However, the
593 document no longer formally updates [RFC4291], and therefore the
594 specified algorithm no longer formally replaces the Modified
595 EUI-64 format identifiers.
597 February 2013:
598 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages
599 IPv6 address patterns is released [Gont2013].
601 July 2013:
602 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on
603 the security and privacy properties of all known algorithms for
604 generating IPv6 IIDs.
606 January 2014:
607 The 6man WG publishes [draft-ietf-6man-default-iids-00]
608 ("Recommendation on Stable IPv6 Interface Identifiers"),
609 recommending [I-D.ietf-6man-stable-privacy-addresses] for the
610 generation of stable addresses.
612 April 2014:
613 [RFC7217] (formerly [I-D.ietf-6man-stable-privacy-addresses]) is
614 published, specifying "A Method for Generating Semantically Opaque
615 Interface Identifiers with IPv6 Stateless Address
616 Autoconfiguration (SLAAC)" as an alternative to (but *not*
617 replacement of) Modified EUI-64 format IIDs.
619 March 2016:
620 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning], and later
621 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network
622 Reconnaissance in IPv6 Networks", is published.
624 March 2016:
625 [RFC7721] (formerly
626 [I-D.cooper-6man-ipv6-address-generation-privacy] and later
627 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security
628 and Privacy Considerations for IPv6 Address Generation
629 Mechanisms", is published.
631 May 2016:
632 [draft-gont-6man-non-stable-iids-00] is published, with the goal
633 of specifying requirements for non-stable addresses, and updating
634 [RFC4941] such that use of only temporary addresses is allowed.
636 May 2016:
637 [draft-gont-6man-address-usage-recommendations-00] is published,
638 providing an analysis of how different aspects on an address (from
639 stability to usage mode) affect their corresponding security and
640 privacy properties, and meaning to eventually provide advice in
641 this area.
643 February 2017:
644 The 6man WG publishes [RFC8064] ("Recommendation on Stable IPv6
645 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]),
646 with requirements for stable addresses and a recommendation to
647 employ [RFC7217] for the generation of stable addresses. It
648 formally updates a large number of RFCs.
650 March 2018:
651 [draft-fgont-6man-rfc4941bis-00] is published (as suggested by the
652 6man WG), to address flaws in [RFC4941] by revising it (as an
653 alternative to the [draft-gont-6man-non-stable-iids-00] effort,
654 published in March 2016).
656 July 2018:
657 [draft-fgont-6man-rfc4941bis-00] is adopted (as
658 [draft-ietf-6man-rfc4941bis-00]) as a WG item of the 6man WG.
660 December 2020:
661 [I-D.ietf-6man-rfc4941bis] is approved by the IESG for publication
662 as an RFC.
664 February 2021:
665 [I-D.ietf-6man-rfc4941bis] is finally published as [RFC8981].
667 4.4. NTP Reference IDs (REFIDs)
669 The NTP [RFC5905] Reference ID is a 32-bit code identifying the
670 particular server or reference clock. Above stratum 1 (secondary
671 servers and clients), this value can be employed to avoid degree-one
672 timing loops; that is, scenarios where two NTP peers are (mutually)
673 the time source of each other. If using the IPv4 address family, the
674 identifier is the four-octet IPv4 address. If using the IPv6 address
675 family, it is the first four octets of the MD5 hash of the IPv6
676 address.
678 June 2010:
679 [RFC5905], "Network Time Protocol Version 4: Protocol and
680 Algorithms Specification" is published. It specifies that for NTP
681 peers with stratum higher than 1 the REFID embeds the IPv4 Address
682 of the time source or an MD5 hash of the IPv6 address of the time
683 source.
685 July 2016:
686 [draft-stenn-ntp-not-you-refid-00] is published, describing the
687 information leakage produced via the NTP REFID. It proposes that
688 NTP returns a special REFID when a packet employs an IP Source
689 Address that is not believed to be a current NTP peer, but
690 otherwise generates and returns the traditional REFID. It is
691 subsequently adopted by the NTP WG as
692 [I-D.ietf-ntp-refid-updates].
694 April 2019:
695 [Gont-NTP] notes that the proposed fix specified in
696 [draft-ietf-ntp-refid-updates-00] is, at the very least, sub-
697 optimal.
699 4.5. Transport Protocol Ephemeral Port Numbers
701 Most (if not all) transport protocols employ "port numbers" to
702 demultiplex packets to the corresponding transport protocol
703 instances.
705 August 1980:
706 [RFC0768] notes that the UDP source port is optional and
707 identifies the port of the sending process. It does not specify
708 interoperability requirements for source port selection, nor does
709 it suggest possible ways to select port numbers. Most popular
710 implementations end up selecting source ports from a system-wide
711 global counter.
713 September 1981:
714 [RFC0793] (the TCP specification) essentially describes the use of
715 port numbers, and specifies that port numbers should result in a
716 unique socket pair (local address, local port, remote address,
717 remote port). How ephemeral ports (i.e. port numbers for "active
718 opens") are selected, and the port range from which they are
719 selected, are left unspecified.
721 July 1996:
722 OpenBSD implements ephemeral port randomization [OpenBSD-PR].
724 July 2008:
725 The CERT Coordination Centre published details of what became
726 known as the "Kaminsky Attack" [VU-800113] on the DNS. The attack
727 exploited the lack of source port randomization in many major DNS
728 implementations to perform cache poisoning in an effective and
729 practical manner.
731 January 2009:
732 [RFC5452] mandates the use of port randomization for DNS
733 resolvers, and mandates that implementations must randomize ports
734 from the range (53 or 1024, and above) or the largest possible
735 port range. It does not recommend possible algorithms for port
736 randomization, although the document specifically targets DNS
737 resolvers, for which a simple port randomization suffices (e.g.
738 Algorithm 1 of [RFC6056]). This document led to the
739 implementation of port randomization in the DNS resolver
740 themselves, rather than in the underlying transport-protocols.
742 January 2011:
743 [RFC6056] notes that many TCP and UDP implementations result in
744 predictable port numbers, and also notes that many implementations
745 select port numbers from a small portion of the whole port number
746 space. It recommends the implementation and use of ephemeral port
747 randomization, proposes a number of possible algorithms for port
748 randomization, and also recommends to randomize port numbers over
749 the range 1024-65535.
751 March 2016:
752 [NIST-NTP] reports a non-normal distribution of the ephemeral port
753 numbers employed by the NTP clients of an Internet Time Service.
755 April 2019:
756 [I-D.gont-ntp-port-randomization] notes that some NTP
757 implementations employ the NTP service port (123) as the local
758 port for non-symmetric modes, and aims to update the NTP
759 specification to recommend port randomization in such cases, in
760 line with [RFC6056]. The proposal experiences some push-back in
761 the relevant working group (NTP WG) [NTP-PORTR], but is finally
762 adopted as a working group item as
763 [I-D.ietf-ntp-port-randomization].
765 August 2021:
766 [I-D.ietf-ntp-port-randomization] is finally published as
767 [RFC9109].
769 5. Conclusions
771 For more than 30 years, a large number of implementations of the TCP/
772 IP protocol suite have been subject to a variety of attacks, with
773 effects ranging from Denial of Service (DoS) or data injection, to
774 information leakages that could be exploited for pervasive monitoring
775 [RFC7258]. The root cause of these issues has been, in many cases,
776 poor selection of transient numeric identifiers, usually as a result
777 of insufficient or misleading specifications.
779 While it is generally possible to identify an algorithm that can
780 satisfy the interoperability requirements for a given transient
781 numeric identifier, this document provides empirical evidence that
782 doing so without negatively affecting the security or privacy
783 properties of the aforementioned protocols is non-trivial. It is
784 thus evident that advice in this area is warranted.
786 [I-D.gont-numeric-ids-sec-considerations] aims at requiring future
787 protocol specifications to contain analysis of the security and
788 privacy properties of any transient numeric identifiers specified by
789 the protocol, and to recommend an algorithm for the generation of
790 such transient numeric identifiers.
791 [I-D.irtf-pearg-numeric-ids-generation] specifies a number of sample
792 algorithms for generating transient numeric identifiers with specific
793 interorability requirements and failure severities.
795 6. IANA Considerations
797 There are no IANA registries within this document. The RFC-Editor
798 can remove this section before publication of this document as an
799 RFC.
801 7. Security Considerations
803 This document analyzes the timeline of the specification and
804 implementation of the transient numeric identifiers of some sample
805 IETF protocols, and how the security and privacy properties of such
806 protocols have been affected as a result of it. It provides concrete
807 evidence that advice in this area is warranted.
809 [I-D.gont-numeric-ids-sec-considerations] formally requires protocol
810 specifications to specify the interoperability requirements for their
811 transient numeric identifiers, to do a warranted vulnerability
812 assessment of such transient numeric identifiers, and to recommend
813 possible algorithms for their generation, such that the
814 interoperability requirements are complied with, while any negative
815 security and privacy properties of these transient numeric
816 identifiers are mitigated.
818 [I-D.irtf-pearg-numeric-ids-generation] analyzes and categorizes
819 transient numeric identifiers based on their interoperability
820 requirements and their associated failure severities, and recommends
821 possible algorithms that can comply with those requirements without
822 negatively affecting the security and privacy properties of the
823 corresponding protocols.
825 8. Acknowledgements
827 The authors would like to thank (in alphabetical order) Bernard
828 Aboba, Dave Crocker, Theo de Raadt, Sara Dickinson, Guillermo Gont,
829 Christian Huitema, Colin Perkins, Vincent Roca, Kris Shrishak, Joe
830 Touch, and Christopher Wood, for providing valuable comments on
831 earlier versions of this document.
833 The authors would like to thank (in alphabetical order) Steven
834 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for
835 providing valuable comments on [I-D.gont-predictable-numeric-ids], on
836 which this document is based.
838 Section 4.2 of this document borrows text from [RFC6528], authored by
839 Fernando Gont and Steven Bellovin.
841 The authors would like to thank Sara Dickinson and Christopher Wood,
842 for their guidance during the publication process of this document.
844 The authors would like to thank Diego Armando Maradona for his magic
845 and inspiration.
847 9. References
848 9.1. Normative References
850 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
851 DOI 10.17487/RFC0768, August 1980,
852 .
854 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
855 RFC 793, DOI 10.17487/RFC0793, September 1981,
856 .
858 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
859 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
860 2012, .
862 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
863 DOI 10.17487/RFC0791, September 1981,
864 .
866 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
867 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
868 December 1995, .
870 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
871 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
872 December 1998, .
874 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
875 (IPv6) Specification", STD 86, RFC 8200,
876 DOI 10.17487/RFC8200, July 2017,
877 .
879 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
880 Interface Identifiers with IPv6 Stateless Address
881 Autoconfiguration (SLAAC)", RFC 7217,
882 DOI 10.17487/RFC7217, April 2014,
883 .
885 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
886 Stateless Address Autoconfiguration in IPv6", RFC 3041,
887 DOI 10.17487/RFC3041, January 2001,
888 .
890 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J.
891 Postel, "An IPv6 Provider-Based Unicast Address Format",
892 RFC 2073, DOI 10.17487/RFC2073, January 1997,
893 .
895 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6
896 Aggregatable Global Unicast Address Format", RFC 2374,
897 DOI 10.17487/RFC2374, July 1998,
898 .
900 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
901 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
902 August 2003, .
904 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
905 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
906 December 1995, .
908 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
909 Architecture", RFC 4291, DOI 10.17487/RFC4291, February
910 2006, .
912 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
913 Extensions for Stateless Address Autoconfiguration in
914 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
915 .
917 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
918 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
919 .
921 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
922 Address Autoconfiguration", RFC 4862,
923 DOI 10.17487/RFC4862, September 2007,
924 .
926 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
927 Richardson, M., Jiang, S., Lemon, T., and T. Winters,
928 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
929 RFC 8415, DOI 10.17487/RFC8415, November 2018,
930 .
932 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
933 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
934 1992, .
936 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
937 Protocol Port Randomization", BCP 156, RFC 6056,
938 DOI 10.17487/RFC6056, January 2011,
939 .
941 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
942 Resilient against Forged Answers", RFC 5452,
943 DOI 10.17487/RFC5452, January 2009,
944 .
946 9.2. Informative References
948 [OpenBSD-PR]
949 OpenBSD, "Implementation of port randomization", 29 July
950 1996, .
953 [VU-800113]
954 CERT/CC, "Multiple DNS implementations vulnerable to cache
955 poisoning (Vulnerability Note VU#800113)", 8 July 2008,
956 .
958 [IANA-PROT]
959 IANA, "Protocol Registries",
960 .
962 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
963 RFC 5157, DOI 10.17487/RFC5157, March 2008,
964 .
966 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
967 "Temporary Address Extensions for Stateless Address
968 Autoconfiguration in IPv6", RFC 8981,
969 DOI 10.17487/RFC8981, February 2021,
970 .
972 [I-D.ietf-6man-rfc4941bis]
973 Gont, F., Krishnan, S., Narten, T., and R. Draves,
974 "Temporary Address Extensions for Stateless Address
975 Autoconfiguration in IPv6", Work in Progress, Internet-
976 Draft, draft-ietf-6man-rfc4941bis-12, 2 November 2020,
977 .
980 [I-D.gont-opsec-ipv6-host-scanning]
981 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
982 Networks", Work in Progress, Internet-Draft, draft-gont-
983 opsec-ipv6-host-scanning-02, 22 October 2012,
984 .
987 [I-D.ietf-opsec-ipv6-host-scanning]
988 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
989 Networks", Work in Progress, Internet-Draft, draft-ietf-
990 opsec-ipv6-host-scanning-08, 28 August 2015,
991 .
994 [I-D.gont-6man-stable-privacy-addresses]
995 Gont, F., "A method for Generating Stable Privacy-Enhanced
996 Addresses with IPv6 Stateless Address Autoconfiguration
997 (SLAAC)", Work in Progress, Internet-Draft, draft-gont-
998 6man-stable-privacy-addresses-01, 31 March 2012,
999 .
1002 [I-D.ietf-6man-stable-privacy-addresses]
1003 Gont, F., "A Method for Generating Semantically Opaque
1004 Interface Identifiers with IPv6 Stateless Address
1005 Autoconfiguration (SLAAC)", Work in Progress, Internet-
1006 Draft, draft-ietf-6man-stable-privacy-addresses-17, 27
1007 January 2014, .
1010 [I-D.cooper-6man-ipv6-address-generation-privacy]
1011 Cooper, A., Gont, F., and D. Thaler, "Privacy
1012 Considerations for IPv6 Address Generation Mechanisms",
1013 Work in Progress, Internet-Draft, draft-cooper-6man-ipv6-
1014 address-generation-privacy-00, 15 July 2013,
1015 .
1018 [I-D.ietf-6man-ipv6-address-generation-privacy]
1019 Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
1020 Considerations for IPv6 Address Generation Mechanisms",
1021 Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
1022 address-generation-privacy-08, 23 September 2015,
1023 .
1026 [Gont2013] Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit
1027 (help wanted!)", Message posted to the IPv6 Hackers
1028 mailing-list Message-ID:
1029 <51184548.3030105@si6networks.com>, 2013,
1030 .
1033 [IPv6-Toolkit]
1034 SI6 Networks, "SI6 Networks' IPv6 Toolkit",
1035 .
1037 [draft-gont-6man-stable-privacy-addresses-00]
1038 Gont, F., "A method for Generating Stable Privacy-Enhanced
1039 Addresses with IPv6 Stateless Address Autoconfiguration
1040 (SLAAC)", Work in Progress, Internet-Draft, draft-gont-
1041 6man-stable-privacy-addresses-00, 15 December 2011,
1042 .
1045 [draft-ietf-6man-stable-privacy-addresses-00]
1046 Gont, F., "A method for Generating Stable Privacy-Enhanced
1047 Addresses with IPv6 Stateless Address Autoconfiguration
1048 (SLAAC)", Work in Progress, Internet-Draft, draft-ietf-
1049 6man-stable-privacy-addresses-00, 18 May 2012,
1050 .
1053 [draft-gont-6man-address-usage-recommendations-00]
1054 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations",
1055 Work in Progress, Internet-Draft, draft-gont-6man-address-
1056 usage-recommendations-00, 27 May 2016,
1057 .
1060 [draft-gont-6man-non-stable-iids-00]
1061 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6
1062 Interface Identifiers", Work in Progress, Internet-Draft,
1063 draft-gont-6man-non-stable-iids-00, 23 May 2016,
1064 .
1067 [draft-ietf-6man-default-iids-00]
1068 Gont, F., Cooper, A., Thaler, D., and W. Liu,
1069 "Recommendation on Stable IPv6 Interface Identifiers",
1070 Work in Progress, Internet-Draft, draft-ietf-6man-default-
1071 iids-00, 28 July 2014, .
1074 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
1075 "Recommendation on Stable IPv6 Interface Identifiers",
1076 RFC 8064, DOI 10.17487/RFC8064, February 2017,
1077 .
1079 [draft-ietf-6man-rfc4941bis-00]
1080 Gont, F., Krishnan, S.K., Narten, T.N., and R.D. Draves,
1081 "Privacy Extensions for Stateless Address
1082 Autoconfiguration in IPv6", Work in Progress, Internet-
1083 Draft, draft-ietf-6man-rfc4941bis-00, 2 July 2018,
1084 .
1087 [draft-fgont-6man-rfc4941bis-00]
1088 Gont, F., Krishnan, S.K., Narten, T.N., and R.D. Draves,
1089 "Privacy Extensions for Stateless Address
1090 Autoconfiguration in IPv6", Work in Progress, Internet-
1091 Draft, draft-fgont-6man-rfc4941bis-00, 25 March 2018,
1092 .
1095 [I-D.ietf-6man-default-iids]
1096 Gont, F., Cooper, A., Thaler, D., and W. Liu,
1097 "Recommendation on Stable IPv6 Interface Identifiers",
1098 Work in Progress, Internet-Draft, draft-ietf-6man-default-
1099 iids-16, 28 September 2016,
1100 .
1103 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
1104 Considerations for IPv6 Address Generation Mechanisms",
1105 RFC 7721, DOI 10.17487/RFC7721, March 2016,
1106 .
1108 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
1109 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
1110 .
1112 [I-D.gont-predictable-numeric-ids]
1113 Gont, F. and I. Arce, "Security and Privacy Implications
1114 of Numeric Identifiers Employed in Network Protocols",
1115 Work in Progress, Internet-Draft, draft-gont-predictable-
1116 numeric-ids-03, 11 March 2019,
1117 .
1120 [I-D.gont-numeric-ids-sec-considerations]
1121 Gont, F. and I. Arce, "Security Considerations for
1122 Transient Numeric Identifiers Employed in Network
1123 Protocols", Work in Progress, Internet-Draft, draft-gont-
1124 numeric-ids-sec-considerations-06, 5 December 2020,
1125 .
1128 [I-D.irtf-pearg-numeric-ids-generation]
1129 Gont, F. and I. Arce, "On the Generation of Transient
1130 Numeric Identifiers", Work in Progress, Internet-Draft,
1131 draft-irtf-pearg-numeric-ids-generation-07, 2 February
1132 2021, .
1135 [I-D.ietf-6man-rfc2460bis]
1136 <>, S. E. D. and R. M. Hinden, "Internet Protocol, Version
1137 6 (IPv6) Specification", Work in Progress, Internet-Draft,
1138 draft-ietf-6man-rfc2460bis-13, 19 May 2017,
1139 .
1142 [draft-stenn-ntp-not-you-refid-00]
1143 Goldberg, S. and H. Stenn, "Network Time Protocol Not You
1144 REFID", Work in Progress, Internet-Draft, draft-stenn-ntp-
1145 not-you-refid-00, 8 July 2016, .
1148 [draft-ietf-ntp-refid-updates-00]
1149 Goldberg, S. and H. Stenn, "Network Time Protocol Not You
1150 REFID", Work in Progress, Internet-Draft, draft-ietf-ntp-
1151 refid-updates-00, 13 November 2016,
1152 .
1155 [Gont-NTP] Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates-
1156 05", Post to the NTP WG mailing list Message-ID:
1157 , 16
1158 April 2019, .
1161 [I-D.ietf-ntp-refid-updates]
1162 Stenn, H. and S. Goldberg, "Network Time Protocol REFID
1163 Updates", Work in Progress, Internet-Draft, draft-ietf-
1164 ntp-refid-updates-05, 25 March 2019,
1165 .
1168 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
1169 "Network Time Protocol Version 4: Protocol and Algorithms
1170 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
1171 .
1173 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
1174 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
1175 2014, .
1177 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
1178 RFC 1948, DOI 10.17487/RFC1948, May 1996,
1179 .
1181 [Wright1994]
1182 Wright, G.R. and W.R. Stevens, "TCP/IP Illustrated, Volume
1183 2: The Implementation", Addison-Wesley, 1994.
1185 [Zalewski2001]
1186 Zalewski, M., "Strange Attractors and TCP/IP Sequence
1187 Number Analysis", 2001,
1188 .
1190 [Zalewski2002]
1191 Zalewski, M., "Strange Attractors and TCP/IP Sequence
1192 Number Analysis - One Year Later", 2001,
1193 .
1195 [Bellovin1989]
1196 Bellovin, S., "Security Problems in the TCP/IP Protocol
1197 Suite", Computer Communications Review, vol. 19, no. 2,
1198 pp. 32-48, 1989,
1199 .
1201 [Morris1985]
1202 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
1203 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill,
1204 NJ, 1985,
1205 .
1207 [USCERT2001]
1208 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple
1209 TCP/IP implementations may use statistically predictable
1210 initial sequence numbers", 2001,
1211 .
1213 [CERT2001] CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in
1214 TCP/IP Initial Sequence Numbers", 2001,
1215 .
1218 [Shimomura1995]
1219 Shimomura, T., "Technical details of the attack described
1220 by Markoff in NYT", Message posted in USENET's
1221 comp.security.misc newsgroup Message-ID:
1222 <3g5gkl$5j1@ariel.sdsc.edu>, 1995,
1223 .
1225 [I-D.eddy-rfc793bis-04]
1226 Eddy, W., "Transmission Control Protocol Specification",
1227 Work in Progress, Internet-Draft, draft-eddy-rfc793bis-04,
1228 25 August 2014,
1229 .
1231 [OpenBSD-TCP-ISN-I]
1232 OpenBSD, "Implementation of TCP ISN randomization based on
1233 random increments", 29 July 1996,
1234 .
1237 [OpenBSD-TCP-ISN-R]
1238 OpenBSD, "Implementation of TCP ISN randomization based on
1239 simple randomization", 13 December 2000,
1240 .
1243 [OpenBSD-TCP-ISN-H]
1244 OpenBSD, "Implementation of RFC1948 for TCP ISN
1245 randomization", 13 December 2000,
1246 .
1249 [I-D.gont-ntp-port-randomization]
1250 Gont, F. and G. Gont, "Port Randomization in the Network
1251 Time Protocol Version 4", Work in Progress, Internet-
1252 Draft, draft-gont-ntp-port-randomization-04, 6 August
1253 2019, .
1256 [I-D.ietf-ntp-port-randomization]
1257 Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
1258 Version 4: Port Randomization", Work in Progress,
1259 Internet-Draft, draft-ietf-ntp-port-randomization-08, 10
1260 June 2021, .
1263 [RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
1264 Version 4: Port Randomization", RFC 9109,
1265 DOI 10.17487/RFC9109, August 2021,
1266 .
1268 [NTP-PORTR]
1269 Gont, F., "[Ntp] New rev of the NTP port randomization I-D
1270 (Fwd: New Version Notification for draft-gont-ntp-port-
1271 randomization-01.txt)", 2019,
1272 .
1275 [NIST-NTP] Sherman, J.A. and J. Levine, "Usage Analysis of the NIST
1276 Internet Time Service", Journal of Research of the
1277 National Institute of Standards and Technology Volume 121,
1278 8 March 2016, .
1280 [IPID-DEV] Klein, A. and B. Pinkas, "From IP ID to Device ID and
1281 KASLR Bypass (Extended Version)", June 2019,
1282 .
1284 [RFC1035] Mockapetris, P., "Domain names - implementation and
1285 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1286 November 1987, .
1288 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol
1289 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
1290 .
1292 [RFC7739] Gont, F., "Security Implications of Predictable Fragment
1293 Identification Values", RFC 7739, DOI 10.17487/RFC7739,
1294 February 2016, .
1296 [Bellovin2002]
1297 Bellovin, S. M., "A Technique for Counting NATted Hosts",
1298 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002,
1299 .
1301 [Fyodor2002]
1302 Fyodor, "Idle scanning and related IP ID games", 2002,
1303 .
1305 [Sanfilippo1998a]
1306 Sanfilippo, S., "about the ip header id", Post to Bugtraq
1307 mailing-list, Mon Dec 14 1998,
1308 .
1310 [Sanfilippo1998b]
1311 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list,
1312 1998, .
1315 [Sanfilippo1999]
1316 Sanfilippo, S., "more ip id", Post to Bugtraq mailing-
1317 list, 1999,
1318 .
1321 [Morbitzer2013]
1322 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message
1323 posted to the nmap-dev mailing-list, 2013,
1324 .
1326 [OpenBSD-IPv4-ID]
1327 OpenBSD, "Randomization of the IPv4 Identification field",
1328 26 December 1998,
1329 .
1332 [OpenBSD-IPv6-ID]
1333 OpenBSD, "Randomization of the IPv6 Identification field",
1334 1 October 2003,
1335 .
1338 [Silbersack2005]
1339 Silbersack, M.J., "Improving TCP/IP security through
1340 randomization without sacrificing interoperability",
1341 EuroBSDCon 2005 Conference, 2005,
1342 .
1345 [Zalewski2003]
1346 Zalewski, M., "A new TCP/IP blind data injection
1347 technique?", 2003,
1348 .
1350 [Arce1997] Arce, I. and E. Kargieman, "BIND Vulnerabilities and
1351 Solutions", 1997,
1352 .
1354 [Klein2007]
1355 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
1356 Predictable IP ID Vulnerability", 2007,
1357 .
1361 [Gont2011] Gont, F., "Hacking IPv6 Networks (training course)", Hack
1362 In Paris 2011 Conference Paris, France, June 2011.
1364 [RedHat2011]
1365 RedHat, "RedHat Security Advisory RHSA-2011:1465-1:
1366 Important: kernel security and bug fix update", 2011,
1367 .
1369 [Ubuntu2011]
1370 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel
1371 vulnerabilities", 2011,
1372 .
1374 [SUSE2011] SUSE, "SUSE Security Announcement: Linux kernel security
1375 update (SUSE-SA:2011:046)", 2011,
1376 .
1379 [Gont2012] Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012
1380 Conference Ottawa, Canada. May 11-12, 2012, May 2012,
1381 .
1385 [I-D.gont-6man-predictable-fragment-id]
1386 Gont, F., "Security Implications of Predictable Fragment
1387 Identification Values", Work in Progress, Internet-Draft,
1388 draft-gont-6man-predictable-fragment-id-03, 9 January
1389 2013, .
1392 [I-D.ietf-6man-predictable-fragment-id]
1393 Gont, F., "Security Implications of Predictable Fragment
1394 Identification Values", Work in Progress, Internet-Draft,
1395 draft-ietf-6man-predictable-fragment-id-10, 9 October
1396 2015, .
1399 [draft-ietf-6man-predictable-fragment-id-01]
1400 Gont, F., "Security Implications of Predictable Fragment
1401 Identification Values", Work in Progress, Internet-Draft,
1402 draft-ietf-6man-predictable-fragment-id-01, 30 April 2014,
1403 .
1406 [draft-ietf-6man-predictable-fragment-id-02]
1407 Gont, F., "Security Implications of Predictable Fragment
1408 Identification Values", Work in Progress, Internet-Draft,
1409 draft-ietf-6man-predictable-fragment-id-02, 19 December
1410 2014, .
1413 [draft-gont-6man-predictable-fragment-id-00]
1414 Gont, F., "Security Implications of Predictable Fragment
1415 Identification Values", Work in Progress, Internet-Draft,
1416 draft-gont-6man-predictable-fragment-id-00, 15 December
1417 2011, .
1420 [draft-ietf-6man-predictable-fragment-id-00]
1421 Gont, F., "Security Implications of Predictable Fragment
1422 Identification Values", Work in Progress, Internet-Draft,
1423 draft-ietf-6man-predictable-fragment-id-00, 22 March 2013,
1424 .
1427 [draft-ietf-6man-predictable-fragment-id-08]
1428 Gont, F., "Security Implications of Predictable Fragment
1429 Identification Values", Work in Progress, Internet-Draft,
1430 draft-ietf-6man-predictable-fragment-id-08, 9 June 2015,
1431 .
1434 Authors' Addresses
1436 Fernando Gont
1437 EdgeUno
1438 Segurola y Habana 4310 7mo piso
1439 Ciudad Autonoma de Buenos Aires
1440 Buenos Aires
1441 Argentina
1443 Email: fernando.gont@edgeuno.com
1444 URI: https://www.edgeuno.com
1446 Ivan Arce
1447 Quarkslab
1448 Segurola y Habana 4310 7mo piso
1449 Ciudad Autonoma de Buenos Aires
1450 Buenos Aires
1451 Argentina
1453 Email: iarce@quarkslab.com
1454 URI: https://www.quarkslab.com