idnits 2.17.1 draft-irtf-pearg-numeric-ids-history-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 23, 2019) is 1698 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 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-04 -- 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: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: February 24, 2020 Quarkslab 6 August 23, 2019 8 Unfortunate History of Transient Numeric Identifiers 9 draft-irtf-pearg-numeric-ids-history-00 11 Abstract 13 This document analyzes the timeline of the specification of different 14 types of "numeric identifiers" used in IETF protocols, and how the 15 security and privacy implications of such protocols has been affected 16 as a result of it. It provides concrete evidence that advice in this 17 area is warranted. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 24, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . . . 4 57 5. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . . . 8 58 6. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . . . 9 59 7. NTP Reference IDs (REFID) . . . . . . . . . . . . . . . . . . 12 60 8. Transport Protocol Port Numbers . . . . . . . . . . . . . . . 13 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 65 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 66 12.2. Informative References . . . . . . . . . . . . . . . . . 17 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 69 1. Introduction 71 Network protocols employ a variety of numeric identifiers for 72 different protocol entities, ranging from DNS Transaction IDs (TxIDs) 73 to transport protocol numbers (e.g. TCP ports) or IPv6 Interface 74 Identifiers (IIDs). These identifiers usually have specific 75 properties that must be satisfied such that they do not result in 76 negative interoperability implications (e.g. uniqueness during a 77 specified period of time), and associated failure severity when such 78 properties are not met, ranging from soft to hard failures. 80 For more than 30 years, a large number of implementations of the TCP/ 81 IP protocol suite have been subject to a variety of attacks, with 82 effects ranging from Denial of Service (DoS) or data injection, to 83 information leakage that could be exploited for pervasive monitoring 84 [RFC7258]. The root of these issues has been, in many cases, the 85 poor selection of identifiers in such protocols, usually as a result 86 of an insufficient or misleading specification. While it is 87 generally trivial to identify an algorithm that can satisfy the 88 interoperability requirements for a given identifier, there exists 89 practical evidence that doing so without negatively affecting the 90 security and/or privacy properties of the aforementioned protocols is 91 prone to error. 93 For example, implementations have been subject to security and/or 94 privacy issues resulting from: 96 o Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. 97 [Morris1985]) 99 o Predictable ephemeral transport protocol numbers (see e.g. 100 [RFC6056] and [Silbersack2005]) 102 o Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. 103 [RFC5722], [RFC6274], and [RFC7739]) 105 o Predictable IPv6 IIDs (see e.g. [RFC7721] and [RFC7707]) 107 o Predictable DNS TxIDs [RFC1035] 109 Recent history indicate that when new protocols are standardized or 110 new protocol implementations are produced, the security and privacy 111 properties of the associated identifiers tend to be overlooked and 112 inappropriate algorithms to generate identifier values are either 113 suggested in the specification or selected by implementers. 115 This document contains a non-exhaustive timeline of vulnerability 116 disclosures related to some sample transient numeric identifiers and 117 other work that has led to advances in this area, with the goal of 118 illustrating that: 120 o Vulnerabilities related to how the values for some identifiers are 121 generated and assigned have affected implementations for an 122 extremely long period of time. 124 o Such vulnerabilities, even when addressed for a given protocol 125 version, were later reintroduced in new versions or new 126 implementations of the same protocol. 128 o Standardization efforts that discuss and provide advice in this 129 area can have a positive effect on protocol specifications and 130 protocol implementations. 132 Other related documents ([I-D.gont-numeric-ids-generation] and 133 [I-D.gont-numeric-ids-sec-considerations]) provide guidance in this 134 area. 136 2. Terminology 138 Identifier: 139 A data object in a protocol specification that can be used to 140 definitely distinguish a protocol object (a datagram, network 141 interface, transport protocol endpoint, session, etc) from all 142 other objects of the same type, in a given context. Identifiers 143 are usually defined as a series of bits and represented using 144 integer values. We note that different identifiers may have 145 additional requirements or properties depending on their specific 146 use in a protocol. We use the term "identifier" as a generic term 147 to refer to any data object in a protocol specification that 148 satisfies the identification property stated above. 150 Failure Severity: 151 The consequences of a failure to comply with the interoperability 152 requirements of a given identifier. Severity considers the worst 153 potential consequence of a failure, determined by the system 154 damage and/or time lost to repair the failure. In this document 155 we define two types of failure severity: "soft" and "hard". 157 Hard Failure: 158 A hard failure is a non-recoverable condition in which a protocol 159 does not operate in the prescribed manner or it operates with 160 excessive degradation of service. For example, an established TCP 161 connection that is aborted due to an error condition constitutes, 162 from the point of view of the transport protocol, a hard failure, 163 since it enters a state from which normal operation cannot be 164 recovered. 166 Soft Failure: 167 A soft failure is a recoverable condition in which a protocol does 168 not operate in the prescribed manner but normal operation can be 169 resumed automatically in a short period of time. For example, a 170 simple packet-loss event that is subsequently recovered with a 171 retransmission can be considered a soft failure. 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 3. Threat Model 179 Throughout this document, we assume an attacker does not have 180 physical or logical device to the device(s) being attacked. We 181 assume the attacker can simply send any traffic to the target 182 devices, to e.g. sample identifiers employed by such devices. 184 4. IPv4/IPv6 Identification 186 This section presents the timeline of the Identification field both 187 for IPv4 and for IPv6. The reason for presenting both cases in the 188 same section is so that it becomes evident that, while the 189 Identification value serves the same purpose in both IPv4 and IPv6, 190 the work and research done for the IPv4 case did not affect the IPv6 191 specifications or implementations. 193 The IPv4 Identification value is specified in [RFC0791], which 194 specifies the interoperability requirements for the Identification 195 field: the sender must choose the Identification field to be unique 196 for a given source address, destination address, and protocol for the 197 time the datagram (or any fragment of it) could be alive in the 198 internet. It suggests that a node may keep "a table of Identifiers, 199 one entry for each destination it has communicated with in the last 200 maximum packet lifetime for the internet", and suggests that "since 201 the Identifier field allows 65,536 different values, some host may be 202 able to simply use unique identifiers independent of destination". 203 The above may be read as a suggestion to employ per-destination or 204 global counters for the generation of Identification values. While 205 [RFC0791] does not suggest any flawed algorithm for the generation of 206 Identification values, it misses a discussion of the security and 207 privacy implications of employing predictable. This has resulted in 208 virtually all IP4 implementations generating predictable fragment 209 Identification values by means of a global counter, at least at some 210 point during the lifetime of such implementations. 212 The IPv6 Identification is specified in [RFC2460]. It serves the 213 same purpose as its IPv4 counterpart, with the only difference 214 residing in the length of the corresponding field, and that while the 215 IPv4 Identification field is part of the base IPv4 header, in the 216 IPv6 case it is part of the Fragment header (which may or may not be 217 present in an IPv6 packet). [RFC2460] states, in Section 4.5, that 218 the Identification must be different than that of any other 219 fragmented packet sent recently (within the maximum likely lifetime 220 of a packet) with the same Source Address and Destination Address. 221 Subsequently, it notes that this requirement can be met by means of a 222 wrap-around 32-bit counter that is incremented each time a packet 223 must be fragmented, and that it is an implementation choice whether 224 to use a global or a per-destination counter. Thus, the 225 implementation of the IPv6 Identification is similar to that of the 226 IPv4 case, with the only difference that in the IPv6 case the 227 suggestions to use simple counters is more explicit. 229 September 1981: 230 [RFC0791] specifies the interoperability requirements for IPv4 231 Identification value, but does not specify any requirements in the 232 area of security and privacy. 234 December 1998: 235 [Sanfilippo1998a] finds that predictable IPv4 Identification 236 values (generated by most popular implementations) can be 237 leveraged to count the number of packets sent by a target node. 238 [Sanfilippo1998b] explains how to leverage the same vulnerability 239 to implement a port-scanning technique known as dumb/idle scan. A 240 tool that implements this attack is publicly released. 242 December 1998: 243 [RFC2460] suggests that a global counter be used to generate the 244 IPv6 Identification value. 246 November 1999: 247 [Sanfilippo1999] discusses how to leverage predictable IPv4 248 Identification to uncover the rules of a number of firewalls. 250 November 1999: 251 [Bellovin2002] explains how the IPv4 Identification field can be 252 exploited to count the number of systems behind a NAT. 254 September 2002: 255 [Fyodor2002] explains how to implement a stealth port-scanning 256 technique by leveraging nodes that employ predictable IPv4 257 Identification values. 259 December 2003: 260 [Zalewski2003] explains a technique to perform TCP data injection 261 attack based on predictable IPv4 identification values which 262 requires less effort than TCP injection attacks performed with 263 bare TCP packets. 265 November 2005: 266 [Silbersack2005] discusses shortcoming in a number of techniques 267 to mitigate predictable IPv4 Identification values. 269 October 2007: 270 [Klein2007] describes a weakness in the pseudo random number 271 generator (PRNG) in use for the generation of the IP 272 Identification by a number of operating systems. 274 June 2011: 275 [Gont2011] describes how to perform idle scan attacks in IPv6. 277 November 2011: 278 Linux mitigates predictable IPv6 Identification values 279 [RedHat2011] [SUSE2011] [Ubuntu2011]. 281 December 2011: 282 [draft-gont-6man-predictable-fragment-id-00] describes the 283 security implications of predictable IPv6 Identification values, 284 and possible mitigations. This document is published on the 285 Standards Track, meaning to formally update [RFC2460], to 286 introduce security and privacy requirements on IPv6 Identification 287 values. 289 May 2012: 291 [Gont2012] notes that some major IPv6 implementations still employ 292 predictable IPv6 Identification values. 294 March 2013: 295 The 6man WG adopts [I-D.gont-6man-predictable-fragment-id], but 296 changes the track to "BCP" (while still formally updating 297 [RFC2460]), publishing the resulting document as 298 [draft-ietf-6man-predictable-fragment-id-00]. 300 June 2013: 301 A patch that implements IPv6-based idle-scan in nmap is submitted 302 [Morbitzer2013]. 304 December 2014: 305 The 6man WG changes the status of the aforementioned IETF Internet 306 Draft to "Informational" and publishes it as 307 [draft-ietf-6man-predictable-fragment-id-02]. As a result, it no 308 longer formally updates [RFC2460]. 310 June 2015: 311 [draft-ietf-6man-predictable-fragment-id-08] notes that some 312 popular host and router implementations still employ predictable 313 IPv6 Identification values. 315 February 2016: 316 [RFC7739] (based on [I-D.ietf-6man-predictable-fragment-id]) 317 analyzes the security and privacy implications of predictable IPv6 318 Identification values, and provides guidance for selecting an 319 algorithm to generate such values. However, being published on 320 the Informational track, it does not formally update [RFC2460]. 322 June 2016: 323 [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the 324 suggestion from RFC2460 to employ a global counter for the 325 generation of IPv6 Identification values, but does not specify any 326 security and privacy requirements for the IPv6 Identification 327 value. 329 July 2017: 330 [I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200], 331 obsoleting [RFC2460], and pointing to [RFC7739] for sample 332 algorithms for the generation of IPv6 Fragment Identification 333 values. 335 June 2019: 336 [IPID-DEV] notes that the IPv6 ID generator of the current version 337 of a popular operating system is flawed. 339 5. TCP Initial Sequence Numbers (ISNs) 341 [RFC0793] suggests that the choice of the ISN of a connection is not 342 arbitrary, but aims to reduce the chances of a stale segment from 343 being accepted by a new incarnation of a previous connection. 344 [RFC0793] suggests the use of a global 32-bit ISN generator that is 345 incremented by 1 roughly every 4 microseconds. However, as a matter 346 of fact, protection against stale segments from a previous 347 incarnation of the connection is enforced by preventing the creation 348 of a new incarnation of a previous connection before 2*MSL have 349 passed since a segment corresponding to the old incarnation was last 350 seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). This 351 is accomplished by the TIME-WAIT state and TCP's "quiet time" concept 352 (see Appendix B of [RFC1323]). Based on the assumption that ISNs are 353 monotonically increasing across connections, many stacks (e.g., 354 4.2BSD-derived) use the ISN of an incoming SYN segment to perform 355 "heuristics" that enable the creation of a new incarnation of a 356 connection while the previous incarnation is still in the TIME-WAIT 357 state (see p. 945 of [Wright1994]). This avoids an interoperability 358 problem that may arise when a node establishes connections to a 359 specific TCP end-point at a high rate [Silbersack2005]. 361 In the case of TCP, the interoperability requirements for the ISNs 362 are probably not clearly spelled out as one would expect. 363 Furthermore, the suggestion of employing a global counter in 364 [RFC0793] leads to negative security and privacy implications. 366 September 1981: 367 [RFC0793], suggests the use of a global 32-bit ISN generator, 368 whose lower bit is incremented roughly every 4 microseconds. 369 However, such an ISN generator makes it trivial to predict the ISN 370 that a TCP will use for new connections, thus allowing a variety 371 of attacks against TCP. 373 February 1985: 374 [Morris1985] was the first to describe how to exploit predictable 375 TCP ISNs for forging TCP connections that could then be leveraged 376 for trust relationship exploitation. 378 April 1989: 379 [Bellovin1989] discussed the security implications of predictable 380 ISNs (along with a range of other protocol-based vulnerabilities). 382 February 1995: 383 [Shimomura1995] reported a real-world exploitation of the attack 384 described in 1985 (ten years before) in [Morris1985]. 386 May 1996: 388 [RFC1948] was the first IETF effort, authored by Steven Bellovin, 389 to address predictable TCP ISNs. The same concept specified in 390 this document for TCP ISNs was later proposed for TCP ephemeral 391 ports [RFC6056], TCP Timestamps, and eventually even IPv6 392 Interface Identifiers [RFC7217]. 394 March 2001: 395 [Zalewski2001] provides a detailed analysis of statistical 396 weaknesses in some ISN generators, and includes a survey of the 397 algorithms in use by popular TCP implementations. 399 May 2001: 400 Vulnerability advisories [CERT2001] [USCERT2001] are released 401 regarding statistical weaknesses in some ISN generators, affecting 402 popular TCP/IP implementations. 404 March 2002: 405 [Zalewski2002] updates and complements [Zalewski2001]. It 406 concludes that "while some vendors [...] reacted promptly and 407 tested their solutions properly, many still either ignored the 408 issue and never evaluated their implementations, or implemented a 409 flawed solution that apparently was not tested using a known 410 approach" [Zalewski2002]. 412 February 2012: 413 [RFC6528], after 27 years of Morris' original work [Morris1985], 414 formally updates [RFC0793] to mitigate predictable TCP ISNs. 416 August 2014: 417 [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP 418 protocol specification, incorporates the algorithm specified in 419 [RFC6528] as the recommended algorithm for TCP ISN generation. 421 6. IPv6 Interface Identifiers (IIDs) 423 IPv6 Interface Identifiers can be generated in multiple ways: SLAAC 424 [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section 425 focuses on Interface Identifiers resulting from SLAAC. 427 The Interface Identifier of stable (traditional) IPv6 addresses 428 resulting from SLAAC have traditionally resulted in the underlying 429 link-layer address being embedded in the IID. IPv6 addresses 430 resulting from SLAAC are currently required to employ Modified EUI-64 431 format identifiers, which essentially embed the underlying link-layer 432 address of the corresponding network interface. At the time, 433 employing the underlying link-layer address for the IID was seen as a 434 convenient way to obtain a unique address. However, recent awareness 435 about the security and privacy implications of this approach 437 [RFC7707] [RFC7721] has led to the replacement of such flawed scheme 438 with an alternative one that mitigates its security and privacy 439 implications [RFC7217] [RFC8064]. 441 January 1997: 442 [RFC2073] specifies the syntax of IPv6 global addresses (referred 443 to as "An IPv6 Provider-Based Unicast Address Format" at the 444 time), consistent with the IPv6 addressing architecture specified 445 in [RFC1884]. Hosts are recommended to "generate addresses using 446 link-specific addresses as Interface ID such as 48 bit IEEE-802 447 MAC addresses". 449 July 1998: 450 [RFC2374] specifies "An IPv6 Aggregatable Global Unicast Address 451 Format" (obsoleting [RFC2373]) changing the size of the Interface 452 ID to 64 bits, and specifies that that IIDs must be constructed in 453 IEEE EUI-64 format. How such identifiers are constructed becomes 454 specified in the appropriate "IPv6 over " specification such 455 as "IPv6 over Ethernet". 457 January 2001: 458 [RFC3041] recognizes the problem of network activity correlation, 459 and specifies temporary addresses. Temporary addresses are to be 460 used along with stable addresses. 462 August 2003: 463 [RFC3587] obsoletes [RFC2374], making the TLA/NLA structure 464 historic. The syntax and recommendations for the traditional 465 stable IIDs remain unchanged, though. 467 February 2006: 468 [RFC4291] is published as the latest "IP Version 6 Addressing 469 Architecture", requiring the IIDs of the traditional (stable) 470 autoconfigured addresses to employ the Modified EUI-64 format. 471 The details of constructing such interface identifiers are defined 472 in the appropriate "IPv6 over " specifications. 474 March 2008: 475 [RFC5157] provides hints regarding how patterns in IPv6 addresses 476 could be leveraged for the purpose of address scanning. 478 December 2011: 479 [draft-gont-6man-stable-privacy-addresses-00] notes that the 480 traditional scheme for generating stable addresses allows for 481 address scanning, and also does not prevent active node tracking. 482 It also specifies an alternative algorithm meant to replace IIDs 483 based on Modified EUI-64 format identifiers. 485 November 2012: 486 The 6man WG adopts [I-D.gont-6man-stable-privacy-addresses] as a 487 working group item (as 488 [draft-ietf-6man-stable-privacy-addresses-00]). However, the 489 specified algorithm no longer formally replaces the Modified 490 EUI-64 format identifiers. 492 February 2013: 493 An address-scanning tool (scan6 of [IPv6-Toolkit]) that leverages 494 IPv6 address patterns is released [Gont2013]. 496 July 2013: 497 [I-D.cooper-6man-ipv6-address-generation-privacy] elaborates on 498 the security and privacy implications on all known algorithms for 499 generating IPv6 IIDs. 501 January 2014: 502 The 6man wg publishes [draft-ietf-6man-default-iids-00] 503 ("Recommendation on Stable IPv6 Interface Identifiers"), 504 recommending [I-D.ietf-6man-stable-privacy-addresses] for the 505 generation of stable addresses. 507 April 2014: 508 [RFC7217] is published, specifying "A Method for Generating 509 Semantically Opaque Interface Identifiers with IPv6 Stateless 510 Address Autoconfiguration (SLAAC)" as an alternative to (but *not* 511 replacement of) Modified EUI-64 format IIDs. 513 March 2016: 514 [RFC7707] (formerly [I-D.gont-opsec-ipv6-host-scanning] and later 515 [I-D.ietf-opsec-ipv6-host-scanning]), about "Network 516 Reconnaissance in IPv6 Networks", is published. 518 March 2016: 519 [RFC7721] (formerly 520 [I-D.cooper-6man-ipv6-address-generation-privacy] and later 521 [I-D.ietf-6man-ipv6-address-generation-privacy]), about "Security 522 and Privacy Considerations for IPv6 Address Generation 523 Mechanisms", is published. 525 May 2016: 526 [draft-gont-6man-non-stable-iids-00] is published, with the goal 527 of specifying requirements for non-stable addresses, and updating 528 [RFC4941] such that use of only temporary addresses is allowed. 530 May 2016: 531 [draft-gont-6man-address-usage-recommendations-00] is published, 532 providing an analysis of how different aspects on an address (from 533 stability to usage mode) affect their corresponding security and 534 privacy implications, and meaning to eventually provide advice in 535 this area. 537 February 2017: 538 The 6man wg publishes [RFC8064] ("Recommendation on Stable IPv6 539 Interface Identifiers") (formerly [I-D.ietf-6man-default-iids]), 540 with requirements for stable addresses and a recommendation to 541 employ [RFC7217] for the generation of stable addresses. It 542 formally updated a large number of RFCs. 544 March 2018: 545 [draft-fgont-6man-rfc4941bis-00] is published (as suggested by the 546 6man wg), to address flaws in [RFC4941] by revising it (as an 547 alternative to the [draft-gont-6man-non-stable-iids-00] effort, 548 published in March 2016). 550 July 2018: 551 [draft-ietf-6man-rfc4941bis-00] is adopted (as 552 [draft-fgont-6man-rfc4941bis-00]) as a wg item of the 6man wg. 554 7. NTP Reference IDs (REFID) 556 The NTP [RFC5905] is employed to avoid timing loops degree-one timing 557 loops in scenarios where two NTP peers are (mutually) the time source 558 of each other. 560 June 2010: 561 [RFC5905], "Network Time Protocol Version 4: Protocol and 562 Algorithms Specification" is published. It specifies that for NTP 563 peers with stratum higher than 1 the REFID embeds the IPv4 Address 564 of the time source or an MD5 hash of the IPv6 address of the time 565 source. 567 July 2016: 568 [draft-stenn-ntp-not-you-refid-00] is published, describing the 569 information leakage produced via de NTP REFID. It proposes that 570 NTP returns a special REFID when a packet employs an IP Source 571 Address that is not believed to be a current NTP peer, but 572 otherwise generates and returns the traditional REFID. It is 573 subsequently adopted by the NTP WG as 574 [I-D.ietf-ntp-refid-updates]. 576 April 2019: 577 [Gont-NTP] notes that the proposed fix specified in 578 [draft-ietf-ntp-refid-updates-00] is, at the very least, sub- 579 optimal. 581 8. Transport Protocol Port Numbers 583 Most (if not all) transport protocols employ "port numbers" to 584 demultiplex packets to the corresponding transport protocol 585 instances. 587 August 1980: 588 [RFC0768] notes that the UDP source port is optional and 589 identifies the port of the sending process. It does not specify 590 interoperability requirements for source port selection, nor does 591 it suggest possible ways to select port numbers. Most popular 592 implementations end up selecting source ports from a system-wide 593 global counter. 595 September 1981: 596 [RFC0793] (the TCP specification) essentially describes the use of 597 port numbers, and specifies that port numbers should result in a 598 unique socket pair (local address, local port, remote address, 599 remote port). How ephemeral ports (i.e. port numbers for "active 600 opens") are selected, and the port range from which they are 601 selected, are left unspecified. 603 January 2009: 604 [RFC5452] mandates the use of port randomization for DNS 605 resolvers, and mandates that implementations must randomize port 606 from the range (53 or 1024, and above) or the largest possible 607 port range. It does not recommend possible algorithms for port 608 randomization, although the document specifically targets DNS 609 resolvers, for which a simple random port suffices (e.g. 610 Algorithm 1 of [RFC6056]). This document led to the 611 implementation of port randomization in the DNS resolver 612 themselves, rather than in the underlying transport-protocols. 614 January 2011: 615 [RFC6056] notes that many TCP and UDP implementations result in 616 predictable port numbers, and also notes that many implementations 617 select port numbers from a small portion of the whole port number 618 space. It recommends the implementation and use of ephemeral port 619 randomization, proposes a number of possible algorithms for port 620 randomization, and also recommends to randomize port numbers over 621 the range 1024-65535. 623 March 2016: 624 [NIST-NTP] reports a non-normal distribution of the ephemeral port 625 numbers employed by the NTP clients of an Internet Time Service. 627 April 2019: 629 [I-D.gont-ntp-port-randomization] notes that some NTP 630 implementations employ the NTP service port (123) as the local 631 port for non-symmetric modes, and aims to update the NTP such that 632 they employ port randomization in such cases, as recommended by 633 [RFC6056]. The proposal experiments some push-back in the 634 relevant working group (NTP WG) [NTP-PORTR]. 636 9. IANA Considerations 638 There are no IANA registries within this document. The RFC-Editor 639 can remove this section before publication of this document as an 640 RFC. 642 10. Security Considerations 644 This document analyzes the timeline of the specification of different 645 types of "numeric identifiers" used in IETF protocols, and how the 646 security and privacy implications of such protocols has been affected 647 as a result of it. It provides concrete evidence that advice in this 648 area is warranted. [I-D.gont-numeric-ids-sec-considerations] 649 formally requires protocol specifications to do a warranted analysis 650 of the interoperability implications of the transient numeric 651 identifiers they specify, and to recommend possible algorithms for 652 their generation, such that possible security and privacy 653 implications are mitigated. [I-D.gont-numeric-ids-generation] 654 analyzes categorizes transient numeric identifiers based on their 655 interoperability requirements and their associated failure modes, and 656 recommends possible algorithms to that can comply with the associated 657 requirements while mitigating possible security and privacy 658 implications. 660 11. Acknowledgements 662 The authors would like to thank (in alphabetical order) Dave Crocker, 663 Christian Huitema, and Joe Touch, for providing valuable comments on 664 earlier versions of this document. 666 The authors would like to thank (in alphabetical order) Steven 667 Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for 668 providing valuable comments on [I-D.gont-predictable-numeric-ids], on 669 which this document is based. 671 Section 5 of this document borrows text from [RFC6528], authored by 672 Fernando Gont and Steven Bellovin. 674 The authors would like to thank Diego Armando Maradona for his magic 675 and inspiration. 677 12. References 679 12.1. Normative References 681 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 682 DOI 10.17487/RFC0768, August 1980, 683 . 685 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 686 DOI 10.17487/RFC0791, September 1981, 687 . 689 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 690 RFC 793, DOI 10.17487/RFC0793, September 1981, 691 . 693 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 694 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 695 1992, . 697 [RFC1884] Hinden, R., Ed. and S. Deering, Ed., "IP Version 6 698 Addressing Architecture", RFC 1884, DOI 10.17487/RFC1884, 699 December 1995, . 701 [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. 702 Postel, "An IPv6 Provider-Based Unicast Address Format", 703 RFC 2073, DOI 10.17487/RFC2073, January 1997, 704 . 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, 708 DOI 10.17487/RFC2119, March 1997, 709 . 711 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 712 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 713 . 715 [RFC2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 716 Aggregatable Global Unicast Address Format", RFC 2374, 717 DOI 10.17487/RFC2374, July 1998, 718 . 720 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 721 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 722 December 1998, . 724 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 725 Stateless Address Autoconfiguration in IPv6", RFC 3041, 726 DOI 10.17487/RFC3041, January 2001, 727 . 729 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 730 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 731 August 2003, . 733 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 734 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 735 2006, . 737 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 738 Address Autoconfiguration", RFC 4862, 739 DOI 10.17487/RFC4862, September 2007, 740 . 742 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 743 Extensions for Stateless Address Autoconfiguration in 744 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 745 . 747 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 748 Resilient against Forged Answers", RFC 5452, 749 DOI 10.17487/RFC5452, January 2009, 750 . 752 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 753 RFC 5722, DOI 10.17487/RFC5722, December 2009, 754 . 756 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 757 Protocol Port Randomization", BCP 156, RFC 6056, 758 DOI 10.17487/RFC6056, January 2011, 759 . 761 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 762 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 763 2012, . 765 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 766 Interface Identifiers with IPv6 Stateless Address 767 Autoconfiguration (SLAAC)", RFC 7217, 768 DOI 10.17487/RFC7217, April 2014, 769 . 771 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 772 (IPv6) Specification", STD 86, RFC 8200, 773 DOI 10.17487/RFC8200, July 2017, 774 . 776 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 777 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 778 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 779 RFC 8415, DOI 10.17487/RFC8415, November 2018, 780 . 782 12.2. Informative References 784 [Bellovin1989] 785 Bellovin, S., "Security Problems in the TCP/IP Protocol 786 Suite", Computer Communications Review, vol. 19, no. 2, 787 pp. 32-48, 1989, 788 . 790 [Bellovin2002] 791 Bellovin, S., "A Technique for Counting NATted Hosts", 792 IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. 794 [CERT2001] 795 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 796 TCP/IP Initial Sequence Numbers", 2001, 797 . 799 [draft-fgont-6man-rfc4941bis-00] 800 Gont, F., Krishnan, S., Narten, T., and R. Draves, 801 "Privacy Extensions for Stateless Address 802 Autoconfiguration in IPv6", draft-fgont-6man-rfc4941bis-00 803 (work in progress), March 2018. 805 [draft-gont-6man-address-usage-recommendations-00] 806 Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", 807 draft-gont-6man-address-usage-recommendations-00 (work in 808 progress), May 2016. 810 [draft-gont-6man-non-stable-iids-00] 811 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 812 Interface Identifiers", draft-gont-6man-non-stable-iids-00 813 (work in progress), May 2016. 815 [draft-gont-6man-predictable-fragment-id-00] 816 Gont, F., "Security Implications of Predictable Fragment 817 Identification Values", draft-gont-6man-predictable- 818 fragment-id-00 (work in progress), December 2011. 820 [draft-gont-6man-stable-privacy-addresses-00] 821 Gont, F., "A method for Generating Stable Privacy-Enhanced 822 Addresses with IPv6 Stateless Address Autoconfiguration 823 (SLAAC)", draft-gont-6man-stable-privacy-addresses-00 824 (work in progress), December 2011. 826 [draft-ietf-6man-default-iids-00] 827 Gont, F., Cooper, A., Thaler, D., and W. Liu, 828 "Recommendation on Stable IPv6 Interface Identifiers", 829 draft-ietf-6man-default-iids-00 (work in progress), July 830 2014. 832 [draft-ietf-6man-predictable-fragment-id-00] 833 Gont, F., "Security Implications of Predictable Fragment 834 Identification Values", draft-ietf-6man-predictable- 835 fragment-id-00 (work in progress), March 2013. 837 [draft-ietf-6man-predictable-fragment-id-02] 838 Gont, F., "Security Implications of Predictable Fragment 839 Identification Values", draft-ietf-6man-predictable- 840 fragment-id-02 (work in progress), December 2014. 842 [draft-ietf-6man-predictable-fragment-id-08] 843 Gont, F., "Security Implications of Predictable Fragment 844 Identification Values", draft-ietf-6man-predictable- 845 fragment-id-08 (work in progress), June 2015. 847 [draft-ietf-6man-rfc4941bis-00] 848 Gont, F., Krishnan, S., Narten, T., and R. Draves, 849 "Privacy Extensions for Stateless Address 850 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-00 851 (work in progress), July 2018. 853 [draft-ietf-6man-stable-privacy-addresses-00] 854 Gont, F., "A method for Generating Stable Privacy-Enhanced 855 Addresses with IPv6 Stateless Address Autoconfiguration 856 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00 857 (work in progress), May 2012. 859 [draft-ietf-ntp-refid-updates-00] 860 Goldberg, S. and H. Stenn, "Network Time Protocol Not You 861 REFID", draft-ietf-ntp-refid-updates-00 (work in 862 progress), November 2016. 864 [draft-stenn-ntp-not-you-refid-00] 865 Goldberg, S. and S. KrishnansTENN, "Network Time Protocol 866 Not You REFID", draft-stenn-ntp-not-you-refid-00 (work in 867 progress), July 2016. 869 [Fyodor2002] 870 Fyodor, "Idle scanning and related IP ID games", 2002, 871 . 873 [Gont-NTP] 874 Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates- 875 05", Post to the NTP WG mailing list Message-ID: 876 , 877 April 2019, . 880 [Gont2011] 881 Gont, F., "Hacking IPv6 Networks (training course)", Hack 882 In Paris 2011 Conference Paris, France, June 2011. 884 [Gont2012] 885 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 886 Conference Ottawa, Canada. May 11-12, 2012, May 2012. 888 [Gont2013] 889 Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit 890 (help wanted!)", Message posted to the IPv6 Hackers 891 mailing-list Message-ID: 892 <51184548.3030105@si6networks.com>, 1995, 893 . 896 [I-D.cooper-6man-ipv6-address-generation-privacy] 897 Cooper, A., Gont, F., and D. Thaler, "Privacy 898 Considerations for IPv6 Address Generation Mechanisms", 899 draft-cooper-6man-ipv6-address-generation-privacy-00 (work 900 in progress), July 2013. 902 [I-D.eddy-rfc793bis-04] 903 Eddy, W., "Transmission Control Protocol Specification", 904 draft-eddy-rfc793bis-04 (work in progress), August 2014. 906 [I-D.gont-6man-predictable-fragment-id] 907 Gont, F., "Security Implications of Predictable Fragment 908 Identification Values", draft-gont-6man-predictable- 909 fragment-id-03 (work in progress), January 2013. 911 [I-D.gont-6man-stable-privacy-addresses] 912 Gont, F., "A method for Generating Stable Privacy-Enhanced 913 Addresses with IPv6 Stateless Address Autoconfiguration 914 (SLAAC)", draft-gont-6man-stable-privacy-addresses-01 915 (work in progress), March 2012. 917 [I-D.gont-ntp-port-randomization] 918 Gont, F. and G. Gont, "Port Randomization in the Network 919 Time Protocol Version 4", draft-gont-ntp-port- 920 randomization-04 (work in progress), August 2019. 922 [I-D.gont-numeric-ids-generation] 923 Gont, F. and I. Arce, "On the Generation of Transient 924 Numeric Identifiers", draft-gont-numeric-ids-generation-04 925 (work in progress), July 2019. 927 [I-D.gont-numeric-ids-sec-considerations] 928 Gont, F. and I. Arce, "Security Considerations for 929 Transient Numeric Identifiers Employed in Network 930 Protocols", draft-gont-numeric-ids-sec-considerations-04 931 (work in progress), July 2019. 933 [I-D.gont-opsec-ipv6-host-scanning] 934 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 935 Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in 936 progress), October 2012. 938 [I-D.gont-predictable-numeric-ids] 939 Gont, F. and I. Arce, "Security and Privacy Implications 940 of Numeric Identifiers Employed in Network Protocols", 941 draft-gont-predictable-numeric-ids-03 (work in progress), 942 March 2019. 944 [I-D.ietf-6man-default-iids] 945 Gont, F., Cooper, A., Thaler, D., and S. LIU, 946 "Recommendation on Stable IPv6 Interface Identifiers", 947 draft-ietf-6man-default-iids-16 (work in progress), 948 September 2016. 950 [I-D.ietf-6man-ipv6-address-generation-privacy] 951 Cooper, A., Gont, F., and D. Thaler, "Privacy 952 Considerations for IPv6 Address Generation Mechanisms", 953 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 954 in progress), September 2015. 956 [I-D.ietf-6man-predictable-fragment-id] 957 Gont, F., "Security Implications of Predictable Fragment 958 Identification Values", draft-ietf-6man-predictable- 959 fragment-id-10 (work in progress), October 2015. 961 [I-D.ietf-6man-rfc2460bis] 962 Deering, S. and R. Hinden, "Internet Protocol, Version 6 963 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work 964 in progress), May 2017. 966 [I-D.ietf-6man-stable-privacy-addresses] 967 Gont, F., "A Method for Generating Semantically Opaque 968 Interface Identifiers with IPv6 Stateless Address 969 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 970 privacy-addresses-17 (work in progress), January 2014. 972 [I-D.ietf-ntp-refid-updates] 973 Stenn, H. and S. Goldberg, "Network Time Protocol REFID 974 Updates", draft-ietf-ntp-refid-updates-05 (work in 975 progress), March 2019. 977 [I-D.ietf-opsec-ipv6-host-scanning] 978 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 979 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 980 progress), August 2015. 982 [IPID-DEV] 983 Klein, A. and B. Pinkas, "From IP ID to Device ID and 984 KASLR Bypass (Extended Version)", June 2019, 985 . 987 [IPv6-Toolkit] 988 SI6 Networks, "SI6 Networks' IPv6 Toolkit", 989 . 991 [Klein2007] 992 Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S 993 Predictable IP ID Vulnerability", 2007, 994 . 997 [Morbitzer2013] 998 Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message 999 posted to the nmap-dev mailing-list, 2013, 1000 . 1002 [Morris1985] 1003 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 1004 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 1005 NJ, 1985, 1006 . 1008 [NIST-NTP] 1009 Sherman, J. and J. Levine, "Usage Analysis of the NIST 1010 Internet Time Service", Journal of Research of the 1011 National Institute of Standards and Technology Volume 121, 1012 March 2016, . 1014 [NTP-PORTR] 1015 Gont, F., "[Ntp] New rev of the NTP port randomization I-D 1016 (Fwd: New Version Notification for draft-gont-ntp-port- 1017 randomization-01.txt)", 2019, 1018 . 1021 [RedHat2011] 1022 RedHat, "RedHat Security Advisory RHSA-2011:1465-1: 1023 Important: kernel security and bug fix update", 2011, 1024 . 1026 [RFC1035] Mockapetris, P., "Domain names - implementation and 1027 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1028 November 1987, . 1030 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 1031 RFC 1948, DOI 10.17487/RFC1948, May 1996, 1032 . 1034 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1035 RFC 5157, DOI 10.17487/RFC5157, March 2008, 1036 . 1038 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1039 "Network Time Protocol Version 4: Protocol and Algorithms 1040 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1041 . 1043 [RFC6274] Gont, F., "Security Assessment of the Internet Protocol 1044 Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, 1045 . 1047 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1048 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1049 2014, . 1051 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1052 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1053 . 1055 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1056 Considerations for IPv6 Address Generation Mechanisms", 1057 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1058 . 1060 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 1061 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 1062 February 2016, . 1064 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1065 "Recommendation on Stable IPv6 Interface Identifiers", 1066 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1067 . 1069 [Sanfilippo1998a] 1070 Sanfilippo, S., "about the ip header id", Post to Bugtraq 1071 mailing-list, Mon Dec 14 1998, 1072 . 1074 [Sanfilippo1998b] 1075 Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1076 1998, . 1078 [Sanfilippo1999] 1079 Sanfilippo, S., "more ip id", Post to Bugtraq mailing- 1080 list, 1999, 1081 . 1083 [Shimomura1995] 1084 Shimomura, T., "Technical details of the attack described 1085 by Markoff in NYT", Message posted in USENET's 1086 comp.security.misc newsgroup Message-ID: 1087 <3g5gkl$5j1@ariel.sdsc.edu>, 1995, 1088 . 1090 [Silbersack2005] 1091 Silbersack, M., "Improving TCP/IP security through 1092 randomization without sacrificing interoperability", 1093 EuroBSDCon 2005 Conference, 2005, 1094 . 1097 [SUSE2011] 1098 SUSE, "SUSE Security Announcement: Linux kernel security 1099 update (SUSE-SA:2011:046)", 2011, 1100 . 1103 [Ubuntu2011] 1104 Ubuntu, "Ubuntu: USN-1253-1: Linux kernel 1105 vulnerabilities", 2011, 1106 . 1108 [USCERT2001] 1109 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 1110 TCP/IP implementations may use statistically predictable 1111 initial sequence numbers", 2001, 1112 . 1114 [Wright1994] 1115 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 1116 The Implementation", Addison-Wesley, 1994. 1118 [Zalewski2001] 1119 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1120 Number Analysis", 2001, 1121 . 1123 [Zalewski2002] 1124 Zalewski, M., "Strange Attractors and TCP/IP Sequence 1125 Number Analysis - One Year Later", 2001, 1126 . 1128 [Zalewski2003] 1129 Zalewski, M., "A new TCP/IP blind data injection 1130 technique?", 2003, 1131 . 1133 Authors' Addresses 1135 Fernando Gont 1136 SI6 Networks 1137 Evaristo Carriego 2644 1138 Haedo, Provincia de Buenos Aires 1706 1139 Argentina 1141 Phone: +54 11 4650 8472 1142 Email: fgont@si6networks.com 1143 URI: https://www.si6networks.com 1145 Ivan Arce 1146 Quarkslab 1148 Email: iarce@quarkslab.com 1149 URI: https://www.quarkslab.com