idnits 2.17.1
draft-irtf-pearg-numeric-ids-history-05.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 (January 6, 2021) is 1206 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-04
-- 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: July 10, 2021 Quarkslab
6 January 6, 2021
8 Unfortunate History of Transient Numeric Identifiers
9 draft-irtf-pearg-numeric-ids-history-05
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.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at https://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on July 10, 2021.
36 Copyright Notice
38 Copyright (c) 2021 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
52 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4
53 4. Issues with the Specification of Transient Numeric
54 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 4
55 5. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . . . 5
56 6. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . . . 9
57 7. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . . . 11
58 8. NTP Reference IDs (REFIDs) . . . . . . . . . . . . . . . . . 14
59 9. Transport Protocol Ephemeral Port Numbers . . . . . . . . . . 14
60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
61 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
62 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
63 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
64 13.1. Normative References . . . . . . . . . . . . . . . . . . 17
65 13.2. Informative References . . . . . . . . . . . . . . . . . 19
66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
68 1. Introduction
70 Networking protocols employ a variety of transient numeric
71 identifiers for different protocol objects, ranging from DNS
72 Transaction IDs (TxIDs) to transport protocol ephemeral port numbers
73 or IPv6 Interface Identifiers (IIDs). These identifiers typically
74 have specific interoperability requirements (e.g. uniqueness during a
75 specified period of time), and an associated modes when such
76 properties are not met [I-D.irtf-pearg-numeric-ids-generation].
78 For more than 30 years, a large number of implementations of the TCP/
79 IP protocol suite have been subject to a variety of attacks, with
80 effects ranging from Denial of Service (DoS) or data injection, to
81 information leakages that could be exploited for pervasive monitoring
82 [RFC7258]. The root cause of these issues has been, in many cases,
83 poor selection of transient numeric identifiers, usually as a result
84 of insufficient or misleading specifications.
86 For example, implementations have been subject to security or privacy
87 issues resulting from:
89 o Predictable TCP Initial Sequence Numbers (ISNs) (see e.g.
90 [Morris1985], [Bellovin1989], and [RFC6528])
92 o Predictable transport protocol ephemeral port numbers (see e.g.
93 [RFC6056] and [Silbersack2005])
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 DNS TxIDs (see e.g. [Schuba1993] and [Klein2007])
103 These examples indicate that when new protocols are standardized or
104 implemented, the security and privacy properties of the associated
105 transient numeric identifiers tend to be overlooked, and
106 inappropriate algorithms to generate such identifiers (i.e. that
107 negatively affect the security or privacy properties of the protocol)
108 are either suggested in the specification or selected by
109 implementers.
111 This document contains a non-exhaustive timeline of the specification
112 and vulnerability disclosures related to some sample transient
113 numeric identifiers, including other work that has led to advances in
114 this area. This analysis indicates that:
116 o Vulnerabilities associated with the inappropriate generation of
117 transient numeric identifiers have affected protocol
118 implementations for an extremely long period of time.
120 o Such vulnerabilities, even when addressed for a given protocol
121 version, were later reintroduced in new versions or new
122 implementations of the same protocol.
124 o Standardization efforts that discuss and provide advice in this
125 area can have a positive effect on protocol specifications and
126 protocol implementations.
128 While it is generally possible to identify an algorithm that can
129 satisfy the interoperability requirements for a given transient
130 numeric identifier, this document provides empirical evidence that
131 doing so without negatively affecting the security or privacy
132 properties of the aforementioned protocols is non-trivial. Other
133 related documents ([I-D.irtf-pearg-numeric-ids-generation] and
134 [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this
135 area, as motivated by the present document.
137 2. Terminology
139 Transient Numeric Identifier:
140 A data object in a protocol specification that can be used to
141 definitely distinguish a protocol object (a datagram, network
142 interface, transport protocol endpoint, session, etc) from all
143 other objects of the same type, in a given context. Transient
144 numeric identifiers are usually defined as a series of bits, and
145 represented using integer values. These identifiers are typically
146 dynamically selected, as opposed to statically-assigned numeric
147 identifiers (see e.g. [IANA-PROT]). We note that different
148 identifiers may have additional requirements or properties
149 depending on their specific use in a protocol. We use the term
150 "transient numeric identifier" (or simply "numeric identifier" or
151 "identifier" as short forms) as a generic term to refer to any
152 data object in a protocol specification that satisfies the
153 identification property stated above.
155 The terms "constant IID", "stable IID", and "temporary IID" are to be
156 interpreted as defined in [RFC7721].
158 3. Threat Model
160 Throughout this document, we assume an attacker does not have
161 physical or logical access to the device(s) being attacked, and does
162 not have access to the packets being transferred between the sender
163 and the receiver(s) of the target protocol (if any). However, we
164 assume the attacker can send any traffic to the target device(s), to
165 e.g. sample transient numeric identifiers employed by such device(s).
167 4. Issues with the Specification of Transient Numeric Identifiers
169 While assessing protocol specifications regarding the use of
170 transient numeric identifiers, we have found that most of the issues
171 discussed in this document arise as a result of one of the following
172 conditions:
174 o Protocol specifications that under-specify the requirements for
175 their transient numeric identifiers
177 o Protocol specifications that over-specify their transient numeric
178 identifiers
180 o Protocol implementations that simply fail to comply with the
181 specified requirements
183 A number of protocol specifications (too many of them) have simply
184 overlooked the security and privacy implications of transient numeric
185 identifiers. Examples of them are the specification of TCP ephemeral
186 ports in [RFC0793], the specification of TCP sequence numbers in
187 [RFC0793], or the specification of the DNS TxID in [RFC1035].
189 On the other hand, there are a number of protocol specifications that
190 over-specify some of their associated transient numeric identifiers.
192 For example, [RFC4291] essentially overloads the semantics of IPv6
193 Interface Identifiers (IIDs) by embedding link-layer addresses in the
194 IPv6 IIDs, when the interoperability requirement of uniqueness could
195 be achieved in other ways that do not result in negative security and
196 privacy implications [RFC7721]. Similarly, [RFC2460] suggested the
197 use of a global counter for the generation of Fragment Identification
198 values, when the interoperability properties of uniqueness per {Src
199 IP, Dst IP} could be achieved with other algorithms that do not
200 result in negative security and privacy implications [RFC7739].
202 Finally, there are protocol implementations that simply fail to
203 comply with existing protocol specifications. For example, some
204 popular operating systems (notably Microsoft Windows) still fail to
205 implement transport protocol ephemeral port randomization, as
206 recommended in [RFC6056].
208 5. IPv4/IPv6 Identification
210 This section presents the timeline of the Identification field
211 employed by IPv4 (in the base header) and IPv6 (in Fragment Headers).
212 The reason for presenting both cases in the same section is to make
213 it evident that while the Identification value serves the same
214 purpose in both IPv4 and IPv6, the work and research done for the
215 IPv4 case did not affect IPv6 specifications or implementations.
217 The IPv4 Identification is specified in [RFC0791], which specifies
218 the interoperability requirements for the Identification field: the
219 sender must choose the Identification field to be unique for a given
220 source address, destination address, and protocol, for the time the
221 datagram (or any fragment of it) could be alive in the internet. It
222 suggests that a node may keep "a table of Identifiers, one entry for
223 each destination it has communicated with in the last maximum packet
224 lifetime for the internet", and suggests that "since the Identifier
225 field allows 65,536 different values, hosts may be able to simply use
226 unique identifiers independent of destination". The above has been
227 interpreted numerous times as a suggestion to employ per-destination
228 or global counters for the generation of Identification values.
229 While [RFC0791] does not suggest any flawed algorithm for the
230 generation of Identification values, the specification omits a
231 discussion of the security and privacy implications of predictable
232 Identification values. This has resulted in many IPv4
233 implementations generating predictable fragment Identification values
234 by means of a global counter, at least at some point in time.
236 The IPv6 Identification was originally specified in [RFC1883]. It
237 serves the same purpose as its IPv4 counterpart, with the only
238 difference residing in the length of the corresponding field, and
239 that while the IPv4 Identification field is part of the base IPv4
240 header, in the IPv6 case it is part of the Fragment header (which may
241 or may not be present in an IPv6 packet). [RFC1883] states, in
242 Section 4.5, that the Identification must be different than that of
243 any other fragmented packet sent recently (within the maximum likely
244 lifetime of a packet) with the same Source Address and Destination
245 Address. Subsequently, it notes that this requirement can be met by
246 means of a wrap-around 32-bit counter that is incremented each time a
247 packet must be fragmented, and that it is an implementation choice
248 whether to use a global or a per-destination counter. Thus, the
249 implementation of the IPv6 Identification is similar to that of the
250 IPv4 case, with the only difference that in the IPv6 case the
251 suggestions to use simple counters is more explicit. [RFC2460] was
252 the first revision of the core IPv6 specification, and maintained the
253 same text for the specification of the IPv6 Identification field.
254 [RFC8200], the second revision of the core IPv6 specification,
255 removes the suggestion from [RFC2460] to use a counter for the
256 generation of IPv6 Identification values, and points to [RFC7739] for
257 sample algorithms for their generation.
259 September 1981:
260 [RFC0791] specifies the interoperability requirements for IPv4
261 Identification value, but does not perform a vulnerability
262 assessment of this transient numeric identifier.
264 December 1995:
265 [RFC1883], the first specification of the IPv6 protocol, is
266 published. It suggests that a counter be used to generate the
267 IPv6 Identification value, and notes that it is an implementation
268 choice whether to maintain a single counter for the node or
269 multiple counters, e.g., one for each of the node's possible
270 source addresses, or one for each active (source address,
271 destination address) combination.
273 December 1998:
274 [Sanfilippo1998a] finds that predictable IPv4 Identification
275 values (generated by most popular implementations) can be
276 leveraged to count the number of packets sent by a target node.
277 [Sanfilippo1998b] explains how to leverage the same vulnerability
278 to implement a port-scanning technique known as dumb/idle scan. A
279 tool that implements this attack is publicly released.
281 December 1998:
282 [RFC2460], a revision of the IPv6 specification, is published,
283 obsoleting [RFC1883]. It maintains the same specification of the
284 IPv6 Identification field as its predecessor ([RFC1883]).
286 November 1999:
288 [Sanfilippo1999] discusses how to leverage predictable IPv4
289 Identification to uncover the rules of a number of firewalls.
291 December 1998:
292 OpenBSD implements randomization of the IPv4 Identification field
293 [OpenBSD-IPv4-ID]. This feature eventually shipped with OpenBSD
294 2.5.
296 November 1999:
297 [Bellovin2002] explains how the IPv4 Identification field can be
298 exploited to count the number of systems behind a NAT.
300 September 2002:
301 [Fyodor2002] explains how to implement a stealth port-scanning
302 technique by leveraging nodes that employ predictable IPv4
303 Identification values.
305 October 2003:
306 OpenBSD implements randomization of the IPv6 Identification field
307 [OpenBSD-IPv6-ID]. This feature eventually shipped with OpenBSD
308 3.4.
310 December 2003:
311 [Zalewski2003] explains a technique to perform TCP data injection
312 attack based on predictable IPv4 identification values which
313 requires less effort than TCP injection attacks performed with
314 bare TCP packets.
316 November 2005:
317 [Silbersack2005] discusses shortcoming in a number of techniques
318 to mitigate predictable IPv4 Identification values.
320 October 2007:
321 [Klein2007] describes a weakness in the pseudo random number
322 generator (PRNG) in use for the generation of the IP
323 Identification by a number of operating systems.
325 June 2011:
326 [Gont2011] describes how to perform idle scan attacks in IPv6.
328 November 2011:
329 Linux mitigates predictable IPv6 Identification values
330 [RedHat2011] [SUSE2011] [Ubuntu2011].
332 December 2011:
333 [draft-gont-6man-predictable-fragment-id-00] describes the
334 security implications of predictable IPv6 Identification values,
335 and possible mitigations. This document is published on the
336 Standards Track, meaning to formally update [RFC2460], to
337 introduce security and privacy requirements on IPv6 Identification
338 values.
340 May 2012:
341 [Gont2012] notes that some major IPv6 implementations still employ
342 predictable IPv6 Identification values.
344 March 2013:
345 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but
346 changes the track to "BCP" (while still formally updating
347 [RFC2460]), publishing the resulting document as
348 [draft-ietf-6man-predictable-fragment-id-00].
350 June 2013:
351 A patch that implements IPv6-based idle-scan in nmap is submitted
352 [Morbitzer2013].
354 December 2014:
355 The 6man WG changes the status of
356 [draft-ietf-6man-predictable-fragment-id-01] to "Informational"
357 and publishes it as [draft-ietf-6man-predictable-fragment-id-02].
358 As a result, it no longer formally updates [RFC2460].
360 June 2015:
361 [draft-ietf-6man-predictable-fragment-id-08] notes that some
362 popular host and router implementations still employ predictable
363 IPv6 Identification values.
365 February 2016:
366 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id])
367 analyzes the security and privacy implications of predictable IPv6
368 Identification values, and provides guidance for selecting an
369 algorithm to generate such values. However, being published on
370 the Informational track, it does not formally update [RFC2460].
372 June 2016:
373 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the
374 suggestion from RFC2460 to use a counter for the generation of
375 IPv6 Identification values, but does not perform a vulnerability
376 analisys of the generation of IPv6 Identification values.
378 July 2017:
379 [I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200],
380 obsoleting [RFC2460], and pointing to [RFC7739] for sample
381 algorithms for the generation of IPv6 Fragment Identification
382 values.
384 June 2019:
385 [IPID-DEV] notes that the IPv6 ID generators of two popular
386 operating systems are flawed.
388 6. TCP Initial Sequence Numbers (ISNs)
390 [RFC0793] suggests that the choice of the ISN of a connection is not
391 arbitrary, but aims to reduce the chances of a stale segment from
392 being accepted by a new incarnation of a previous connection.
393 [RFC0793] suggests the use of a global 32-bit ISN generator that is
394 incremented by 1 roughly every 4 microseconds. However, as a matter
395 of fact, protection against stale segments from a previous
396 incarnation of the connection is enforced by preventing the creation
397 of a new incarnation of a previous connection before 2*MSL have
398 passed since a segment corresponding to the old incarnation was last
399 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This
400 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept
401 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are
402 monotonically increasing across connections, many stacks (e.g.,
403 4.2BSD-derived) use the ISN of an incoming SYN segment to perform
404 "heuristics" that enable the creation of a new incarnation of a
405 connection while the previous incarnation is still in the TIME-WAIT
406 state (see p. 945 of [Wright1994]). This avoids an interoperability
407 problem that may arise when a node establishes connections to a
408 specific TCP end-point at a high rate [Silbersack2005].
410 The interoperability requirements for TCP ISNs are probably not
411 clearly spelled out as one would expect. Furthermore, the suggestion
412 of employing a global counter in [RFC0793] negatively affects the
413 security and privacy properties of the protocol.
415 September 1981:
416 [RFC0793], suggests the use of a global 32-bit ISN generator,
417 whose lower bit is incremented roughly every 4 microseconds.
418 However, such an ISN generator makes it trivial to predict the ISN
419 that a TCP will use for new connections, thus allowing a variety
420 of attacks against TCP.
422 February 1985:
423 [Morris1985] was the first to describe how to exploit predictable
424 TCP ISNs for forging TCP connections that could then be leveraged
425 for trust relationship exploitation.
427 April 1989:
428 [Bellovin1989] discussed the security considerations for
429 predictable ISNs (along with a range of other protocol-based
430 vulnerabilities).
432 February 1995:
433 [Shimomura1995] reported a real-world exploitation of the attack
434 described in 1985 (ten years before) in [Morris1985].
436 May 1996:
437 [RFC1948] was the first IETF effort, authored by Steven Bellovin,
438 to address predictable TCP ISNs. The same concept specified in
439 this document for TCP ISNs was later proposed for TCP ephemeral
440 ports [RFC6056], TCP Timestamps, and eventually even IPv6
441 Interface Identifiers [RFC7217].
443 July 1996:
444 OpenBSD implements TCP ISN randomization based on random
445 increments (please see Appendix A.2 of
446 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-I]. The
447 feature eventually shipped with OpenBSD 2.0.
449 December 2000:
450 OpenBSD implements TCP ISN randomization using simple
451 randomization (please see Section 7.1 of
452 [I-D.irtf-pearg-numeric-ids-generation]) [OpenBSD-TCP-ISN-R]. The
453 feature eventually shipped with OpenBSD 2.9.
455 March 2001:
456 [Zalewski2001] provides a detailed analysis of statistical
457 weaknesses in some ISN generators, and includes a survey of the
458 algorithms in use by popular TCP implementations.
460 May 2001:
461 Vulnerability advisories [CERT2001] [USCERT2001] are released
462 regarding statistical weaknesses in some ISN generators, affecting
463 popular TCP/IP implementations.
465 March 2002:
466 [Zalewski2002] updates and complements [Zalewski2001]. It
467 concludes that "while some vendors [...] reacted promptly and
468 tested their solutions properly, many still either ignored the
469 issue and never evaluated their implementations, or implemented a
470 flawed solution that apparently was not tested using a known
471 approach" [Zalewski2002].
473 June 2007:
474 OpenBSD implements TCP ISN randomization based on the algorithm
475 specified in [RFC1948] (currently obsoleted by [RFC6528]) for the
476 TCP endpoint that performs the active open, while keeping the
477 simple randomization scheme for the endpoint performing the
478 passive open [OpenBSD-TCP-ISN-H]. This provides monotonically-
479 increasing ISNs for the client side (allowing the BSD heuristics
480 to work as expexted), while avoiding any patterns in the ISN
481 generation for the server side. This feature eventually shipped
482 with OpenBSD 4.2.
484 February 2012:
485 [RFC6528], after 27 years of Morris' original work [Morris1985],
486 formally updates [RFC0793] to mitigate predictable TCP ISNs.
488 August 2014:
489 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP
490 protocol specification, incorporates the algorithm specified in
491 [RFC6528] as the recommended algorithm for TCP ISN generation.
493 7. IPv6 Interface Identifiers (IIDs)
495 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC
496 [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section
497 focuses on Interface Identifiers resulting from SLAAC.
499 The Interface Identifier of stable (traditional) IPv6 addresses
500 resulting from SLAAC have traditionally resulted in the underlying
501 link-layer address being embedded in the IID.At the time, employing
502 the underlying link-layer address for the IID was seen as a
503 convenient way to obtain a unique address. However, recent awareness
504 about the security and privacy properties of this approach [RFC7707]
505 [RFC7721] has led to the replacement of this flawed scheme with an
506 alternative one [RFC7217] [RFC8064] that does not negatively affect
507 the security and privacy properties of the protocol.
509 January 1997:
510 [RFC2073] specifies the syntax of IPv6 global addresses (referred
511 to as "An IPv6 Provider-Based Unicast Address Format" at the
512 time), consistent with the IPv6 addressing architecture specified
513 in [RFC1884]. Hosts are recommended to "generate addresses using
514 link-specific addresses as Interface ID such as 48 bit IEEE-802
515 MAC addresses".
517 July 1998:
518 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address
519 Format" (obsoleting [RFC2373]) changing the size of the Interface
520 ID to 64 bits, and specifies that that IIDs must be constructed in
521 IEEE EUI-64 format. How such identifiers are constructed becomes
522 specified in the appropriate "IPv6 over " specification such
523 as "IPv6 over Ethernet".
525 January 2001:
527 [RFC3041] recognizes the problem of network activity correlation,
528 and specifies temporary addresses. Temporary addresses are to be
529 used along with stable addresses.
531 August 2003:
532 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure
533 historic. The syntax and recommendations for the traditional
534 stable IIDs remain unchanged, though.
536 February 2006:
537 [RFC4291] is published as the latest "IP Version 6 Addressing
538 Architecture", requiring the IIDs of the traditional (stable)
539 autoconfigured addresses to employ the Modified EUI-64 format.
540 The details of constructing such interface identifiers are defined
541 in the appropriate "IPv6 over " specifications.
543 March 2008:
544 [RFC5157] provides hints regarding how patterns in IPv6 addresses
545 could be leveraged for the purpose of address scanning.
547 December 2011:
548 [draft-gont-6man-stable-privacy-addresses-00] notes that the
549 traditional scheme for generating stable addresses allows for
550 address scanning, and also does not prevent active node tracking.
551 It also specifies an alternative algorithm meant to replace IIDs
552 based on Modified EUI-64 format identifiers.
554 November 2012:
555 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a
556 working group item (as
557 [draft-ietf-6man-stable-privacy-addresses-00]). However, the
558 specified algorithm no longer formally replaces the Modified
559 EUI-64 format identifiers.
561 February 2013:
562 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages
563 IPv6 address patterns is released [Gont2013].
565 July 2013:
566 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on
567 the security and privacy properties of all known algorithms for
568 generating IPv6 IIDs.
570 January 2014:
571 The 6man WG publishes [draft-ietf-6man-default-iids-00]
572 ("Recommendation on Stable IPv6 Interface Identifiers"),
573 recommending [I-D.ietf-6man-stable-privacy-addresses] for the
574 generation of stable addresses.
576 April 2014:
577 [RFC7217] is published, specifying "A Method for Generating
578 Semantically Opaque Interface Identifiers with IPv6 Stateless
579 Address Autoconfiguration (SLAAC)" as an alternative to (but *not*
580 replacement of) Modified EUI-64 format IIDs.
582 March 2016:
583 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning] and later
584 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network
585 Reconnaissance in IPv6 Networks", is published.
587 March 2016:
588 [RFC7721] (formerly
589 [I-D.cooper-6man-ipv6-address-generation-privacy] and later
590 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security
591 and Privacy Considerations for IPv6 Address Generation
592 Mechanisms", is published.
594 May 2016:
595 [draft-gont-6man-non-stable-iids-00] is published, with the goal
596 of specifying requirements for non-stable addresses, and updating
597 [RFC4941] such that use of only temporary addresses is allowed.
599 May 2016:
600 [draft-gont-6man-address-usage-recommendations-00] is published,
601 providing an analysis of how different aspects on an address (from
602 stability to usage mode) affect their corresponding security and
603 privacy properties, and meaning to eventually provide advice in
604 this area.
606 February 2017:
607 The 6man WG publishes [RFC8064] ("Recommendation on Stable IPv6
608 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]),
609 with requirements for stable addresses and a recommendation to
610 employ [RFC7217] for the generation of stable addresses. It
611 formally updated a large number of RFCs.
613 March 2018:
614 [draft-fgont-6man-rfc4941bis-00] is published (as suggested by the
615 6man WG), to address flaws in [RFC4941] by revising it (as an
616 alternative to the [draft-gont-6man-non-stable-iids-00] effort,
617 published in March 2016).
619 July 2018:
620 [draft-ietf-6man-rfc4941bis-00] is adopted (as
621 [draft-fgont-6man-rfc4941bis-00]) as a WG item of the 6man WG.
623 March 2020:
625 [I-D.ietf-6man-rfc4941bis] passes WGLC.
627 December 2020:
628 [I-D.ietf-6man-rfc4941bis] is finally approved by the IESG for
629 publication as an RFC.
631 8. NTP Reference IDs (REFIDs)
633 NTP [RFC5905] Reference IDs are employed to avoid degree-one timing
634 loops in scenarios where two NTP peers are (mutually) the time source
635 of each other.
637 June 2010:
638 [RFC5905], "Network Time Protocol Version 4: Protocol and
639 Algorithms Specification" is published. It specifies that for NTP
640 peers with stratum higher than 1 the REFID embeds the IPv4 Address
641 of the time source or an MD5 hash of the IPv6 address of the time
642 source.
644 July 2016:
645 [draft-stenn-ntp-not-you-refid-00] is published, describing the
646 information leakage produced via de NTP REFID. It proposes that
647 NTP returns a special REFID when a packet employs an IP Source
648 Address that is not believed to be a current NTP peer, but
649 otherwise generates and returns the traditional REFID. It is
650 subsequently adopted by the NTP WG as
651 [I-D.ietf-ntp-refid-updates].
653 April 2019:
654 [Gont-NTP] notes that the proposed fix specified in
655 [draft-ietf-ntp-refid-updates-00] is, at the very least, sub-
656 optimal.
658 9. Transport Protocol Ephemeral Port Numbers
660 Most (if not all) transport protocols employ "port numbers" to
661 demultiplex packets to the corresponding transport protocol
662 instances.
664 August 1980:
665 [RFC0768] notes that the UDP source port is optional and
666 identifies the port of the sending process. It does not specify
667 interoperability requirements for source port selection, nor does
668 it suggest possible ways to select port numbers. Most popular
669 implementations end up selecting source ports from a system-wide
670 global counter.
672 September 1981:
674 [RFC0793] (the TCP specification) essentially describes the use of
675 port numbers, and specifies that port numbers should result in a
676 unique socket pair (local address, local port, remote address,
677 remote port). How ephemeral ports (i.e. port numbers for "active
678 opens") are selected, and the port range from which they are
679 selected, are left unspecified.
681 July 1996:
682 OpenBSD implements ephemeral port randomization [OpenBSD-PR]. The
683 feature eventually shipped with OpenBSD 2.0.
685 January 2009:
686 [RFC5452] mandates the use of port randomization for DNS
687 resolvers, and mandates that implementations must randomize ports
688 from the range (53 or 1024, and above) or the largest possible
689 port range. It does not recommend possible algorithms for port
690 randomization, although the document specifically targets DNS
691 resolvers, for which a simple port randomization suffices (e.g.
692 Algorithm 1 of [RFC6056]). This document led to the
693 implementation of port randomization in the DNS resolver
694 themselves, rather than in the underlying transport-protocols.
696 January 2011:
697 [RFC6056] notes that many TCP and UDP implementations result in
698 predictable port numbers, and also notes that many implementations
699 select port numbers from a small portion of the whole port number
700 space. It recommends the implementation and use of ephemeral port
701 randomization, proposes a number of possible algorithms for port
702 randomization, and also recommends to randomize port numbers over
703 the range 1024-65535.
705 March 2016:
706 [NIST-NTP] reports a non-normal distribution of the ephemeral port
707 numbers employed by the NTP clients of an Internet Time Service.
709 April 2019:
710 [I-D.gont-ntp-port-randomization] notes that some NTP
711 implementations employ the NTP service port (123) as the local
712 port for non-symmetric modes, and aims to update the NTP
713 specification to recommend port randomization in such cases, in
714 line with [RFC6056]. The proposal experiences some push-back in
715 the relevant working group (NTP WG) [NTP-PORTR], but is finally
716 adopted as a working group item as
717 [I-D.ietf-ntp-port-randomization].
719 September 2019:
720 [I-D.ietf-ntp-port-randomization] passes its WGLC.
722 10. IANA Considerations
724 There are no IANA registries within this document. The RFC-Editor
725 can remove this section before publication of this document as an
726 RFC.
728 11. Security Considerations
730 This document analyzes the timeline of the specification and
731 implementation of the transient numeric identifiers of some sample
732 IETF protocols, and how the security and privacy properties of such
733 protocols have been affected as a result of it. It provides concrete
734 evidence that advice in this area is warranted.
736 [I-D.gont-numeric-ids-sec-considerations] formally requires protocol
737 specifications to specify the interoperability requirements for their
738 transient numeric identifiers, to do a warranted vulnerability
739 assessment of such transient numeric identifiers, and to recommend
740 possible algorithms for their generation, such that the
741 interoperability requirements are complied with, while any negative
742 security and privacy properties of these transient numeric
743 identifiers are mitigated.
745 [I-D.irtf-pearg-numeric-ids-generation] analyzes and categorizes
746 transient numeric identifiers based on their interoperability
747 requirements and their associated failure modes, and recommends
748 possible algorithms that can comply with those requirements without
749 negatively affecting the security and privacy properties of the
750 corresponding protocols.
752 12. Acknowledgements
754 The authors would like to thank (in alphabetical order) Bernard
755 Aboba, Dave Crocker, Theo de Raadt, Guillermo Gont, Christian
756 Huitema, Kris Shrishak, Joe Touch, and Christopher Wood, for
757 providing valuable comments on earlier versions of this document.
759 The authors would like to thank (in alphabetical order) Steven
760 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for
761 providing valuable comments on [I-D.gont-predictable-numeric-ids], on
762 which this document is based.
764 Section 6 of this document borrows text from [RFC6528], authored by
765 Fernando Gont and Steven Bellovin.
767 The authors would like to thank Christopher Wood for his guidance
768 during the publication process of this document.
770 The authors would like to thank Diego Armando Maradona for his magic
771 and inspiration.
773 13. References
775 13.1. Normative References
777 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
778 DOI 10.17487/RFC0768, August 1980,
779 .
781 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
782 DOI 10.17487/RFC0791, September 1981,
783 .
785 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
786 RFC 793, DOI 10.17487/RFC0793, September 1981,
787 .
789 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
790 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
791 1992, .
793 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
794 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883,
795 December 1995, .
797 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
798 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
799 December 1995, .
801 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J.
802 Postel, "An IPv6 Provider-Based Unicast Address Format",
803 RFC 2073, DOI 10.17487/RFC2073, January 1997,
804 .
806 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
807 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
808 .
810 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6
811 Aggregatable Global Unicast Address Format", RFC 2374,
812 DOI 10.17487/RFC2374, July 1998,
813 .
815 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
816 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
817 December 1998, .
819 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
820 Stateless Address Autoconfiguration in IPv6", RFC 3041,
821 DOI 10.17487/RFC3041, January 2001,
822 .
824 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
825 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
826 August 2003, .
828 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
829 Architecture", RFC 4291, DOI 10.17487/RFC4291, February
830 2006, .
832 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
833 Address Autoconfiguration", RFC 4862,
834 DOI 10.17487/RFC4862, September 2007,
835 .
837 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
838 Extensions for Stateless Address Autoconfiguration in
839 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
840 .
842 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
843 Resilient against Forged Answers", RFC 5452,
844 DOI 10.17487/RFC5452, January 2009,
845 .
847 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
848 Protocol Port Randomization", BCP 156, RFC 6056,
849 DOI 10.17487/RFC6056, January 2011,
850 .
852 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
853 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
854 2012, .
856 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
857 Interface Identifiers with IPv6 Stateless Address
858 Autoconfiguration (SLAAC)", RFC 7217,
859 DOI 10.17487/RFC7217, April 2014,
860 .
862 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
863 (IPv6) Specification", STD 86, RFC 8200,
864 DOI 10.17487/RFC8200, July 2017,
865 .
867 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
868 Richardson, M., Jiang, S., Lemon, T., and T. Winters,
869 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
870 RFC 8415, DOI 10.17487/RFC8415, November 2018,
871 .
873 13.2. Informative References
875 [Bellovin1989]
876 Bellovin, S., "Security Problems in the TCP/IP Protocol
877 Suite", Computer Communications Review, vol. 19, no. 2,
878 pp. 32-48, 1989,
879 .
881 [Bellovin2002]
882 Bellovin, S., "A Technique for Counting NATted Hosts",
883 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.
885 [CERT2001]
886 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in
887 TCP/IP Initial Sequence Numbers", 2001,
888 .
890 [draft-fgont-6man-rfc4941bis-00]
891 Gont, F., Krishnan, S., Narten, T., and R. Draves,
892 "Privacy Extensions for Stateless Address
893 Autoconfiguration in IPv6", draft-fgont-6man-rfc4941bis-00
894 (work in progress), March 2018.
896 [draft-gont-6man-address-usage-recommendations-00]
897 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations",
898 draft-gont-6man-address-usage-recommendations-00 (work in
899 progress), May 2016.
901 [draft-gont-6man-non-stable-iids-00]
902 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6
903 Interface Identifiers", draft-gont-6man-non-stable-iids-00
904 (work in progress), May 2016.
906 [draft-gont-6man-predictable-fragment-id-00]
907 Gont, F., "Security Implications of Predictable Fragment
908 Identification Values", draft-gont-6man-predictable-
909 fragment-id-00 (work in progress), December 2011.
911 [draft-gont-6man-stable-privacy-addresses-00]
912 Gont, F., "A method for Generating Stable Privacy-Enhanced
913 Addresses with IPv6 Stateless Address Autoconfiguration
914 (SLAAC)", draft-gont-6man-stable-privacy-addresses-00
915 (work in progress), December 2011.
917 [draft-ietf-6man-default-iids-00]
918 Gont, F., Cooper, A., Thaler, D., and W. Liu,
919 "Recommendation on Stable IPv6 Interface Identifiers",
920 draft-ietf-6man-default-iids-00 (work in progress), July
921 2014.
923 [draft-ietf-6man-predictable-fragment-id-00]
924 Gont, F., "Security Implications of Predictable Fragment
925 Identification Values", draft-ietf-6man-predictable-
926 fragment-id-00 (work in progress), March 2013.
928 [draft-ietf-6man-predictable-fragment-id-01]
929 Gont, F., "Security Implications of Predictable Fragment
930 Identification Values", draft-ietf-6man-predictable-
931 fragment-id-01 (work in progress), April 2014.
933 [draft-ietf-6man-predictable-fragment-id-02]
934 Gont, F., "Security Implications of Predictable Fragment
935 Identification Values", draft-ietf-6man-predictable-
936 fragment-id-02 (work in progress), December 2014.
938 [draft-ietf-6man-predictable-fragment-id-08]
939 Gont, F., "Security Implications of Predictable Fragment
940 Identification Values", draft-ietf-6man-predictable-
941 fragment-id-08 (work in progress), June 2015.
943 [draft-ietf-6man-rfc4941bis-00]
944 Gont, F., Krishnan, S., Narten, T., and R. Draves,
945 "Privacy Extensions for Stateless Address
946 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-00
947 (work in progress), July 2018.
949 [draft-ietf-6man-stable-privacy-addresses-00]
950 Gont, F., "A method for Generating Stable Privacy-Enhanced
951 Addresses with IPv6 Stateless Address Autoconfiguration
952 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00
953 (work in progress), May 2012.
955 [draft-ietf-ntp-refid-updates-00]
956 Goldberg, S. and H. Stenn, "Network Time Protocol Not You
957 REFID", draft-ietf-ntp-refid-updates-00 (work in
958 progress), November 2016.
960 [draft-stenn-ntp-not-you-refid-00]
961 Goldberg, S. and S. KrishnansTENN, "Network Time Protocol
962 Not You REFID", draft-stenn-ntp-not-you-refid-00 (work in
963 progress), July 2016.
965 [Fyodor2002]
966 Fyodor, "Idle scanning and related IP ID games", 2002,
967 .
969 [Gont-NTP]
970 Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates-
971 05", Post to the NTP WG mailing list Message-ID:
972 ,
973 April 2019, .
976 [Gont2011]
977 Gont, F., "Hacking IPv6 Networks (training course)", Hack
978 In Paris 2011 Conference Paris, France, June 2011.
980 [Gont2012]
981 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012
982 Conference Ottawa, Canada. May 11-12, 2012, May 2012.
984 [Gont2013]
985 Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit
986 (help wanted!)", Message posted to the IPv6 Hackers
987 mailing-list Message-ID:
988 <51184548.3030105@si6networks.com>, 1995,
989 .
992 [I-D.cooper-6man-ipv6-address-generation-privacy]
993 Cooper, A., Gont, F., and D. Thaler, "Privacy
994 Considerations for IPv6 Address Generation Mechanisms",
995 draft-cooper-6man-ipv6-address-generation-privacy-00 (work
996 in progress), July 2013.
998 [I-D.eddy-rfc793bis-04]
999 Eddy, W., "Transmission Control Protocol Specification",
1000 draft-eddy-rfc793bis-04 (work in progress), August 2014.
1002 [I-D.gont-6man-predictable-fragment-id]
1003 Gont, F., "Security Implications of Predictable Fragment
1004 Identification Values", draft-gont-6man-predictable-
1005 fragment-id-03 (work in progress), January 2013.
1007 [I-D.gont-6man-stable-privacy-addresses]
1008 Gont, F., "A method for Generating Stable Privacy-Enhanced
1009 Addresses with IPv6 Stateless Address Autoconfiguration
1010 (SLAAC)", draft-gont-6man-stable-privacy-addresses-01
1011 (work in progress), March 2012.
1013 [I-D.gont-ntp-port-randomization]
1014 Gont, F. and G. Gont, "Port Randomization in the Network
1015 Time Protocol Version 4", draft-gont-ntp-port-
1016 randomization-04 (work in progress), August 2019.
1018 [I-D.gont-numeric-ids-sec-considerations]
1019 Gont, F. and I. Arce, "Security Considerations for
1020 Transient Numeric Identifiers Employed in Network
1021 Protocols", draft-gont-numeric-ids-sec-considerations-06
1022 (work in progress), December 2020.
1024 [I-D.gont-opsec-ipv6-host-scanning]
1025 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
1026 Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in
1027 progress), October 2012.
1029 [I-D.gont-predictable-numeric-ids]
1030 Gont, F. and I. Arce, "Security and Privacy Implications
1031 of Numeric Identifiers Employed in Network Protocols",
1032 draft-gont-predictable-numeric-ids-03 (work in progress),
1033 March 2019.
1035 [I-D.ietf-6man-default-iids]
1036 Gont, F., Cooper, A., Thaler, D., and S. LIU,
1037 "Recommendation on Stable IPv6 Interface Identifiers",
1038 draft-ietf-6man-default-iids-16 (work in progress),
1039 September 2016.
1041 [I-D.ietf-6man-ipv6-address-generation-privacy]
1042 Cooper, A., Gont, F., and D. Thaler, "Privacy
1043 Considerations for IPv6 Address Generation Mechanisms",
1044 draft-ietf-6man-ipv6-address-generation-privacy-08 (work
1045 in progress), September 2015.
1047 [I-D.ietf-6man-predictable-fragment-id]
1048 Gont, F., "Security Implications of Predictable Fragment
1049 Identification Values", draft-ietf-6man-predictable-
1050 fragment-id-10 (work in progress), October 2015.
1052 [I-D.ietf-6man-rfc2460bis]
1053 Deering, S. and R. Hinden, "Internet Protocol, Version 6
1054 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work
1055 in progress), May 2017.
1057 [I-D.ietf-6man-rfc4941bis]
1058 Gont, F., Krishnan, S., Narten, T., and R. Draves,
1059 "Temporary Address Extensions for Stateless Address
1060 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-12
1061 (work in progress), November 2020.
1063 [I-D.ietf-6man-stable-privacy-addresses]
1064 Gont, F., "A Method for Generating Semantically Opaque
1065 Interface Identifiers with IPv6 Stateless Address
1066 Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
1067 privacy-addresses-17 (work in progress), January 2014.
1069 [I-D.ietf-ntp-port-randomization]
1070 Gont, F., Gont, G., and M. Lichvar, "Port Randomization in
1071 the Network Time Protocol Version 4", draft-ietf-ntp-port-
1072 randomization-06 (work in progress), September 2020.
1074 [I-D.ietf-ntp-refid-updates]
1075 Stenn, H. and S. Goldberg, "Network Time Protocol REFID
1076 Updates", draft-ietf-ntp-refid-updates-05 (work in
1077 progress), March 2019.
1079 [I-D.ietf-opsec-ipv6-host-scanning]
1080 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
1081 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in
1082 progress), August 2015.
1084 [I-D.irtf-pearg-numeric-ids-generation]
1085 Gont, F. and I. Arce, "On the Generation of Transient
1086 Numeric Identifiers", draft-irtf-pearg-numeric-ids-
1087 generation-04 (work in progress), December 2020.
1089 [IANA-PROT]
1090 IANA, "Protocol Registries",
1091 .
1093 [IPID-DEV]
1094 Klein, A. and B. Pinkas, "From IP ID to Device ID and
1095 KASLR Bypass (Extended Version)", June 2019,
1096 .
1098 [IPv6-Toolkit]
1099 SI6 Networks, "SI6 Networks' IPv6 Toolkit",
1100 .
1102 [Klein2007]
1103 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
1104 Predictable IP ID Vulnerability", 2007,
1105 .
1108 [Morbitzer2013]
1109 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message
1110 posted to the nmap-dev mailing-list, 2013,
1111 .
1113 [Morris1985]
1114 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
1115 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill,
1116 NJ, 1985,
1117 .
1119 [NIST-NTP]
1120 Sherman, J. and J. Levine, "Usage Analysis of the NIST
1121 Internet Time Service", Journal of Research of the
1122 National Institute of Standards and Technology Volume 121,
1123 March 2016, .
1125 [NTP-PORTR]
1126 Gont, F., "[Ntp] New rev of the NTP port randomization I-D
1127 (Fwd: New Version Notification for draft-gont-ntp-port-
1128 randomization-01.txt)", 2019,
1129 .
1132 [OpenBSD-IPv4-ID]
1133 OpenBSD, "Randomization of the IPv4 Identification field",
1134 December 1998,
1135 .
1138 [OpenBSD-IPv6-ID]
1139 OpenBSD, "Randomization of the IPv6 Identification field",
1140 October 2003,
1141 .
1144 [OpenBSD-PR]
1145 OpenBSD, "Implementation of port randomization", July
1146 1996, .
1149 [OpenBSD-TCP-ISN-H]
1150 OpenBSD, "Implementation of RFC1948 for TCP ISN
1151 randomization", December 2000,
1152 .
1155 [OpenBSD-TCP-ISN-I]
1156 OpenBSD, "Implementation of TCP ISN randomization based on
1157 random increments", July 1996,
1158 .
1161 [OpenBSD-TCP-ISN-R]
1162 OpenBSD, "Implementation of TCP ISN randomization based on
1163 simple randomization", December 2000,
1164 .
1167 [RedHat2011]
1168 RedHat, "RedHat Security Advisory RHSA-2011:1465-1:
1169 Important: kernel security and bug fix update", 2011,
1170 .
1172 [RFC1035] Mockapetris, P., "Domain names - implementation and
1173 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1174 November 1987, .
1176 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
1177 RFC 1948, DOI 10.17487/RFC1948, May 1996,
1178 .
1180 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
1181 RFC 5157, DOI 10.17487/RFC5157, March 2008,
1182 .
1184 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
1185 "Network Time Protocol Version 4: Protocol and Algorithms
1186 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
1187 .
1189 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol
1190 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
1191 .
1193 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
1194 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
1195 2014, .
1197 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
1198 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
1199 .
1201 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
1202 Considerations for IPv6 Address Generation Mechanisms",
1203 RFC 7721, DOI 10.17487/RFC7721, March 2016,
1204 .
1206 [RFC7739] Gont, F., "Security Implications of Predictable Fragment
1207 Identification Values", RFC 7739, DOI 10.17487/RFC7739,
1208 February 2016, .
1210 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
1211 "Recommendation on Stable IPv6 Interface Identifiers",
1212 RFC 8064, DOI 10.17487/RFC8064, February 2017,
1213 .
1215 [Sanfilippo1998a]
1216 Sanfilippo, S., "about the ip header id", Post to Bugtraq
1217 mailing-list, Mon Dec 14 1998,
1218 .
1220 [Sanfilippo1998b]
1221 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list,
1222 1998, .
1224 [Sanfilippo1999]
1225 Sanfilippo, S., "more ip id", Post to Bugtraq mailing-
1226 list, 1999,
1227 .
1229 [Schuba1993]
1230 Schuba, C., "ADDRESSING WEAKNESSES IN THE DOMAIN NAME
1231 SYSTEM PROTOCOL", 1993,
1232 .
1235 [Shimomura1995]
1236 Shimomura, T., "Technical details of the attack described
1237 by Markoff in NYT", Message posted in USENET's
1238 comp.security.misc newsgroup Message-ID:
1239 <3g5gkl$5j1@ariel.sdsc.edu>, 1995,
1240 .
1242 [Silbersack2005]
1243 Silbersack, M., "Improving TCP/IP security through
1244 randomization without sacrificing interoperability",
1245 EuroBSDCon 2005 Conference, 2005,
1246 .
1249 [SUSE2011]
1250 SUSE, "SUSE Security Announcement: Linux kernel security
1251 update (SUSE-SA:2011:046)", 2011,
1252 .
1255 [Ubuntu2011]
1256 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel
1257 vulnerabilities", 2011,
1258 .
1260 [USCERT2001]
1261 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple
1262 TCP/IP implementations may use statistically predictable
1263 initial sequence numbers", 2001,
1264 .
1266 [Wright1994]
1267 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
1268 The Implementation", Addison-Wesley, 1994.
1270 [Zalewski2001]
1271 Zalewski, M., "Strange Attractors and TCP/IP Sequence
1272 Number Analysis", 2001,
1273 .
1275 [Zalewski2002]
1276 Zalewski, M., "Strange Attractors and TCP/IP Sequence
1277 Number Analysis - One Year Later", 2001,
1278 .
1280 [Zalewski2003]
1281 Zalewski, M., "A new TCP/IP blind data injection
1282 technique?", 2003,
1283 .
1285 Authors' Addresses
1286 Fernando Gont
1287 SI6 Networks
1288 Evaristo Carriego 2644
1289 Haedo, Provincia de Buenos Aires 1706
1290 Argentina
1292 Phone: +54 11 4650 8472
1293 Email: fgont@si6networks.com
1294 URI: https://www.si6networks.com
1296 Ivan Arce
1297 Quarkslab
1299 Email: iarce@quarkslab.com
1300 URI: https://www.quarkslab.com