-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathdraft-gont-numeric-ids-sec-considerations-05.txt
504 lines (329 loc) · 19.2 KB
/
draft-gont-numeric-ids-sec-considerations-05.txt
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
Network Working Group F. Gont
Internet-Draft SI6 Networks
Updates: 3552 (if approved) I. Arce
Intended status: Best Current Practice Quarkslab
Expires: January 30, 2021 July 29, 2020
Security Considerations for Transient Numeric Identifiers Employed in
Network Protocols
draft-gont-numeric-ids-sec-considerations-05
Abstract
Poor selection of transient numerical identifiers in protocols such
as the TCP/IP suite has historically led to a number of attacks on
implementations, ranging from Denial of Service (DoS) to data
injection and information leakage that can be exploited by pervasive
monitoring. To prevent such flaws in future protocols and
implementations, this document updates RFC 3552, requiring future
RFCs to contain analysis of the security and privacy properties of
any transient numeric identifiers specified by the protocol.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 30, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Gont & Arce Expires January 30, 2021 [Page 1]
Internet-Draft Security Considerations for IDs July 2020
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Issues with the Specification of Transient Identifiers . . . 4
4. Common Flaws in the Generation of Transient Identifiers . . . 5
5. Security and Privacy Requirements for Identifiers . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Network protocols employ a variety of transient numeric identifiers
for different protocol entities, ranging from DNS Transaction IDs
(TxIDs) to transport protocol numbers (e.g. TCP ports) or IPv6
Interface Identifiers (IIDs). These identifiers usually have
specific properties that must be satisfied such that they do not
result in negative interoperability implications (e.g., uniqueness
during a specified period of time), and an associated failure
severity when such properties not met.
The TCP/IP protocol suite alone has been subject to variety of
attacks on its numerical identifiers over the past 30 years or more,
with effects ranging from Denial of Service (DoS) or data injection,
to information leakage that could be exploited for pervasive
monitoring [RFC7258]. The root of these issues has been, in many
cases, the poor selection of identifiers in such protocols, usually
as a result of insufficient or misleading specifications. While it
is generally trivial to identify an algorithm that can satisfy the
interoperability requirements for a given identifier, there exists
practical evidence [I-D.irtf-pearg-numeric-ids-history] that doing so
without negatively affecting the security and/or privacy properties
of the aforementioned protocols is prone to error.
For example, implementations have been subject to security and/or
privacy issues resulting from:
Gont & Arce Expires January 30, 2021 [Page 2]
Internet-Draft Security Considerations for IDs July 2020
o Predictable TCP sequence numbers
o Predictable transport protocol numbers
o Predictable IPv4 or IPv6 Fragment Identifiers
o Predictable IPv6 IIDs
o Predictable DNS TxIDs
Recent history indicates that when new protocols are standardized or
new protocol implementations are produced, the security and privacy
properties of the associated identifiers tend to be overlooked and
inappropriate algorithms to generate such identifiers are either
suggested in the specification or selected by implementers. As a
result, advice in this area is warranted.
Section 3 provides an overview of common flaws in the specification
of transient numeric identifiers. Section 4 provides an overview of
the implications of predictable transient numeric identifiers.
Finally, Section 5 provides key guidelines for protocol designers.
2. Terminology
Transient Numeric Identifier:
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. [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.
Failure Severity:
The consequences of a failure to comply with the interoperability
requirements of a given identifier. Severity considers the worst
potential consequence of a failure, determined by the system
damage and/or time lost to repair the failure. In this document
we define two types of failure severity: "soft" and "hard".
Hard Failure:
Gont & Arce Expires January 30, 2021 [Page 3]
Internet-Draft Security Considerations for IDs July 2020
A hard failure is a non-recoverable condition in which a protocol
does not operate in the prescribed manner or it operates with
excessive degradation of service. For example, an established TCP
connection that is aborted due to an error condition constitutes,
from the point of view of the transport protocol, a hard failure,
since it enters a state from which normal operation cannot be
recovered.
Soft Failure:
A soft failure is a recoverable condition in which a protocol does
not operate in the prescribed manner but normal operation can be
resumed automatically in a short period of time. For example, a
simple packet-loss event that is subsequently recovered with a
retransmission can be considered a soft failure.
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Issues with the Specification of Transient Identifiers
A recent survey of transient numerical identifier usage in protocol
specifications and implementations
[I-D.irtf-pearg-numeric-ids-history] revealed that most of the issues
discussed in this document arise as a result of one of the following
conditions:
o Protocol specifications that under-specify the requirements for
their identifiers
o Protocol specifications that over-specify their identifiers
o Protocol implementations that simply fail to comply with the
specified requirements
A number of protocol implementations (too many of them) simply
overlook the security and privacy implications of identifiers.
Examples of them are the specification of TCP port numbers in
[RFC0793], the specification of TCP sequence numbers in [RFC0793], or
the specification of the DNS TxID in [RFC1035].
On the other hand, there are a number of protocol specifications that
over-specify some of their associated protocol identifiers.
Similarly, [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
Gont & Arce Expires January 30, 2021 [Page 4]
Internet-Draft Security Considerations for IDs July 2020
be achieved with other algorithms that do not result in negative
security and privacy implications.
Finally, there are protocol implementations that simply fail to
comply with existing protocol specifications. That is, appropriate
guidance is provided by the protocol specification (whether the core
specification or or an update to it), but an implementation simply
fails to follow such guidance. For example, some popular operating
systems (notably Microsoft Windows) still fails to implement
transport-protocol port randomization, as specified in [RFC6056].
Clear specification of the interoperability requirements for the
transient numeric identifiers will help identify possible algorithms
that could be employed to generate them, and also make evident if
such identifiers are being over-specified. A protocol specification
will usually also benefit from a security and privacy analysis of the
transient numeric identifiers they specify, to prevent the
corresponding considerations from being overlooked.
4. Common Flaws in the Generation of Transient Identifiers
This section briefly notes common flaws associated with the
generation of transient numeric identifiers. Such common flaws
include, but are not limited to:
o Employing trivial algorithms (e.g. global counters) that result in
predictable identifiers
o Employing the same identifier across contexts in which constancy
is not required
o Re-using identifiers across different protocols or layers of the
protocol stack
o Initializing counters or timers to constant values, when such
initialization is not required
o Employing the same increment space across different contexts
o Use of flawed pseudo-random number generators (PRNGs).
Employing trivial algorithms for generating the identifiers means
that any node that is able to sample such identifiers can easily
predict future identifiers employed by the victim node.
When one identifier is employed across contexts where such constancy
is not needed, activity correlation is made made possible. For
Gont & Arce Expires January 30, 2021 [Page 5]
Internet-Draft Security Considerations for IDs July 2020
example, employing an identifier that is constant across networks
allows for node tracking across networks.
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 properties of the original identifier (over
which the protocol re-using the identifier may have no control
regarding its generation). Besides, when re-using an identifier
across protocols from different layers, the goal of of isolating the
properties of a layer from that of another layer is broken, and the
privacy and security analysis may be harder to perform, since the
combined system, rather than each protocol in isolation will have to
be assessed.
At times, a protocol needs to convey order information (whether
sequence, timing, etc.). In many cases, there is no reason for the
corresponding counter or timer to be initialized to any specific
value e.g. at system bootstrap. Similarly, there may not be a need
for the difference between successive counted values to be a
predictable.
A node that implements a per-context linear function may share the
increment space among different contexts (please see the "Simple
Hash-Based Algorithm" in [I-D.irtf-pearg-numeric-ids-generation]).
Sharing the same increment space allows an attacker that can sample
identifiers in other context to e.g. learn how many identifiers have
been generated between two sampled values.
Finally, some implementations have been found to employ flawed PRNGs.
See e.g.[Klein2007].
5. Security and Privacy Requirements for Identifiers
When a protocol specifies transient numerical identifiers, it is
critical for the protocol specification to:
1. Clearly specify the interoperability requirements for the
aforementioned identifiers (e.g., required properties such as
uniqueness, along with the failure severity if such properties
are not met).
2. Provide a security and privacy analysis of the aforementioned
identifiers.
3. Recommend an algorithm for generating the aforementioned
identifiers that mitigates security and privacy issues, such as
those discussed in [I-D.irtf-pearg-numeric-ids-generation].
Gont & Arce Expires January 30, 2021 [Page 6]
Internet-Draft Security Considerations for IDs July 2020
6. IANA Considerations
There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an
RFC.
7. Security Considerations
This entire document is about the security and privacy implications
of transient numeric identifiers, and formally updates [RFC3552] such
that the security and privacy implications of transient numeric
identifiers are considered when writing the "Security Considerations"
section of future RFCs.
8. Acknowledgements
The authors would like to thank Benjamin Kaduk for providing valuable
comments and suggestions that have been incorporated into this
document.
This document is based on the document
[I-D.gont-predictable-numeric-ids] co-authored by Fernando Gont and
Ivan Arce. Thus, the authors would like to thank (in alphabetical
order) Steven Bellovin, Joseph Lorenzo Hall, Gre Norcie, for
providing valuable comments on that document.
The authors would like to thank Diego Armando Maradona for his magic
and inspiration.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Gont & Arce Expires January 30, 2021 [Page 7]
Internet-Draft Security Considerations for IDs July 2020
9.2. Informative References
[I-D.gont-predictable-numeric-ids]
Gont, F. and I. Arce, "Security and Privacy Implications
of Numeric Identifiers Employed in Network Protocols",
draft-gont-predictable-numeric-ids-03 (work in progress),
March 2019.
[I-D.irtf-pearg-numeric-ids-generation]
Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", draft-irtf-pearg-numeric-ids-
generation-02 (work in progress), May 2020.
[I-D.irtf-pearg-numeric-ids-history]
Gont, F. and I. Arce, "Unfortunate History of Transient
Numeric Identifiers", draft-irtf-pearg-numeric-ids-
history-02 (work in progress), April 2020.
[IANA-PROT]
IANA, "Protocol Registries",
<https://www.iana.org/protocols>.
[Klein2007]
Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability", 2007,
<http://www.trusteer.com/files/OpenBSD_DNS_Cache_Poisoning
_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
Gont & Arce Expires January 30, 2021 [Page 8]
Internet-Draft Security Considerations for IDs July 2020
Authors' Addresses
Fernando Gont
SI6 Networks
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: [email protected]
URI: https://www.si6networks.com
Ivan Arce
Quarkslab
Email: [email protected]
URI: https://www.quarkslab.com
Gont & Arce Expires January 30, 2021 [Page 9]