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