-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-smith-encrypted-traffic-management.html
668 lines (630 loc) · 31.8 KB
/
draft-smith-encrypted-traffic-management.html
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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>Network management of encrypted traffic</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Document structure"/>
<link href="#rfc.section.2" rel="Chapter" title="2 Network management functions"/>
<link href="#rfc.section.3" rel="Chapter" title="3 Persisting traffic management without breaching encryption"/>
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Providing hints to and from the network"/>
<link href="#rfc.section.3.1.1" rel="Chapter" title="3.1.1 DiffServ Code Points (DSCP)"/>
<link href="#rfc.section.3.1.2" rel="Chapter" title="3.1.2 Explicit Congestion Notification (ECN)"/>
<link href="#rfc.section.3.1.3" rel="Chapter" title="3.1.3 Multiprotocol Label Switching (MPLS)"/>
<link href="#rfc.section.3.1.4" rel="Chapter" title="3.1.4 Substrate Protocol for User Datagrams (SPUD)"/>
<link href="#rfc.section.3.1.5" rel="Chapter" title="3.1.5 Mobile throughput Guidance"/>
<link href="#rfc.section.3.1.6" rel="Chapter" title="3.1.6 Port Control Protocol Flowdata options"/>
<link href="#rfc.section.3.1.7" rel="Chapter" title="3.1.7 IPv6 Flow label"/>
<link href="#rfc.section.3.1.8" rel="Chapter" title="3.1.8 DISCUSS"/>
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Inferred flow information"/>
<link href="#rfc.section.3.2.1" rel="Chapter" title="3.2.1 Heuristics"/>
<link href="#rfc.section.3.3" rel="Chapter" title="3.3 Co-operation on congestion control"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Acknowledgements"/>
<link href="#rfc.section.5" rel="Chapter" title="5 IANA Considerations"/>
<link href="#rfc.section.6" rel="Chapter" title="6 Security Considerations"/>
<link href="#rfc.references" rel="Chapter" title="7 References"/>
<link href="#rfc.references.1" rel="Chapter" title="7.1 Normative References"/>
<link href="#rfc.references.2" rel="Chapter" title="7.2 Informative References"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.4.11 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Smith, K." />
<meta name="dct.identifier" content="urn:ietf:id:draft-smith-encrypted-traffic-management-04" />
<meta name="dct.issued" scheme="ISO8601" content="2015-11-13" />
<meta name="dct.abstract" content="Encrypted Internet traffic may pose traffic management challenges to network operators. This document recommends approaches to help manage encrypted traffic, without breaching user privacy or security." />
<meta name="description" content="Encrypted Internet traffic may pose traffic management challenges to network operators. This document recommends approaches to help manage encrypted traffic, without breaching user privacy or security." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Network Working Group</td>
<td class="right">K. Smith</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Vodafone Group</td>
</tr>
<tr>
<td class="left">Intended status: Informational</td>
<td class="right">November 13, 2015</td>
</tr>
<tr>
<td class="left">Expires: May 16, 2016</td>
<td class="right"></td>
</tr>
</tbody>
</table>
<p class="title">Network management of encrypted traffic<br />
<span class="filename">draft-smith-encrypted-traffic-management-04</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>Encrypted Internet traffic may pose traffic management challenges to network operators. This document recommends approaches to help manage encrypted traffic, without breaching user privacy or security.</p>
<h1 id="rfc.status">
<a href="#rfc.status">Status of This Memo</a>
</h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>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 http://datatracker.ietf.org/drafts/current/.</p>
<p>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."</p>
<p>This Internet-Draft will expire on May 16, 2016.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<ul><li>1.1. <a href="#rfc.section.1.1">Document structure</a></li>
</ul><li>2. <a href="#rfc.section.2">Network management functions</a></li>
<li>3. <a href="#rfc.section.3">Persisting traffic management without breaching encryption</a></li>
<ul><li>3.1. <a href="#rfc.section.3.1">Providing hints to and from the network</a></li>
<ul><li>3.1.1. <a href="#rfc.section.3.1.1">DiffServ Code Points (DSCP)</a></li>
<li>3.1.2. <a href="#rfc.section.3.1.2">Explicit Congestion Notification (ECN)</a></li>
<li>3.1.3. <a href="#rfc.section.3.1.3">Multiprotocol Label Switching (MPLS)</a></li>
<li>3.1.4. <a href="#rfc.section.3.1.4">Substrate Protocol for User Datagrams (SPUD)</a></li>
<li>3.1.5. <a href="#rfc.section.3.1.5">Mobile throughput Guidance</a></li>
<li>3.1.6. <a href="#rfc.section.3.1.6">Port Control Protocol Flowdata options</a></li>
<li>3.1.7. <a href="#rfc.section.3.1.7">IPv6 Flow label</a></li>
<li>3.1.8. <a href="#rfc.section.3.1.8">DISCUSS</a></li>
</ul><li>3.2. <a href="#rfc.section.3.2">Inferred flow information</a></li>
<ul><li>3.2.1. <a href="#rfc.section.3.2.1">Heuristics</a></li>
</ul><li>3.3. <a href="#rfc.section.3.3">Co-operation on congestion control</a></li>
</ul><li>4. <a href="#rfc.section.4">Acknowledgements</a></li>
<li>5. <a href="#rfc.section.5">IANA Considerations</a></li>
<li>6. <a href="#rfc.section.6">Security Considerations</a></li>
<li>7. <a href="#rfc.references">References</a></li>
<ul><li>7.1. <a href="#rfc.references.1">Normative References</a></li>
<li>7.2. <a href="#rfc.references.2">Informative References</a></li>
</ul><li><a href="#rfc.authors">Author's Address</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#intro" id="intro">Introduction</a></h1>
<p id="rfc.section.1.p.1">Networks utilise various management techniques to ensure efficient throughput, congestion management, anti-SPAM and security measures. Historically these functions have utilised visibility of the Internet application layer.</p>
<p id="rfc.section.1.p.2">This visibility is rapidly diminishing - encrypted Internet traffic is expected to continue its upward trend, driven by increased privacy awareness, uptake by popular services, and advocacy from the <a href="#IAB">[IAB]</a>, <a href="#RFC7258">[RFC7258]</a> and W3C <a href="#TAG">[TAG]</a> .</p>
<p><a href="#IAB">[IAB]</a>, <a href="#RFC7258">[RFC7258]</a> and <a href="#mm-effect-encrypt">[mm-effect-encrypt]</a> recognise that network management functions may be impacted by encryption, and that solutions to persist these management functions must not threaten user security or privacy. Such solutions can ensure the benefits of encryption do not degrade network efficiency.</p>
<p id="rfc.section.1.p.4">This document lists such solutions, and points to evolving IETF work addressing the problem.</p>
<h1 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1.</a> <a href="#struc" id="struc">Document structure</a></h1>
<p id="rfc.section.1.1.p.1">This document refers to network management functions that may be hindered by traffic encryption, as described in <a href="#mm-effect-encrypt">[mm-effect-encrypt]</a></p>
<p id="rfc.section.1.1.p.2">It then describes the technical details of existing options to fully or partially persist these functions under encryption. The guidance includes existing techniques as well as ongoing IETF work in this area.‘Encryption’ in this document typically refers to HTTP over TLS <a href="#RFC2818">[RFC2818]</a>; other forms of encryption are noted where applicable.</p>
<p id="rfc.section.1.1.p.3">Finally, a summary is provided of ongoing IETF work which is investigating how network operators, origin servers and clients may co-operate in efficient traffic delivery without the need for pervasive network monitoring.</p>
<p id="rfc.section.1.1.p.4">The legal, political and commercial aspects of network management are recgnised but not covered in this technical document.</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#netman" id="netman">Network management functions</a></h1>
<p id="rfc.section.2.p.1">Please refer to 'Network Service Provider Monitoring' in <a href="#mm-effect-encrypt">[mm-effect-encrypt]</a></p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#flow" id="flow">Persisting traffic management without breaching encryption</a></h1>
<p id="rfc.section.3.p.1">This section involves utilisation of 'Application-based Flow Information Visible to a Network', <a href="#mm-effect-encrypt">[mm-effect-encrypt]</a>.</p>
<h1 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1.</a> <a href="#hint" id="hint">Providing hints to and from the network</a></h1>
<p id="rfc.section.3.1.p.1">The following protocols aim to support a secure and privacy-aware dialogue between client, server and the network elements. These hints can allow information item exchange between the endpoints and the network, to assist queuing mechanisms and traffic pacing that accounts for network congestion and variable connection strength. These relate to the cooperative path to endpoint signalling as discussed at the IAB SEMI <a href="#SEMI">[SEMI]</a> and MaRNEW <a href="#MaRNEW">[MaRNEW]</a> workshops, with the network following a more clearly-defined role in encrypted traffic delivery. </p>
<h1 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1.</a> <a href="#dscp" id="dscp">DiffServ Code Points (DSCP)</a></h1>
<p id="rfc.section.3.1.1.p.1">Data packets may be flagged with a traffic class (class of service). Network operators may honour a DiffServ classification <a href="#RFC2474">[RFC2474]</a> entering their network, or may choose to override it (since it is potentially open to abuse by a service provider that classifies all its content as high priority). The purpose is to help manage traffic and congestion in the network.</p>
<p id="rfc.section.3.1.1.p.2">This requires the content provider to flag data packets. This is extra work for the provider, and it has potential for abuse if a content provider simply flags all packets with high priorities. The network would need to know which flags to trust and which to override. The use of DiffServ within the operator network is beneficial where the operator determines the class of service itself; but where content is encrypted then heuristics would be needed to predict the traffic type entering the network. HTTP/2 allows several streams to be multiplexed over a single TCP connection. This means that if a provider decides to send Web pages, videos, chat etc. as individual streams over the same connection, then DiffServ would be useless as it would apply to the TCP/IP connection as a whole. However it may be more efficient for such Web providers to serve each content type from separate, dedicated servers – this will become clearer as HTTP/2 deployments are tuned for optimal delivery.</p>
<h1 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2.</a> <a href="#ecs" id="ecs">Explicit Congestion Notification (ECN)</a></h1>
<p id="rfc.section.3.1.2.p.1">Explicit Congestion Notification <a href="#RFC6138">[RFC6138]</a> routers can exchange congestion notification headers to ECN compliant endpoints. This is in preference to inferring congestion from dropped packets (e.g. in TCP). The purpose is to help manage traffic and congestion in the network.</p>
<p id="rfc.section.3.1.2.p.2">This solution is required to be implemented at network and service provider. The service provider will utilise the ECN to reduce throughput until it is notified that congestion has eased.</p>
<p id="rfc.section.3.1.2.p.3">As with DiffServ, operators may not trust an external entity to mark packets in a fair/consistent manner.</p>
<h1 id="rfc.section.3.1.3"><a href="#rfc.section.3.1.3">3.1.3.</a> <a href="#mpls" id="mpls">Multiprotocol Label Switching (MPLS)</a></h1>
<p id="rfc.section.3.1.3.p.1">On entering an MPLS-compliant network <a href="#RFC3031">[RFC3031]</a>, IP packets are flagged with a ’Forward Equivalence Class’ (FEC). This allows the network to make packet-forwarding decisions according to their latency requirements. MPLS routers within the network parse and act upon the FEC value. The FEC is set according to the source IP address and port. The purpose is to help managing traffic and congestion in the network. This requires deployment of an MPLS ‘backbone’ with label-aware switches/ routers.</p>
<p id="rfc.section.3.1.3.p.2">An up-to-date correspondence table between Websites (or service sites in general) and server IP address must be created. Then, the category(s) of traffic have to be consistently mapped to a set of MPLS labels ,which entails a significant effort to setup and maintain.</p>
<p id="rfc.section.3.1.3.p.3">Note: MPLS can specify how OSI Layer 3 (IP layer) traffic can be routed over Layer 2 (Data Link); DiffServ only operates over Layer 3. DiffServ is potentially a less complex integration as it is applied at the network edge servers only.</p>
<h1 id="rfc.section.3.1.4"><a href="#rfc.section.3.1.4">3.1.4.</a> <a href="#spud" id="spud">Substrate Protocol for User Datagrams (SPUD)</a></h1>
<p id="rfc.section.3.1.4.p.1">SPUD <a href="#SPUD">[SPUD]</a> is a prototype to research how network devices on the path between endpoints can share information to improve a flow. The network involvement is outside of the end-to-end context, to minimise any privacy or security breach. The initial prototype involves grouping UDP packets into an explicit 'tube', however support of additional transport layers (such as TCP) will also be investigated.</p>
<h1 id="rfc.section.3.1.5"><a href="#rfc.section.3.1.5">3.1.5.</a> <a href="#mtg" id="mtg">Mobile throughput Guidance</a></h1>
<p id="rfc.section.3.1.5.p.1">Mobile Throughput Guidance In-band Signalling <a href="#MTG">[MTG]</a> is a draft proposal to allows the network to inform the server endpoint as to what bandwidth the TCP connection can reasonably expect. This allows the server to adapt their throughput pacing based on dynamic network conditions, which can assist mechanisms such as Adaptive Bitrate Streaming and TCP congestion control.</p>
<h1 id="rfc.section.3.1.6"><a href="#rfc.section.3.1.6">3.1.6.</a> <a href="#pcp" id="pcp">Port Control Protocol Flowdata options</a></h1>
<p id="rfc.section.3.1.6.p.1">PCP Flowdata options <a href="#PCPFD">[PCPFD]</a> defines a mechanism for a host to signal flow characteristics to the network, and the network to signal its ability to accommodate that flow back to the host. This allows certain network flows to receive service that is differentiated from other network flows, and may be used to establish flow priority before connection establishment. PCP Flowdata operates at IPv4/IPv6 level.</p>
<h1 id="rfc.section.3.1.7"><a href="#rfc.section.3.1.7">3.1.7.</a> <a href="#ip6" id="ip6">IPv6 Flow label</a></h1>
<p id="rfc.section.3.1.7.p.1">IPv6 includes a flow label header field. <a href="#RFC6438">[RFC6438]</a> details how this may be used to identify flows for load balancing and multipath routing, which may be of particular use for application-layer encrypted traffic. The flow label field is part of the main header, which means it is not subject to the disadvantages of extension headers (namely their risk of being dropped by intermediary routers). The flow label may also be exposed as part of the outer IP packet in an IP tunnel, thus providing network flow information without compromising the payload.</p>
<h1 id="rfc.section.3.1.8"><a href="#rfc.section.3.1.8">3.1.8.</a> <a href="#discuss" id="discuss">DISCUSS</a></h1>
<p id="rfc.section.3.1.8.p.1">Differentiated prIorities and Status Code-points Using Stun Signalling <a href="#DISCUSS">[DISCUSS]</a> describes a mechanism for information exchange between an application and the network, viable only for UDP. As such it can be considered in the same bracket as SPUD</p>
<h1 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2.</a> <a href="#inflow" id="inflow">Inferred flow information</a></h1>
<h1 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1.</a> <a href="#heur" id="heur">Heuristics</a></h1>
<p id="rfc.section.3.2.1.p.1">Heuristics can be used to map given input data to particular conclusions via some heuristic reasoning. Examples of input data to this reasoning include IP destination address, TCP destination port, server name from SNI, and typical traffic patterns (e.g. occurrence of IP packets and TCP segments over time). The accuracy of heuristics depends on whether the observed traffic originates from a source delivering a single service, or a blend of services. In many scenarios, this makes it possible to directly classify the traffic related to a specific server/service even when the traffic is fully encrypted.</p>
<p id="rfc.section.3.2.1.p.2">If the server/service is co-located on an infrastructure with other services that shares the same IP-address, the encrypted traffic cannot be directly classified. However, commercial traffic classifiers today typically apply heuristic methods, using traffic pattern matching algorithms to be able to identify the traffic. As an example, classifier products are able to identify popular VoIP services using heuristic methods although the traffic is encrypted and mostly peer-to-peer.</p>
<h1 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3.</a> <a href="#coop" id="coop">Co-operation on congestion control</a></h1>
<p id="rfc.section.3.3.p.1">One idea from the IAB 'Managing Radio Networks in an Encrypted World' workshop <a href="#MaRNEW">[MaRNEW]</a> was that of better co-operation between 3GPP mobile networks and Internet services on congestion management. . 3GPP networks are concerned with ensuring that all devices attached to a particular cell receive a fair share of radio resources. This is critical, since these resources are constrained to various licenced spectrum bands, and volatile due to signal strength variation/cell handover/interference etc. The resource sharing process occurs independently to TCP congestion management performed between the client and server connected via the mobile network: the result is that TCP may wrongly infer congestion and react accordingly, or attempt to accelerate throughput without consideration of the available radio resources. Therefore the notion is to investigate co-operation between radio and TCP congestion controls to better manage connection throughput. </p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#ack" id="ack">Acknowledgements</a></h1>
<p id="rfc.section.4.p.1">The editor would like to thank the GSMA Web Working Group for their contributions, in particular to the technical solutions and network management functions; the contributions via the SAAG mailing list (Panos Kampanakis, Brian Carpenter); and Kathleen Moriarty and Al Morton for their guidance in aligning this draft with <a href="#mm-effect-encrypt">[mm-effect-encrypt]</a> </p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#iana" id="iana">IANA Considerations</a></h1>
<p id="rfc.section.5.p.1">There are no IANA considerations.</p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#sec" id="sec">Security Considerations</a></h1>
<p id="rfc.section.6.p.1">The intention of this document is to consider how to persist network management of encrypted traffic, without breaching user privacy or end-to-end security. In particular this document does not recommend any approach that intercepts or modifies client-server Transport Layer Security.</p>
<h1 id="rfc.references"><a href="#rfc.references">7.</a> References</h1>
<h1 id="rfc.references.1"><a href="#rfc.references.1">7.1.</a> Normative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="RFC2474">[RFC2474]</b>
</td>
<td class="top"><a>Nichols, K.</a>, "<a href="http://tools.ietf.org/html/rfc2474">Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers</a>", RFC 2474, Dec 1998.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC2818">[RFC2818]</b>
</td>
<td class="top"><a>Rescorla, E.</a>, "<a href="http://tools.ietf.org/html/rfc2818">HTTP Over TLS</a>", RFC 2818, May 2000.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC3031">[RFC3031]</b>
</td>
<td class="top"><a>Rosen, E.</a>, "<a href="http://tools.ietf.org/html/rfc3031">Multiprotocol Label Switching Architecture</a>", RFC 3031, Jan 2001.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6138">[RFC6138]</b>
</td>
<td class="top"><a>Ramakrishnan, K.</a>, "<a href="http://tools.ietf.org/html/rfc6138">The Addition of Explicit Congestion Notification (ECN) to IP</a>", RFC 6138, Sep 2001.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6438">[RFC6438]</b>
</td>
<td class="top"><a>Carpenter, B.</a> and <a>S. Amante</a>, "<a href="http://tools.ietf.org/html/rfc6438">Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels</a>", RFC 6438, 2011.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7258">[RFC7258]</b>
</td>
<td class="top"><a>Farrell, S.</a> and <a>H. Tschofenig</a>, "<a href="http://tools.ietf.org/html/rfc7258">Pervasive Monitoring Is an Attack</a>", BCP 188, RFC 7258, May 2014.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.references.2"><a href="#rfc.references.2">7.2.</a> Informative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="DISCUSS">[DISCUSS]</b>
</td>
<td class="top"><a>Cisco</a>, "<a href="https://tools.ietf.org/html/draft-martinsen-tram-discuss-02">Differentiated prIorities and Status Code-points Using Stun Signalling</a>", 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="IAB">[IAB]</b>
</td>
<td class="top"><a>IAB</a>, "<a href="https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/">IAB statement on Internet confidentiality</a>", n.d..</td>
</tr>
<tr>
<td class="reference">
<b id="MTG">[MTG]</b>
</td>
<td class="top"><a>IETF</a>, "<a href="https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidance/">Mobile Throughput Guidance Inband Signaling Protocol</a>", n.d..</td>
</tr>
<tr>
<td class="reference">
<b id="MaRNEW">[MaRNEW]</b>
</td>
<td class="top"><a>IAB</a> and <a>GSMA</a>, "<a href="https://www.iab.org/activities/workshops/marnew/">Managing Radio Networks in an Encrypted World (MaRNEW)</a>", 2015.</td>
</tr>
<tr>
<td class="reference">
<b id="PCPFD">[PCPFD]</b>
</td>
<td class="top"><a>Cisco</a>, "<a href="https://tools.ietf.org/html/draft-wing-pcp-flowdata-00">PCP Flowdata option</a>", 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="SEMI">[SEMI]</b>
</td>
<td class="top"><a>IAB</a>, "<a href="https://www.iab.org/activities/workshops/semi/">IAB workshop, 'Stack Evolution in a Middlebox Internet'</a>", n.d..</td>
</tr>
<tr>
<td class="reference">
<b id="SPUD">[SPUD]</b>
</td>
<td class="top"><a>IETF</a>, "<a href="https://tools.ietf.org/html/draft-hildebrand-spud-prototype-03">Substrate Protocol for User Datagrams</a>", n.d..</td>
</tr>
<tr>
<td class="reference">
<b id="TAG">[TAG]</b>
</td>
<td class="top"><a>W3C</a>, "<a href="https://w3ctag.github.io/web-https/">Securing the Web</a>", n.d..</td>
</tr>
<tr>
<td class="reference">
<b id="mm-effect-encrypt">[mm-effect-encrypt]</b>
</td>
<td class="top"><a>IETF</a>, "<a href="https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/">Effect of Ubiquitous Encryption</a>", n.d..</td>
</tr>
</tbody>
</table>
<h1 id="rfc.authors">
<a href="#rfc.authors">Author's Address</a>
</h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Kevin Smith</span>
<span class="n hidden">
<span class="family-name">Smith</span>
</span>
</span>
<span class="org vcardline">Vodafone Group</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:kevin.smith@vodafone.com">kevin.smith@vodafone.com</a></span>
</address>
</div>
</body>
</html>