< draft-gont-numeric-ids-history-04.txt   draft-gont-numeric-ids-history-05.txt >
Network Working Group F. Gont Network Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks
Intended status: Informational I. Arce Intended status: Informational I. Arce
Expires: September 12, 2019 Quarkslab Expires: January 9, 2020 Quarkslab
March 11, 2019 July 8, 2019
Unfortunate History of Transient Numeric Identifiers Unfortunate History of Transient Numeric Identifiers
draft-gont-numeric-ids-history-04 draft-gont-numeric-ids-history-05
Abstract Abstract
This document performs an analysis of the security and privacy This document analyzes the timeline of the specification of different
implications of different types of "numeric identifiers" used in IETF types of "numeric identifiers" used in IETF protocols, and how the
protocols, and tries to categorize them based on their security and privacy implications of such protocols has been affected
interoperability requirements and the associated failure severity as a result of it. It provides concrete evidence that advice in this
when such requirements are not met. It describes a number of area is warranted.
algorithms that have been employed in real implementations to meet
such requirements and analyzes their security and privacy properties.
Additionally, it provides advice on possible algorithms that could be
employed to satisfy the interoperability requirements of each
identifier type, while minimizing the security and privacy
implications, thus providing guidance to protocol designers and
protocol implementers. Finally, it provides recommendations for
future protocol specifications regarding the specification of the
aforementioned numeric identifiers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 13
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may not be modified, and derivative works of it may not This document may not be modified, and derivative works of it may not
be created, and it may not be published except as an Internet-Draft. be created, and it may not be published except as an Internet-Draft.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . . . 5 4. IPv4/IPv6 Identification . . . . . . . . . . . . . . . . . . 4
5. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . . . 8 5. TCP Initial Sequence Numbers (ISNs) . . . . . . . . . . . . . 8
6. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . . . 9 6. IPv6 Interface Identifiers (IIDs) . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. NTP Reference IDs (REFID) . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Transport Protocol Port Numbers . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Network protocols employ a variety of numeric identifiers for Network protocols employ a variety of numeric identifiers for
different protocol entities, ranging from DNS Transaction IDs (TxIDs) different protocol entities, ranging from DNS Transaction IDs (TxIDs)
to transport protocol numbers (e.g. TCP ports) or IPv6 Interface to transport protocol numbers (e.g. TCP ports) or IPv6 Interface
Identifiers (IIDs). These identifiers usually have specific Identifiers (IIDs). These identifiers usually have specific
properties that must be satisfied such that they do not result in properties that must be satisfied such that they do not result in
negative interoperability implications (e.g. uniqueness during a negative interoperability implications (e.g. uniqueness during a
specified period of time), and associated failure severities when specified period of time), and associated failure severity when such
such properties are not met, ranging from soft to hard failures. properties are not met, ranging from soft to hard failures.
For more than 30 years, a large number of implementations of the TCP/ For more than 30 years, a large number of implementations of the TCP/
IP protocol suite have been subject to a variety of attacks, with IP protocol suite have been subject to a variety of attacks, with
effects ranging from Denial of Service (DoS) or data injection, to effects ranging from Denial of Service (DoS) or data injection, to
information leakage that could be exploited for pervasive monitoring information leakage that could be exploited for pervasive monitoring
[RFC7528]. The root of these issues has been, in many cases, the [RFC7258]. The root of these issues has been, in many cases, the
poor selection of identifiers in such protocols, usually as a result poor selection of identifiers in such protocols, usually as a result
of an insufficient or misleading specification. While it is of an insufficient or misleading specification. While it is
generally trivial to identify an algorithm that can satisfy the generally trivial to identify an algorithm that can satisfy the
interoperability requirements for a given identifier, there exists interoperability requirements for a given identifier, there exists
practical evidence that doing so without negatively affecting the practical evidence that doing so without negatively affecting the
security and/or privacy properties of the aforementioned protocols is security and/or privacy properties of the aforementioned protocols is
prone to error. prone to error.
For example, implementations have been subject to security and/or For example, implementations have been subject to security and/or
privacy issues resulting from: privacy issues resulting from:
skipping to change at page 3, line 28 skipping to change at page 3, line 19
[Morris1985]) [Morris1985])
o Predictable ephemeral transport protocol numbers (see e.g. o Predictable ephemeral transport protocol numbers (see e.g.
[RFC6056] and [Silbersack2005]) [RFC6056] and [Silbersack2005])
o Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. o Predictable IPv4 or IPv6 Fragment Identifiers (see e.g.
[RFC5722], [RFC6274], and [RFC7739]) [RFC5722], [RFC6274], and [RFC7739])
o Predictable IPv6 IIDs (see e.g. [RFC7721] and [RFC7707]) o Predictable IPv6 IIDs (see e.g. [RFC7721] and [RFC7707])
o Predictable DNS TxIDs o Predictable DNS TxIDs [RFC1035]
Recent history indicate that when new protocols are standardized or Recent history indicate that when new protocols are standardized or
new protocol implementations are produced, the security and privacy new protocol implementations are produced, the security and privacy
properties of the associated identifiers tend to be overlooked and properties of the associated identifiers tend to be overlooked and
inappropriate algorithms to generate identifier values are either inappropriate algorithms to generate identifier values are either
suggested in the specification or selected by implementers. suggested in the specification or selected by implementers.
This document contains a non-exhaustive timeline of vulnerability This document contains a non-exhaustive timeline of vulnerability
disclosures related to some sample transient numeric identifiers and disclosures related to some sample transient numeric identifiers and
other work that has led to advances in this area, with the goal of other work that has led to advances in this area, with the goal of
skipping to change at page 6, line 33 skipping to change at page 6, line 21
IPv6 Identification value. IPv6 Identification value.
November 1999: November 1999:
[Sanfilippo1999] discusses how to leverage predictable IPv4 [Sanfilippo1999] discusses how to leverage predictable IPv4
Identification to uncover the rules of a number of firewalls. Identification to uncover the rules of a number of firewalls.
November 1999: November 1999:
[Bellovin2002] explains how the IPv4 Identification field can be [Bellovin2002] explains how the IPv4 Identification field can be
exploited to count the number of systems behind a NAT. exploited to count the number of systems behind a NAT.
September 2002:
[Fyodor2002] explains how to implement a stealth port-scanning
technique by leveraging nodes that employ predictable IPv4
Identification values.
December 2003: December 2003:
[Zalewski2003] explains a technique to perform TCP data injection [Zalewski2003] explains a technique to perform TCP data injection
attack based on predictable IPv4 identification values which attack based on predictable IPv4 identification values which
requires less effort than TCP injection attacks performed with requires less effort than TCP injection attacks performed with
bare TCP packets. bare TCP packets.
November 2005: November 2005:
[Silbersack2005] discusses shortcoming in a number of techniques [Silbersack2005] discusses shortcoming in a number of techniques
to mitigate predictable IPv4 Identification values. to mitigate predictable IPv4 Identification values.
skipping to change at page 8, line 7 skipping to change at page 7, line 47
algorithm to generate such values. However, being published on algorithm to generate such values. However, being published on
the Informational track, it does not formally update [RFC2460]. the Informational track, it does not formally update [RFC2460].
June 2016: June 2016:
[I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the [I-D.ietf-6man-rfc2460bis], revision of [RFC2460], removes the
suggestion from RFC2460 to employ a global counter for the suggestion from RFC2460 to employ a global counter for the
generation of IPv6 Identification values, but does not specify any generation of IPv6 Identification values, but does not specify any
security and privacy requirements for the IPv6 Identification security and privacy requirements for the IPv6 Identification
value. value.
July 2017:
[I-D.ietf-6man-rfc2460bis] is finally published as [RFC8200],
obsoleting [RFC2460], and pointing to [RFC7739] for sample
algorithms for the generation of IPv6 Fragment Identification
values.
June 2019:
[IPID-DEV] notes that the IPv6 ID generator of the current version
of a popular operating system is flawed.
5. TCP Initial Sequence Numbers (ISNs) 5. TCP Initial Sequence Numbers (ISNs)
[RFC0793] suggests that the choice of the ISN of a connection is not [RFC0793] suggests that the choice of the ISN of a connection is not
arbitrary, but aims to reduce the chances of a stale segment from arbitrary, but aims to reduce the chances of a stale segment from
being accepted by a new incarnation of a previous connection. being accepted by a new incarnation of a previous connection.
[RFC0793] suggests the use of a global 32-bit ISN generator that is [RFC0793] suggests the use of a global 32-bit ISN generator that is
incremented by 1 roughly every 4 microseconds. However, as a matter incremented by 1 roughly every 4 microseconds. However, as a matter
of fact, protection against stale segments from a previous of fact, protection against stale segments from a previous
incarnation of the connection is enforced by preventing the creation incarnation of the connection is enforced by preventing the creation
of a new incarnation of a previous connection before 2*MSL have of a new incarnation of a previous connection before 2*MSL have
skipping to change at page 9, line 45 skipping to change at page 9, line 45
formally updates [RFC0793] to mitigate predictable TCP ISNs. formally updates [RFC0793] to mitigate predictable TCP ISNs.
August 2014: August 2014:
[I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP [I-D.eddy-rfc793bis-04], the upcoming revision of the core TCP
protocol specification, incorporates the algorithm specified in protocol specification, incorporates the algorithm specified in
[RFC6528] as the recommended algorithm for TCP ISN generation. [RFC6528] as the recommended algorithm for TCP ISN generation.
6. IPv6 Interface Identifiers (IIDs) 6. IPv6 Interface Identifiers (IIDs)
IPv6 Interface Identifiers can be generated in multiple ways: SLAAC IPv6 Interface Identifiers can be generated in multiple ways: SLAAC
[RFC4862], DHCPv6 [RFC3315], and manual configuration. This section [RFC4862], DHCPv6 [RFC8415], and manual configuration. This section
focuses on Interface Identifiers resulting from SLAAC. focuses on Interface Identifiers resulting from SLAAC.
The Interface Identifier of stable (traditional) IPv6 addresses The Interface Identifier of stable (traditional) IPv6 addresses
resulting from SLAAC have traditionally resulted in the underlying resulting from SLAAC have traditionally resulted in the underlying
link-layer address being embedded in the IID. IPv6 addresses link-layer address being embedded in the IID. IPv6 addresses
resulting from SLAAC are currently required to employ Modified EUI-64 resulting from SLAAC are currently required to employ Modified EUI-64
format identifiers, which essentially embed the underlying link-layer format identifiers, which essentially embed the underlying link-layer
address of the corresponding network interface. At the time, address of the corresponding network interface. At the time,
employing the underlying link-layer address for the IID was seen as a employing the underlying link-layer address for the IID was seen as a
convenient way to obtain a unique address. However, recent awareness convenient way to obtain a unique address. However, recent awareness
about the security and privacy implications of this approach, and about the security and privacy implications of this approach
thus ongoing work [I-D.ietf-6man-default-iids] at the IETF is in the [RFC7707] [RFC7721] has led to the replacement of such flawed scheme
process of addressing this problem. with an alternative one that mitigates its security and privacy
implications [RFC7217] [RFC8064].
January 1997: January 1997:
[RFC2073] specifies the syntax of IPv6 global addresses (referred [RFC2073] specifies the syntax of IPv6 global addresses (referred
to as "An IPv6 Provider-Based Unicast Address Format" at the to as "An IPv6 Provider-Based Unicast Address Format" at the
time), consistent with the IPv6 addressing architecture specified time), consistent with the IPv6 addressing architecture specified
in [RFC1884]. Hosts are recommended to "generate addresses using in [RFC1884]. Hosts are recommended to "generate addresses using
link-specific addresses as Interface ID such as 48 bit IEEE-802 link-specific addresses as Interface ID such as 48 bit IEEE-802
MAC addresses". MAC addresses".
July 1998: July 1998:
skipping to change at page 12, line 12 skipping to change at page 12, line 12
of specifying requirements for non-stable addresses, and updating of specifying requirements for non-stable addresses, and updating
[RFC4941] such that use of only temporary addresses is allowed. [RFC4941] such that use of only temporary addresses is allowed.
May 2016: May 2016:
[draft-gont-6man-address-usage-recommendations-00] is published, [draft-gont-6man-address-usage-recommendations-00] is published,
providing an analysis of how different aspects on an address (from providing an analysis of how different aspects on an address (from
stability to usage mode) affect their corresponding security and stability to usage mode) affect their corresponding security and
privacy implications, and meaning to eventually provide advice in privacy implications, and meaning to eventually provide advice in
this area. this area.
7. IANA Considerations February 2017:
The 6man wg publishes [RFC8064] ("Recommendation on Stable IPv6
Interface Identifiers") (formely [I-D.ietf-6man-default-iids]),
with requirements for stable addresses and a recommendation to
employ [RFC7217] for the generation of stable addresses. It
formally updated a large number of RFCs.
March 2018:
[draft-fgont-6man-rfc4941bis-00] is published (as suggested by the
6man wg), to address flaws in [RFC4941] by revising it (as an
alternative to the [draft-gont-6man-non-stable-iids-00] effort,
published in March 2016).
July 2018:
[draft-ietf-6man-rfc4941bis-00] is adopted (as
[draft-fgont-6man-rfc4941bis-00]) as a wg item of the 6man wg.
7. NTP Reference IDs (REFID)
The NTP [RFC5905] is employed to avoid timing loops degree-one timing
loops in scenarios where two NTP peers are (mutually) the time source
of each other.
June 2010:
[RFC5905], "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 soucre or an MD5 hash of the IPv6 address of the time
source.
July 2016:
[draft-stenn-ntp-not-you-refid-00] is published, describing the
information leakage produced via de 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
[I-D.ietf-ntp-refid-updates].
April 2019:
[Gont-NTP] notes that the proposed fix specified in
[draft-ietf-ntp-refid-updates-00] is, at the very least, sub-
optimal.
8. Transport Protocol Port Numbers
Most (if not all) transport protocols employ "port numbers" to
demultiplex packets to the corresponding transport protocol
instances.
August 1980:
[RFC0768] 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.
September 1981:
[RFC0793] (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.
January 2009:
[RFC5452] mandates the use of port randomization for DNS
resolvers, and mandates that implementations must randomize port
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 random port suffices (e.g.
Algorithm 1 of [RFC6056]). This document led to the
implementation of port randomization in the DNS resolver
themselves, rather than in the underlying transport-protocols.
January 2011:
[RFC6056] 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.
March 2016:
[NIST-NTP] reports a non-normal distribution of the ephemeral port
numbers employed by the NTP clients of an Internet Time Service.
April 2019:
[I-D.gont-ntp-port-randomization] 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 such that
they employ port randomization in such cases, as recommended by
[RFC6056]. The proposal experiments some push-back in the
relevant working group (NTP WG) [NTP-PORTR].
9. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
8. Security Considerations 10. Security Considerations
The entire document is about the security and privacy implications of This document analyzes the timeline of the specification of different
transient numeric identifiers. types of "numeric identifiers" used in IETF protocols, and how the
security and privacy implications of such protocols has been affected
as a result of it. It provides concrete evidence that advice in this
area is warranted. [I-D.gont-numeric-ids-sec-considerations]
formally requires protocol specifications to do a warranted analysis
of the interoperability implications of the transient numeric
identifiers they specify, and to recommend possible algorithms for
their generation, such that possible security and privacy
implications are mitigated. [I-D.gont-numeric-ids-generation]
analyzes categorizes transient numeric identifiers based on their
interoperability requirements and their associated failure modes, and
recommends possible algorithms to that can comply with the associated
requirements while mitigating possible security and privacy
implications.
9. Acknowledgements 11. Acknowledgements
The authors would like to thank (in alphabetical order) Dave Crocker, The authors would like to thank (in alphabetical order) Dave Crocker,
Christian Huitema, and Joe Touch, for providing valuable comments on Christian Huitema, and Joe Touch, for providing valuable comments on
earlier versions of this document. earlier versions of this document.
The authors would like to thank (in alphabetical order) Steven The authors would like to thank (in alphabetical order) Steven
Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for
providing valuable comments on [I-D.gont-predictable-numeric-ids], on providing valuable comments on [I-D.gont-predictable-numeric-ids], on
which this document is based. which this document is based.
Section 5 of this document borrows text from [RFC7528], authored by Section 5 of this document borrows text from [RFC6528], authored by
Fernando Gont and Steven Bellovin. Fernando Gont and Steven Bellovin.
The authors would like to thank Diego Armando Maradona for his magic The authors would like to thank Diego Armando Maradona for his magic
and inspiration. and inspiration.
10. References 12. References
10.1. Normative References 12.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
skipping to change at page 13, line 41 skipping to change at page 16, line 14
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
DOI 10.17487/RFC3041, January 2001, DOI 10.17487/RFC3041, January 2001,
<https://www.rfc-editor.org/info/rfc3041>. <https://www.rfc-editor.org/info/rfc3041>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587,
August 2003, <https://www.rfc-editor.org/info/rfc3587>. August 2003, <https://www.rfc-editor.org/info/rfc3587>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452,
DOI 10.17487/RFC5452, January 2009,
<https://www.rfc-editor.org/info/rfc5452>.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, DOI 10.17487/RFC5722, December 2009, RFC 5722, DOI 10.17487/RFC5722, December 2009,
<https://www.rfc-editor.org/info/rfc5722>. <https://www.rfc-editor.org/info/rfc5722>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", Protocol Port Randomization", BCP 156, RFC 6056,
RFC 6151, DOI 10.17487/RFC6151, March 2011, DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc6056>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <https://www.rfc-editor.org/info/rfc6528>. 2012, <https://www.rfc-editor.org/info/rfc6528>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
10.2. Informative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
12.2. Informative References
[Bellovin1989] [Bellovin1989]
Bellovin, S., "Security Problems in the TCP/IP Protocol Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", Computer Communications Review, vol. 19, no. 2, Suite", Computer Communications Review, vol. 19, no. 2,
pp. 32-48, 1989, pp. 32-48, 1989,
<https://www.cs.columbia.edu/~smb/papers/ipext.pdf>. <https://www.cs.columbia.edu/~smb/papers/ipext.pdf>.
[Bellovin2002] [Bellovin2002]
Bellovin, S., "A Technique for Counting NATted Hosts", Bellovin, S., "A Technique for Counting NATted Hosts",
IMW'02 Nov. 6-8, 2002, Marseille, France, 2002. IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.
[CERT2001] [CERT2001]
CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in
TCP/IP Initial Sequence Numbers", 2001, TCP/IP Initial Sequence Numbers", 2001,
<http://www.cert.org/advisories/CA-2001-09.html>. <http://www.cert.org/advisories/CA-2001-09.html>.
[CPNI-TCP] [draft-fgont-6man-rfc4941bis-00]
Gont, F., "Security Assessment of the Transmission Control Gont, F., Krishnan, S., Narten, T., and R. Draves,
Protocol (TCP)", United Kingdom's Centre for the "Privacy Extensions for Stateless Address
Protection of National Infrastructure (CPNI) Technical Autoconfiguration in IPv6", draft-fgont-6man-rfc4941bis-00
Report, 2009, <http://www.gont.com.ar/papers/ (work in progress), March 2018.
tn-03-09-security-assessment-TCP.pdf>.
[draft-gont-6man-address-usage-recommendations-00] [draft-gont-6man-address-usage-recommendations-00]
Gont, F. and W. Liu, "IPv6 Address Usage Recommendations", Gont, F. and W. Liu, "IPv6 Address Usage Recommendations",
draft-gont-6man-address-usage-recommendations-00 (work in draft-gont-6man-address-usage-recommendations-00 (work in
progress), May 2016. progress), May 2016.
[draft-gont-6man-non-stable-iids-00] [draft-gont-6man-non-stable-iids-00]
Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6 Gont, F. and W. Liu, "Recommendation on Non-Stable IPv6
Interface Identifiers", draft-gont-6man-non-stable-iids-00 Interface Identifiers", draft-gont-6man-non-stable-iids-00
(work in progress), May 2016. (work in progress), May 2016.
skipping to change at page 16, line 15 skipping to change at page 18, line 42
[draft-ietf-6man-predictable-fragment-id-02] [draft-ietf-6man-predictable-fragment-id-02]
Gont, F., "Security Implications of Predictable Fragment Gont, F., "Security Implications of Predictable Fragment
Identification Values", draft-ietf-6man-predictable- Identification Values", draft-ietf-6man-predictable-
fragment-id-02 (work in progress), December 2014. fragment-id-02 (work in progress), December 2014.
[draft-ietf-6man-predictable-fragment-id-08] [draft-ietf-6man-predictable-fragment-id-08]
Gont, F., "Security Implications of Predictable Fragment Gont, F., "Security Implications of Predictable Fragment
Identification Values", draft-ietf-6man-predictable- Identification Values", draft-ietf-6man-predictable-
fragment-id-08 (work in progress), June 2015. fragment-id-08 (work in progress), June 2015.
[draft-ietf-6man-rfc4941bis-00]
Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-00
(work in progress), July 2018.
[draft-ietf-6man-stable-privacy-addresses-00] [draft-ietf-6man-stable-privacy-addresses-00]
Gont, F., "A method for Generating Stable Privacy-Enhanced Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", draft-ietf-6man-stable-privacy-addresses-00 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-00
(work in progress), May 2012. (work in progress), May 2012.
[Fyodor2004] [draft-ietf-ntp-refid-updates-00]
Fyodor, "Idle scanning and related IP ID games", 2004, Goldberg, S. and H. Stenn, "Network Time Protocol Not You
REFID", draft-ietf-ntp-refid-updates-00 (work in
progress), November 2016.
[draft-stenn-ntp-not-you-refid-00]
Goldberg, S. and S. KrishnansTENN, "Network Time Protocol
Not You REFID", draft-stenn-ntp-not-you-refid-00 (work in
progress), July 2016.
[Fyodor2002]
Fyodor, "Idle scanning and related IP ID games", 2002,
<http://www.insecure.org/nmap/idlescan.html>. <http://www.insecure.org/nmap/idlescan.html>.
[Gont-NTP]
Gont, F., "[Ntp] Comments on draft-ietf-ntp-refid-updates-
05", Post to the NTP WG mailing list Message-ID:
<d871d66d-4043-d8d0-f924-2191ebb2e2ce@si6networks.com>,
April 2019, <https://mailarchive.ietf.org/arch/msg/ntp/
NkfTHxUUOdp14Agh3h1IPqfcRRg>.
[Gont2011] [Gont2011]
Gont, F., "Hacking IPv6 Networks (training course)", Hack Gont, F., "Hacking IPv6 Networks (training course)", Hack
In Paris 2011 Conference Paris, France, June 2011. In Paris 2011 Conference Paris, France, June 2011.
[Gont2012] [Gont2012]
Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012 Gont, F., "Recent Advances in IPv6 Security", BSDCan 2012
Conference Ottawa, Canada. May 11-12, 2012, May 2012. Conference Ottawa, Canada. May 11-12, 2012, May 2012.
[Gont2013] [Gont2013]
Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit Gont, F., "Beta release of the SI6 Network's IPv6 Toolkit
skipping to change at page 17, line 16 skipping to change at page 20, line 16
Gont, F., "Security Implications of Predictable Fragment Gont, F., "Security Implications of Predictable Fragment
Identification Values", draft-gont-6man-predictable- Identification Values", draft-gont-6man-predictable-
fragment-id-03 (work in progress), January 2013. fragment-id-03 (work in progress), January 2013.
[I-D.gont-6man-stable-privacy-addresses] [I-D.gont-6man-stable-privacy-addresses]
Gont, F., "A method for Generating Stable Privacy-Enhanced Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", draft-gont-6man-stable-privacy-addresses-01 (SLAAC)", draft-gont-6man-stable-privacy-addresses-01
(work in progress), March 2012. (work in progress), March 2012.
[I-D.gont-ntp-port-randomization]
Gont, F. and G. Gont, "Port Randomization in the Network
Time Protocol Version 4", draft-gont-ntp-port-
randomization-02 (work in progress), July 2019.
[I-D.gont-numeric-ids-generation] [I-D.gont-numeric-ids-generation]
Gont, F. and I. Arce, "On the Generation of Transient Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", draft-gont-numeric-ids-generation-02 Numeric Identifiers", draft-gont-numeric-ids-generation-03
(work in progress), February 2018. (work in progress), March 2019.
[I-D.gont-numeric-ids-sec-considerations] [I-D.gont-numeric-ids-sec-considerations]
Gont, F. and I. Arce, "Security Considerations for Gont, F. and I. Arce, "Security Considerations for
Transient Numeric Identifiers Employed in Network Transient Numeric Identifiers Employed in Network
Protocols", draft-gont-numeric-ids-sec-considerations-02 Protocols", draft-gont-numeric-ids-sec-considerations-03
(work in progress), February 2018. (work in progress), April 2019.
[I-D.gont-opsec-ipv6-host-scanning] [I-D.gont-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in Networks", draft-gont-opsec-ipv6-host-scanning-02 (work in
progress), October 2012. progress), October 2012.
[I-D.gont-predictable-numeric-ids] [I-D.gont-predictable-numeric-ids]
Gont, F. and I. Arce, "Security and Privacy Implications Gont, F. and I. Arce, "Security and Privacy Implications
of Numeric Identifiers Employed in Network Protocols", of Numeric Identifiers Employed in Network Protocols",
draft-gont-predictable-numeric-ids-02 (work in progress), draft-gont-predictable-numeric-ids-03 (work in progress),
February 2018. March 2019.
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and S. LIU, Gont, F., Cooper, A., Thaler, D., and S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-16 (work in progress), draft-ietf-6man-default-iids-16 (work in progress),
September 2016. September 2016.
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
skipping to change at page 18, line 21 skipping to change at page 21, line 27
Deering, S. and R. Hinden, "Internet Protocol, Version 6 Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work
in progress), May 2017. in progress), May 2017.
[I-D.ietf-6man-stable-privacy-addresses] [I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A Method for Generating Semantically Opaque Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", draft-ietf-6man-stable- Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
privacy-addresses-17 (work in progress), January 2014. privacy-addresses-17 (work in progress), January 2014.
[I-D.ietf-ntp-refid-updates]
Stenn, H. and S. Goldberg, "Network Time Protocol REFID
Updates", draft-ietf-ntp-refid-updates-05 (work in
progress), March 2019.
[I-D.ietf-opsec-ipv6-host-scanning] [I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in
progress), August 2015. progress), August 2015.
[IPID-DEV]
Klein, A. and B. Pinkas, "From IP ID to Device ID and
KASLR Bypass (Extended Version)", June 2019,
<https://arxiv.org/pdf/1906.10478.pdf>.
[IPv6-Toolkit] [IPv6-Toolkit]
SI6 Networks, "SI6 Networks' IPv6 Toolkit", SI6 Networks, "SI6 Networks' IPv6 Toolkit",
<https://www.si6networks.com/tools/ipv6toolkit>. <https://www.si6networks.com/tools/ipv6toolkit>.
[Joncheray1995]
Joncheray, L., "A Simple Active Attack Against TCP", Proc.
Fifth Usenix UNIX Security Symposium, 1995.
[Klein2007] [Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", 2007, Predictable IP ID Vulnerability", 2007,
<http://www.trusteer.com/files/OpenBSD_DNS_Cache_Poisoning <http://www.trusteer.com/files/OpenBSD_DNS_Cache_Poisoning
_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf>. _and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf>.
[Morbitzer2013] [Morbitzer2013]
Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message Morbitzer, M., "[PATCH] TCP Idle Scan in IPv6", Message
posted to the nmap-dev mailing-list, 2013, posted to the nmap-dev mailing-list, 2013,
<http://seclists.org/nmap-dev/2013/q2/394>. <http://seclists.org/nmap-dev/2013/q2/394>.
[Morris1985] [Morris1985]
Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, Software", CSTR 117, AT&T Bell Laboratories, Murray Hill,
NJ, 1985, NJ, 1985,
<https://pdos.csail.mit.edu/~rtm/papers/117.pdf>. <https://pdos.csail.mit.edu/~rtm/papers/117.pdf>.
[NIST-NTP]
Sherman, J. and J. Levine, "Usage Analysis of the NIST
Internet Time Service", Journal of Research of the
National Institute of Standards and Technology Volume 121,
March 2016, <https://tf.nist.gov/general/pdf/2818.pdf>.
[NTP-PORTR]
Gont, F., "[Ntp] New rev of the NTP port randomization I-D
(Fwd: New Version Notification for draft-gont-ntp-port-
randomization-01.txt)", 2019,
<https://mailarchive.ietf.org/arch/browse/
ntp/?gbt=1&index=n09Sb61WkH03lSRtamkELXwEQN4>.
[RedHat2011] [RedHat2011]
RedHat, "RedHat Security Advisory RHSA-2011:1465-1: RedHat, "RedHat Security Advisory RHSA-2011:1465-1:
Important: kernel security and bug fix update", 2011, Important: kernel security and bug fix update", 2011,
<https://rhn.redhat.com/errata/RHSA-2011-1465.html>. <https://rhn.redhat.com/errata/RHSA-2011-1465.html>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, DOI 10.17487/RFC1948, May 1996, RFC 1948, DOI 10.17487/RFC1948, May 1996,
<https://www.rfc-editor.org/info/rfc1948>. <https://www.rfc-editor.org/info/rfc1948>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007,
<https://www.rfc-editor.org/info/rfc4963>.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, DOI 10.17487/RFC5157, March 2008, RFC 5157, DOI 10.17487/RFC5157, March 2008,
<https://www.rfc-editor.org/info/rfc5157>. <https://www.rfc-editor.org/info/rfc5157>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
Protocol Port Randomization", BCP 156, RFC 6056, "Network Time Protocol Version 4: Protocol and Algorithms
DOI 10.17487/RFC6056, January 2011, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc6056>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol [RFC6274] Gont, F., "Security Assessment of the Internet Protocol
Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011, Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
<https://www.rfc-editor.org/info/rfc6274>. <https://www.rfc-editor.org/info/rfc6274>.
[RFC7528] Higgs, P. and J. Piesing, "A Uniform Resource Name (URN) [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
Association", RFC 7528, DOI 10.17487/RFC7528, April 2015, 2014, <https://www.rfc-editor.org/info/rfc7258>.
<https://www.rfc-editor.org/info/rfc7528>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>. <https://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment [RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739, Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>. February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[Sanfilippo1998a] [Sanfilippo1998a]
Sanfilippo, S., "about the ip header id", Post to Bugtraq Sanfilippo, S., "about the ip header id", Post to Bugtraq
mailing-list, Mon Dec 14 1998, mailing-list, Mon Dec 14 1998,
<http://seclists.org/bugtraq/1998/Dec/48>. <http://seclists.org/bugtraq/1998/Dec/48>.
[Sanfilippo1998b] [Sanfilippo1998b]
Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list,
1998, <http://www.kyuzz.org/antirez/papers/dumbscan.html>. 1998, <http://www.kyuzz.org/antirez/papers/dumbscan.html>.
[Sanfilippo1999] [Sanfilippo1999]
skipping to change at page 21, line 21 skipping to change at page 25, line 4
Zalewski, M., "Strange Attractors and TCP/IP Sequence Zalewski, M., "Strange Attractors and TCP/IP Sequence
Number Analysis - One Year Later", 2001, Number Analysis - One Year Later", 2001,
<http://lcamtuf.coredump.cx/newtcp/>. <http://lcamtuf.coredump.cx/newtcp/>.
[Zalewski2003] [Zalewski2003]
Zalewski, M., "A new TCP/IP blind data injection Zalewski, M., "A new TCP/IP blind data injection
technique?", 2003, technique?", 2003,
<http://lcamtuf.coredump.cx/ipfrag.txt>. <http://lcamtuf.coredump.cx/ipfrag.txt>.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: https://www.si6networks.com
Ivan Arce Ivan Arce
Quarkslab Quarkslab
Email: iarce@quarkslab.com Email: iarce@quarkslab.com
URI: https://www.quarkslab.com URI: https://www.quarkslab.com
 End of changes. 45 change blocks. 
94 lines changed or deleted 270 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/