rfc9414v4.txt | rfc9414.txt | |||
---|---|---|---|---|
skipping to change at line 294 ¶ | skipping to change at line 294 ¶ | |||
times as a suggestion to employ per-destination or global counters | times as a suggestion to employ per-destination or global counters | |||
for the generation of Identification values. While [RFC0791] does | for the generation of Identification values. While [RFC0791] does | |||
not suggest any flawed algorithm for the generation of Identification | not suggest any flawed algorithm for the generation of Identification | |||
values, the specification omits a discussion of the security and | values, the specification omits a discussion of the security and | |||
privacy implications of predictable Identification values. This | privacy implications of predictable Identification values. This | |||
resulted in many IPv4 implementations generating predictable | resulted in many IPv4 implementations generating predictable | |||
Identification values by means of a global counter, at least at some | Identification values by means of a global counter, at least at some | |||
point in time. | point in time. | |||
The IPv6 Identification was originally specified in [RFC1883]. It | The IPv6 Identification was originally specified in [RFC1883]. It | |||
serves the same purpose as its IPv4 counterpart, but rather being | serves the same purpose as its IPv4 counterpart, but rather than | |||
part of the base header (as in the IPv4 case), it is part of the | being part of the base header (as in the IPv4 case), it is part of | |||
Fragment Header (which may or may not be present in an IPv6 packet). | the Fragment Header (which may or may not be present in an IPv6 | |||
Section 4.5 of [RFC1883] states that the Identification must be | packet). Section 4.5 of [RFC1883] states that the Identification | |||
different than that of any other fragmented packet sent recently | must be different than that of any other fragmented packet sent | |||
(within the maximum likely lifetime of a packet) with the same Source | recently (within the maximum likely lifetime of a packet) with the | |||
Address and Destination Address. Subsequently, it notes that this | same Source Address and Destination Address. Subsequently, it notes | |||
requirement can be met by means of a wrap-around 32-bit counter that | that this requirement can be met by means of a wrap-around 32-bit | |||
is incremented each time a packet must be fragmented and that it is | counter that is incremented each time a packet must be fragmented and | |||
an implementation choice whether to use a global or a per-destination | that it is an implementation choice whether to use a global or a per- | |||
counter. Thus, the specification of the IPv6 Identification is | destination counter. Thus, the specification of the IPv6 | |||
similar to that of the IPv4 case, with the only difference that, in | Identification is similar to that of the IPv4 case, with the only | |||
the IPv6 case, the suggestions to use simple counters is more | difference that, in the IPv6 case, the suggestions to use simple | |||
explicit. [RFC2460] is the first revision of the core IPv6 | counters is more explicit. [RFC2460] is the first revision of the | |||
specification and maintains the same text for the specification of | core IPv6 specification and maintains the same text for the | |||
the IPv6 Identification field. [RFC8200], the second revision of the | specification of the IPv6 Identification field. [RFC8200], the | |||
core IPv6 specification, removes the suggestion from [RFC2460] to use | second revision of the core IPv6 specification, removes the | |||
a counter for the generation of IPv6 Identification values and points | suggestion from [RFC2460] to use a counter for the generation of IPv6 | |||
to [RFC7739] for sample algorithms for their generation. | Identification values and points to [RFC7739] for sample algorithms | |||
for their generation. | ||||
September 1981: | September 1981: | |||
[RFC0791] specifies the interoperability requirements for the IPv4 | [RFC0791] specifies the interoperability requirements for the IPv4 | |||
Identification but does not perform a vulnerability assessment of | Identification but does not perform a vulnerability assessment of | |||
this transient numeric identifier. | this transient numeric identifier. | |||
December 1995: | December 1995: | |||
[RFC1883], the first specification of the IPv6 protocol, is | [RFC1883], the first specification of the IPv6 protocol, is | |||
published. It suggests that a counter be used to generate the | published. It suggests that a counter be used to generate the | |||
IPv6 Identification values and notes that it is an implementation | IPv6 Identification values and notes that it is an implementation | |||
skipping to change at line 761 ¶ | skipping to change at line 762 ¶ | |||
remote port}. How ephemeral ports are selected and the port range | remote port}. How ephemeral ports are selected and the port range | |||
from which they are selected are left unspecified. | from which they are selected are left unspecified. | |||
July 1996: | July 1996: | |||
OpenBSD implements ephemeral port randomization [OpenBSD-PR]. | OpenBSD implements ephemeral port randomization [OpenBSD-PR]. | |||
July 2008: | July 2008: | |||
The CERT Coordination Center publishes details of what became | The CERT Coordination Center publishes details of what became | |||
known as the "Kaminsky Attack" [VU-800113] [Kaminsky2008] on the | known as the "Kaminsky Attack" [VU-800113] [Kaminsky2008] on the | |||
DNS. The attack exploits the lack of ephemeral port randomization | DNS. The attack exploits the lack of ephemeral port randomization | |||
and DNS ID randmization in many major DNS implementations to | and DNS ID randomization in many major DNS implementations to | |||
perform cache poisoning in an effective and practical manner. | perform cache poisoning in an effective and practical manner. | |||
January 2009: | January 2009: | |||
[RFC5452] mandates the use of port randomization for DNS resolvers | [RFC5452] mandates the use of port randomization for DNS resolvers | |||
and mandates that implementations must randomize ports from the | and mandates that implementations must randomize ports from the | |||
range of available ports (53 or 1024 and above) that is are large | range of available ports (53 or 1024 and above) that is as large | |||
as possible and practicable. It does not recommend possible | as possible and practicable. It does not recommend possible | |||
algorithms for port randomization, although the document | algorithms for port randomization, although the document | |||
specifically targets DNS resolvers, for which a simple port | specifically targets DNS resolvers, for which a simple port | |||
randomization suffices (e.g., Algorithm 1 of [RFC6056]). This | randomization suffices (e.g., Algorithm 1 of [RFC6056]). This | |||
document led to the implementation of port randomization in the | document led to the implementation of port randomization in the | |||
DNS resolvers themselves, rather than in the underlying transport | DNS resolvers themselves, rather than in the underlying transport | |||
protocols. | protocols. | |||
January 2011: | January 2011: | |||
[RFC6056] notes that many TCP and UDP implementations result in | [RFC6056] notes that many TCP and UDP implementations result in | |||
skipping to change at line 1197 ¶ | skipping to change at line 1198 ¶ | |||
[draft-ietf-6man-predictable-fragment-id-10] | [draft-ietf-6man-predictable-fragment-id-10] | |||
Gont, F., "Security Implications of Predictable Fragment | Gont, F., "Security Implications of Predictable Fragment | |||
Identification Values", Work in Progress, Internet-Draft, | Identification Values", Work in Progress, Internet-Draft, | |||
draft-ietf-6man-predictable-fragment-id-10, 9 October | draft-ietf-6man-predictable-fragment-id-10, 9 October | |||
2015, <https://www.ietf.org/archive/id/draft-ietf-6man- | 2015, <https://www.ietf.org/archive/id/draft-ietf-6man- | |||
predictable-fragment-id-10.txt>. | predictable-fragment-id-10.txt>. | |||
[draft-ietf-6man-rfc2460bis-05] | [draft-ietf-6man-rfc2460bis-05] | |||
Deering, S. and R. Hinden, "Internet Protocol, Version 6 | Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
(IPv6) Specification", Internt-Draft draft-ietf-6man- | (IPv6) Specification", Work in Progress, Internet-Draft, | |||
rfc2460bis-05, 28 June 2016, | draft-ietf-6man-rfc2460bis-05, 28 June 2016, | |||
<https://www.ietf.org/archive/id/draft-ietf-6man- | <https://www.ietf.org/archive/id/draft-ietf-6man- | |||
rfc2460bis-05.txt>. | rfc2460bis-05.txt>. | |||
[draft-ietf-6man-rfc2460bis-13] | [draft-ietf-6man-rfc2460bis-13] | |||
Deering, S. and R. Hinden, "draft-ietf-6man-rfc2460bis- | Deering, S. and R. Hinden, "draft-ietf-6man-rfc2460bis- | |||
13", Work in Progress, Internet-Draft, draft-ietf-6man- | 13", Work in Progress, Internet-Draft, draft-ietf-6man- | |||
rfc2460bis-13, 19 May 2017, | rfc2460bis-13, 19 May 2017, | |||
<https://www.ietf.org/archive/id/draft-ietf-6man- | <https://www.ietf.org/archive/id/draft-ietf-6man- | |||
rfc2460bis-13.txt>. | rfc2460bis-13.txt>. | |||
skipping to change at line 1464 ¶ | skipping to change at line 1465 ¶ | |||
Autoconfiguration in IPv6", RFC 8981, | Autoconfiguration in IPv6", RFC 8981, | |||
DOI 10.17487/RFC8981, February 2021, | DOI 10.17487/RFC8981, February 2021, | |||
<https://www.rfc-editor.org/info/rfc8981>. | <https://www.rfc-editor.org/info/rfc8981>. | |||
[RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol | [RFC9109] Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol | |||
Version 4: Port Randomization", RFC 9109, | Version 4: Port Randomization", RFC 9109, | |||
DOI 10.17487/RFC9109, August 2021, | DOI 10.17487/RFC9109, August 2021, | |||
<https://www.rfc-editor.org/info/rfc9109>. | <https://www.rfc-editor.org/info/rfc9109>. | |||
[RFC9415] Gont, F. and I. Arce, "On the Generation of Transient | [RFC9415] Gont, F. and I. Arce, "On the Generation of Transient | |||
Numeric Identifiers", RFC 9415, DOI 10.17487/RFC9415, June | Numeric Identifiers", RFC 9415, DOI 10.17487/RFC9415, July | |||
2023, <https://www.rfc-editor.org/info/rfc9415>. | 2023, <https://www.rfc-editor.org/info/rfc9415>. | |||
[RFC9416] Gont, F. and I. Arce, "Security Considerations for | [RFC9416] Gont, F. and I. Arce, "Security Considerations for | |||
Transient Numeric Identifiers Employed in Network | Transient Numeric Identifiers Employed in Network | |||
Protocols", BCP 72, RFC 9416, DOI 10.17487/RFC9416, June | Protocols", BCP 72, RFC 9416, DOI 10.17487/RFC9416, July | |||
2023, <https://www.rfc-editor.org/info/rfc9416>. | 2023, <https://www.rfc-editor.org/info/rfc9416>. | |||
[Sacramento2002] | [Sacramento2002] | |||
Sacramento, V., "CAIS-ALERT: Vulnerability in the sending | Sacramento, V., "CAIS-ALERT: Vulnerability in the sending | |||
requests control of BIND", message to the Bugtraq mailing | requests control of BIND", message to the Bugtraq mailing | |||
list, 25 November 2002, | list, 25 November 2002, | |||
<https://seclists.org/bugtraq/2002/Nov/331>. | <https://seclists.org/bugtraq/2002/Nov/331>. | |||
[Sanfilippo1998a] | [Sanfilippo1998a] | |||
Sanfilippo, S., "about the ip header id", message to the | Sanfilippo, S., "about the ip header id", message to the | |||
End of changes. 6 change blocks. | ||||
25 lines changed or deleted | 26 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |