-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathdraft-irtf-pearg-numeric-ids-history-06.xml
1793 lines (1252 loc) · 77.9 KB
/
draft-irtf-pearg-numeric-ids-history-06.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="no" ?>
<rfc category="info" docName="draft-irtf-pearg-numeric-ids-history-06" ipr="trust200902" submissionType="IRTF">
<front>
<title abbrev="Predictable Numeric IDs">Unfortunate History of Transient Numeric Identifiers</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
<organization abbrev="SI6 Networks">SI6 Networks</organization>
<address>
<postal>
<street>Evaristo Carriego 2644</street>
<code>1706</code>
<city>Haedo</city>
<region>Provincia de Buenos Aires</region>
<country>Argentina</country>
</postal>
<phone>+54 11 4650 8472</phone>
<email>[email protected]</email>
<uri>https://www.si6networks.com</uri>
</address>
</author>
<author fullname="Ivan Arce" initials="I." surname="Arce">
<organization abbrev="Quarkslab">Quarkslab</organization>
<address>
<!--
<postal>
<street>Av. Cordoba 744 Piso 5 Oficina I</street>
<code>C1054AAT</code>
<city>Ciudad Autonoma de Buenos Aires</city>
<region>Buenos Aires</region>
<country>Argentina</country>
</postal>
<phone>+54 11 4328 5164</phone>
-->
<email>[email protected]</email>
<uri>https://www.quarkslab.com</uri>
</address>
</author>
<date/>
<workgroup>Internet Research Task Force (IRTF)</workgroup>
<!--
<area>Internet</area>
<workgroup>Dynamic Host Configuration (dhc)</workgroup>
-->
<!-- <area/> -->
<!-- <workgroup/> -->
<abstract>
<t>
This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols, and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>
Networking protocols employ a variety of transient numeric identifiers for different protocol objects, such as IPv4 and IPv6 Fragment Identifiers <xref target="RFC0791"/> <xref target="RFC8200"/>, IPv6 Interface Identifiers (IIDs) <xref target="RFC4291"/>, transport protocol ephemeral port numbers <xref target="RFC6056"/>, TCP Initial Sequence Numbers (ISNs) <xref target="RFC0793"/>, and DNS Transaction IDs (TxIDs) <xref target="RFC1035"/>. These identifiers typically have specific interoperability requirements (e.g. uniqueness during a specified period of time), and associated failure modes when such requirements are not met <xref target="I-D.irtf-pearg-numeric-ids-generation"/>.
</t>
<t>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 effects ranging from Denial of Service (DoS) or data injection, to information leakages that could be exploited for pervasive monitoring <xref target="RFC7258"/>. The root cause of these issues has been, in many cases, poor selection of transient numeric identifiers, usually as a result of insufficient or misleading specifications.</t>
<t>For example, implementations have been subject to security or privacy issues resulting from:
<list style="symbols">
<t>Predictable IPv4 or IPv6 Fragment Identifiers (see e.g. <xref target="Sanfilippo1998a"/>, <xref target="RFC6274"/>, and <xref target="RFC7739"/>)</t>
<t>Predictable IPv6 IIDs (see e.g. <xref target="RFC7721"/>, <xref target="RFC7707"/>, and <xref target="RFC7217"/>)</t>
<t>Predictable transport protocol ephemeral port numbers (see e.g. <xref target="RFC6056"/> and <xref target="Silbersack2005"/>)</t>
<t>Predictable TCP Initial Sequence Numbers (ISNs) (see e.g. <xref target="Morris1985"/>, <xref target="Bellovin1989"/>, and <xref target="RFC6528"/>)</t>
<t>Predictable DNS TxIDs (see e.g. <xref target="Schuba1993"/> and <xref target="Klein2007"/>)</t>
</list>
<!--
<list style="symbols">
<t>Predictable TCP Initial Sequence Numbers (ISNs) <xref target="RFC0793"/>
<list style="hanging">
<t>See e.g. <xref target="Morris1985"/>, <xref target="Bellovin1989"/>, and <xref target="RFC6528"/>.</t>
</list>
</t>
<t>Predictable transport protocol ephemeral port numbers <xref target="RFC0793"/> <xref target="RFC0768"/>
<list style="hanging">
<t>
See e.g. <xref target="RFC6056"/> and <xref target="Silbersack2005"/>.</t>
</list>
</t>
<t>Predictable IPv4 or IPv6 Fragment Identifiers <xref target="RFC0791"/> <xref target="RFC8200"/>
<list style="hanging">
<t>See e.g. <xref target="Sanfilippo1998a"/>, <xref target="RFC6274"/>, and <xref target="RFC7739"/>.</t>
</list>
</t>
<t>Predictable IPv6 IIDs <xref target="RFC4291"/>
<list style="hanging">
<t>See e.g. <xref target="RFC7721"/>, <xref target="RFC7707"/>, and <xref target="RFC7217"/>.</t>
</list>
</t>
<t>Predictable DNS TxIDs <xref target="RFC1035"/>
<list style="hanging">
<t>See e.g. <xref target="Schuba1993"/> and <xref target="Klein2007"/>.</t>
</list>
</t>
</list>
-->
These examples indicate that when new protocols are standardized or implemented, the security and privacy properties of the associated transient numeric identifiers tend to be overlooked, and inappropriate algorithms to generate such identifiers (i.e. that negatively affect the security or privacy properties of the protocol) are either suggested in the specification or selected by implementers.
</t>
<t>This document contains a non-exhaustive timeline of the specification and vulnerability disclosures related to some sample transient numeric identifiers, including other work that has led to advances in this area. This analysis indicates that:
<list style="symbols">
<t>Vulnerabilities associated with the inappropriate generation of transient numeric identifiers have affected protocol implementations for an extremely long period of time.</t>
<t>Such vulnerabilities, even when addressed for a given protocol version, were later reintroduced in new versions or new implementations of the same protocol.</t>
<t>Standardization efforts that discuss and provide advice in this area can have a positive effect on protocol specifications and protocol implementations.</t>
</list>
</t>
<t>While it is generally possible to identify an algorithm that can satisfy the interoperability requirements for a given transient numeric identifier, this document provides empirical evidence that doing so without negatively affecting the security or privacy properties of the aforementioned protocols is non-trivial. Other related documents (<xref target="I-D.irtf-pearg-numeric-ids-generation"/> and <xref target="I-D.gont-numeric-ids-sec-considerations"/>) provide guidance in this area, as motivated by the present document.</t>
<t>This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF.</t>
</section>
<section title="Terminology" anchor="terminology">
<t>
<list style="hanging">
<t hangText="Transient Numeric Identifier:">
<vspace blankLines="0" />A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, transport protocol endpoint, session, etc) from all other objects of the same type, in a given context. Transient numeric identifiers are usually defined as a series of bits, and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically-assigned numeric identifiers (see e.g. <xref target="IANA-PROT"/>). We note that different identifiers may have additional requirements or properties depending on their specific use in a protocol. We use the term "transient numeric identifier" (or simply "numeric identifier" or "identifier" as short forms) as a generic term to refer to any data object in a protocol specification that satisfies the identification property stated above.
</t>
</list>
</t>
<t>
The terms "constant IID", "stable IID", and "temporary IID" are to be
interpreted as defined in <xref target="RFC7721"/>.
</t>
<!--
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target='RFC2119' /> <xref target='RFC8174' /> when, and only when, they
appear in all capitals, as shown here.
</t>
-->
</section>
<section title="Threat Model" anchor="threat-model">
<t>Throughout this document, we assume an attacker does not have physical or logical access to the system(s) being attacked, and cannot observe the packets being transferred between the sender and the receiver(s) of the target protocol (if any). However, we assume the attacker can send any traffic to the target device(s), to e.g. sample transient numeric identifiers employed by such device(s).
</t>
</section>
<section title="Issues with the Specification of Transient Numeric Identifiers" anchor="issues">
<t>While assessing protocol specifications regarding the use of transient numeric identifiers, we have found that most of the issues discussed in this document arise as a result of one of the following conditions:
<list style="symbols">
<t>Protocol specifications that under-specify the requirements for their transient numeric identifiers</t>
<t>Protocol specifications that over-specify their transient numeric identifiers</t>
<t>Protocol implementations that simply fail to comply with the specified requirements</t>
</list>
</t>
<t>A number of protocol specifications (too many of them) have simply overlooked the security and privacy implications of transient numeric identifiers. Examples of them are the specification of TCP ephemeral ports in <xref target="RFC0793"/>, the specification of TCP sequence numbers in <xref target="RFC0793"/>, or the specification of the DNS TxID in <xref target="RFC1035"/>.</t>
<t>On the other hand, there are a number of protocol specifications that over-specify some of their associated transient numeric identifiers. For example, <xref target="RFC4291"/> essentially overloads the semantics of IPv6 Interface Identifiers (IIDs) by embedding link-layer addresses in the IPv6 IIDs, when the interoperability requirement of uniqueness could be achieved in other ways that do not result in negative security and privacy implications <xref target="RFC7721"/>. Similarly, <xref target="RFC2460"/> suggested the use of a global counter for the generation of Fragment Identification values, when the interoperability properties of uniqueness per {Src IP, Dst IP} could be achieved with other algorithms that do not result in negative security and privacy implications <xref target="RFC7739"/>.</t>
<t>Finally, there are protocol implementations that simply fail to comply with existing protocol specifications. For example, some popular operating systems (notably Microsoft Windows) still fail to implement transport protocol ephemeral port randomization, as recommended in <xref target="RFC6056"/>.</t>
</section>
<section title="IPv4/IPv6 Identification" anchor="ipid">
<t>This section presents the timeline of the Identification field employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). The reason for presenting both cases in the same section is to make it evident that while the Identification value serves the same purpose in both IPv4 and IPv6, the work and research done for the IPv4 case did not affect IPv6 specifications or implementations.</t>
<t>The IPv4 Identification is specified in <xref target="RFC0791"/>, which specifies the interoperability requirements for the Identification field: the sender must choose the Identification field to be unique for a given source address, destination address, and protocol, for the time the datagram (or any fragment of it) could be alive in the internet. It suggests that a node may keep "a table of Identifiers, one entry for each destination it has communicated with in the last maximum packet lifetime for the internet", and suggests that "since the Identifier field allows 65,536 different values, hosts may be able to simply use unique identifiers independent of destination". The above has been interpreted numerous times as a suggestion to employ per-destination or global counters for the generation of Identification values. While <xref target="RFC0791"/> does not suggest any flawed algorithm for the generation of Identification values, the specification omits a discussion of the security and privacy implications of predictable Identification values. This has resulted in many IPv4 implementations generating predictable fragment Identification values by means of a global counter, at least at some point in time.
</t>
<t>
The IPv6 Identification was originally specified in <xref target="RFC1883"/>. It serves the same purpose as its IPv4 counterpart, with the only difference residing in the length of the corresponding field, and that while the IPv4 Identification field is part of the base IPv4 header, in the IPv6 case it is part of the Fragment header (which may or may not be present in an IPv6 packet). <xref target="RFC1883"/> states, in Section 4.5, that the Identification must be different than that of any other fragmented packet sent recently (within the maximum likely lifetime of a packet) with the same Source Address and Destination Address. Subsequently, it notes that this requirement can be met by means of a wrap-around 32-bit counter that is incremented each time a packet must be fragmented, and that it is an implementation choice whether to use a global or a per-destination counter. Thus, the implementation of the IPv6 Identification is similar to that of the IPv4 case, with the only difference that in the IPv6 case the suggestions to use simple counters is more explicit. <xref target="RFC2460"/> was the first revision of the core IPv6 specification, and maintained the same text for the specification of the IPv6 Identification field. <xref target="RFC8200"/>, the second revision of the core IPv6 specification, removes the suggestion from <xref target="RFC2460"/> to use a counter for the generation of IPv6 Identification values, and points to <xref target="RFC7739"/> for sample algorithms for their generation.
</t>
<t>
<list style="hanging">
<t hangText="September 1981:">
<vspace blankLines="0" /><xref target="RFC0791"/> specifies the interoperability requirements for IPv4 Identification value, but does not perform a vulnerability assessment of this transient numeric identifier.
</t>
<t hangText="December 1995:">
<vspace blankLines="0" /><xref target="RFC1883"/>, the first specification of the IPv6 protocol, is published. It suggests that a counter be used to generate the IPv6 Identification value, and notes that it is an implementation choice whether to maintain a single counter for the node or multiple counters, e.g., one for each of the node's possible source addresses, or one for each active (source address, destination address) combination.
</t>
<t hangText="December 1998:">
<vspace blankLines="0" /><xref target="Sanfilippo1998a"/> finds that predictable IPv4 Identification values (generated by most popular implementations) can be leveraged to count the number of packets sent by a target node. <xref target="Sanfilippo1998b"/> explains how to leverage the same vulnerability to implement a port-scanning technique known as dumb/idle scan. A tool that implements this attack is publicly released.
</t>
<t hangText="December 1998:">
<vspace blankLines="0" /><xref target="RFC2460"/>, a revision of the IPv6 specification, is published, obsoleting <xref target="RFC1883"/>. It maintains the same specification of the IPv6 Identification field as its predecessor (<xref target="RFC1883"/>).
</t>
<t hangText="November 1999:">
<vspace blankLines="0" /><xref target="Sanfilippo1999"/> discusses how to leverage predictable IPv4 Identification to uncover the rules of a number of firewalls.
</t>
<t hangText="December 1998:">
<vspace blankLines="0" />OpenBSD implements randomization of the IPv4 Identification field <xref target="OpenBSD-IPv4-ID"/>. This feature eventually shipped with OpenBSD 2.5.
</t>
<t hangText="November 1999:">
<vspace blankLines="0" /><xref target="Bellovin2002"/> explains how the IPv4 Identification field can be exploited to count the number of systems behind a NAT.
</t>
<t hangText="September 2002:">
<vspace blankLines="0" /><xref target="Fyodor2002"/> explains how to implement a stealth port-scanning technique by leveraging nodes that employ predictable IPv4 Identification values.
</t>
<t hangText="October 2003:">
<vspace blankLines="0" />OpenBSD implements randomization of the IPv6 Identification field <xref target="OpenBSD-IPv6-ID"/>. This feature eventually shipped with OpenBSD 3.4.
</t>
<t hangText="December 2003:">
<vspace blankLines="0" /><xref target="Zalewski2003"/> explains a technique to perform TCP data injection attack based on predictable IPv4 identification values which requires less effort than TCP injection attacks performed with bare TCP packets.
</t>
<t hangText="November 2005:">
<vspace blankLines="0" /><xref target="Silbersack2005"/> discusses shortcoming in a number of techniques to mitigate predictable IPv4 Identification values.
</t>
<t hangText="October 2007:">
<vspace blankLines="0" /><xref target="Klein2007"/> describes a weakness in the pseudo random number generator (PRNG) in use for the generation of the IP Identification by a number of operating systems.
</t>
<t hangText="June 2011:">
<vspace blankLines="0" /><xref target="Gont2011"/> describes how to perform idle scan attacks in IPv6.
</t>
<t hangText="November 2011:">
<vspace blankLines="0" />Linux mitigates predictable IPv6 Identification values <xref target="RedHat2011"/> <xref target="SUSE2011"/> <xref target="Ubuntu2011"/>.
</t>
<t hangText="December 2011:">
<vspace blankLines="0" /><xref target="draft-gont-6man-predictable-fragment-id-00"/> describes the security implications of predictable IPv6 Identification values, and possible mitigations. This document has the Intended Status of "Standards Track", with the intention to formally update <xref target="RFC2460"/>, to introduce security and privacy requirements on IPv6 Identification values.
</t>
<t hangText="May 2012:">
<vspace blankLines="0" /><xref target="Gont2012"/> notes that some major IPv6 implementations still employ predictable IPv6 Identification values.
</t>
<!-- [fgont] Historia de RFC7739 -->
<t hangText="March 2013:">
<vspace blankLines="0" />The 6man WG adopts <xref target="I-D.gont-6man-predictable-fragment-id"/>, but changes the track to "BCP" (while still formally updating <xref target="RFC2460"/>), publishing the resulting document as <xref target="draft-ietf-6man-predictable-fragment-id-00"/>.
</t>
<t hangText="June 2013:">
<vspace blankLines="0" />A patch that implements IPv6-based idle-scan in nmap is submitted <xref target="Morbitzer2013"/>.
</t>
<t hangText="December 2014:">
<vspace blankLines="0" />The 6man WG changes the Intended Status of <xref target="draft-ietf-6man-predictable-fragment-id-01"/> to "Informational" and publishes it as <xref target="draft-ietf-6man-predictable-fragment-id-02"/>. As a result, it no longer formally updates <xref target="RFC2460"/>.
</t>
<t hangText="June 2015:">
<vspace blankLines="0" /><xref target="draft-ietf-6man-predictable-fragment-id-08"/> notes that some popular host and router implementations still employ predictable IPv6 Identification values.
</t>
<t hangText="February 2016:">
<vspace blankLines="0" /><xref target="RFC7739"/> (based on <xref target="I-D.ietf-6man-predictable-fragment-id"/>) analyzes the security and privacy implications of predictable IPv6 Identification values, and provides guidance for selecting an algorithm to generate such values. However, being published with the Intended Status of "Informational", it does not formally update <xref target="RFC2460"/>. <!--Note: The oiginal individual submission IP, revision of <xref target="RFC2460"/> removes the suggestion from RFC2460 to employ a global counter for the generation of IPv6 Identification values, but does specify any security and privacy requirements for the IPv6 Identification value.-->
</t>
<t hangText="June 2016:">
<vspace blankLines="0" /><xref target="I-D.ietf-6man-rfc2460bis"/>, revision of <xref target="RFC2460"/>, removes the suggestion from RFC2460 to use a counter for the generation of IPv6 Identification values, but does not perform a vulnerability assessment of the generation of IPv6 Identification values.
</t>
<t hangText="July 2017:">
<vspace blankLines="0" /><xref target="I-D.ietf-6man-rfc2460bis"/> is finally published as <xref target="RFC8200"/>, obsoleting <xref target="RFC2460"/>, and pointing to <xref target="RFC7739"/> for sample algorithms for the generation of IPv6 Fragment Identification values.
</t>
<t hangText="June 2019:">
<vspace blankLines="0" /><xref target="IPID-DEV"/> notes that the IPv6 ID generators of two popular operating systems are flawed.
</t>
</list>
</t>
</section>
<section title="TCP Initial Sequence Numbers (ISNs)" anchor="tcp-isns">
<t>
<xref target="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 being accepted by a new incarnation of a previous connection. <xref target="RFC0793"/> suggests the use of a global 32-bit ISN generator that is incremented by 1 roughly every 4 microseconds. However, as a matter of fact, protection against stale segments from a previous incarnation of the connection is enforced by preventing the creation of a new incarnation of a previous connection before 2*MSL have passed since a segment corresponding to the old incarnation was last seen (where "MSL" is the "Maximum Segment Lifetime" <xref target="RFC0793"/>). This is accomplished by the TIME-WAIT state and TCP's "quiet time" concept (see Appendix B of <xref target="RFC1323"/>). Based on the assumption that ISNs are monotonically increasing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an incoming SYN segment to perform "heuristics" that enable the creation of a new incarnation of a connection while the previous incarnation is still in the TIME-WAIT state (see p. 945 of <xref target="Wright1994"/>). This avoids an interoperability problem that may arise when a node establishes connections to a specific TCP end-point at a high rate <xref target="Silbersack2005"/>.</t>
<t>The interoperability requirements for TCP ISNs are probably not as clearly spelled out as one would expect. Furthermore, the suggestion of employing a global counter in <xref target="RFC0793"/> negatively affects the security and privacy properties of the protocol.</t>
<t>
<list style="hanging">
<t hangText="September 1981:">
<vspace blankLines="0" /><xref target="RFC0793"/>, suggests the use of a global 32-bit ISN
generator, whose lower bit is incremented roughly every 4 microseconds. However, such an ISN generator makes it trivial to predict the ISN that a TCP instance will use for new connections, thus allowing a variety of attacks against TCP.
</t>
<!--
<t hangText="September 1981:">
<vspace blankLines="0" /><xref target="RFC0793"/>, suggests the use of a global 32-bit ISN
generator, whose lower bit is incremented roughly every 4 microseconds. However, such an ISN generator makes it trivial to predict the ISN that a TCP will use for new connections, thus allowing a variety of attacks against TCP.
</t>
-->
<t hangText="February 1985:">
<vspace blankLines="0" /><xref target="Morris1985"/> was the first to describe how to exploit predictable TCP ISNs for forging TCP connections that could then be leveraged for trust relationship exploitation.
</t>
<t hangText="April 1989:">
<vspace blankLines="0" /><xref target="Bellovin1989"/> discussed the security considerations for predictable ISNs (along with a range of other protocol-based vulnerabilities).
</t>
<t hangText="February 1995:">
<vspace blankLines="0" /><xref target="Shimomura1995"/> reported a real-world exploitation of the attack described in 1985 (ten years before) in <xref target="Morris1985"/>.
</t>
<t hangText="May 1996:">
<vspace blankLines="0" /><xref target="RFC1948"/> was the first IETF effort, authored by Steven Bellovin, to address predictable TCP ISNs. The same concept specified in this document for TCP ISNs was later proposed for TCP ephemeral ports <xref target="RFC6056"/>, TCP Timestamps, and eventually even IPv6 Interface Identifiers <xref target="RFC7217"/>.
</t>
<t hangText="July 1996:">
<vspace blankLines="0" />OpenBSD implements TCP ISN randomization based on random increments (please see Appendix A.2 of <xref target="I-D.irtf-pearg-numeric-ids-generation"/>) <xref target="OpenBSD-TCP-ISN-I"/>. The feature eventually shipped with OpenBSD 2.0.
</t>
<t hangText="December 2000:">
<vspace blankLines="0" />OpenBSD implements TCP ISN randomization using simple randomization (please see Section 7.1 of <xref target="I-D.irtf-pearg-numeric-ids-generation"/>) <xref target="OpenBSD-TCP-ISN-R"/>. The feature eventually shipped with OpenBSD 2.9.
</t>
<t hangText="March 2001:">
<vspace blankLines="0" /><xref target="Zalewski2001"/> provides a detailed analysis of statistical weaknesses in some ISN generators, and includes a survey of the algorithms in use by popular TCP implementations.
</t>
<t hangText="May 2001:">
<vspace blankLines="0" />Vulnerability advisories <xref target="CERT2001"/> <xref target="USCERT2001"/> are released regarding statistical weaknesses in some ISN generators, affecting popular TCP/IP implementations.
</t>
<t hangText="March 2002:">
<vspace blankLines="0" /><xref target="Zalewski2002"/> updates and complements <xref target="Zalewski2001"/>. It concludes that "while some vendors [...] reacted promptly and tested their solutions properly, many still either ignored the issue and never evaluated their implementations, or implemented a flawed solution that apparently was not tested using a known approach" <xref target="Zalewski2002"/>.
</t>
<t hangText="June 2007:">
<vspace blankLines="0" />OpenBSD implements TCP ISN randomization based on the algorithm specified in <xref target="RFC1948"/> (currently obsoleted by <xref target="RFC6528"/>) for the TCP endpoint that performs the active open, while keeping the simple randomization scheme for the endpoint performing the passive open <xref target="OpenBSD-TCP-ISN-H"/>. This provides monotonically-increasing ISNs for the client side (allowing the BSD heuristics to work as expected), while avoiding any patterns in the ISN generation for the server side. This feature eventually shipped with OpenBSD 4.2.
</t>
<t hangText="February 2012:">
<vspace blankLines="0" /><xref target="RFC6528"/>, published 27 years after Morris' original work <xref target="Morris1985"/>, formally updates <xref target="RFC0793"/> to mitigate predictable TCP ISNs.
</t>
<t hangText="August 2014:">
<vspace blankLines="0" /><xref target="I-D.eddy-rfc793bis-04"/>, the upcoming revision of the core TCP protocol specification, incorporates the algorithm specified in <xref target="RFC6528"/> as the recommended algorithm for TCP ISN generation.
</t>
</list>
</t>
</section>
<section title="IPv6 Interface Identifiers (IIDs)" anchor="ipv6-iids">
<t>IPv6 Interface Identifiers can be generated in multiple ways: SLAAC <xref target="RFC4862"/>, DHCPv6 <xref target="RFC8415"/>, and manual configuration. This section focuses on Interface Identifiers resulting from SLAAC.</t>
<t>The Interface Identifier of stable (traditional) IPv6 addresses resulting from SLAAC have traditionally resulted in the underlying link-layer address being embedded in the IID.<!-- IPv6 addresses resulting from SLAAC are currently required to employ Modified EUI-64 format identifiers, which essentially embed the underlying link-layer address of the corresponding network interface. --> At the time, employing the underlying link-layer address for the IID was seen as a convenient way to obtain a unique address. However, recent awareness about the security and privacy properties of this approach <xref target="RFC7707"/> <xref target="RFC7721"/> has led to the replacement of this flawed scheme with an alternative one <xref target="RFC7217"/> <xref target="RFC8064"/> that does not negatively affect the security and privacy properties of the protocol.
</t>
<t>
<list style="hanging">
<t hangText="January 1997:">
<vspace blankLines="0" /><xref target="RFC2073"/> specifies the syntax of IPv6 global addresses (referred to as "An IPv6 Provider-Based Unicast Address Format" at the time), consistent with the IPv6 addressing architecture specified in <xref target="RFC1884"/>. Hosts are recommended to "generate addresses using link-specific addresses as Interface ID such as 48 bit IEEE-802 MAC addresses".
</t>
<t hangText="July 1998:">
<vspace blankLines="0" /><xref target="RFC2374"/> specifies "An IPv6 Aggregatable Global Unicast Address Format" (obsoleting <xref target="RFC2373"/>) changing the size of the Interface ID to 64 bits, and specifies that that IIDs must be constructed in IEEE EUI-64 format. How such identifiers are constructed becomes specified in the appropriate "IPv6 over <link>" specification such as "IPv6 over Ethernet".
</t>
<t hangText="January 2001:">
<vspace blankLines="0" /><xref target="RFC3041"/> recognizes the problem of network activity correlation, and specifies temporary addresses. Temporary addresses are to be used along with stable addresses.
</t>
<t hangText="August 2003:">
<vspace blankLines="0" /><xref target="RFC3587"/> obsoletes <xref target="RFC2374"/>, making the TLA/NLA structure historic. The syntax and recommendations for the traditional stable IIDs remain unchanged, though.
</t>
<t hangText="February 2006:">
<vspace blankLines="0" /><xref target="RFC4291"/> is published as the latest "IP Version 6 Addressing Architecture", requiring the IIDs of the traditional (stable) autoconfigured addresses to employ the Modified EUI-64 format. The details of constructing such interface identifiers are defined in the appropriate "IPv6 over <link>" specifications.
</t>
<t hangText="March 2008:">
<vspace blankLines="0" /><xref target="RFC5157"/> provides hints regarding how patterns in IPv6 addresses could be leveraged for the purpose of address scanning.
</t>
<t hangText="December 2011:">
<vspace blankLines="0" /><xref target="draft-gont-6man-stable-privacy-addresses-00"/> notes that the traditional scheme for generating stable addresses allows for address scanning, and also does not prevent active node tracking. It also specifies an alternative algorithm meant to replace IIDs based on Modified EUI-64 format identifiers.
</t>
<t hangText="November 2012:">
<vspace blankLines="0" />The 6man WG adopts <xref target="I-D.gont-6man-stable-privacy-addresses"/> as a working group item (as <xref target="draft-ietf-6man-stable-privacy-addresses-00"/>). However, the document no longer formally updates <xref target="RFC4291"/>, and therefore the specified algorithm no longer formally replaces the Modified EUI-64 format identifiers.
</t>
<t hangText="February 2013:">
<vspace blankLines="0" />An address-scanning tool (scan6 of <xref target="IPv6-Toolkit"/>) that leverages IPv6 address patterns is released <xref target="Gont2013"/>.
</t>
<t hangText="July 2013:">
<vspace blankLines="0" /><xref target="I-D.cooper-6man-ipv6-address-generation-privacy"/> elaborates on the security and privacy properties of all known algorithms for generating IPv6 IIDs.
</t>
<t hangText="January 2014:">
<vspace blankLines="0" />The 6man WG publishes <xref target="draft-ietf-6man-default-iids-00"/> ("Recommendation on Stable IPv6 Interface Identifiers"), recommending <xref target="I-D.ietf-6man-stable-privacy-addresses"/> for the generation of stable addresses.
</t>
<t hangText="April 2014:">
<vspace blankLines="0" /><xref target="RFC7217"/> (formerly <xref target="I-D.ietf-6man-stable-privacy-addresses"/>) is published, specifying "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" as an alternative to (but *not* replacement of) Modified EUI-64 format IIDs.
</t>
<t hangText="March 2016:">
<vspace blankLines="0" /><xref target="RFC7707"/> (formerly <xref target="I-D.gont-opsec-ipv6-host-scanning"/>, and later <xref target="I-D.ietf-opsec-ipv6-host-scanning"/>), about "Network Reconnaissance in IPv6 Networks", is published.
</t>
<t hangText="March 2016:">
<vspace blankLines="0" /><xref target="RFC7721"/> (formerly <xref target="I-D.cooper-6man-ipv6-address-generation-privacy"/> and later <xref target="I-D.ietf-6man-ipv6-address-generation-privacy"/>), about "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", is published.
</t>
<t hangText="May 2016:">
<vspace blankLines="0" /><xref target="draft-gont-6man-non-stable-iids-00"/> is published, with the goal of specifying requirements for non-stable addresses, and updating <xref target="RFC4941"/> such that use of only temporary addresses is allowed.
</t>
<t hangText="May 2016:">
<vspace blankLines="0" /><xref target="draft-gont-6man-address-usage-recommendations-00"/> is published, providing an analysis of how different aspects on an address (from stability to usage mode) affect their corresponding security and privacy properties, and meaning to eventually provide advice in this area.
</t>
<t hangText="February 2017:">
<vspace blankLines="0" />The 6man WG publishes <xref target="RFC8064"/> ("Recommendation on Stable IPv6 Interface Identifiers") (formerly <xref target="I-D.ietf-6man-default-iids"/>), with requirements for stable addresses and a recommendation to employ <xref target="RFC7217"/> for the generation of stable addresses. It formally updates a large number of RFCs.
</t>
<t hangText="March 2018:">
<vspace blankLines="0" /><xref target="draft-fgont-6man-rfc4941bis-00"/> is published (as suggested by the 6man WG), to address flaws in <xref target="RFC4941"/> by revising it (as an alternative to the <xref target="draft-gont-6man-non-stable-iids-00"/> effort, published in March 2016).
</t>
<t hangText="July 2018:">
<vspace blankLines="0" /><xref target="draft-ietf-6man-rfc4941bis-00"/> is adopted (as <xref target="draft-fgont-6man-rfc4941bis-00"/>) as a WG item of the 6man WG.
</t>
<t hangText="March 2020:">
<vspace blankLines="0" /><xref target="I-D.ietf-6man-rfc4941bis"/> passes WGLC.
</t>
<t hangText="December 2020:">
<vspace blankLines="0" /><xref target="I-D.ietf-6man-rfc4941bis"/> is finally approved by the IESG for publication as an RFC.
</t>
</list>
</t>
</section>
<!-- [fgont] Una revision futura podria incluir la generacion de direcciones IPv6 leaseadas via DHCPv6
<section title="DHCPv6-leased IPv6 Addresses" anchor="dhcpv6-addresses">
<t>
</t>
</section>
-->
<section title="NTP Reference IDs (REFIDs)" anchor="ntp-refid">
<!-- [fgont] Esto hay que expandirlo, como en los otros casos -->
<t>NTP <xref target="RFC5905"/> Reference IDs are employed to avoid degree-one timing loops in scenarios where two NTP peers are (mutually) the time source of each other.</t>
<t>
<list style="hanging">
<t hangText="June 2010:">
<vspace blankLines="0" /><xref target="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 source or an MD5 hash of the IPv6 address of the time source.
</t>
<t hangText="July 2016:">
<vspace blankLines="0" /><xref target="draft-stenn-ntp-not-you-refid-00"/> is published, describing the information leakage produced via the NTP REFID. It proposes that NTP returns a special REFID when a packet employs an IP Source Address that is not believed to be a current NTP peer, but otherwise generates and returns the traditional REFID. It is subsequently adopted by the NTP WG as <xref target="I-D.ietf-ntp-refid-updates"/>.
</t>
<t hangText="April 2019:">
<vspace blankLines="0" /><xref target="Gont-NTP"/> notes that the proposed fix specified in <xref target="draft-ietf-ntp-refid-updates-00"/> is, at the very least, sub-optimal.
</t>
</list>
</t>
</section>
<section title="Transport Protocol Ephemeral Port Numbers" anchor="port-numbers">
<t>Most (if not all) transport protocols employ "port numbers" to demultiplex packets to the corresponding transport protocol instances.</t>
<!-- [fgont] esto hay que expandirlo, como en los otros casos -->
<t>
<list style="hanging">
<t hangText="August 1980:">
<vspace blankLines="0" /><xref target="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.</t>
<t hangText="September 1981:">
<vspace blankLines="0" /><xref target="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.
</t>
<t hangText="July 1996:">
<vspace blankLines="0" />OpenBSD implements ephemeral port randomization <xref target="OpenBSD-PR"/>. The feature eventually shipped with OpenBSD 2.0.
</t>
<t hangText="July 2008:">
<vspace blankLines="0" />The CERT Coordination Centre published details of what became known as the "Kaminsky Attack" <xref target="VU-800113"/> on the DNS. The attack exploited the lack of source port randomisation in many major DNS implementations to perform cache poisoning in an effective and practical manner.
</t>
<t hangText="January 2009:">
<vspace blankLines="0" /><xref target="RFC5452"/> mandates the use of port randomization for DNS resolvers, and mandates that implementations must randomize ports from the range (53 or 1024, and above) or the largest possible port range. It does not recommend possible algorithms for port randomization, although the document specifically targets DNS resolvers, for which a simple port randomization suffices (e.g. Algorithm 1 of <xref target="RFC6056"/>). This document led to the implementation of port randomization in the DNS resolver themselves, rather than in the underlying transport-protocols.
</t>
<t hangText="January 2011:">
<vspace blankLines="0" /><xref target="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.
</t>
<t hangText="March 2016:">
<vspace blankLines="0" /><xref target="NIST-NTP"/> reports a non-normal distribution of the ephemeral port numbers employed by the NTP clients of an Internet Time Service.
</t>
<t hangText="April 2019:">
<vspace blankLines="0" /><xref target="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 specification to recommend port randomization in such cases, in line with <xref target="RFC6056"/>. The proposal experiences some push-back in the relevant working group (NTP WG) <xref target="NTP-PORTR"/>, but is finally adopted as a working group item as <xref target="I-D.ietf-ntp-port-randomization"/>.
</t>
<t hangText="September 2019:">
<vspace blankLines="0" /><xref target="I-D.ietf-ntp-port-randomization"/> passes its WGLC.
</t>
</list>
</t>
</section>
<!--
<t>The DNS Query ID <xref target="RFC1035"/> is employed to match queries with responses.</t>
<list style="hanging">
<t hangText="November 1987:">
<vspace blankLines="0" /><xref target="RFC1035"/> specifies that the ID is a 16 bit identifier assigned by the program that
generates any kind of query, and that this identifier is copied the corresponding reply and can be used by the requester to match up replies to outstanding queries. It does nto specify the interoperability requirements for these numeric identifiers, nor does it suggest an algorithm for generating them.</t>
<t hangText="1993:">
<vspace blankLines="0" /><xref target="Schuba"/> describes DNS cache poisoning attacks that require the attacker to guess the Query ID.</t>
<t hangText="June 1995:">
<vspace blankLines="0" /><xref target="Vixie"/> notes that both the UDP source port and the ID of query packets should be randomized.</t>
<t hangText="April 1997:">
<vspace blankLines="0" /><xref target="AK"/> finds that implementations employ predictable UDP source ports and predictable Query IDs, and argue that both should be randomized.</t>
<t hangText="November 2002:">
<vspace blankLines="0" /><xref target="Sacramento"/> finds that by spoofing multiple requests for the same domain name from different IP addresses, an attacker may guess the Query ID employed for a victim with a high probability of success, thus performing DNS cache poisoning attacks.</t>
<t hangText="March 2007:">
<vspace blankLines="0" /><xref target="KleinDNS"/> finds that a popular DNS server software (BIND 9) that randomize the Query ID are stil subject to DNS cache poisoning attacks by forging a large number of queries and leveraging the birthday paradox.</t>
</t>
</list>
</t>
</section>
-->
<section title="IANA Considerations" anchor="iana-considerations">
<t>There are no IANA registries within this document. The RFC-Editor can remove this section before publication of this document as an RFC.</t>
</section>
<section title="Security Considerations">
<t>This document analyzes the timeline of the specification and implementation of the transient numeric identifiers of some sample IETF protocols, and how the security and privacy properties of such protocols have been affected as a result of it. It provides concrete evidence that advice in this area is warranted.</t>
<t><xref target="I-D.gont-numeric-ids-sec-considerations"/> formally requires protocol specifications to specify the interoperability requirements for their transient numeric identifiers, to do a warranted vulnerability assessment of such transient numeric identifiers, and to recommend possible algorithms for their generation, such that the interoperability requirements are complied with, while any negative security and privacy properties of these transient numeric identifiers are mitigated.</t>
<t><xref target="I-D.irtf-pearg-numeric-ids-generation"/> analyzes and categorizes transient numeric identifiers based on their interoperability requirements and their associated failure modes, and recommends possible algorithms that can comply with those requirements without negatively affecting the security and privacy properties of the corresponding protocols.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank (in alphabetical order) Bernard Aboba, Dave Crocker, Theo de Raadt, Sara Dickinson, Guillermo Gont, Christian Huitema, Kris Shrishak, Joe Touch, and Christopher Wood, for providing valuable comments on earlier versions of this document.</t>
<t>The authors would like to thank (in alphabetical order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, and Martin Thomson, for providing valuable comments on <xref target="I-D.gont-predictable-numeric-ids"/>, on which this document is based.</t>
<t><xref target="tcp-isns"/> of this document borrows text from <xref target="RFC6528"/>, authored by Fernando Gont and Steven Bellovin.</t>
<t>The authors would like to thank Sara Dickinson and Christopher Wood, for their guidance during the publication process of this document.</t>
<t>The authors would like to thank Diego Armando Maradona for his magic and inspiration.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<!--
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2119" ?>
-->
<!-- UDP -->
<?rfc include="reference.RFC.0768" ?>
<!-- TCP sequence numbers -->
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.6528" ?> <!-- TCP SEQ randomization -->
<!-- IPv4-->
<?rfc include="reference.RFC.0791" ?>
<!-- IPv6 -->
<?rfc include="reference.RFC.1883" ?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.8200" ?>
<!-- Randomness requirements-->
<!--
<?rfc include="reference.RFC.4086" ?>
-->
<!--
<?rfc include="reference.RFC.6151" ?>
-->
<!-- IPv6 Addresses -->
<?rfc include="reference.RFC.7217" ?>
<?rfc include="reference.RFC.3041" ?>
<?rfc include="reference.RFC.2073" ?>
<?rfc include="reference.RFC.2374" ?>
<?rfc include="reference.RFC.3587" ?>
<?rfc include="reference.RFC.1884" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.2373" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.8415" ?>
<!-- TCP ISNs -->
<?rfc include="reference.RFC.1323" ?>
<!-- Port randomization -->
<?rfc include="reference.RFC.6056" ?>
<?rfc include="reference.RFC.5452" ?>
</references>
<references title='Informative References'>
<reference anchor="OpenBSD-PR" target="https://cvsweb.openbsd.org/src/sys/netinet/in_pcb.c?rev=1.6">
<front>
<title>Implementation of port randomization</title>
<author>
<organization>OpenBSD</organization>
</author>
<date day="29" month="July" year="1996"/>
</front>
</reference>
<reference anchor="VU-800113" target="https://www.kb.cert.org/vuls/id/800113">
<front>
<title>Multiple DNS implementations vulnerable to cache poisoning (Vulnerability Note VU#800113)</title>
<author>
<organization>CERT/CC</organization>
</author>
<date day="8" month="July" year="2008"/>
</front>
</reference>
<reference anchor="IANA-PROT" target="https://www.iana.org/protocols">
<front>
<title>Protocol Registries</title>
<author initials="" surname="IANA" fullname="IANA">
<organization></organization>
</author>
<date/>
</front>
<!--
<seriesInfo name="" value="Federal Information Processing Standards Publication 180-4"/>
-->
</reference>
<!-- IPv6 Addresses -->
<?rfc include="reference.RFC.5157" ?>
<?rfc include="reference.I-D.ietf-6man-rfc4941bis" ?>
<?rfc include="reference.I-D.gont-opsec-ipv6-host-scanning" ?>
<?rfc include="reference.I-D.ietf-opsec-ipv6-host-scanning" ?>
<?rfc include="reference.I-D.gont-6man-stable-privacy-addresses" ?>
<?rfc include="reference.I-D.ietf-6man-stable-privacy-addresses" ?>
<?rfc include="reference.I-D.cooper-6man-ipv6-address-generation-privacy" ?>
<?rfc include="reference.I-D.ietf-6man-ipv6-address-generation-privacy" ?>
<reference anchor="Gont2013" target="https://lists.si6networks.com/pipermail/ipv6hackers/2013-February/000947.html">
<front>
<title>Beta release of the SI6 Network's IPv6 Toolkit (help wanted!)</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<date year="2013"/>
</front>
<seriesInfo name="Message posted to the IPv6 Hackers mailing-list" value=" Message-ID: <[email protected]>"/>
</reference>
<reference anchor="IPv6-Toolkit" target="https://www.si6networks.com/tools/ipv6toolkit">
<front>
<title>SI6 Networks' IPv6 Toolkit</title>
<author>
<organization>SI6 Networks</organization>
</author>
<date/>
</front>
</reference>
<reference anchor='draft-gont-6man-stable-privacy-addresses-00'>
<front>
<title>A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<date month='December' day='15' year='2011' />
</front>
<seriesInfo name='Internet-Draft' value='draft-gont-6man-stable-privacy-addresses-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-gont-6man-stable-privacy-addresses-00.txt' />
</reference>
<reference anchor='draft-ietf-6man-stable-privacy-addresses-00'>
<front>
<title>A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<date month='May' day='18' year='2012' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-stable-privacy-addresses-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-00.txt' />
</reference>
<reference anchor='draft-gont-6man-address-usage-recommendations-00'>
<front>
<title>IPv6 Address Usage Recommendations</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<author initials="W." surname="Liu" fullname="Will Liu">
</author>
<date month='May' day='27' year='2016' />
</front>
<seriesInfo name='Internet-Draft' value='draft-gont-6man-address-usage-recommendations-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-gont-6man-address-usage-recommendations-00.txt' />
</reference>
<reference anchor='draft-gont-6man-non-stable-iids-00'>
<front>
<title>Recommendation on Non-Stable IPv6 Interface Identifiers</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<author initials="W." surname="Liu" fullname="Will Liu">
</author>
<date month='May' day='23' year='2016' />
</front>
<seriesInfo name='Internet-Draft' value='draft-gont-6man-non-stable-iids-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-gont-6man-non-stable-iids-00.txt' />
</reference>
<reference anchor='draft-ietf-6man-default-iids-00'>
<front>
<title>Recommendation on Stable IPv6 Interface Identifiers</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
</author>
<author initials="A." surname="Cooper" fullname="Alissa Cooper">
</author>
<author
fullname="Dave Thaler"
initials="D."
surname="Thaler">
</author>
<author initials="W." surname="Liu" fullname="Will Liu">
</author>
<date month='July' day='28' year='2014' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-default-iids-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-6man-default-iids-00.txt' />
</reference>
<?rfc include="reference.RFC.8064" ?>
<reference anchor='draft-ietf-6man-rfc4941bis-00'>
<front>
<title abbrev="Privacy Extensions to Autoconf">Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
<organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks /
UTN-FRH</organization>
</author>
<author initials="S.K." surname="Krishnan"
fullname="Suresh Krishnan">
<organization>Ericsson Research</organization>
</author>
<author initials="T.N." surname="Narten"
fullname="Thomas Narten">
<organization>IBM Corporation</organization>
</author>
<author initials="R.D." surname="Draves"
fullname="Richard Draves">
<organization>Microsoft Research</organization>
</author>
<date month='July' day='2' year='2018' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-6man-rfc4941bis-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-6man-rfc4941bis-00.txt' />
</reference>
<reference anchor='draft-fgont-6man-rfc4941bis-00'>
<front>
<title abbrev="Privacy Extensions to Autoconf">Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6</title>
<author fullname="Fernando Gont" initials="F." surname="Gont">
<organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks /
UTN-FRH</organization>
</author>
<author initials="S.K." surname="Krishnan"
fullname="Suresh Krishnan">
<organization>Ericsson Research</organization>
</author>
<author initials="T.N." surname="Narten"
fullname="Thomas Narten">
<organization>IBM Corporation</organization>
</author>
<author initials="R.D." surname="Draves"
fullname="Richard Draves">
<organization>Microsoft Research</organization>
</author>
<date month='March' day='25' year='2018' />
</front>
<seriesInfo name='Internet-Draft' value='draft-fgont-6man-rfc4941bis-00' />
<format type='TXT'
target='https://tools.ietf.org/id/draft-fgont-6man-rfc4941bis-00.txt' />
</reference>