< draft-gont-numeric-ids-sec-considerations-03.txt   draft-gont-numeric-ids-sec-considerations-04.txt >
Network Working Group F. Gont Network Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks
Updates: 3552 (if approved) I. Arce Updates: 3552 (if approved) I. Arce
Intended status: Best Current Practice Quarkslab Intended status: Best Current Practice Quarkslab
Expires: September 12, 2019 March 11, 2019 Expires: January 9, 2020 July 8, 2019
Security Considerations for Transient Numeric Identifiers Employed in Security Considerations for Transient Numeric Identifiers Employed in
Network Protocols Network Protocols
draft-gont-numeric-ids-sec-considerations-03 draft-gont-numeric-ids-sec-considerations-04
Abstract Abstract
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.
The root of these issues has been, in many cases, the poor selection The root of these issues has been, in many cases, the poor selection
of transient identifiers in such protocols, usually as a result of an of transient numeric identifiers in such protocols, usually as a
insufficient or misleading specifications. This document formally result of insufficient or misleading specifications. This document
updates RFC3552, such that RFCs are required to perform a security formally updates RFC3552, such that RFCs are required to include a
and privacy analysis of the transient numeric identifiers they security and privacy analysis of the transient numeric identifiers
specify. they specify.
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 28 skipping to change at page 2, line 28
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Issues with the Specification of Identifiers . . . . . . . . 4 3. Issues with the Specification of Identifiers . . . . . . . . 4
4. Common Flaws in the Generation of Transient Identifiers . . . 5 4. Common Flaws in the Generation of Transient Identifiers . . . 5
5. Security and Privacy Requirements for Identifiers . . . . . . 6 5. Security and Privacy Requirements for Identifiers . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8
9.3. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Network protocols employ a variety of transient numeric identifiers Network protocols employ a variety of transient numeric identifiers
for different protocol entities, ranging from DNS Transaction IDs for different protocol entities, ranging from DNS Transaction IDs
(TxIDs) to transport protocol numbers (e.g. TCP ports) or IPv6 (TxIDs) to transport protocol numbers (e.g. TCP ports) or IPv6
Interface Identifiers (IIDs). These identifiers usually have Interface Identifiers (IIDs). These identifiers usually have
specific properties that must be satisfied such that they do not specific properties that must be satisfied such that they do not
result in negative interoperability implications (e.g. uniqueness result in negative interoperability implications (e.g. uniqueness
during a specified period of time), and associated failure severities during a specified period of time), and an associated failure
when such properties are not met. severity when such properties not met.
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 insufficient or misleading specifications. While it is generally
generally trivial to identify an algorithm that can satisfy the 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 [I-D.gont-numeric-ids-history] that doing so
security and/or privacy properties of the aforementioned protocols is without negatively affecting the security and/or privacy properties
prone to error. of the aforementioned protocols is 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:
o Predictable TCP sequence numbers o Predictable TCP sequence numbers
o Predictable transport protocol numbers o Predictable transport protocol numbers
o Predictable IPv4 or IPv6 Fragment Identifiers o Predictable IPv4 or IPv6 Fragment Identifiers
o Predictable IPv6 IIDs o Predictable IPv6 IIDs
o Predictable DNS TxIDs o Predictable DNS TxIDs
Recent history indicates that when new protocols are standardized or Recent history indicates 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 such identifiers are either
suggested in the specification or selected by implementators. As a suggested in the specification or selected by implementers. As a
result, we believe that advice in this area is warranted. result, advice in this area is warranted.
2. Terminology 2. Terminology
Identifier: Identifier:
A data object in a protocol specification that can be used to A data object in a protocol specification that can be used to
definetely distinguish a protocol object (a datagram, network definitely distinguish a protocol object (a datagram, network
interface, transport protocol endpoint, session, etc) from all interface, transport protocol endpoint, session, etc) from all
other objects of the same type, in a given context. Identifiers other objects of the same type, in a given context. Identifiers
are usually defined as a series of bits and represented using are usually defined as a series of bits and represented using
integer values. We note that different identifiers may have integer values. We note that these identifiers may have
additional requirements or properties depending on their specific additional requirements or properties depending on their specific
use in a protocol. We use the term "identifier" as a generic term use in a protocol. We use the term "identifier" as a generic term
to refer to any data object in a protocol specification that to refer to any data object in a protocol specification that
satisfies the identification property stated above. Throughout satisfies the identification property stated above. Throughout
this document we refer as "transient network identifiers" (or this document we refer as "transient numeric identifiers" (or
simply as "identifiers") to the identifiers being dynamically simply as "identifiers") to the identifiers being dynamically
selected by a protocol. Our use of "identifier" excludes static selected by a protocol. Our use of "identifier" excludes static
values such as "Protocol Numbers" and the like. values such as "Protocol Numbers" and the like.
Failure Severity: Failure Severity:
The consequences of a failure to comply with the interoperability The consequences of a failure to comply with the interoperability
requirements of a given identifier. Severity considers the worst requirements of a given identifier. Severity considers the worst
potential consequence of a failure, determined by the system potential consequence of a failure, determined by the system
damage and/or time lost to repair the failure. In this document damage and/or time lost to repair the failure. In this document
we define two types of failure severity: "soft" and "hard". we define two types of failure severity: "soft" and "hard".
skipping to change at page 4, line 28 skipping to change at page 4, line 28
simple packet-loss event that is subsequently recovered with a simple packet-loss event that is subsequently recovered with a
retransmission can be considered a soft failure. retransmission can be considered a soft failure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Issues with the Specification of Identifiers 3. Issues with the Specification of Identifiers
While assessing protocol specifications and implementations regarding While assessing protocol specifications and implementations regarding
the use of transient numeric identifiers, we found that most of the the use of transient numeric identifiers
issues discussed in this document arise as a result of one of the [I-D.gont-numeric-ids-history], we found that most of the issues
following: discussed in this document arise as a result of one of the following
conditions:
o Protocol specifications which under-specify the requirements for o Protocol specifications that under-specify the requirements for
their identifiers their identifiers
o Protocol specifications that over-specify their identifiers o Protocol specifications that over-specify their identifiers
o Protocol implementations that simply fail to comply with the o Protocol implementations that simply fail to comply with the
specified requirements specified requirements
A number of protocol implementations (too many of them) simply A number of protocol implementations (too many of them) simply
overlook the security and privacy implications of identifiers. overlook the security and privacy implications of identifiers.
Examples of them are the specification of TCP port numbers in Examples of them are the specification of TCP port numbers in
[RFC0793], the specification of TCP sequence numbers in [RFC0793], or [RFC0793], the specification of TCP sequence numbers in [RFC0793], or
the specification of the DNS TxID in [RFC1035]. the specification of the DNS TxID in [RFC1035].
On the other hand, there are a number of protocol specifications that On the other hand, there are a number of protocol specifications that
over-specify some of their associated protocol identifiers. For over-specify some of their associated protocol identifiers. For
example, [RFC4291] essentially results in link-layer addresses being example, [RFC4291] essentially results in link-layer addresses being
embedded in the IPv6 Interface Identifiers (IIDs) when the embedded in the IPv6 Interface Identifiers (IIDs) when the
interoperability requirement of uniqueness could be achieved in other interoperability requirement of uniqueness could be achieved in other
ways that do not result in negative security and privacy implications ways that do not result in negative security and privacy implications
[RFC7721]. Similarly, [RFC2460] suggests the use of a global counter
for the generation of Fragment Identification values, when the [RFC7721]. Similarly, [RFC2460] suggested the use of a global
interoperability properties of uniqueness per {Src IP, Dst IP} could counter for the generation of Fragment Identification values, when
be achieved with other algorithms that do not result in negative the interoperability properties of uniqueness per {Src IP, Dst IP}
security and privacy implications. could be achieved with other algorithms that do not result in
negative security and privacy implications.
Finally, there are protocol implementations that simply fail to Finally, there are protocol implementations that simply fail to
comply with existing protocol specifications. For example, some comply with existing protocol specifications. For example, some
popular operating systems (notably Microsoft Windows) still fail to popular operating systems (notably Microsoft Windows) still fails to
implement randomization of transport protocol ephemeral ports, as implement transport-protocol port randomization, as specified in
specified in [RFC6056]. [RFC6056].
By requiring protocol specifications to clearly specify the By requiring protocol specifications to clearly specify the
interoperability requirements for the transient numeric identifiers interoperability requirements for the transient numeric identifiers
they specify, the constraints in the possible algorithms to generate they specify, the constraints in the possible algorithms to generate
them, as well as possible over-specification of such identifiers, them, as well as possible over-specification of such identifiers,
become evident. Furthermore, requiring specifications to include a become evident. Furthermore, requiring specifications to include a
security and privacy analysis of the transient numeric identifiers security and privacy analysis of the transient numeric identifiers
they specify prevents the corresponding considerations from being they specify prevents the corresponding considerations from being
overlooked at the time a protocol is specified. overlooked at the time a protocol is specified.
skipping to change at page 5, line 47 skipping to change at page 5, line 49
protocol stack protocol stack
o Initializing counters or timers to constant values, when such o Initializing counters or timers to constant values, when such
initialization is not required initialization is not required
o Employing the same increment space across different contexts o Employing the same increment space across different contexts
o Use of flawed PRNGs. o Use of flawed PRNGs.
Employing trivial algorithms for generating the identifiers means Employing trivial algorithms for generating the identifiers means
that any node that is able to sample the aforementioned identifier that any node that is able to sample such identifiers can easily
can easily predict future identifiers employed by the victim node. predict future identifiers employed by the victim node. For example,
For example, the algorithm for Fragment Identification selection in the algorithm for Fragment Identification selection in [RFC2460] and
[RFC2460] and the algorithm for TCP ISN selection in [RFC0793]. the algorithm for TCP ISN selection in [RFC0793] suffer from that
problem.
When one identifier is employed across contexts where such constancy When one identifier is employed across contexts where such constancy
is not needed, activity correlation is made made possible. For is not needed, activity correlation is made made possible. For
example, [RFC4291] essentially results in link-layer addresses being example, [RFC4291] essentially results in link-layer addresses being
embedded in the IPv6 Interface Identifiers (IIDs) when the embedded in the IPv6 Interface Identifiers (IIDs) when the
interoperability requirement of uniqueness could be achieved in other interoperability requirement of uniqueness could be achieved in other
ways. Employing an identifier that is constant across networks ways. Employing an identifier that is constant across networks
allows for node tracking across networks. allows for node tracking across networks.
Re-using identifiers across different layers or protocols ties the Re-using identifiers across different layers or protocols ties the
security and privacy of the protocol re-using the identifier to the security and privacy of the protocol re-using the identifier to the
security and privacy properties of such identifier (over which the security and privacy properties of the original identifier (over
protocol re-using the identifier may have no control regarding its which the protocol re-using the identifier may have no control
generation). Besides, when re-using an identifier across protocols regarding its generation). Besides, when re-using an identifier
from different layer, this breaks the goal of layers of isolating the across protocols from different layers, the goal of of isolating the
properties of a layer from that of another layer. The reuse of link- properties of a layer from that of another layer is broken. Re-using
layer addresses in IPv6 addresses specified in [RFC4291] is one link-layer addresses in IPv6 addresses as specified in [RFC4291] is
example of that. one example of that.
At times, a protocol needs to convey order information (whether At times, a protocol needs to convey order information (whether
sequence, timing, etc.). In many cases, there is no reason for the sequence, timing, etc.). In many cases, there is no reason for the
corresponding counter or timer to be initialized to any specific corresponding counter or timer to be initialized to any specific
value e.g. at system bootstrap. For example, an implementations that value e.g. at system bootstrap. For example, an implementations that
employs a counter for the Fragment Identifier [RFC2460] that gets employs a counter for the Fragment Identifier [RFC8200] that gets
initialized to zero upon system bootstrapping will leak the amount of initialized to zero upon system bootstrapping will leak the number of
fragmented traffic that this node has transmitted. Similarly, a node fragmented packets that this node has transmitted. Similarly, a node
that updates a timer to zero when bootstrapping will reveal the that updates a timer to zero when bootstrapping will reveal the
"uptime" of the node. "uptime" of the node.
When a node that implements a per-context linear function may share A node that implements a per-context linear function may share the
the increment space among different contexts (please see the "Simple increment space among different contexts (please see the "Simple
Hash-Based Algorithm" in [I-D.gont-predictable-numeric-ids]). Hash-Based Algorithm" in [I-D.gont-predictable-numeric-ids]).
Sharing the same increment space allows an attacker that can sample Sharing the same increment space allows an attacker that can sample
identifiers in other context to e.g. learn how many identifiers have identifiers in other context to e.g. learn how many identifiers have
been generated between two sampled values. [Sanfilippo1998a] and been generated between two sampled values. [Sanfilippo1998a] and
[Sanfilippo1998b] employ shared increment spaces to leak the amount [Sanfilippo1998b] employ shared increment spaces to leak the number
of fragmented traffic that has been transmitted by a target node. of fragmented packets that has been transmitted by a target node.
Finally, some implementations have been found to emply flawed PRNGs. Finally, some implementations have been found to employ flawed PRNGs.
See e.g.[Klein2007]. See e.g.[Klein2007].
5. Security and Privacy Requirements for Identifiers 5. Security and Privacy Requirements for Identifiers
Protocol specifications that specify transient numeric identifiers Protocol specifications that specify transient numeric identifiers
MUST: MUST:
1. Clearly specify the interoperability requirements for the 1. Clearly specify the interoperability requirements for the
aforementioned identifiers. aforementioned identifiers.
2. Provide a security and privacy analysis of the aforementioned 2. Provide a security and privacy analysis of the aforementioned
identifiers. identifiers.
3. Recommend an algorithm for generating the aforementioned 3. Recommend an algorithm for generating the aforementioned
identifiers that mitigates security and privacy issues, such as identifiers that mitigates security and privacy issues, such as
those discussed in [I-D.gont-predictable-numeric-ids]. those discussed in [I-D.gont-numeric-ids-generation].
6. IANA Considerations 6. 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.
7. Security Considerations 7. Security Considerations
The entire document is about the security and privacy implications of This entire document is about the security and privacy implications
transient numeric identifiers, and formally updates [RFC3552] such of transient numeric identifiers, and formally updates [RFC3552] such
that the "Security Considerations" sections of RFCs are required to that the "Security Considerations" sections of RFCs are required to
perform a security and privacy analysis of the numeric identifiers perform a security and privacy analysis of the transient numeric
they specify. identifiers they specify.
8. Acknowledgements 8. Acknowledgements
This document is based on the document This document is based on the document
[I-D.gont-predictable-numeric-ids] co-authored by Fernando Gont and [I-D.gont-predictable-numeric-ids] co-authored by Fernando Gont and
Ivan Arce. Thus, the authors would like to thank (in alphabetical Ivan Arce. Thus, the authors would like to thank (in alphabetical
order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, for order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, for
providing valuable comments on that document. providing valuable comments on that document.
The authors would like to thank Diego Armando Maradona for his magic The authors would like to thank Diego Armando Maradona for his magic
skipping to change at page 8, line 10 skipping to change at page 8, 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>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[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>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011, DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>. <https://www.rfc-editor.org/info/rfc6056>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", (IPv6) Specification", STD 86, RFC 8200,
RFC 6151, DOI 10.17487/RFC6151, March 2011, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <https://www.rfc-editor.org/info/rfc6528>.
[RFC7098] Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6
Flow Label for Load Balancing in Server Farms", RFC 7098,
DOI 10.17487/RFC7098, January 2014,
<https://www.rfc-editor.org/info/rfc7098>.
9.2. Informative References 9.2. Informative References
[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.
[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>.
[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>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[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>.
[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>.
[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>.
[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>.
9.3. Informative References
[I-D.gont-numeric-ids-generation]
Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", draft-gont-numeric-ids-generation-03
(work in progress), March 2019.
[I-D.gont-numeric-ids-history]
Gont, F. and I. Arce, "Unfortunate History of Transient
Numeric Identifiers", draft-gont-numeric-ids-history-04
(work in progress), March 2019.
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. 35 change blocks. 
89 lines changed or deleted 86 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/