Unfortunate History of Transient Numeric Identifiers
SI6 Networks
Segurola y Habana 4310 7mo piso
Ciudad Autonoma de Buenos Aires
Buenos Aires
Argentina
fgont@si6networks.com
https://www.si6networks.com
Quarkslab
Segurola y Habana 4310 7mo piso
Ciudad Autonoma de Buenos Aires
Buenos Aires
Argentina
iarce@quarkslab.com
https://www.quarkslab.com
Internet Research Task Force (IRTF)
This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols, and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF.
Networking protocols employ a variety of transient numeric identifiers for different protocol objects, such as IPv4 and IPv6 Fragment Identifiers , IPv6 Interface Identifiers (IIDs) , transport protocol ephemeral port numbers , TCP Initial Sequence Numbers (ISNs) , NTP Reference IDs (REFIDs) , and DNS Query IDs . These identifiers typically have specific interoperability requirements (e.g. uniqueness during a specified period of time), and associated failure severities when such requirements are not met .
For more than 30 years, a large number of implementations of the IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection, to information leakages that could be exploited for pervasive monitoring . The root cause of these issues has been, in many cases, poor selection of transient numeric identifiers, usually as a result of insufficient or misleading specifications.
For example, implementations have been subject to security or privacy issues resulting from:
Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. , , and )
Predictable IPv6 IIDs (see e.g. , , and )
Predictable transport protocol ephemeral port numbers (see e.g. and )
Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. , , and )
Predictable DNS Query IDs (see e.g. and )
These examples indicate that when new protocols are standardized or implemented, the security and privacy properties of the associated transient numeric identifiers tend to be overlooked, and inappropriate algorithms to generate such identifiers (i.e. that negatively affect the security or privacy properties of the protocol) are either suggested in the specification or selected by implementers.
This document contains a non-exhaustive timeline of the specification and vulnerability disclosures related to some sample transient numeric identifiers, including other work that has led to advances in this area. This analysis indicates that:
Vulnerabilities associated with the inappropriate generation of transient numeric identifiers have affected protocol implementations for an extremely long period of time.
Such vulnerabilities, even when addressed for a given protocol version, were later reintroduced in new versions or new implementations of the same protocol.
Standardization efforts that discuss and provide advice in this area can have a positive effect on IETF specifications and their corresponding implementations.
While it is generally possible to identify an algorithm that can satisfy the interoperability requirements for a given transient numeric identifier, this document provides empirical evidence that doing so without negatively affecting the security or privacy properties of the aforementioned protocols is non-trivial. Other related documents ( and ) provide guidance in this area, as motivated by the present document.
This document represents the consensus of the Privacy Enhancement and Assessment Research Group (PEARG).
A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, transport protocol endpoint, session, etc) from all other objects of the same type, in a given context. Transient numeric identifiers are usually defined as a series of bits, and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically-assigned numeric identifiers (see e.g. ). We note that different identifiers may have additional requirements or properties depending on their specific use in a protocol. We use the term "transient numeric identifier" (or simply "numeric identifier" or "identifier" as short forms) as a generic term to refer to any data object in a protocol specification that satisfies the identification property stated above.
The terms "constant IID", "stable IID", and "temporary IID" are to be
interpreted as defined in .
Throughout this document, we do not consider on-path attacks. That is, we assume the attacker does not have physical or logical access to the system(s) being attacked, and that the attacker can only observe traffic explicitly directed to the attacker. Similarly, an attacker cannot observe traffic transferred between a sender and the receiver(s) of a target protocol, but may be able to interact with any of these entities, including by e.g. sending any traffic to them to sample transient numeric identifiers employed by the target systems when communicating with the attacker.
For example, when analyzing vulnerabilities associated with TCP Initial Sequence Numbers (ISNs), we consider the attacker is unable to capture network traffic corresponding to a TCP connection between two other hosts. However, we consider the attacker is able to communicate with any of these hosts (e.g., establish a TCP connection with any of them), to e.g. sample the TCP ISNs employed by these systems when communicating with the attacker.
Similarly, when considering host-tracking attacks based on IPv6 interface identifiers, we consider an attacker may learn the IPv6 address employed by a victim node if e.g. the address becomes exposed as a result of the victim node communicating with an attacker-operated server. Subsequently, an attacker may perform host-tracking by probing a set of target addresses composed by a set of target prefixes and the IPv6 interface identifier originally learned by the attacker. Alternatively, an attacker may perform host tracking if e.g. the victim node communicates with an attacker-operated server as it moves from one location to another, those exposing its configured addresses. We note that none of these scenarios requires the attacker observe traffic not explicitly directed to the attacker.
While assessing IETF protocol specifications regarding the use of transient numeric identifiers, we have found that most of the issues discussed in this document arise as a result of one of the following conditions:
Protocol specifications that under-specify the requirements for their transient numeric identifiers
Protocol specifications that over-specify their transient numeric identifiers
Protocol implementations that simply fail to comply with the specified requirements
A number of IETF protocol specifications have simply overlooked the security and privacy implications of transient numeric identifiers. Examples of them are the specification of TCP ephemeral ports in , the specification of TCP sequence numbers in , or the specification of the DNS TxID in .
On the other hand, there are a number of IETF protocol specifications that over-specify some of their associated transient numeric identifiers. For example, essentially overloads the semantics of IPv6 Interface Identifiers (IIDs) by embedding link-layer addresses in the IPv6 IIDs, when the interoperability requirement of uniqueness could be achieved in other ways that do not result in negative security and privacy implications . Similarly, suggested the use of a global counter for the generation of Fragment Identification values, when the interoperability properties of uniqueness per {Src IP, Dst IP} could be achieved with other algorithms that do not result in negative security and privacy implications .
Finally, there are implementations that simply fail to comply with the corresponding IETF protocol specifications or recommendations. For example, some popular operating systems (notably Microsoft Windows) still fail to implement transport protocol ephemeral port randomization, as recommended in .
The following subsections document the timelines for a number of sample transient numeric identifiers, that illustrate how the problem discussed in this document has affected protocols from different layers over time. These sample transient numeric identifiers have different interoperability requirements and failure severities (see Section 6 of ), and thus are considered to be representative of the problem being analyzed in this document.
This section presents the timeline of the Identification field employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). The reason for presenting both cases in the same section is to make it evident that while the Identification value serves the same purpose in both IPv4 and IPv6, the work and research done for the IPv4 case did not affect IPv6 specifications or implementations.
The IPv4 Identification is specified in , which specifies the interoperability requirements for the Identification field: the sender must choose the Identification field to be unique for a given source address, destination address, and protocol, for the time the datagram (or any fragment of it) could be alive in the internet. It suggests that a node may keep "a table of Identifiers, one entry for each destination it has communicated with in the last maximum packet lifetime for the internet", and suggests that "since the Identifier field allows 65,536 different values, hosts may be able to simply use unique identifiers independent of destination". The above has been interpreted numerous times as a suggestion to employ per-destination or global counters for the generation of Identification values. While does not suggest any flawed algorithm for the generation of Identification values, the specification omits a discussion of the security and privacy implications of predictable Identification values. This has resulted in many IPv4 implementations generating predictable fragment Identification values by means of a global counter, at least at some point in time.
The IPv6 Identification was originally specified in . It serves the same purpose as its IPv4 counterpart, with the only difference residing in the length of the corresponding field, and that while the IPv4 Identification field is part of the base IPv4 header, in the IPv6 case it is part of the Fragment header (which may or may not be present in an IPv6 packet). states, in Section 4.5, that the Identification must be different than that of any other fragmented packet sent recently (within the maximum likely lifetime of a packet) with the same Source Address and Destination Address. Subsequently, it notes that this requirement can be met by means of a wrap-around 32-bit counter that is incremented each time a packet must be fragmented, and that it is an implementation choice whether to use a global or a per-destination counter. Thus, the implementation of the IPv6 Identification is similar to that of the IPv4 case, with the only difference that in the IPv6 case the suggestions to use simple counters is more explicit. was the first revision of the core IPv6 specification, and maintained the same text for the specification of the IPv6 Identification field. , the second revision of the core IPv6 specification, removes the suggestion from to use a counter for the generation of IPv6 Identification values, and points to for sample algorithms for their generation.
specifies the interoperability requirements for IPv4 Identification value, but does not perform a vulnerability assessment of this transient numeric identifier.
, the first specification of the IPv6 protocol, is published. It suggests that a counter be used to generate the IPv6 Identification value, and notes that it is an implementation choice whether to maintain a single counter for the node or multiple counters, e.g., one for each of the node's possible source addresses, or one for each active (source address, destination address) combination.
finds that predictable IPv4 Identification values (generated by most popular implementations) can be leveraged to count the number of packets sent by a target node. explains how to leverage the same vulnerability to implement a port-scanning technique known as "dumb/idle scan". A tool that implements this attack is publicly released.
, a revision of the IPv6 specification, is published, obsoleting . It maintains the same specification of the IPv6 Identification field as its predecessor ().
OpenBSD implements randomization of the IPv4 Identification field .
discusses how to leverage predictable IPv4 Identification to uncover the rules of a number of firewalls.
documents the implementation of the "idle/dumb scan" technique in the popular nmap tool.
explains how the IPv4 Identification field can be exploited to count the number of systems behind a NAT.
OpenBSD implements randomization of the IPv6 Identification field .
explains a technique to perform TCP data injection attacks based on predictable IPv4 identification values, which requires less effort than TCP injection attacks performed with bare TCP packets.
discusses shortcomings in a number of techniques to mitigate predictable IPv4 Identification values.
describes a weakness in the pseudo random number generator (PRNG) in use for the generation of the IP Identification by a number of operating systems.
describes how to perform dumb/idle scan attacks in IPv6.
Linux mitigates predictable IPv6 Identification values .
describes the security implications of predictable IPv6 Identification values, and possible mitigations. This document has the Intended Status of "Standards Track", with the intention to formally update , to introduce security and privacy requirements on the generation of IPv6 Identification values.
notes that some major IPv6 implementations still employ predictable IPv6 Identification values.
The 6man WG adopts , but changes the track to "BCP" (while still formally updating ), publishing the resulting document as .
A patch to incorporate support for IPv6-based idle/dumb scans in nmap is submitted .
The 6man WG changes the Intended Status of to "Informational" and publishes it as . As a result, it no longer formally updates , and security and privacy requirements on the generation of IPv6 Identification values are eliminated.
notes that some popular host and router implementations still employ predictable IPv6 Identification values.
(based on ) analyzes the security and privacy implications of predictable IPv6 Identification values, and provides guidance for selecting an algorithm to generate such values. However, being published with the Intended Status of "Informational", it does not formally update , and does not introduce security and privacy requirements on the generation of IPv6 Identification values.
, revision of , removes the suggestion from RFC2460 to use a counter for the generation of IPv6 Identification values, but does not perform a vulnerability assessment of the generation of IPv6 Identification values, and does not introduce security and privacy requirements on the generation of IPv6 Identification values.
is finally published as , obsoleting , and pointing to for sample algorithms for the generation of IPv6 Fragment Identification values. However, it does not introduce security and privacy requirements on the generation of IPv6 Identification values.
notes that the IPv6 ID generators of two popular operating systems are flawed.
suggests that the choice of the ISN of a connection is not arbitrary, but aims to reduce the chances of a stale segment from being accepted by a new incarnation of a previous connection. suggests the use of a global 32-bit ISN generator that is incremented by 1 roughly every 4 microseconds. However, as a matter of fact, protection against stale segments from a previous incarnation of the connection is enforced by preventing the creation of a new incarnation of a previous connection before 2*MSL have passed since a segment corresponding to the old incarnation was last seen (where "MSL" is the "Maximum Segment Lifetime" ). This is accomplished by the TIME-WAIT state and TCP's "quiet time" concept (see Appendix B of ). Based on the assumption that ISNs are monotonically increasing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an incoming SYN segment to perform "heuristics" that enable the creation of a new incarnation of a connection while the previous incarnation is still in the TIME-WAIT state (see p. 945 of ). This avoids an interoperability problem that may arise when a node establishes connections to a specific TCP end-point at a high rate .
The interoperability requirements for TCP ISNs are probably not as clearly spelled out as one would expect. Furthermore, the suggestion of employing a global counter in negatively affects the security and privacy properties of the protocol.
, suggests the use of a global 32-bit ISN
generator, whose lower bit is incremented roughly every 4 microseconds. However, such an ISN generator makes it trivial to predict the ISN that a TCP instance will use for new connections, thus allowing a variety of attacks against TCP.
was the first to describe how to exploit predictable TCP ISNs for forging TCP connections that could then be leveraged for trust relationship exploitation.
discussed the security considerations for predictable ISNs (along with a range of other protocol-based vulnerabilities).
reported a real-world exploitation of the attack described in ten years before (in 1985).
was the first IETF effort, authored by Steven Bellovin, to address predictable TCP ISNs. However, does not formally update . The same concept specified in this document for TCP ISNs was later proposed for TCP ephemeral ports , TCP Timestamps, and eventually even IPv6 Interface Identifiers .
OpenBSD implements TCP ISN randomization based on random increments (please see Appendix A.2 of ) .
OpenBSD implements TCP ISN randomization using simple randomization (please see Section 7.1 of ) .
provides a detailed analysis of statistical weaknesses in some ISN generators, and includes a survey of the algorithms in use by popular TCP implementations.
Vulnerability advisories were released regarding statistical weaknesses in some ISN generators, affecting popular TCP implementations.
updates and complements . It concludes that "while some vendors [...] reacted promptly and tested their solutions properly, many still either ignored the issue and never evaluated their implementations, or implemented a flawed solution that apparently was not tested using a known approach" .
OpenBSD implements TCP ISN randomization based on the algorithm specified in (currently obsoleted and replaced by ) for the TCP endpoint that performs the active open, while keeping the simple randomization scheme for the endpoint performing the passive open . This provides monotonically-increasing ISNs for the client side (allowing the BSD heuristics to work as expected), while avoiding any patterns in the ISN generation for the server side.
, published 27 years after Morris' original work , formally updates to mitigate predictable TCP ISNs.
, the upcoming revision of the core TCP protocol specification, incorporates the algorithm specified in as the recommended ("SHOULD") algorithm for TCP ISN generation.
IPv6 Interface Identifiers can be generated as a result of different mechanisms, including SLAAC , DHCPv6 , and manual configuration. This section focuses on Interface Identifiers resulting from SLAAC.
The Interface Identifier of stable (traditional) IPv6 addresses resulting from SLAAC have traditionally resulted in the underlying link-layer address being embedded in the IID. At the time, employing the underlying link-layer address for the IID was seen as a convenient way to obtain a unique address. However, recent awareness about the security and privacy properties of this approach has led to the replacement of this flawed scheme with an alternative one that does not negatively affect the security and privacy properties of the protocol.
specifies the syntax of IPv6 global addresses (referred to as "An IPv6 Provider-Based Unicast Address Format" at the time), consistent with the IPv6 addressing architecture specified in . Hosts are recommended to "generate addresses using link-specific addresses as Interface ID such as 48 bit IEEE-802 MAC addresses".
specifies "An IPv6 Aggregatable Global Unicast Address Format" (obsoleting ) changing the size of the IID to 64 bits, and specifies that IIDs must be constructed in IEEE EUI-64 format. How such identifiers are constructed becomes specified in the corresponding "IPv6 over <link>" specifications, such as "IPv6 over Ethernet".
recognizes the problem of network activity correlation, and specifies temporary addresses. Temporary addresses are to be used along with stable addresses.
obsoletes , making the TLA/NLA structure historic. The syntax and recommendations for the traditional stable IIDs remain unchanged, though.
is published as the latest "IP Version 6 Addressing Architecture", requiring the IIDs of the traditional (stable) IPv6 addresses resulting from SLAAC to employ the Modified EUI-64 format. The details of constructing such interface identifiers are defined in the corresponding "IPv6 over <link>" specifications.
provides hints regarding how patterns in IPv6 addresses could be leveraged for the purpose of address scanning.
notes that the traditional scheme for generating stable addresses allows for address scanning, and also does not prevent active node tracking. It also specifies an alternative algorithm meant to replace IIDs based on Modified EUI-64 format identifiers.
The 6man WG adopts as a working group item (as ). However, the document no longer formally updates , and therefore the specified algorithm no longer formally replaces the Modified EUI-64 format identifiers.
An address-scanning tool (scan6 of ) that leverages IPv6 address patterns is released .
elaborates on the security and privacy properties of all known algorithms for generating IPv6 IIDs.
The 6man WG publishes ("Recommendation on Stable IPv6 Interface Identifiers"), recommending for the generation of stable addresses.
(formerly ) is published, specifying "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" as an alternative to (but *not* replacement of) Modified EUI-64 format IIDs.
(formerly , and later ), about "Network Reconnaissance in IPv6 Networks", is published.
(formerly and later ), about "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", is published.
is published, with the goal of specifying requirements for non-stable addresses, and updating such that use of only temporary addresses is allowed.
is published, providing an analysis of how different aspects on an address (from stability to usage mode) affect their corresponding security and privacy properties, and meaning to eventually provide advice in this area.
The 6man WG publishes ("Recommendation on Stable IPv6 Interface Identifiers") (formerly ), with requirements for stable addresses and a recommendation to employ for the generation of stable addresses. It formally updates a large number of RFCs.
is published (as suggested by the 6man WG), to address flaws in by revising it (as an alternative to the effort, published in March 2016).
is adopted (as ) as a WG item of the 6man WG.
is approved by the IESG for publication as an RFC.
is finally published as .
The NTP Reference ID is a 32-bit code identifying the particular server or reference clock. Above stratum 1 (secondary servers and clients), this value can be employed to avoid degree-one timing loops; that is, scenarios where two NTP peers are (mutually) the time source of each other. If using the IPv4 address family, the identifier is the four-octet IPv4 address. If using the IPv6 address family, it is the first four octets of the MD5 hash of the IPv6 address.
, "Network Time Protocol Version 4: Protocol and Algorithms Specification" is published. It specifies that for NTP peers with stratum higher than 1 the REFID embeds the IPv4 Address of the time source or an MD5 hash of the IPv6 address of the time source.
is published, describing the information leakage produced via the NTP REFID. It proposes that NTP returns a special REFID when a packet employs an IP Source Address that is not believed to be a current NTP peer, but otherwise generates and returns the traditional REFID. It is subsequently adopted by the NTP WG as .
notes that the proposed fix specified in is, at the very least, sub-optimal. As a result of lack of WG support, the effort is eventually abandoned.
Most (if not all) transport protocols employ "port numbers" to demultiplex packets to the corresponding transport protocol instances.
notes that the UDP source port is optional and identifies the port of the sending process. It does not specify interoperability requirements for source port selection, nor does it suggest possible ways to select port numbers. Most popular implementations end up selecting source ports from a system-wide global counter.
(the TCP specification) essentially describes the use of port numbers, and specifies that port numbers should result in a unique socket pair (local address, local port, remote address, remote port). How ephemeral ports (i.e. port numbers for "active opens") are selected, and the port range from which they are selected, are left unspecified.
OpenBSD implements ephemeral port randomization .
The CERT Coordination Centre published details of what became known as the "Kaminsky Attack" on the DNS. The attack exploited the lack of source port randomization in many major DNS implementations to perform cache poisoning in an effective and practical manner.
mandates the use of port randomization for DNS resolvers, and mandates that implementations must randomize ports from the range (53 or 1024, and above) or the largest possible port range. It does not recommend possible algorithms for port randomization, although the document specifically targets DNS resolvers, for which a simple port randomization suffices (e.g. Algorithm 1 of ). This document led to the implementation of port randomization in the DNS resolver themselves, rather than in the underlying transport-protocols.
notes that many TCP and UDP implementations result in predictable port numbers, and also notes that many implementations select port numbers from a small portion of the whole port number space. It recommends the implementation and use of ephemeral port randomization, proposes a number of possible algorithms for port randomization, and also recommends to randomize port numbers over the range 1024-65535.
reports a non-normal distribution of the ephemeral port numbers employed by the NTP clients of an Internet Time Service.
notes that some NTP implementations employ the NTP service port (123) as the local port for non-symmetric modes, and aims to update the NTP specification to recommend port randomization in such cases, in line with . The proposal experiences some push-back in the relevant working group (NTP WG) , but is finally adopted as a working group item as .
is finally published as .
The DNS Query ID can be employed to match DNS replies to outstanding DNS queries.
specifies that the ID is a 16 bit identifier assigned by the program that
generates any kind of query, and that this identifier is copied in the corresponding reply and can be used by the requester to match up replies to outstanding queries. It does not specify the interoperability requirements for these numeric identifiers, nor does it suggest an algorithm for generating them.
describes DNS cache poisoning attacks that require the attacker to guess the Query ID.
suggests that both the UDP source port and the ID of query packets should be randomized, although that might not provide enough entropy to prevent an attacker from guessing these values.
finds that implementations employ predictable UDP source ports and predictable Query IDs, and argues that both should be randomized.
finds that by spoofing multiple requests for the same domain name from different IP addresses, an attacker may guess the Query ID employed for a victim with a high probability of success, thus performing DNS cache poisoning attacks.
finds that a popular DNS server software (BIND 9) that randomizes the Query ID is still subject to DNS cache poisoning attacks by forging a large number of queries and leveraging the birthday paradox.
finds that Microsoft Windows DNS Server generates predictable Query ID values.
finds that OpenBSD's DNS software (based on ISC's BIND DNS Server) generates predictable Query ID values.
is published, requiring resolvers to randomize the Query ID of DNS queries, and to verify that the Query ID of a DNS reply matches that of the DNS query as part of the DNS reply validation process.
finds that Windows SMTP Service implements its own DNS resolver that results in predictable Query ID values. Additionally, it fails to validate that the Query ID of DNS reply matches the one from the DNS query that supposedly elicited the reply.
For more than 30 years, a large number of implementations of the IETF protocols have been subject to a variety of attacks, with
effects ranging from Denial of Service (DoS) or data injection, to
information leakages that could be exploited for pervasive monitoring
. The root cause of these issues has been, in many cases,
poor selection of transient numeric identifiers, usually as a result
of insufficient or misleading specifications.
While it is generally possible to identify an algorithm that can
satisfy the interoperability requirements for a given transient
numeric identifier, this document provides empirical evidence that
doing so without negatively affecting the security or privacy
properties of the aforementioned protocols is non-trivial. It is thus
evident that advice in this area is warranted.
aims at requiring future
IETF protocol specifications to contain analysis of the security and
privacy properties of any transient numeric identifiers specified by
the protocol, and to recommend an algorithm for the generation
of such transient numeric identifiers. specifies a number of sample algorithms for generating
transient numeric identifiers with specific interorability
requirements and failure severities.
There are no IANA registries within this document.
This document analyzes the timeline of the specification and implementation of the transient numeric identifiers of some sample IETF protocols, and how the security and privacy properties of such protocols have been affected as a result of it. It provides concrete evidence that advice in this area is warranted.
formally requires IETF protocol specifications to specify the interoperability requirements for their transient numeric identifiers, to do a warranted vulnerability assessment of such transient numeric identifiers, and to recommend possible algorithms for their generation, such that the interoperability requirements are complied with, while any negative security and privacy properties of these transient numeric identifiers are mitigated.
analyzes and categorizes transient numeric identifiers based on their interoperability requirements and their associated failure severities, and recommends possible algorithms that can comply with those requirements without negatively affecting the security and privacy properties of the corresponding protocols.
The authors would like to thank (in alphabetical order) Bernard Aboba, Dave Crocker, Spencer Dawkins, Theo de Raadt, Sara Dickinson, Guillermo Gont, Christian Huitema, Colin Perkins, Vincent Roca, Kris Shrishak, Joe Touch, Brian Trammell, and Christopher Wood, for providing valuable comments on earlier versions of this document.
The authors would like to thank (in alphabetical order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for providing valuable comments on , on which this document is based.
of this document borrows text from , authored by Fernando Gont and Steven Bellovin.
The authors would like to thank Sara Dickinson and Christopher Wood, for their guidance during the publication process of this document.
The authors would like to thank Diego Armando Maradona for his magic and inspiration.
Implementation of port randomization
OpenBSD
Multiple DNS implementations vulnerable to cache poisoning (Vulnerability Note VU#800113)
CERT/CC
Protocol Registries
Beta release of the SI6 Network's IPv6 Toolkit (help wanted!)
SI6 Networks' IPv6 Toolkit
SI6 Networks
A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
IPv6 Address Usage Recommendations
Recommendation on Non-Stable IPv6 Interface Identifiers
Recommendation on Stable IPv6 Interface Identifiers
Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6
SI6 Networks /
UTN-FRH
Ericsson Research
IBM Corporation
Microsoft Research
Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6
SI6 Networks /
UTN-FRH
Ericsson Research
IBM Corporation
Microsoft Research
Network Time Protocol Not You REFID
Boston University
Network Time Foundation
Network Time Protocol Not You REFID
Boston University
Network Time Foundation
[Ntp] Comments on draft-ietf-ntp-refid-updates-05
TCP/IP Illustrated, Volume 2: The Implementation
Strange Attractors and TCP/IP Sequence Number Analysis
Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later
Security Problems in the TCP/IP Protocol Suite
A Weakness in the 4.2BSD UNIX TCP/IP Software
US-CERT Vulnerability Note VU#498440: Multiple TCP/IP implementations may use statistically predictable initial sequence numbers
CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence Numbers
Technical details of the attack described by Markoff in NYT
Transmission Control Protocol Specification
This document specifies the Internet's Transmission Control Protocol
(TCP). TCP is an important transport layer protocol in the Internet
stack, and has continuously evolved over decades of use and growth of
the Internet. Over this time, a number of changes have been made to
TCP as it was specified in RFC 793, though these have only been
documented in a piecemeal fashion. This document collects and brings
those changes together with the protocol specification from RFC 793.
This document obsoletes RFC 793 and several other RFCs (TODO: list
all actual RFCs when finished).
RFC EDITOR NOTE: If approved for publication as an RFC, this should
be marked additionally as "STD: 7" and replace RFC 793 in that role.
Implementation of TCP ISN randomization based on random increments
OpenBSD
Implementation of TCP ISN randomization based on simple randomization
OpenBSD
Implementation of RFC1948 for TCP ISN randomization
OpenBSD
[Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
1706
Haedo
Provincia de Buenos Aires
Argentina
+54 11 4650 8472
fgont@si6networks.com
https://www.si6networks.com
Usage Analysis of the NIST Internet Time Service
From IP ID to Device ID and KASLR Bypass (Extended Version)
A Technique for Counting NATted Hosts
Idle scanning and related IP ID games
about the ip header id
Idle scan
more ip id
[PATCH] TCP Idle Scan in IPv6
Randomization of the IPv4 Identification field
OpenBSD
Randomization of the IPv6 Identification field
OpenBSD
Improving TCP/IP security through randomization without sacrificing interoperability
The FreeBSD Project
A new TCP/IP blind data injection technique?
BIND Vulnerabilities and Solutions
Core Seguridad del Informacion
Core Seguridad del Informacion
OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability
Hacking IPv6 Networks (training course)
RedHat Security Advisory RHSA-2011:1465-1: Important: kernel security and bug fix update
Ubuntu: USN-1253-1: Linux kernel vulnerabilities
SUSE Security Announcement: Linux kernel security update (SUSE-SA:2011:046)
Recent Advances in IPv6 Security
Security Implications of Predictable Fragment Identification Values
Security Implications of Predictable Fragment Identification Values
Security Implications of Predictable Fragment Identification Values
IPv6 specifies the Fragment Header, which is employed for the
fragmentation and reassembly mechanisms. The Fragment Header
contains an "Identification" field which, together with the IPv6
Source Address and the IPv6 Destination Address of the packet,
identifies fragments that correspond to the same original datagram,
such that they can be reassembled together at the receiving host.
The only requirement for setting the "Identification" value is that
it must be different than that of any other fragmented packet sent
recently with the same Source Address and Destination Address. Some
implementations simply use a global counter for setting the Fragment
Identification field, thus leading to predictable values. This
document analyzes the security implications of predictable
Identification values, and updates RFC 2460 specifying additional
requirements for setting the Fragment Identification, such that the
aforementioned security implications are mitigated.
Security Implications of Predictable Fragment Identification Values
Security Implications of Predictable Fragment Identification Values
IPv6 specifies the Fragment Header, which is employed for the
fragmentation and reassembly mechanisms. The Fragment Header
contains an "Identification" field which, together with the IPv6
Source Address and the IPv6 Destination Address of a packet,
identifies fragments that correspond to the same original datagram,
such that they can be reassembled together by the receiving host.
The only requirement for setting the "Identification" field is that
the corresponding value must be different than that employed for any
other fragmented packet sent recently with the same Source Address
and Destination Address. Some implementations use a simple global
counter for setting the Identification field, thus leading to
predictable Identification values. This document analyzes the
security implications of predictable Identification values, and
provides implementation guidance for selecting the Identification
field of the Fragment Header, such that the aforementioned security
implications are mitigated.
ADDRESSING WEAKNESSES IN THE DOMAIN NAME SYSTEM PROTOCOL
DNS and BIND Security Issues
BIND 9 DNS Cache Poisoning
Windows DNS Server Cache Poisoning
CAIS-ALERT: Vulnerability in the sending requests control of BIND
Black Ops 2008: It's The End Of The Cache As We Know It
Windows SMTP Service DNS query Id vulnerabilities