idnits 2.17.1
draft-irtf-pearg-numeric-ids-history-08.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 copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 13, 2021) is 1047 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293)
** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323)
** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460)
** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373)
** Obsolete normative reference: RFC 2073 (Obsoleted by RFC 2374)
** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513)
** Obsolete normative reference: RFC 2374 (Obsoleted by RFC 3587)
** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200)
** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941)
** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981)
** Obsolete normative reference: RFC 6528 (Obsoleted by RFC 9293)
== Outdated reference: A later version (-05) exists of
draft-eddy-rfc793bis-04
== Outdated reference: A later version (-11) exists of
draft-gont-numeric-ids-sec-considerations-06
== Outdated reference: A later version (-08) exists of
draft-ietf-ntp-port-randomization-06
== Outdated reference: A later version (-12) exists of
draft-irtf-pearg-numeric-ids-generation-07
-- Obsolete informational reference (is this intentional?): RFC 1948 (ref.
'OpenBSD-TCP-ISN-H') (Obsoleted by RFC 6528)
-- Duplicate reference: RFC1948, mentioned in 'RFC1948', was also mentioned
in 'OpenBSD-TCP-ISN-H'.
-- Obsolete informational reference (is this intentional?): RFC 1948
(Obsoleted by RFC 6528)
-- Obsolete informational reference (is this intentional?): RFC 5157
(Obsoleted by RFC 7707)
Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 5 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 SI6 Networks
4 Intended status: Informational I. Arce
5 Expires: December 15, 2021 Quarkslab
6 June 13, 2021
8 Unfortunate History of Transient Numeric Identifiers
9 draft-irtf-pearg-numeric-ids-history-08
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 December 15, 2021.
38 Copyright Notice
40 Copyright (c) 2021 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
45 (https://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
54 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4
55 4. Issues with the Specification of Transient Numeric
56 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4
57 4.1. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . 5
58 4.2. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . 9
59 4.3. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . 11
60 4.4. NTP Reference IDs (REFIDs) . . . . . . . . . . . . . . . 14
61 4.5. Transport Protocol Ephemeral Port Numbers . . . . . . . . 15
62 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
67 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
68 9.2. Informative References . . . . . . . . . . . . . . . . . 20
69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
71 1. Introduction
73 Networking protocols employ a variety of transient numeric
74 identifiers for different protocol objects, such as IPv4 and IPv6
75 Fragment Identifiers [RFC0791] [RFC8200], IPv6 Interface Identifiers
76 (IIDs) [RFC4291], transport protocol ephemeral port numbers
77 [RFC6056], TCP Initial Sequence Numbers (ISNs) [RFC0793], and DNS
78 Transaction IDs (TxIDs) [RFC1035]. These identifiers typically have
79 specific interoperability requirements (e.g. uniqueness during a
80 specified period of time), and associated failure severities when
81 such requirements are not met
82 [I-D.irtf-pearg-numeric-ids-generation].
84 For more than 30 years, a large number of implementations of the TCP/
85 IP protocol suite have been subject to a variety of attacks, with
86 effects ranging from Denial of Service (DoS) or data injection, to
87 information leakages that could be exploited for pervasive monitoring
88 [RFC7258]. The root cause of these issues has been, in many cases,
89 poor selection of transient numeric identifiers, usually as a result
90 of insufficient or misleading specifications.
92 For example, implementations have been subject to security or privacy
93 issues resulting from:
95 o Predictable IPv4 or IPv6 Fragment Identifiers (see e.g.
96 [Sanfilippo1998a], [RFC6274], and [RFC7739])
98 o Predictable IPv6 IIDs (see e.g. [RFC7721], [RFC7707], and
99 [RFC7217])
101 o Predictable transport protocol ephemeral port numbers (see e.g.
102 [RFC6056] and [Silbersack2005])
104 o Predictable TCP Initial Sequence Numbers (ISNs) (see e.g.
105 [Morris1985], [Bellovin1989], and [RFC6528])
107 o Predictable DNS TxIDs (see e.g. [Arce1997] and [Klein2007])
109 These examples indicate that when new protocols are standardized or
110 implemented, the security and privacy properties of the associated
111 transient numeric identifiers tend to be overlooked, and
112 inappropriate algorithms to generate such identifiers (i.e. that
113 negatively affect the security or privacy properties of the protocol)
114 are either suggested in the specification or selected by
115 implementers.
117 This document contains a non-exhaustive timeline of the specification
118 and vulnerability disclosures related to some sample transient
119 numeric identifiers, including other work that has led to advances in
120 this area. This analysis indicates that:
122 o Vulnerabilities associated with the inappropriate generation of
123 transient numeric identifiers have affected protocol
124 implementations for an extremely long period of time.
126 o Such vulnerabilities, even when addressed for a given protocol
127 version, were later reintroduced in new versions or new
128 implementations of the same protocol.
130 o Standardization efforts that discuss and provide advice in this
131 area can have a positive effect on protocol specifications and
132 protocol implementations.
134 While it is generally possible to identify an algorithm that can
135 satisfy the interoperability requirements for a given transient
136 numeric identifier, this document provides empirical evidence that
137 doing so without negatively affecting the security or privacy
138 properties of the aforementioned protocols is non-trivial. Other
139 related documents ([I-D.irtf-pearg-numeric-ids-generation] and
140 [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this
141 area, as motivated by the present document.
143 This document represents the consensus of the Privacy Enhancement and
144 Assessment Research Group (PEARG).
146 2. Terminology
148 Transient Numeric Identifier:
149 A data object in a protocol specification that can be used to
150 definitely distinguish a protocol object (a datagram, network
151 interface, transport protocol endpoint, session, etc) from all
152 other objects of the same type, in a given context. Transient
153 numeric identifiers are usually defined as a series of bits, and
154 represented using integer values. These identifiers are typically
155 dynamically selected, as opposed to statically-assigned numeric
156 identifiers (see e.g. [IANA-PROT]). We note that different
157 identifiers may have additional requirements or properties
158 depending on their specific use in a protocol. We use the term
159 "transient numeric identifier" (or simply "numeric identifier" or
160 "identifier" as short forms) as a generic term to refer to any
161 data object in a protocol specification that satisfies the
162 identification property stated above.
164 The terms "constant IID", "stable IID", and "temporary IID" are to be
165 interpreted as defined in [RFC7721].
167 3. Threat Model
169 Throughout this document, we assume an attacker does not have
170 physical or logical access to the system(s) being attacked, and
171 cannot necessarily observe all the packets being transferred between
172 the sender and the receiver(s) of the target protocol, but may be
173 able to observe some of them. However, we assume the attacker can
174 send any traffic to the target device(s), to e.g. sample transient
175 numeric identifiers employed by such device(s).
177 4. Issues with the Specification of Transient Numeric Identifiers
179 While assessing protocol specifications regarding the use of
180 transient numeric identifiers, we have found that most of the issues
181 discussed in this document arise as a result of one of the following
182 conditions:
184 o Protocol specifications that under-specify the requirements for
185 their transient numeric identifiers
187 o Protocol specifications that over-specify their transient numeric
188 identifiers
190 o Protocol implementations that simply fail to comply with the
191 specified requirements
193 A number of protocol specifications have simply overlooked the
194 security and privacy implications of transient numeric identifiers.
195 Examples of them are the specification of TCP ephemeral ports in
196 [RFC0793], the specification of TCP sequence numbers in [RFC0793], or
197 the specification of the DNS TxID in [RFC1035].
199 On the other hand, there are a number of protocol specifications that
200 over-specify some of their associated transient numeric identifiers.
201 For example, [RFC4291] essentially overloads the semantics of IPv6
202 Interface Identifiers (IIDs) by embedding link-layer addresses in the
203 IPv6 IIDs, when the interoperability requirement of uniqueness could
204 be achieved in other ways that do not result in negative security and
205 privacy implications [RFC7721]. Similarly, [RFC2460] suggested the
206 use of a global counter for the generation of Fragment Identification
207 values, when the interoperability properties of uniqueness per {Src
208 IP, Dst IP} could be achieved with other algorithms that do not
209 result in negative security and privacy implications [RFC7739].
211 Finally, there are protocol implementations that simply fail to
212 comply with existing protocol specifications. For example, some
213 popular operating systems (notably Microsoft Windows) still fail to
214 implement transport protocol ephemeral port randomization, as
215 recommended in [RFC6056].
217 The following subsections document the timelines for a number of
218 sample transient numeric identifiers, that illustrate how the problem
219 discussed in this document has affected protocols from different
220 layers over time. These sample transient numeric identifiers have
221 different interoperability requirements and failure severities (see
222 Section 6 of [I-D.irtf-pearg-numeric-ids-generation]), and thus are
223 considered to be representative of the problem being analyzed in this
224 document.
226 4.1. IPv4/IPv6 Identification
228 This section presents the timeline of the Identification field
229 employed by IPv4 (in the base header) and IPv6 (in Fragment Headers).
230 The reason for presenting both cases in the same section is to make
231 it evident that while the Identification value serves the same
232 purpose in both IPv4 and IPv6, the work and research done for the
233 IPv4 case did not affect IPv6 specifications or implementations.
235 The IPv4 Identification is specified in [RFC0791], which specifies
236 the interoperability requirements for the Identification field: the
237 sender must choose the Identification field to be unique for a given
238 source address, destination address, and protocol, for the time the
239 datagram (or any fragment of it) could be alive in the internet. It
240 suggests that a node may keep "a table of Identifiers, one entry for
241 each destination it has communicated with in the last maximum packet
242 lifetime for the internet", and suggests that "since the Identifier
243 field allows 65,536 different values, hosts may be able to simply use
244 unique identifiers independent of destination". The above has been
245 interpreted numerous times as a suggestion to employ per-destination
246 or global counters for the generation of Identification values.
247 While [RFC0791] does not suggest any flawed algorithm for the
248 generation of Identification values, the specification omits a
249 discussion of the security and privacy implications of predictable
250 Identification values. This has resulted in many IPv4
251 implementations generating predictable fragment Identification values
252 by means of a global counter, at least at some point in time.
254 The IPv6 Identification was originally specified in [RFC1883]. It
255 serves the same purpose as its IPv4 counterpart, with the only
256 difference residing in the length of the corresponding field, and
257 that while the IPv4 Identification field is part of the base IPv4
258 header, in the IPv6 case it is part of the Fragment header (which may
259 or may not be present in an IPv6 packet). [RFC1883] states, in
260 Section 4.5, that the Identification must be different than that of
261 any other fragmented packet sent recently (within the maximum likely
262 lifetime of a packet) with the same Source Address and Destination
263 Address. Subsequently, it notes that this requirement can be met by
264 means of a wrap-around 32-bit counter that is incremented each time a
265 packet must be fragmented, and that it is an implementation choice
266 whether to use a global or a per-destination counter. Thus, the
267 implementation of the IPv6 Identification is similar to that of the
268 IPv4 case, with the only difference that in the IPv6 case the
269 suggestions to use simple counters is more explicit. [RFC2460] was
270 the first revision of the core IPv6 specification, and maintained the
271 same text for the specification of the IPv6 Identification field.
272 [RFC8200], the second revision of the core IPv6 specification,
273 removes the suggestion from [RFC2460] to use a counter for the
274 generation of IPv6 Identification values, and points to [RFC7739] for
275 sample algorithms for their generation.
277 September 1981:
278 [RFC0791] specifies the interoperability requirements for IPv4
279 Identification value, but does not perform a vulnerability
280 assessment of this transient numeric identifier.
282 December 1995:
283 [RFC1883], the first specification of the IPv6 protocol, is
284 published. It suggests that a counter be used to generate the
285 IPv6 Identification value, and notes that it is an implementation
286 choice whether to maintain a single counter for the node or
287 multiple counters, e.g., one for each of the node's possible
288 source addresses, or one for each active (source address,
289 destination address) combination.
291 December 1998:
292 [Sanfilippo1998a] finds that predictable IPv4 Identification
293 values (generated by most popular implementations) can be
294 leveraged to count the number of packets sent by a target node.
295 [Sanfilippo1998b] explains how to leverage the same vulnerability
296 to implement a port-scanning technique known as dumb/idle scan. A
297 tool that implements this attack is publicly released.
299 December 1998:
300 [RFC2460], a revision of the IPv6 specification, is published,
301 obsoleting [RFC1883]. It maintains the same specification of the
302 IPv6 Identification field as its predecessor ([RFC1883]).
304 December 1998:
305 OpenBSD implements randomization of the IPv4 Identification field
306 [OpenBSD-IPv4-ID].
308 November 1999:
309 [Sanfilippo1999] discusses how to leverage predictable IPv4
310 Identification to uncover the rules of a number of firewalls.
312 November 1999:
313 [Bellovin2002] explains how the IPv4 Identification field can be
314 exploited to count the number of systems behind a NAT.
316 September 2002:
317 [Fyodor2002] explains how to implement a stealth port-scanning
318 technique by leveraging nodes that employ predictable IPv4
319 Identification values.
321 October 2003:
322 OpenBSD implements randomization of the IPv6 Identification field
323 [OpenBSD-IPv6-ID].
325 December 2003:
326 [Zalewski2003] explains a technique to perform TCP data injection
327 attack based on predictable IPv4 identification values which
328 requires less effort than TCP injection attacks performed with
329 bare TCP packets.
331 November 2005:
332 [Silbersack2005] discusses shortcoming in a number of techniques
333 to mitigate predictable IPv4 Identification values.
335 October 2007:
337 [Klein2007] describes a weakness in the pseudo random number
338 generator (PRNG) in use for the generation of the IP
339 Identification by a number of operating systems.
341 June 2011:
342 [Gont2011] describes how to perform idle scan attacks in IPv6.
344 November 2011:
345 Linux mitigates predictable IPv6 Identification values
346 [RedHat2011] [SUSE2011] [Ubuntu2011].
348 December 2011:
349 [draft-gont-6man-predictable-fragment-id-00] describes the
350 security implications of predictable IPv6 Identification values,
351 and possible mitigations. This document has the Intended Status
352 of "Standards Track", with the intention to formally update
353 [RFC2460], to introduce security and privacy requirements on IPv6
354 Identification values.
356 May 2012:
357 [Gont2012] notes that some major IPv6 implementations still employ
358 predictable IPv6 Identification values.
360 March 2013:
361 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but
362 changes the track to "BCP" (while still formally updating
363 [RFC2460]), publishing the resulting document as
364 [draft-ietf-6man-predictable-fragment-id-00].
366 June 2013:
367 A patch that implements IPv6-based idle-scan in nmap is submitted
368 [Morbitzer2013].
370 December 2014:
371 The 6man WG changes the Intended Status of
372 [draft-ietf-6man-predictable-fragment-id-01] to "Informational"
373 and publishes it as [draft-ietf-6man-predictable-fragment-id-02].
374 As a result, it no longer formally updates [RFC2460].
376 June 2015:
377 [draft-ietf-6man-predictable-fragment-id-08] notes that some
378 popular host and router implementations still employ predictable
379 IPv6 Identification values.
381 February 2016:
382 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id])
383 analyzes the security and privacy implications of predictable IPv6
384 Identification values, and provides guidance for selecting an
385 algorithm to generate such values. However, being published with
386 the Intended Status of "Informational", it does not formally
387 update [RFC2460].
389 June 2016:
390 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the
391 suggestion from RFC2460 to use a counter for the generation of
392 IPv6 Identification values, but does not perform a vulnerability
393 assessment of the generation of IPv6 Identification values.
395 July 2017:
396 [I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200],
397 obsoleting [RFC2460], and pointing to [RFC7739] for sample
398 algorithms for the generation of IPv6 Fragment Identification
399 values.
401 June 2019:
402 [IPID-DEV] notes that the IPv6 ID generators of two popular
403 operating systems are flawed.
405 4.2. TCP Initial Sequence Numbers (ISNs)
407 [RFC0793] suggests that the choice of the ISN of a connection is not
408 arbitrary, but aims to reduce the chances of a stale segment from
409 being accepted by a new incarnation of a previous connection.
410 [RFC0793] suggests the use of a global 32-bit ISN generator that is
411 incremented by 1 roughly every 4 microseconds. However, as a matter
412 of fact, protection against stale segments from a previous
413 incarnation of the connection is enforced by preventing the creation
414 of a new incarnation of a previous connection before 2*MSL have
415 passed since a segment corresponding to the old incarnation was last
416 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This
417 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept
418 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are
419 monotonically increasing across connections, many stacks (e.g.,
420 4.2BSD-derived) use the ISN of an incoming SYN segment to perform
421 "heuristics" that enable the creation of a new incarnation of a
422 connection while the previous incarnation is still in the TIME-WAIT
423 state (see p. 945 of [Wright1994]). This avoids an interoperability
424 problem that may arise when a node establishes connections to a
425 specific TCP end-point at a high rate [Silbersack2005].
427 The interoperability requirements for TCP ISNs are probably not as
428 clearly spelled out as one would expect. Furthermore, the suggestion
429 of employing a global counter in [RFC0793] negatively affects the
430 security and privacy properties of the protocol.
432 September 1981:
434 [RFC0793], suggests the use of a global 32-bit ISN generator,
435 whose lower bit is incremented roughly every 4 microseconds.
436 However, such an ISN generator makes it trivial to predict the ISN
437 that a TCP instance will use for new connections, thus allowing a
438 variety of attacks against TCP.
440 February 1985:
441 [Morris1985] was the first to describe how to exploit predictable
442 TCP ISNs for forging TCP connections that could then be leveraged
443 for trust relationship exploitation.
445 April 1989:
446 [Bellovin1989] discussed the security considerations for
447 predictable ISNs (along with a range of other protocol-based
448 vulnerabilities).
450 February 1995:
451 [Shimomura1995] reported a real-world exploitation of the attack
452 described in 1985 (ten years before) in [Morris1985].
454 May 1996:
455 [RFC1948] was the first IETF effort, authored by Steven Bellovin,
456 to address predictable TCP ISNs. The same concept specified in
457 this document for TCP ISNs was later proposed for TCP ephemeral
458 ports [RFC6056], TCP Timestamps, and eventually even IPv6
459 Interface Identifiers [RFC7217].
461 July 1996:
462 OpenBSD implements TCP ISN randomization based on random
463 increments (please see Appendix A.2 of
464 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-I].
466 December 2000:
467 OpenBSD implements TCP ISN randomization using simple
468 randomization (please see Section 7.1 of
469 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-R].
471 March 2001:
472 [Zalewski2001] provides a detailed analysis of statistical
473 weaknesses in some ISN generators, and includes a survey of the
474 algorithms in use by popular TCP implementations.
476 May 2001:
477 Vulnerability advisories [CERT2001] [USCERT2001] are released
478 regarding statistical weaknesses in some ISN generators, affecting
479 popular TCP/IP implementations.
481 March 2002:
483 [Zalewski2002] updates and complements [Zalewski2001]. It
484 concludes that "while some vendors [...] reacted promptly and
485 tested their solutions properly, many still either ignored the
486 issue and never evaluated their implementations, or implemented a
487 flawed solution that apparently was not tested using a known
488 approach" [Zalewski2002].
490 June 2007:
491 OpenBSD implements TCP ISN randomization based on the algorithm
492 specified in [RFC1948] (currently obsoleted by [RFC6528]) for the
493 TCP endpoint that performs the active open, while keeping the
494 simple randomization scheme for the endpoint performing the
495 passive open [OpenBSD-TCP-ISN-H]. This provides monotonically-
496 increasing ISNs for the client side (allowing the BSD heuristics
497 to work as expected), while avoiding any patterns in the ISN
498 generation for the server side.
500 February 2012:
501 [RFC6528], published 27 years after Morris' original work
502 [Morris1985], formally updates [RFC0793] to mitigate predictable
503 TCP ISNs.
505 August 2014:
506 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP
507 protocol specification, incorporates the algorithm specified in
508 [RFC6528] as the recommended algorithm for TCP ISN generation.
510 4.3. IPv6 Interface Identifiers (IIDs)
512 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC
513 [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section
514 focuses on Interface Identifiers resulting from SLAAC.
516 The Interface Identifier of stable (traditional) IPv6 addresses
517 resulting from SLAAC have traditionally resulted in the underlying
518 link-layer address being embedded in the IID. At the time, employing
519 the underlying link-layer address for the IID was seen as a
520 convenient way to obtain a unique address. However, recent awareness
521 about the security and privacy properties of this approach [RFC7707]
522 [RFC7721] has led to the replacement of this flawed scheme with an
523 alternative one [RFC7217] [RFC8064] that does not negatively affect
524 the security and privacy properties of the protocol.
526 January 1997:
527 [RFC2073] specifies the syntax of IPv6 global addresses (referred
528 to as "An IPv6 Provider-Based Unicast Address Format" at the
529 time), consistent with the IPv6 addressing architecture specified
530 in [RFC1884]. Hosts are recommended to "generate addresses using
531 link-specific addresses as Interface ID such as 48 bit IEEE-802
532 MAC addresses".
534 July 1998:
535 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address
536 Format" (obsoleting [RFC2373]) changing the size of the Interface
537 ID to 64 bits, and specifies that that IIDs must be constructed in
538 IEEE EUI-64 format. How such identifiers are constructed becomes
539 specified in the appropriate "IPv6 over " specification such
540 as "IPv6 over Ethernet".
542 January 2001:
543 [RFC3041] recognizes the problem of network activity correlation,
544 and specifies temporary addresses. Temporary addresses are to be
545 used along with stable addresses.
547 August 2003:
548 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure
549 historic. The syntax and recommendations for the traditional
550 stable IIDs remain unchanged, though.
552 February 2006:
553 [RFC4291] is published as the latest "IP Version 6 Addressing
554 Architecture", requiring the IIDs of the traditional (stable)
555 autoconfigured addresses to employ the Modified EUI-64 format.
556 The details of constructing such interface identifiers are defined
557 in the appropriate "IPv6 over " specifications.
559 March 2008:
560 [RFC5157] provides hints regarding how patterns in IPv6 addresses
561 could be leveraged for the purpose of address scanning.
563 December 2011:
564 [draft-gont-6man-stable-privacy-addresses-00] notes that the
565 traditional scheme for generating stable addresses allows for
566 address scanning, and also does not prevent active node tracking.
567 It also specifies an alternative algorithm meant to replace IIDs
568 based on Modified EUI-64 format identifiers.
570 November 2012:
571 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a
572 working group item (as
573 [draft-ietf-6man-stable-privacy-addresses-00]). However, the
574 document no longer formally updates [RFC4291], and therefore the
575 specified algorithm no longer formally replaces the Modified
576 EUI-64 format identifiers.
578 February 2013:
580 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages
581 IPv6 address patterns is released [Gont2013].
583 July 2013:
584 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on
585 the security and privacy properties of all known algorithms for
586 generating IPv6 IIDs.
588 January 2014:
589 The 6man WG publishes [draft-ietf-6man-default-iids-00]
590 ("Recommendation on Stable IPv6 Interface Identifiers"),
591 recommending [I-D.ietf-6man-stable-privacy-addresses] for the
592 generation of stable addresses.
594 April 2014:
595 [RFC7217] (formerly [I-D.ietf-6man-stable-privacy-addresses]) is
596 published, specifying "A Method for Generating Semantically Opaque
597 Interface Identifiers with IPv6 Stateless Address
598 Autoconfiguration (SLAAC)" as an alternative to (but *not*
599 replacement of) Modified EUI-64 format IIDs.
601 March 2016:
602 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning], and later
603 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network
604 Reconnaissance in IPv6 Networks", is published.
606 March 2016:
607 [RFC7721] (formerly
608 [I-D.cooper-6man-ipv6-address-generation-privacy] and later
609 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security
610 and Privacy Considerations for IPv6 Address Generation
611 Mechanisms", is published.
613 May 2016:
614 [draft-gont-6man-non-stable-iids-00] is published, with the goal
615 of specifying requirements for non-stable addresses, and updating
616 [RFC4941] such that use of only temporary addresses is allowed.
618 May 2016:
619 [draft-gont-6man-address-usage-recommendations-00] is published,
620 providing an analysis of how different aspects on an address (from
621 stability to usage mode) affect their corresponding security and
622 privacy properties, and meaning to eventually provide advice in
623 this area.
625 February 2017:
626 The 6man WG publishes [RFC8064] ("Recommendation on Stable IPv6
627 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]),
628 with requirements for stable addresses and a recommendation to
629 employ [RFC7217] for the generation of stable addresses. It
630 formally updates a large number of RFCs.
632 March 2018:
633 [draft-fgont-6man-rfc4941bis-00] is published (as suggested by the
634 6man WG), to address flaws in [RFC4941] by revising it (as an
635 alternative to the [draft-gont-6man-non-stable-iids-00] effort,
636 published in March 2016).
638 July 2018:
639 [draft-fgont-6man-rfc4941bis-00] is adopted (as
640 [draft-ietf-6man-rfc4941bis-00]) as a WG item of the 6man WG.
642 December 2020:
643 [I-D.ietf-6man-rfc4941bis] is approved by the IESG for publication
644 as an RFC.
646 February 2021:
647 [I-D.ietf-6man-rfc4941bis] is finally published as [RFC8981].
649 4.4. NTP Reference IDs (REFIDs)
651 The NTP [RFC5905] Reference ID is a 32-bit code identifying the
652 particular server or reference clock. Above stratum 1 (secondary
653 servers and clients), this value can be employed to avoid degree-one
654 timing loops; that is, scenarios where two NTP peers are (mutually)
655 the time source of each other. If using the IPv4 address family, the
656 identifier is the four-octet IPv4 address. If using the IPv6 address
657 family, it is the first four octets of the MD5 hash of the IPv6
658 address.
660 June 2010:
661 [RFC5905], "Network Time Protocol Version 4: Protocol and
662 Algorithms Specification" is published. It specifies that for NTP
663 peers with stratum higher than 1 the REFID embeds the IPv4 Address
664 of the time source or an MD5 hash of the IPv6 address of the time
665 source.
667 July 2016:
668 [draft-stenn-ntp-not-you-refid-00] is published, describing the
669 information leakage produced via the NTP REFID. It proposes that
670 NTP returns a special REFID when a packet employs an IP Source
671 Address that is not believed to be a current NTP peer, but
672 otherwise generates and returns the traditional REFID. It is
673 subsequently adopted by the NTP WG as
674 [I-D.ietf-ntp-refid-updates].
676 April 2019:
677 [Gont-NTP] notes that the proposed fix specified in
678 [draft-ietf-ntp-refid-updates-00] is, at the very least, sub-
679 optimal.
681 4.5. Transport Protocol Ephemeral Port Numbers
683 Most (if not all) transport protocols employ "port numbers" to
684 demultiplex packets to the corresponding transport protocol
685 instances.
687 August 1980:
688 [RFC0768] notes that the UDP source port is optional and
689 identifies the port of the sending process. It does not specify
690 interoperability requirements for source port selection, nor does
691 it suggest possible ways to select port numbers. Most popular
692 implementations end up selecting source ports from a system-wide
693 global counter.
695 September 1981:
696 [RFC0793] (the TCP specification) essentially describes the use of
697 port numbers, and specifies that port numbers should result in a
698 unique socket pair (local address, local port, remote address,
699 remote port). How ephemeral ports (i.e. port numbers for "active
700 opens") are selected, and the port range from which they are
701 selected, are left unspecified.
703 July 1996:
704 OpenBSD implements ephemeral port randomization [OpenBSD-PR].
706 July 2008:
707 The CERT Coordination Centre published details of what became
708 known as the "Kaminsky Attack" [VU-800113] on the DNS. The attack
709 exploited the lack of source port randomization in many major DNS
710 implementations to perform cache poisoning in an effective and
711 practical manner.
713 January 2009:
714 [RFC5452] mandates the use of port randomization for DNS
715 resolvers, and mandates that implementations must randomize ports
716 from the range (53 or 1024, and above) or the largest possible
717 port range. It does not recommend possible algorithms for port
718 randomization, although the document specifically targets DNS
719 resolvers, for which a simple port randomization suffices (e.g.
720 Algorithm 1 of [RFC6056]). This document led to the
721 implementation of port randomization in the DNS resolver
722 themselves, rather than in the underlying transport-protocols.
724 January 2011:
725 [RFC6056] notes that many TCP and UDP implementations result in
726 predictable port numbers, and also notes that many implementations
727 select port numbers from a small portion of the whole port number
728 space. It recommends the implementation and use of ephemeral port
729 randomization, proposes a number of possible algorithms for port
730 randomization, and also recommends to randomize port numbers over
731 the range 1024-65535.
733 March 2016:
734 [NIST-NTP] reports a non-normal distribution of the ephemeral port
735 numbers employed by the NTP clients of an Internet Time Service.
737 April 2019:
738 [I-D.gont-ntp-port-randomization] notes that some NTP
739 implementations employ the NTP service port (123) as the local
740 port for non-symmetric modes, and aims to update the NTP
741 specification to recommend port randomization in such cases, in
742 line with [RFC6056]. The proposal experiences some push-back in
743 the relevant working group (NTP WG) [NTP-PORTR], but is finally
744 adopted as a working group item as
745 [I-D.ietf-ntp-port-randomization].
747 September 2020:
748 [I-D.ietf-ntp-port-randomization] passes its WGLC.
750 5. Conclusions
752 For more than 30 years, a large number of implementations of the TCP/
753 IP protocol suite have been subject to a variety of attacks, with
754 effects ranging from Denial of Service (DoS) or data injection, to
755 information leakages that could be exploited for pervasive monitoring
756 [RFC7258]. The root cause of these issues has been, in many cases,
757 poor selection of transient numeric identifiers, usually as a result
758 of insufficient or misleading specifications.
760 While it is generally possible to identify an algorithm that can
761 satisfy the interoperability requirements for a given transient
762 numeric identifier, this document provides empirical evidence that
763 doing so without negatively affecting the security or privacy
764 properties of the aforementioned protocols is non-trivial. It is
765 thus evident that advice in this area is warranted.
767 [I-D.gont-numeric-ids-sec-considerations] aims at requiring future
768 protocol specifications to contain analysis of the security and
769 privacy properties of any transient numeric identifiers specified by
770 the protocol, and to recommend an algorithm for the generation of
771 such transient numeric identifiers.
773 [I-D.irtf-pearg-numeric-ids-generation] specifies a number of sample
774 algorithms for generating transient numeric identifiers with specific
775 interorability requirements and failure severities.
777 6. IANA Considerations
779 There are no IANA registries within this document. The RFC-Editor
780 can remove this section before publication of this document as an
781 RFC.
783 7. Security Considerations
785 This document analyzes the timeline of the specification and
786 implementation of the transient numeric identifiers of some sample
787 IETF protocols, and how the security and privacy properties of such
788 protocols have been affected as a result of it. It provides concrete
789 evidence that advice in this area is warranted.
791 [I-D.gont-numeric-ids-sec-considerations] formally requires protocol
792 specifications to specify the interoperability requirements for their
793 transient numeric identifiers, to do a warranted vulnerability
794 assessment of such transient numeric identifiers, and to recommend
795 possible algorithms for their generation, such that the
796 interoperability requirements are complied with, while any negative
797 security and privacy properties of these transient numeric
798 identifiers are mitigated.
800 [I-D.irtf-pearg-numeric-ids-generation] analyzes and categorizes
801 transient numeric identifiers based on their interoperability
802 requirements and their associated failure severities, and recommends
803 possible algorithms that can comply with those requirements without
804 negatively affecting the security and privacy properties of the
805 corresponding protocols.
807 8. Acknowledgements
809 The authors would like to thank (in alphabetical order) Bernard
810 Aboba, Dave Crocker, Theo de Raadt, Sara Dickinson, Guillermo Gont,
811 Christian Huitema, Colin Perkins, Vincent Roca, Kris Shrishak, Joe
812 Touch, and Christopher Wood, for providing valuable comments on
813 earlier versions of this document.
815 The authors would like to thank (in alphabetical order) Steven
816 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for
817 providing valuable comments on [I-D.gont-predictable-numeric-ids], on
818 which this document is based.
820 Section 4.2 of this document borrows text from [RFC6528], authored by
821 Fernando Gont and Steven Bellovin.
823 The authors would like to thank Sara Dickinson and Christopher Wood,
824 for their guidance during the publication process of this document.
826 The authors would like to thank Diego Armando Maradona for his magic
827 and inspiration.
829 9. References
831 9.1. Normative References
833 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
834 DOI 10.17487/RFC0768, August 1980,
835 .
837 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
838 DOI 10.17487/RFC0791, September 1981,
839 .
841 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
842 RFC 793, DOI 10.17487/RFC0793, September 1981,
843 .
845 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
846 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
847 1992, .
849 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
850 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
851 December 1995, .
853 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
854 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
855 December 1995, .
857 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J.
858 Postel, "An IPv6 Provider-Based Unicast Address Format",
859 RFC 2073, DOI 10.17487/RFC2073, January 1997,
860 .
862 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
863 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
864 .
866 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6
867 Aggregatable Global Unicast Address Format", RFC 2374,
868 DOI 10.17487/RFC2374, July 1998,
869 .
871 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
872 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
873 December 1998, .
875 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
876 Stateless Address Autoconfiguration in IPv6", RFC 3041,
877 DOI 10.17487/RFC3041, January 2001,
878 .
880 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
881 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
882 August 2003, .
884 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
885 Architecture", RFC 4291, DOI 10.17487/RFC4291, February
886 2006, .
888 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
889 Address Autoconfiguration", RFC 4862,
890 DOI 10.17487/RFC4862, September 2007,
891 .
893 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
894 Extensions for Stateless Address Autoconfiguration in
895 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
896 .
898 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
899 Resilient against Forged Answers", RFC 5452,
900 DOI 10.17487/RFC5452, January 2009,
901 .
903 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
904 Protocol Port Randomization", BCP 156, RFC 6056,
905 DOI 10.17487/RFC6056, January 2011,
906 .
908 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
909 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
910 2012, .
912 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
913 Interface Identifiers with IPv6 Stateless Address
914 Autoconfiguration (SLAAC)", RFC 7217,
915 DOI 10.17487/RFC7217, April 2014,
916 .
918 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
919 (IPv6) Specification", STD 86, RFC 8200,
920 DOI 10.17487/RFC8200, July 2017,
921 .
923 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
924 Richardson, M., Jiang, S., Lemon, T., and T. Winters,
925 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
926 RFC 8415, DOI 10.17487/RFC8415, November 2018,
927 .
929 9.2. Informative References
931 [Arce1997]
932 Arce, I. and E. Kargieman, "BIND Vulnerabilities and
933 Solutions", 1997,
934 .
936 [Bellovin1989]
937 Bellovin, S., "Security Problems in the TCP/IP Protocol
938 Suite", Computer Communications Review, vol. 19, no. 2,
939 pp. 32-48, 1989,
940 .
942 [Bellovin2002]
943 Bellovin, S., "A Technique for Counting NATted Hosts",
944 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002,
945 .
947 [CERT2001]
948 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in
949 TCP/IP Initial Sequence Numbers", 2001,
950 .
953 [draft-fgont-6man-rfc4941bis-00]
954 Gont, F., Krishnan, S., Narten, T., and R. Draves,
955 "Privacy Extensions for Stateless Address
956 Autoconfiguration in IPv6", draft-fgont-6man-rfc4941bis-00
957 (work in progress), March 2018.
959 [draft-gont-6man-address-usage-recommendations-00]
960 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations",
961 draft-gont-6man-address-usage-recommendations-00 (work in
962 progress), May 2016.
964 [draft-gont-6man-non-stable-iids-00]
965 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6
966 Interface Identifiers", draft-gont-6man-non-stable-iids-00
967 (work in progress), May 2016.
969 [draft-gont-6man-predictable-fragment-id-00]
970 Gont, F., "Security Implications of Predictable Fragment
971 Identification Values", draft-gont-6man-predictable-
972 fragment-id-00 (work in progress), December 2011.
974 [draft-gont-6man-stable-privacy-addresses-00]
975 Gont, F., "A method for Generating Stable Privacy-Enhanced
976 Addresses with IPv6 Stateless Address Autoconfiguration
977 (SLAAC)", draft-gont-6man-stable-privacy-addresses-00
978 (work in progress), December 2011.
980 [draft-ietf-6man-default-iids-00]
981 Gont, F., Cooper, A., Thaler, D., and W. Liu,
982 "Recommendation on Stable IPv6 Interface Identifiers",
983 draft-ietf-6man-default-iids-00 (work in progress), July
984 2014.
986 [draft-ietf-6man-predictable-fragment-id-00]
987 Gont, F., "Security Implications of Predictable Fragment
988 Identification Values", draft-ietf-6man-predictable-
989 fragment-id-00 (work in progress), March 2013.
991 [draft-ietf-6man-predictable-fragment-id-01]
992 Gont, F., "Security Implications of Predictable Fragment
993 Identification Values", draft-ietf-6man-predictable-
994 fragment-id-01 (work in progress), April 2014.
996 [draft-ietf-6man-predictable-fragment-id-02]
997 Gont, F., "Security Implications of Predictable Fragment
998 Identification Values", draft-ietf-6man-predictable-
999 fragment-id-02 (work in progress), December 2014.
1001 [draft-ietf-6man-predictable-fragment-id-08]
1002 Gont, F., "Security Implications of Predictable Fragment
1003 Identification Values", draft-ietf-6man-predictable-
1004 fragment-id-08 (work in progress), June 2015.
1006 [draft-ietf-6man-rfc4941bis-00]
1007 Gont, F., Krishnan, S., Narten, T., and R. Draves,
1008 "Privacy Extensions for Stateless Address
1009 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-00
1010 (work in progress), July 2018.
1012 [draft-ietf-6man-stable-privacy-addresses-00]
1013 Gont, F., "A method for Generating Stable Privacy-Enhanced
1014 Addresses with IPv6 Stateless Address Autoconfiguration
1015 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00
1016 (work in progress), May 2012.
1018 [draft-ietf-ntp-refid-updates-00]
1019 Goldberg, S. and H. Stenn, "Network Time Protocol Not You
1020 REFID", draft-ietf-ntp-refid-updates-00 (work in
1021 progress), November 2016.
1023 [draft-stenn-ntp-not-you-refid-00]
1024 Goldberg, S. and H. Stenn, "Network Time Protocol Not You
1025 REFID", draft-stenn-ntp-not-you-refid-00 (work in
1026 progress), July 2016.
1028 [Fyodor2002]
1029 Fyodor, "Idle scanning and related IP ID games", 2002,
1030 .
1032 [Gont-NTP]
1033 Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates-
1034 05", Post to the NTP WG mailing list Message-ID:
1035 ,
1036 April 2019, .
1039 [Gont2011]
1040 Gont, F., "Hacking IPv6 Networks (training course)", Hack
1041 In Paris 2011 Conference Paris, France, June 2011.
1043 [Gont2012]
1044 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012
1045 Conference Ottawa, Canada. May 11-12, 2012, May 2012,
1046 .
1050 [Gont2013]
1051 Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit
1052 (help wanted!)", Message posted to the IPv6 Hackers
1053 mailing-list Message-ID:
1054 <51184548.3030105@si6networks.com>, 2013,
1055 .
1058 [I-D.cooper-6man-ipv6-address-generation-privacy]
1059 Cooper, A., Gont, F., and D. Thaler, "Privacy
1060 Considerations for IPv6 Address Generation Mechanisms",
1061 draft-cooper-6man-ipv6-address-generation-privacy-00 (work
1062 in progress), July 2013.
1064 [I-D.eddy-rfc793bis-04]
1065 Eddy, W., "Transmission Control Protocol Specification",
1066 draft-eddy-rfc793bis-04 (work in progress), August 2014.
1068 [I-D.gont-6man-predictable-fragment-id]
1069 Gont, F., "Security Implications of Predictable Fragment
1070 Identification Values", draft-gont-6man-predictable-
1071 fragment-id-03 (work in progress), January 2013.
1073 [I-D.gont-6man-stable-privacy-addresses]
1074 Gont, F., "A method for Generating Stable Privacy-Enhanced
1075 Addresses with IPv6 Stateless Address Autoconfiguration
1076 (SLAAC)", draft-gont-6man-stable-privacy-addresses-01
1077 (work in progress), March 2012.
1079 [I-D.gont-ntp-port-randomization]
1080 Gont, F. and G. Gont, "Port Randomization in the Network
1081 Time Protocol Version 4", draft-gont-ntp-port-
1082 randomization-04 (work in progress), August 2019.
1084 [I-D.gont-numeric-ids-sec-considerations]
1085 Gont, F. and I. Arce, "Security Considerations for
1086 Transient Numeric Identifiers Employed in Network
1087 Protocols", draft-gont-numeric-ids-sec-considerations-06
1088 (work in progress), December 2020.
1090 [I-D.gont-opsec-ipv6-host-scanning]
1091 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
1092 Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in
1093 progress), October 2012.
1095 [I-D.gont-predictable-numeric-ids]
1096 Gont, F. and I. Arce, "Security and Privacy Implications
1097 of Numeric Identifiers Employed in Network Protocols",
1098 draft-gont-predictable-numeric-ids-03 (work in progress),
1099 March 2019.
1101 [I-D.ietf-6man-default-iids]
1102 Gont, F., Cooper, A., Thaler, D., and W. Liu,
1103 "Recommendation on Stable IPv6 Interface Identifiers",
1104 draft-ietf-6man-default-iids-16 (work in progress),
1105 September 2016.
1107 [I-D.ietf-6man-ipv6-address-generation-privacy]
1108 Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
1109 Considerations for IPv6 Address Generation Mechanisms",
1110 draft-ietf-6man-ipv6-address-generation-privacy-08 (work
1111 in progress), September 2015.
1113 [I-D.ietf-6man-predictable-fragment-id]
1114 Gont, F., "Security Implications of Predictable Fragment
1115 Identification Values", draft-ietf-6man-predictable-
1116 fragment-id-10 (work in progress), October 2015.
1118 [I-D.ietf-6man-rfc2460bis]
1119 <>, S. E. D. and R. M. Hinden, "Internet Protocol, Version
1120 6 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13
1121 (work in progress), May 2017.
1123 [I-D.ietf-6man-rfc4941bis]
1124 Gont, F., Krishnan, S., Narten, T., and R. Draves,
1125 "Temporary Address Extensions for Stateless Address
1126 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-12
1127 (work in progress), November 2020.
1129 [I-D.ietf-6man-stable-privacy-addresses]
1130 Gont, F., "A Method for Generating Semantically Opaque
1131 Interface Identifiers with IPv6 Stateless Address
1132 Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
1133 privacy-addresses-17 (work in progress), January 2014.
1135 [I-D.ietf-ntp-port-randomization]
1136 Gont, F., Gont, G., and M. Lichvar, "Port Randomization in
1137 the Network Time Protocol Version 4", draft-ietf-ntp-port-
1138 randomization-06 (work in progress), September 2020.
1140 [I-D.ietf-ntp-refid-updates]
1141 Stenn, H. and S. Goldberg, "Network Time Protocol REFID
1142 Updates", draft-ietf-ntp-refid-updates-05 (work in
1143 progress), March 2019.
1145 [I-D.ietf-opsec-ipv6-host-scanning]
1146 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
1147 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in
1148 progress), August 2015.
1150 [I-D.irtf-pearg-numeric-ids-generation]
1151 Gont, F. and I. Arce, "On the Generation of Transient
1152 Numeric Identifiers", draft-irtf-pearg-numeric-ids-
1153 generation-07 (work in progress), February 2021.
1155 [IANA-PROT]
1156 IANA, "Protocol Registries",
1157 .
1159 [IPID-DEV]
1160 Klein, A. and B. Pinkas, "From IP ID to Device ID and
1161 KASLR Bypass (Extended Version)", June 2019,
1162 .
1164 [IPv6-Toolkit]
1165 SI6 Networks, "SI6 Networks' IPv6 Toolkit",
1166 .
1168 [Klein2007]
1169 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
1170 Predictable IP ID Vulnerability", 2007,
1171 .
1175 [Morbitzer2013]
1176 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message
1177 posted to the nmap-dev mailing-list, 2013,
1178 .
1180 [Morris1985]
1181 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
1182 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill,
1183 NJ, 1985,
1184 .
1186 [NIST-NTP]
1187 Sherman, J. and J. Levine, "Usage Analysis of the NIST
1188 Internet Time Service", Journal of Research of the
1189 National Institute of Standards and Technology Volume 121,
1190 March 2016, .
1192 [NTP-PORTR]
1193 Gont, F., "[Ntp] New rev of the NTP port randomization I-D
1194 (Fwd: New Version Notification for draft-gont-ntp-port-
1195 randomization-01.txt)", 2019,
1196 .
1199 [OpenBSD-IPv4-ID]
1200 OpenBSD, "Randomization of the IPv4 Identification field",
1201 December 1998,
1202 .
1205 [OpenBSD-IPv6-ID]
1206 OpenBSD, "Randomization of the IPv6 Identification field",
1207 October 2003,
1208 .
1211 [OpenBSD-PR]
1212 OpenBSD, "Implementation of port randomization", July
1213 1996, .
1216 [OpenBSD-TCP-ISN-H]
1217 OpenBSD, "Implementation of RFC1948 for TCP ISN
1218 randomization", December 2000,
1219 .
1222 [OpenBSD-TCP-ISN-I]
1223 OpenBSD, "Implementation of TCP ISN randomization based on
1224 random increments", July 1996,
1225 .
1228 [OpenBSD-TCP-ISN-R]
1229 OpenBSD, "Implementation of TCP ISN randomization based on
1230 simple randomization", December 2000,
1231 .
1234 [RedHat2011]
1235 RedHat, "RedHat Security Advisory RHSA-2011:1465-1:
1236 Important: kernel security and bug fix update", 2011,
1237 .
1239 [RFC1035] Mockapetris, P., "Domain names - implementation and
1240 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1241 November 1987, .
1243 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
1244 RFC 1948, DOI 10.17487/RFC1948, May 1996,
1245 .
1247 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
1248 RFC 5157, DOI 10.17487/RFC5157, March 2008,
1249 .
1251 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
1252 "Network Time Protocol Version 4: Protocol and Algorithms
1253 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
1254 .
1256 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol
1257 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
1258 .
1260 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
1261 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
1262 2014, .
1264 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
1265 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
1266 .
1268 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
1269 Considerations for IPv6 Address Generation Mechanisms",
1270 RFC 7721, DOI 10.17487/RFC7721, March 2016,
1271 .
1273 [RFC7739] Gont, F., "Security Implications of Predictable Fragment
1274 Identification Values", RFC 7739, DOI 10.17487/RFC7739,
1275 February 2016, .
1277 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
1278 "Recommendation on Stable IPv6 Interface Identifiers",
1279 RFC 8064, DOI 10.17487/RFC8064, February 2017,
1280 .
1282 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
1283 "Temporary Address Extensions for Stateless Address
1284 Autoconfiguration in IPv6", RFC 8981,
1285 DOI 10.17487/RFC8981, February 2021,
1286 .
1288 [Sanfilippo1998a]
1289 Sanfilippo, S., "about the ip header id", Post to Bugtraq
1290 mailing-list, Mon Dec 14 1998,
1291 .
1293 [Sanfilippo1998b]
1294 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list,
1295 1998, .
1298 [Sanfilippo1999]
1299 Sanfilippo, S., "more ip id", Post to Bugtraq mailing-
1300 list, 1999,
1301 .
1304 [Shimomura1995]
1305 Shimomura, T., "Technical details of the attack described
1306 by Markoff in NYT", Message posted in USENET's
1307 comp.security.misc newsgroup Message-ID:
1308 <3g5gkl$5j1@ariel.sdsc.edu>, 1995,
1309 .
1311 [Silbersack2005]
1312 Silbersack, M., "Improving TCP/IP security through
1313 randomization without sacrificing interoperability",
1314 EuroBSDCon 2005 Conference, 2005,
1315 .
1318 [SUSE2011]
1319 SUSE, "SUSE Security Announcement: Linux kernel security
1320 update (SUSE-SA:2011:046)", 2011,
1321 .
1324 [Ubuntu2011]
1325 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel
1326 vulnerabilities", 2011,
1327 .
1329 [USCERT2001]
1330 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple
1331 TCP/IP implementations may use statistically predictable
1332 initial sequence numbers", 2001,
1333 .
1335 [VU-800113]
1336 CERT/CC, "Multiple DNS implementations vulnerable to cache
1337 poisoning (Vulnerability Note VU#800113)", July 2008,
1338 .
1340 [Wright1994]
1341 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
1342 The Implementation", Addison-Wesley, 1994.
1344 [Zalewski2001]
1345 Zalewski, M., "Strange Attractors and TCP/IP Sequence
1346 Number Analysis", 2001,
1347 .
1349 [Zalewski2002]
1350 Zalewski, M., "Strange Attractors and TCP/IP Sequence
1351 Number Analysis - One Year Later", 2001,
1352 .
1354 [Zalewski2003]
1355 Zalewski, M., "A new TCP/IP blind data injection
1356 technique?", 2003,
1357 .
1359 Authors' Addresses
1361 Fernando Gont
1362 SI6 Networks
1363 Segurola y Habana 4310 7mo piso
1364 Ciudad Autonoma de Buenos Aires, Buenos Aires
1365 Argentina
1367 Phone: +54 11 4650 8472
1368 Email: fgont@si6networks.com
1369 URI: https://www.si6networks.com
1370 Ivan Arce
1371 Quarkslab
1372 Segurola y Habana 4310 7mo piso
1373 Ciudad Autonoma de Buenos Aires, Buenos Aires
1374 Argentina
1376 Email: iarce@quarkslab.com
1377 URI: https://www.quarkslab.com