idnits 2.17.1
draft-gont-numeric-ids-history-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
-- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii)
Publication Limitation clause. If this document is intended for
submission to the IESG for publication, this constitutes an error.
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 doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (March 11, 2019) is 1874 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC4086' is defined on line 616, but no explicit
reference was found in the text
== Unused Reference: 'RFC6151' is defined on line 639, but no explicit
reference was found in the text
== Unused Reference: 'CPNI-TCP' is defined on line 671, but no explicit
reference was found in the text
== Unused Reference: 'Fyodor2004' is defined on line 726, but no explicit
reference was found in the text
== Unused Reference: 'Joncheray1995' is defined on line 826, but no
explicit reference was found in the text
== Unused Reference: 'RFC1035' is defined on line 852, but no explicit
reference was found in the text
== Unused Reference: 'RFC4963' is defined on line 860, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293)
** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323)
** 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 3315 (Obsoleted by RFC 8415)
** 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 (-04) exists of
draft-gont-numeric-ids-generation-02
== Outdated reference: A later version (-11) exists of
draft-gont-numeric-ids-sec-considerations-02
== Outdated reference: A later version (-03) exists of
draft-gont-predictable-numeric-ids-02
-- 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 (~~), 13 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group F. Gont
3 Internet-Draft SI6 Networks / UTN-FRH
4 Intended status: Informational I. Arce
5 Expires: September 12, 2019 Quarkslab
6 March 11, 2019
8 Unfortunate History of Transient Numeric Identifiers
9 draft-gont-numeric-ids-history-04
11 Abstract
13 This document performs an analysis of the security and privacy
14 implications of different types of "numeric identifiers" used in IETF
15 protocols, and tries to categorize them based on their
16 interoperability requirements and the associated failure severity
17 when such requirements are not met. It describes a number of
18 algorithms that have been employed in real implementations to meet
19 such requirements and analyzes their security and privacy properties.
20 Additionally, it provides advice on possible algorithms that could be
21 employed to satisfy the interoperability requirements of each
22 identifier type, while minimizing the security and privacy
23 implications, thus providing guidance to protocol designers and
24 protocol implementers. Finally, it provides recommendations for
25 future protocol specifications regarding the specification of the
26 aforementioned numeric identifiers.
28 Status of This Memo
30 This Internet-Draft is submitted in full conformance with the
31 provisions of BCP 78 and BCP 79.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF). Note that other groups may also distribute
35 working documents as Internet-Drafts. The list of current Internet-
36 Drafts is at https://datatracker.ietf.org/drafts/current/.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 This Internet-Draft will expire on September 12, 2019.
45 Copyright Notice
47 Copyright (c) 2019 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (https://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the Simplified BSD License.
60 This document may not be modified, and derivative works of it may not
61 be created, and it may not be published except as an Internet-Draft.
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
67 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 5
68 4. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . . . 5
69 5. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . . . 8
70 6. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . . . 9
71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
75 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
76 10.2. Informative References . . . . . . . . . . . . . . . . . 14
77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
79 1. Introduction
81 Network protocols employ a variety of numeric identifiers for
82 different protocol entities, ranging from DNS Transaction IDs (TxIDs)
83 to transport protocol numbers (e.g. TCP ports) or IPv6 Interface
84 Identifiers (IIDs). These identifiers usually have specific
85 properties that must be satisfied such that they do not result in
86 negative interoperability implications (e.g. uniqueness during a
87 specified period of time), and associated failure severities when
88 such properties are not met, ranging from soft to hard failures.
90 For more than 30 years, a large number of implementations of the TCP/
91 IP protocol suite have been subject to a variety of attacks, with
92 effects ranging from Denial of Service (DoS) or data injection, to
93 information leakage that could be exploited for pervasive monitoring
94 [RFC7528]. The root of these issues has been, in many cases, the
95 poor selection of identifiers in such protocols, usually as a result
96 of an insufficient or misleading specification. While it is
97 generally trivial to identify an algorithm that can satisfy the
98 interoperability requirements for a given identifier, there exists
99 practical evidence that doing so without negatively affecting the
100 security and/or privacy properties of the aforementioned protocols is
101 prone to error.
103 For example, implementations have been subject to security and/or
104 privacy issues resulting from:
106 o Predictable TCP Initial Sequence Numbers (ISNs) (see e.g.
107 [Morris1985])
109 o Predictable ephemeral transport protocol numbers (see e.g.
110 [RFC6056] and [Silbersack2005])
112 o Predictable IPv4 or IPv6 Fragment Identifiers (see e.g.
113 [RFC5722], [RFC6274], and [RFC7739])
115 o Predictable IPv6 IIDs (see e.g. [RFC7721] and [RFC7707])
117 o Predictable DNS TxIDs
119 Recent history indicate that when new protocols are standardized or
120 new protocol implementations are produced, the security and privacy
121 properties of the associated identifiers tend to be overlooked and
122 inappropriate algorithms to generate identifier values are either
123 suggested in the specification or selected by implementers.
125 This document contains a non-exhaustive timeline of vulnerability
126 disclosures related to some sample transient numeric identifiers and
127 other work that has led to advances in this area, with the goal of
128 illustrating that:
130 o Vulnerabilities related to how the values for some identifiers are
131 generated and assigned have affected implementations for an
132 extremely long period of time.
134 o Such vulnerabilities, even when addressed for a given protocol
135 version, were later reintroduced in new versions or new
136 implementations of the same protocol.
138 o Standardization efforts that discuss and provide advice in this
139 area can have a positive effect on protocol specifications and
140 protocol implementations.
142 Other related documents ([I-D.gont-numeric-ids-generation] and
143 [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this
144 area.
146 2. Terminology
148 Identifier:
149 A data object in a protocol specification that can be used to
150 definitely distinguish a protocol object (a datagram, network
151 interface, transport protocol endpoint, session, etc) from all
152 other objects of the same type, in a given context. Identifiers
153 are usually defined as a series of bits and represented using
154 integer values. We note that different identifiers may have
155 additional requirements or properties depending on their specific
156 use in a protocol. We use the term "identifier" as a generic term
157 to refer to any data object in a protocol specification that
158 satisfies the identification property stated above.
160 Failure Severity:
161 The consequences of a failure to comply with the interoperability
162 requirements of a given identifier. Severity considers the worst
163 potential consequence of a failure, determined by the system
164 damage and/or time lost to repair the failure. In this document
165 we define two types of failure severity: "soft" and "hard".
167 Hard Failure:
168 A hard failure is a non-recoverable condition in which a protocol
169 does not operate in the prescribed manner or it operates with
170 excessive degradation of service. For example, an established TCP
171 connection that is aborted due to an error condition constitutes,
172 from the point of view of the transport protocol, a hard failure,
173 since it enters a state from which normal operation cannot be
174 recovered.
176 Soft Failure:
177 A soft failure is a recoverable condition in which a protocol does
178 not operate in the prescribed manner but normal operation can be
179 resumed automatically in a short period of time. For example, a
180 simple packet-loss event that is subsequently recovered with a
181 retransmission can be considered a soft failure.
183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
185 document are to be interpreted as described in RFC 2119 [RFC2119].
187 3. Threat Model
189 Throughout this document, we assume an attacker does not have
190 physical or logical device to the device(s) being attacked. We
191 assume the attacker can simply send any traffic to the target
192 devices, to e.g. sample identifiers employed by such devices.
194 4. IPv4/IPv6 Identification
196 This section presents the timeline of the Identification field both
197 for IPv4 and for IPv6. The reason for presenting both cases in the
198 same section is so that it becomes evident that, while the
199 Identification value serves the same purpose in both IPv4 and IPv6,
200 the work and research done for the IPv4 case did not affect the IPv6
201 specifications or implementations.
203 The IPv4 Identification value is specified in [RFC0791], which
204 specifies the interoperability requirements for the Identification
205 field: the sender must choose the Identification field to be unique
206 for a given source address, destination address, and protocol for the
207 time the datagram (or any fragment of it) could be alive in the
208 internet. It suggests that a node may keep "a table of Identifiers,
209 one entry for each destination it has communicated with in the last
210 maximum packet lifetime for the internet", and suggests that "since
211 the Identifier field allows 65,536 different values, some host may be
212 able to simply use unique identifiers independent of destination".
213 The above may be read as a suggestion to employ per-destination or
214 global counters for the generation of Identification values. While
215 [RFC0791] does not suggest any flawed algorithm for the generation of
216 Identification values, it misses a discussion of the security and
217 privacy implications of employing predictable. This has resulted in
218 virtually all IP4 implementations generating predictable fragment
219 Identification values by means of a global counter, at least at some
220 point during the lifetime of such implementations.
222 The IPv6 Identification is specified in [RFC2460]. It serves the
223 same purpose as its IPv4 counterpart, with the only difference
224 residing in the length of the corresponding field, and that while the
225 IPv4 Identification field is part of the base IPv4 header, in the
226 IPv6 case it is part of the Fragment header (which may or may not be
227 present in an IPv6 packet). [RFC2460] states, in Section 4.5, that
228 the Identification must be different than that of any other
229 fragmented packet sent recently (within the maximum likely lifetime
230 of a packet) with the same Source Address and Destination Address.
231 Subsequently, it notes that this requirement can be met by means of a
232 wrap-around 32-bit counter that is incremented each time a packet
233 must be fragmented, and that it is an implementation choice whether
234 to use a global or a per-destination counter. Thus, the
235 implementation of the IPv6 Identification is similar to that of the
236 IPv4 case, with the only difference that in the IPv6 case the
237 suggestions to use simple counters is more explicit.
239 September 1981:
240 [RFC0791] specifies the interoperability requirements for IPv4
241 Identification value, but does not specify any requirements in the
242 area of security and privacy.
244 December 1998:
245 [Sanfilippo1998a] finds that predictable IPv4 Identification
246 values (generated by most popular implementations) can be
247 leveraged to count the number of packets sent by a target node.
248 [Sanfilippo1998b] explains how to leverage the same vulnerability
249 to implement a port-scanning technique known as dumb/idle scan. A
250 tool that implements this attack is publicly released.
252 December 1998:
253 [RFC2460] suggests that a global counter be used to generate the
254 IPv6 Identification value.
256 November 1999:
257 [Sanfilippo1999] discusses how to leverage predictable IPv4
258 Identification to uncover the rules of a number of firewalls.
260 November 1999:
261 [Bellovin2002] explains how the IPv4 Identification field can be
262 exploited to count the number of systems behind a NAT.
264 December 2003:
265 [Zalewski2003] explains a technique to perform TCP data injection
266 attack based on predictable IPv4 identification values which
267 requires less effort than TCP injection attacks performed with
268 bare TCP packets.
270 November 2005:
271 [Silbersack2005] discusses shortcoming in a number of techniques
272 to mitigate predictable IPv4 Identification values.
274 October 2007:
275 [Klein2007] describes a weakness in the pseudo random number
276 generator (PRNG) in use for the generation of the IP
277 Identification by a number of operating systems.
279 June 2011:
280 [Gont2011] describes how to perform idle scan attacks in IPv6.
282 November 2011:
284 Linux mitigates predictable IPv6 Identification values
285 [RedHat2011] [SUSE2011] [Ubuntu2011].
287 December 2011:
288 [draft-gont-6man-predictable-fragment-id-00] describes the
289 security implications of predictable IPv6 Identification values,
290 and possible mitigations. This document is published on the
291 Standards Track, meaning to formally update [RFC2460], to
292 introduce security and privacy requirements on IPv6 Identification
293 values.
295 May 2012:
296 [Gont2012] notes that some major IPv6 implementations still employ
297 predictable IPv6 Identification values.
299 March 2013:
300 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but
301 changes the track to "BCP" (while still formally updating
302 [RFC2460]), publishing the resulting document as
303 [draft-ietf-6man-predictable-fragment-id-00].
305 June 2013:
306 A patch that implements IPv6-based idle-scan in nmap is submitted
307 [Morbitzer2013].
309 December 2014:
310 The 6man WG changes the status of the aforementioned IETF Internet
311 Draft to "Informational" and publishes it as
312 [draft-ietf-6man-predictable-fragment-id-02]. As a result, it no
313 longer formally updates [RFC2460].
315 June 2015:
316 [draft-ietf-6man-predictable-fragment-id-08] notes that some
317 popular host and router implementations still employ predictable
318 IPv6 Identification values.
320 February 2016:
321 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id])
322 analyzes the security and privacy implications of predictable IPv6
323 Identification values, and provides guidance for selecting an
324 algorithm to generate such values. However, being published on
325 the Informational track, it does not formally update [RFC2460].
327 June 2016:
328 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the
329 suggestion from RFC2460 to employ a global counter for the
330 generation of IPv6 Identification values, but does not specify any
331 security and privacy requirements for the IPv6 Identification
332 value.
334 5. TCP Initial Sequence Numbers (ISNs)
336 [RFC0793] suggests that the choice of the ISN of a connection is not
337 arbitrary, but aims to reduce the chances of a stale segment from
338 being accepted by a new incarnation of a previous connection.
339 [RFC0793] suggests the use of a global 32-bit ISN generator that is
340 incremented by 1 roughly every 4 microseconds. However, as a matter
341 of fact, protection against stale segments from a previous
342 incarnation of the connection is enforced by preventing the creation
343 of a new incarnation of a previous connection before 2*MSL have
344 passed since a segment corresponding to the old incarnation was last
345 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This
346 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept
347 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are
348 monotonically increasing across connections, many stacks (e.g.,
349 4.2BSD-derived) use the ISN of an incoming SYN segment to perform
350 "heuristics" that enable the creation of a new incarnation of a
351 connection while the previous incarnation is still in the TIME-WAIT
352 state (see p. 945 of [Wright1994]). This avoids an interoperability
353 problem that may arise when a node establishes connections to a
354 specific TCP end-point at a high rate [Silbersack2005].
356 In the case of TCP, the interoperability requirements for the ISNs
357 are probably not clearly spelled out as one would expect.
358 Furthermore, the suggestion of employing a global counter in
359 [RFC0793] leads to negative security and privacy implications.
361 September 1981:
362 [RFC0793], suggests the use of a global 32-bit ISN generator,
363 whose lower bit is incremented roughly every 4 microseconds.
364 However, such an ISN generator makes it trivial to predict the ISN
365 that a TCP will use for new connections, thus allowing a variety
366 of attacks against TCP.
368 February 1985:
369 [Morris1985] was the first to describe how to exploit predictable
370 TCP ISNs for forging TCP connections that could then be leveraged
371 for trust relationship exploitation.
373 April 1989:
374 [Bellovin1989] discussed the security implications of predictable
375 ISNs (along with a range of other protocol-based vulnerabilities).
377 February 1995:
379 [Shimomura1995] reported a real-world exploitation of the attack
380 described in 1985 (ten years before) in [Morris1985].
382 May 1996:
383 [RFC1948] was the first IETF effort, authored by Steven Bellovin,
384 to address predictable TCP ISNs. The same concept specified in
385 this document for TCP ISNs was later proposed for TCP ephemeral
386 ports [RFC6056], TCP Timestamps, and eventually even IPv6
387 Interface Identifiers [RFC7217].
389 March 2001:
390 [Zalewski2001] provides a detailed analysis of statistical
391 weaknesses in some ISN generators, and includes a survey of the
392 algorithms in use by popular TCP implementations.
394 May 2001:
395 Vulnerability advisories [CERT2001] [USCERT2001] are released
396 regarding statistical weaknesses in some ISN generators, affecting
397 popular TCP/IP implementations.
399 March 2002:
400 [Zalewski2002] updates and complements [Zalewski2001]. It
401 concludes that "while some vendors [...] reacted promptly and
402 tested their solutions properly, many still either ignored the
403 issue and never evaluated their implementations, or implemented a
404 flawed solution that apparently was not tested using a known
405 approach" [Zalewski2002].
407 February 2012:
408 [RFC6528], after 27 years of Morris' original work [Morris1985],
409 formally updates [RFC0793] to mitigate predictable TCP ISNs.
411 August 2014:
412 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP
413 protocol specification, incorporates the algorithm specified in
414 [RFC6528] as the recommended algorithm for TCP ISN generation.
416 6. IPv6 Interface Identifiers (IIDs)
418 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC
419 [RFC4862], DHCPv6 [RFC3315], and manual configuration. This section
420 focuses on Interface Identifiers resulting from SLAAC.
422 The Interface Identifier of stable (traditional) IPv6 addresses
423 resulting from SLAAC have traditionally resulted in the underlying
424 link-layer address being embedded in the IID. IPv6 addresses
425 resulting from SLAAC are currently required to employ Modified EUI-64
426 format identifiers, which essentially embed the underlying link-layer
427 address of the corresponding network interface. At the time,
428 employing the underlying link-layer address for the IID was seen as a
429 convenient way to obtain a unique address. However, recent awareness
430 about the security and privacy implications of this approach, and
431 thus ongoing work [I-D.ietf-6man-default-iids] at the IETF is in the
432 process of addressing this problem.
434 January 1997:
435 [RFC2073] specifies the syntax of IPv6 global addresses (referred
436 to as "An IPv6 Provider-Based Unicast Address Format" at the
437 time), consistent with the IPv6 addressing architecture specified
438 in [RFC1884]. Hosts are recommended to "generate addresses using
439 link-specific addresses as Interface ID such as 48 bit IEEE-802
440 MAC addresses".
442 July 1998:
443 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address
444 Format" (obsoleting [RFC2373]) changing the size of the Interface
445 ID to 64 bits, and specifies that that IIDs must be constructed in
446 IEEE EUI-64 format. How such identifiers are constructed becomes
447 specified in the appropriate "IPv6 over " specification such
448 as "IPv6 over Ethernet".
450 January 2001:
451 [RFC3041] recognizes the problem of network activity correlation,
452 and specifies temporary addresses. Temporary addresses are to be
453 used along with stable addresses.
455 August 2003:
456 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure
457 historic. The syntax and recommendations for the traditional
458 stable IIDs remain unchanged, though.
460 February 2006:
461 [RFC4291] is published as the latest "IP Version 6 Addressing
462 Architecture", requiring the IIDs of the traditional (stable)
463 autoconfigured addresses to employ the Modified EUI-64 format.
464 The details of constructing such interface identifiers are defined
465 in the appropriate "IPv6 over " specifications.
467 March 2008:
468 [RFC5157] provides hints regarding how patterns in IPv6 addresses
469 could be leveraged for the purpose of address scanning.
471 December 2011:
472 [draft-gont-6man-stable-privacy-addresses-00] notes that the
473 traditional scheme for generating stable addresses allows for
474 address scanning, and also does not prevent active node tracking.
476 It also specifies an alternative algorithm meant to replace IIDs
477 based on Modified EUI-64 format identifiers.
479 November 2012:
480 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a
481 working group item (as
482 [draft-ietf-6man-stable-privacy-addresses-00]). However, the
483 specified algorithm no longer formally replaces the Modified
484 EUI-64 format identifiers.
486 February 2013:
487 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages
488 IPv6 address patterns is released [Gont2013].
490 July 2013:
491 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on
492 the security and privacy implications on all known algorithms for
493 generating IPv6 IIDs.
495 January 2014:
496 The 6man wg publishes [draft-ietf-6man-default-iids-00]
497 ("Recommendation on Stable IPv6 Interface Identifiers"),
498 recommending [I-D.ietf-6man-stable-privacy-addresses] for the
499 generation of stable addresses.
501 April 2014:
502 [RFC7217] is published, specifying "A Method for Generating
503 Semantically Opaque Interface Identifiers with IPv6 Stateless
504 Address Autoconfiguration (SLAAC)" as an alternative to (but *not*
505 replacement of) Modified EUI-64 format IIDs.
507 March 2016:
508 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning] and later
509 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network
510 Reconnaissance in IPv6 Networks", is published.
512 March 2016:
513 [RFC7721] (formerly
514 [I-D.cooper-6man-ipv6-address-generation-privacy] and later
515 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security
516 and Privacy Considerations for IPv6 Address Generation
517 Mechanisms", is published.
519 May 2016:
520 [draft-gont-6man-non-stable-iids-00] is published, with the goal
521 of specifying requirements for non-stable addresses, and updating
522 [RFC4941] such that use of only temporary addresses is allowed.
524 May 2016:
525 [draft-gont-6man-address-usage-recommendations-00] is published,
526 providing an analysis of how different aspects on an address (from
527 stability to usage mode) affect their corresponding security and
528 privacy implications, and meaning to eventually provide advice in
529 this area.
531 7. IANA Considerations
533 There are no IANA registries within this document. The RFC-Editor
534 can remove this section before publication of this document as an
535 RFC.
537 8. Security Considerations
539 The entire document is about the security and privacy implications of
540 transient numeric identifiers.
542 9. Acknowledgements
544 The authors would like to thank (in alphabetical order) Dave Crocker,
545 Christian Huitema, and Joe Touch, for providing valuable comments on
546 earlier versions of this document.
548 The authors would like to thank (in alphabetical order) Steven
549 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for
550 providing valuable comments on [I-D.gont-predictable-numeric-ids], on
551 which this document is based.
553 Section 5 of this document borrows text from [RFC7528], authored by
554 Fernando Gont and Steven Bellovin.
556 The authors would like to thank Diego Armando Maradona for his magic
557 and inspiration.
559 10. References
561 10.1. Normative References
563 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
564 DOI 10.17487/RFC0791, September 1981,
565 .
567 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
568 RFC 793, DOI 10.17487/RFC0793, September 1981,
569 .
571 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
572 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
573 1992, .
575 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6
576 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884,
577 December 1995, .
579 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J.
580 Postel, "An IPv6 Provider-Based Unicast Address Format",
581 RFC 2073, DOI 10.17487/RFC2073, January 1997,
582 .
584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
585 Requirement Levels", BCP 14, RFC 2119,
586 DOI 10.17487/RFC2119, March 1997,
587 .
589 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
590 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
591 .
593 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6
594 Aggregatable Global Unicast Address Format", RFC 2374,
595 DOI 10.17487/RFC2374, July 1998,
596 .
598 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
599 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
600 December 1998, .
602 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
603 Stateless Address Autoconfiguration in IPv6", RFC 3041,
604 DOI 10.17487/RFC3041, January 2001,
605 .
607 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
608 C., and M. Carney, "Dynamic Host Configuration Protocol
609 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
610 2003, .
612 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
613 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
614 August 2003, .
616 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
617 "Randomness Requirements for Security", BCP 106, RFC 4086,
618 DOI 10.17487/RFC4086, June 2005,
619 .
621 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
622 Architecture", RFC 4291, DOI 10.17487/RFC4291, February
623 2006, .
625 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
626 Address Autoconfiguration", RFC 4862,
627 DOI 10.17487/RFC4862, September 2007,
628 .
630 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
631 Extensions for Stateless Address Autoconfiguration in
632 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
633 .
635 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
636 RFC 5722, DOI 10.17487/RFC5722, December 2009,
637 .
639 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
640 for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
641 RFC 6151, DOI 10.17487/RFC6151, March 2011,
642 .
644 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
645 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
646 2012, .
648 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
649 Interface Identifiers with IPv6 Stateless Address
650 Autoconfiguration (SLAAC)", RFC 7217,
651 DOI 10.17487/RFC7217, April 2014,
652 .
654 10.2. Informative References
656 [Bellovin1989]
657 Bellovin, S., "Security Problems in the TCP/IP Protocol
658 Suite", Computer Communications Review, vol. 19, no. 2,
659 pp. 32-48, 1989,
660 .
662 [Bellovin2002]
663 Bellovin, S., "A Technique for Counting NATted Hosts",
664 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.
666 [CERT2001]
667 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in
668 TCP/IP Initial Sequence Numbers", 2001,
669 .
671 [CPNI-TCP]
672 Gont, F., "Security Assessment of the Transmission Control
673 Protocol (TCP)", United Kingdom's Centre for the
674 Protection of National Infrastructure (CPNI) Technical
675 Report, 2009, .
678 [draft-gont-6man-address-usage-recommendations-00]
679 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations",
680 draft-gont-6man-address-usage-recommendations-00 (work in
681 progress), May 2016.
683 [draft-gont-6man-non-stable-iids-00]
684 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6
685 Interface Identifiers", draft-gont-6man-non-stable-iids-00
686 (work in progress), May 2016.
688 [draft-gont-6man-predictable-fragment-id-00]
689 Gont, F., "Security Implications of Predictable Fragment
690 Identification Values", draft-gont-6man-predictable-
691 fragment-id-00 (work in progress), December 2011.
693 [draft-gont-6man-stable-privacy-addresses-00]
694 Gont, F., "A method for Generating Stable Privacy-Enhanced
695 Addresses with IPv6 Stateless Address Autoconfiguration
696 (SLAAC)", draft-gont-6man-stable-privacy-addresses-00
697 (work in progress), December 2011.
699 [draft-ietf-6man-default-iids-00]
700 Gont, F., Cooper, A., Thaler, D., and W. Liu,
701 "Recommendation on Stable IPv6 Interface Identifiers",
702 draft-ietf-6man-default-iids-00 (work in progress), July
703 2014.
705 [draft-ietf-6man-predictable-fragment-id-00]
706 Gont, F., "Security Implications of Predictable Fragment
707 Identification Values", draft-ietf-6man-predictable-
708 fragment-id-00 (work in progress), March 2013.
710 [draft-ietf-6man-predictable-fragment-id-02]
711 Gont, F., "Security Implications of Predictable Fragment
712 Identification Values", draft-ietf-6man-predictable-
713 fragment-id-02 (work in progress), December 2014.
715 [draft-ietf-6man-predictable-fragment-id-08]
716 Gont, F., "Security Implications of Predictable Fragment
717 Identification Values", draft-ietf-6man-predictable-
718 fragment-id-08 (work in progress), June 2015.
720 [draft-ietf-6man-stable-privacy-addresses-00]
721 Gont, F., "A method for Generating Stable Privacy-Enhanced
722 Addresses with IPv6 Stateless Address Autoconfiguration
723 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00
724 (work in progress), May 2012.
726 [Fyodor2004]
727 Fyodor, "Idle scanning and related IP ID games", 2004,
728 .
730 [Gont2011]
731 Gont, F., "Hacking IPv6 Networks (training course)", Hack
732 In Paris 2011 Conference Paris, France, June 2011.
734 [Gont2012]
735 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012
736 Conference Ottawa, Canada. May 11-12, 2012, May 2012.
738 [Gont2013]
739 Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit
740 (help wanted!)", Message posted to the IPv6 Hackers
741 mailing-list Message-ID:
742 <51184548.3030105@si6networks.com>, 1995,
743 .
746 [I-D.cooper-6man-ipv6-address-generation-privacy]
747 Cooper, A., Gont, F., and D. Thaler, "Privacy
748 Considerations for IPv6 Address Generation Mechanisms",
749 draft-cooper-6man-ipv6-address-generation-privacy-00 (work
750 in progress), July 2013.
752 [I-D.eddy-rfc793bis-04]
753 Eddy, W., "Transmission Control Protocol Specification",
754 draft-eddy-rfc793bis-04 (work in progress), August 2014.
756 [I-D.gont-6man-predictable-fragment-id]
757 Gont, F., "Security Implications of Predictable Fragment
758 Identification Values", draft-gont-6man-predictable-
759 fragment-id-03 (work in progress), January 2013.
761 [I-D.gont-6man-stable-privacy-addresses]
762 Gont, F., "A method for Generating Stable Privacy-Enhanced
763 Addresses with IPv6 Stateless Address Autoconfiguration
764 (SLAAC)", draft-gont-6man-stable-privacy-addresses-01
765 (work in progress), March 2012.
767 [I-D.gont-numeric-ids-generation]
768 Gont, F. and I. Arce, "On the Generation of Transient
769 Numeric Identifiers", draft-gont-numeric-ids-generation-02
770 (work in progress), February 2018.
772 [I-D.gont-numeric-ids-sec-considerations]
773 Gont, F. and I. Arce, "Security Considerations for
774 Transient Numeric Identifiers Employed in Network
775 Protocols", draft-gont-numeric-ids-sec-considerations-02
776 (work in progress), February 2018.
778 [I-D.gont-opsec-ipv6-host-scanning]
779 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
780 Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in
781 progress), October 2012.
783 [I-D.gont-predictable-numeric-ids]
784 Gont, F. and I. Arce, "Security and Privacy Implications
785 of Numeric Identifiers Employed in Network Protocols",
786 draft-gont-predictable-numeric-ids-02 (work in progress),
787 February 2018.
789 [I-D.ietf-6man-default-iids]
790 Gont, F., Cooper, A., Thaler, D., and S. LIU,
791 "Recommendation on Stable IPv6 Interface Identifiers",
792 draft-ietf-6man-default-iids-16 (work in progress),
793 September 2016.
795 [I-D.ietf-6man-ipv6-address-generation-privacy]
796 Cooper, A., Gont, F., and D. Thaler, "Privacy
797 Considerations for IPv6 Address Generation Mechanisms",
798 draft-ietf-6man-ipv6-address-generation-privacy-08 (work
799 in progress), September 2015.
801 [I-D.ietf-6man-predictable-fragment-id]
802 Gont, F., "Security Implications of Predictable Fragment
803 Identification Values", draft-ietf-6man-predictable-
804 fragment-id-10 (work in progress), October 2015.
806 [I-D.ietf-6man-rfc2460bis]
807 Deering, S. and R. Hinden, "Internet Protocol, Version 6
808 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work
809 in progress), May 2017.
811 [I-D.ietf-6man-stable-privacy-addresses]
812 Gont, F., "A Method for Generating Semantically Opaque
813 Interface Identifiers with IPv6 Stateless Address
814 Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
815 privacy-addresses-17 (work in progress), January 2014.
817 [I-D.ietf-opsec-ipv6-host-scanning]
818 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
819 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in
820 progress), August 2015.
822 [IPv6-Toolkit]
823 SI6 Networks, "SI6 Networks' IPv6 Toolkit",
824 .
826 [Joncheray1995]
827 Joncheray, L., "A Simple Active Attack Against TCP", Proc.
828 Fifth Usenix UNIX Security Symposium, 1995.
830 [Klein2007]
831 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
832 Predictable IP ID Vulnerability", 2007,
833 .
836 [Morbitzer2013]
837 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message
838 posted to the nmap-dev mailing-list, 2013,
839 .
841 [Morris1985]
842 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
843 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill,
844 NJ, 1985,
845 .
847 [RedHat2011]
848 RedHat, "RedHat Security Advisory RHSA-2011:1465-1:
849 Important: kernel security and bug fix update", 2011,
850 .
852 [RFC1035] Mockapetris, P., "Domain names - implementation and
853 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
854 November 1987, .
856 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
857 RFC 1948, DOI 10.17487/RFC1948, May 1996,
858 .
860 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
861 Errors at High Data Rates", RFC 4963,
862 DOI 10.17487/RFC4963, July 2007,
863 .
865 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
866 RFC 5157, DOI 10.17487/RFC5157, March 2008,
867 .
869 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
870 Protocol Port Randomization", BCP 156, RFC 6056,
871 DOI 10.17487/RFC6056, January 2011,
872 .
874 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol
875 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
876 .
878 [RFC7528] Higgs, P. and J. Piesing, "A Uniform Resource Name (URN)
879 Namespace for the Hybrid Broadcast Broadband TV (HbbTV)
880 Association", RFC 7528, DOI 10.17487/RFC7528, April 2015,
881 .
883 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
884 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
885 .
887 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
888 Considerations for IPv6 Address Generation Mechanisms",
889 RFC 7721, DOI 10.17487/RFC7721, March 2016,
890 .
892 [RFC7739] Gont, F., "Security Implications of Predictable Fragment
893 Identification Values", RFC 7739, DOI 10.17487/RFC7739,
894 February 2016, .
896 [Sanfilippo1998a]
897 Sanfilippo, S., "about the ip header id", Post to Bugtraq
898 mailing-list, Mon Dec 14 1998,
899 .
901 [Sanfilippo1998b]
902 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list,
903 1998, .
905 [Sanfilippo1999]
906 Sanfilippo, S., "more ip id", Post to Bugtraq mailing-
907 list, 1999,
908 .
910 [Shimomura1995]
911 Shimomura, T., "Technical details of the attack described
912 by Markoff in NYT", Message posted in USENET's
913 comp.security.misc newsgroup Message-ID:
914 <3g5gkl$5j1@ariel.sdsc.edu>, 1995,
915 .
917 [Silbersack2005]
918 Silbersack, M., "Improving TCP/IP security through
919 randomization without sacrificing interoperability",
920 EuroBSDCon 2005 Conference, 2005,
921 .
924 [SUSE2011]
925 SUSE, "SUSE Security Announcement: Linux kernel security
926 update (SUSE-SA:2011:046)", 2011,
927 .
930 [Ubuntu2011]
931 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel
932 vulnerabilities", 2011,
933 .
935 [USCERT2001]
936 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple
937 TCP/IP implementations may use statistically predictable
938 initial sequence numbers", 2001,
939 .
941 [Wright1994]
942 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
943 The Implementation", Addison-Wesley, 1994.
945 [Zalewski2001]
946 Zalewski, M., "Strange Attractors and TCP/IP Sequence
947 Number Analysis", 2001,
948 .
950 [Zalewski2002]
951 Zalewski, M., "Strange Attractors and TCP/IP Sequence
952 Number Analysis - One Year Later", 2001,
953 .
955 [Zalewski2003]
956 Zalewski, M., "A new TCP/IP blind data injection
957 technique?", 2003,
958 .
960 Authors' Addresses
962 Fernando Gont
963 SI6 Networks / UTN-FRH
964 Evaristo Carriego 2644
965 Haedo, Provincia de Buenos Aires 1706
966 Argentina
968 Phone: +54 11 4650 8472
969 Email: fgont@si6networks.com
970 URI: http://www.si6networks.com
972 Ivan Arce
973 Quarkslab
975 Email: iarce@quarkslab.com
976 URI: https://www.quarkslab.com