-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-zubov-snif-00.xml
972 lines (972 loc) · 49.7 KB
/
draft-zubov-snif-00.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
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-zubov-snif-00" category="exp" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="false" tocInclude="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.0 -->
<!-- Generated by id2xml 1.5.0 on 2022-01-31T20:50:21Z -->
<front>
<title abbrev="SNIF">Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based End-to-End TLS Forwarding (SNIF)</title>
<seriesInfo name="Internet-Draft" value="draft-zubov-snif-00"/>
<author initials="J." surname="Zubov" fullname="Jim Zubov">
<organization>VESvault Corp</organization>
<address>
<email>[email protected]</email>
<uri>https://snif.host</uri>
</address>
</author>
<date year="2022" month="January" day="31"/>
<abstract>
<t>
This document proposes a solution, referred as SNIF, that provides
the means for any Internet connected device to:</t>
<ul spacing="normal">
<li>allocate a globally unique anonymous hostname</li>
<li>obtain and maintain a publicly trusted X.509 certificate <xref target="RFC5280" format="default"/>
issued for the allocated hostname</li>
<li>accept incoming TLS connections on specific TCP ports of the
allocated hostname from any TLS clients that are capable of sending
Server Name Indication <xref target="RFC6066" format="default"/></li>
</ul>
<t>
The private key associated with the X.509 certificate is securely
stored on the TLS terminating device, and is never exposed to any
other party at any step of the process.</t>
</abstract>
<note>
<name>About This Document</name>
<t>
This note is to be removed before publishing as an RFC.</t>
<t>
Status information for this document may be found at
<eref target="https://datatracker.ietf.org/doc/draft-zubov-snif-00"/> .</t>
<t>
Information can be found at <eref target="https://snif.host"/> .</t>
<t>
Source for this draft and an issue tracker can be found at
<eref target="https://github.com/vesvault/snif-i-d"/> .</t>
</note>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
<t>
A typical Internet-of-Things (IoT) device connects to the Internet
using a dynamic IP address, and is usually unable to accept incoming
connections to TCP ports. A dedicated trusted relay is needed to
facilitate the communications between the IoT device and its intended
users. While all communications are recommended to be TLS encrypted,
the trusted relay will terminate each TLS connection and therefore
have access to unencrypted traffic between IoT devices and user
clients, which may pose undesirable security risk.</t>
<t>
Designing a dedicated relay that works in end-to-end encrypted mode,
where the TLS tunnel is established between the IoT device and the
client, and is passed by the relay in an encrypted form, raises
additional challenges. Clients expect to be able to verify the
authenticity of the TLS certificate presented by the IoT device they
are connecting to. Public certificate authorities requite to validate
the ownership of the hostname the certificate is being requested for,
using certain challenge mechanisms. Therefore, the IoT device needs
to allocate a unique hostname, and to be able to complete the CA
challenge in order to acquire a trusted certificate.</t>
<t>
Alternatively, the client may decide to use a different certificate
trust scheme, not based on publicly trusted root CAs. In this case,
the client is limited to specifically built software with custom
trust rules, or the system trust root on the client device needs to
be customized.</t>
<t>
This document proposes a solution, referred as SNIF, that allows any
common TLS client with standard root CAs, such as a web browser, to
establish a trusted end-to-end TLS connection with an IoT device
using the unique hostname permanently allocated to the device, via a
dedicated relay.</t>
<t>
While this document focuses on IoT devices, SNIF is applicable to any
physical or virtual device or software that can benefit from
accepting trusted TLS connections to an anonymous hostname.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<name>Notational Conventions</name>
<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" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all
capitals, as shown here.</t>
</section>
</section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Overview</name>
<t>
<em>SNIF CA Proxy</em> is a combination of web-based services and background
processes that run on a publicly accessible server, normally on the
same physical server as SNIF Relay. SNIF CA Proxy allocates hostnames
for SNIF Connectors and facilitates issuing and renewing X.509
certificates without having access to the Connectors' private keys.
The functions of SNIF CA Proxy are described in <xref target="sect-3" format="default"/>.</t>
<t>
<em>SNIF Relay</em> is a process that runs on a publicly accessible server,
normally on the same physical server as SNIF CA Proxy. SNIF Relay
facilitates end-to-end TLS connections between SNIF Clients with SNIF
Connectors. The functions of SNIF Relay are described in <xref target="sect-4" format="default"/>.</t>
<t>
<em>SNIF Connector</em> is a software process that runs on an IoT device, or
on other type of device that intends to provide TLS-based services
that can be accessed by general purpose TLS clients using SNIF Relay.
SNIF Connector can be implemented as a standalone process that
communicates with the TLS server processes over local filesystem and
sockets, or as an integral part of a TLS server process.</t>
<t>
<em>SNIF Client</em> is any common TLS-compatible client with SNI capability,
such as a web browser or an email client, that connects to a SNIF
hostname provided by a specific SNIF Connector. SNIF Client does not
need any awareness of SNIF, or of any protocols described in this
document.</t>
<t>
<em>Certificate Authority (CA)</em> is a service that issues public trusted
TLS Certificates to specific hostnames when requested by the hostname
owner, upon validating the ownership of the hostname. CA does not
need any awareness of SNIF, except for a working relationship with
the SNIF CA Proxy that requests certificates using protocols
supported by the CA.</t>
<t>
<em>SNIF Peripheral Process</em> is any kind of additional service that
extends or supplements functions of SNIF, in a way not defined within
the scope of this document.</t>
</section>
<section anchor="sect-3" numbered="true" toc="default">
<name>SNIF CA Proxy Protocol</name>
<t>
SNIF CA Proxy Protocol is designed for securely acquiring and
maintaining a publicly trusted TLS/SSL X.509 certificate issued by a
Certificate Authority to a uniquely allocated hostname, by an agent
that has no direct control over that hostname, or over a server the
hostname is pointing to.</t>
<section anchor="sect-3.1" numbered="true" toc="default">
<name>Protocol Summary</name>
<t>
SNIF CA Proxy accepts requests from SNIF Connectors via HTTP / HTTPS.</t>
<t>
SNIF CA Proxy interacts with the CA using protocols supported by the
CA, such as ACME <xref target="RFC8555" format="default"/>, not covered by this document.</t>
<t>
Each SNIF Connector is configured with a specific initiation URL
({initUrl}), which is specific to the SNIF CA Proxy server the
Connector intends to work with. Depending on the CA Proxy rules,
{initUrl} might be unique for each Connector, or common for multiple
Connectors.</t>
</section>
<section anchor="sect-3.2" numbered="true" toc="default">
<name>Protocol Flow</name>
<t>
Upon the initial start or after a hard reset, the Connector MUST
generate a Private Key, which needs to be securely permanently stored
by the Connector. Any key algorithm acceptable by the CA can be used,
generally RSA-4096 is recommended.</t>
<t>
The Connector MUST send a CN Allocation Request using the
{initUrl}.</t>
<t>
Having the {cn}, the Connector MUST generate a CSR <xref target="RFC2986" format="default"/> using
the Private Key, the subject containing the {cn}. The CSR subject may
or may not have other fields besides {cn}, according to the specific
requirements of the CA.</t>
<t>
The Connector MUST issue a CSR Submission Request to send the CSR
to the CA Proxy.</t>
<t>
Once the CSR is submitted, the Connector MUST permanently store the
{cn} by some means - to minimize the storage compartments it might be
practical to generate and store a dummy self-signed certificate with
the {cn} in the subject until it gets replaced with a trusted
certificate issued by the CA.</t>
<t>
A this point, the Connector will normally know the SNIF hostname it
will be using with the SNIF Relay - it matches the {cn} in case of a
single host CN, or is a one sub-level down from a wildcard {cn}, the
name being derived by the Connector in a way that is not
deterministically derivable from the {cn} and the public key, e.g. a
hash of the Private Key. The Connector SHOULD communicate the
hostname by some means to the SNIF Clients that will be accessing the
Connector. The means of such communication is not covered by this
document.</t>
<t>
The Connector can now send a Certificate Download Request, and
SHOULD verify the returned Certificate. If the Certificate is valid -
the Connector MUST permanently store it.</t>
<t>
If the Certificate Download Request fails - the Connector should
repeat the request after certain delay. In case if the response was
401 and the {authUrl} is returned in a header, and the Connector has
the means of communicating with the device user - the Connector also
SHOULD alert the user and bring {authUrl} to their attention by some
means, so the user can complete the required authorization steps. If
the Connector has no means of alerting the user, which is often the
case with IoT devices - the user should be provided with some
external means of authorizing with the CA Proxy, not covered by this
domcument.</t>
<t>
Once the Certificate is stored, the Connector is capable of
terminating SNIF connections, and may proceed launching a SNIF
Control Connection (<xref target="sect-4.2" format="default"/>).</t>
<t>
The Connector SHOULD watch for the expiration of the stored
Certificate. If the Certificate is about to expire in 7 days or less,
or has already expired - the Connector SHOULD send a Certificate
Download Requests, and repeat with appropriate delays until the
renewed Certificate is successfully downloaded and verified.</t>
<t>
At any stage of the flow, if the Connector receives unexpected volume
of rejections or inconsistent responses from the CA Proxy, the
Connector MAY decide to hard reset the storage and start the flow
over from the beginning. In such case, the Connector will have to
re-send its new SNIF hostname to any concerned SNIF Clients, the
means of such communication is not covered by this document.</t>
</section>
<section anchor="sect-3.3" numbered="true" toc="default">
<name>CN Allocation Request</name>
<dl newline="false" spacing="normal" indent="18">
<dt>Connection from:</dt>
<dd>SNIF Connector</dd>
<dt>Connection to:</dt>
<dd>SNIF CA Proxy</dd>
<dt>Protocol:</dt>
<dd>https or http</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
GET {initUrl}
]]></artwork>
<t>
Response 200: CN is successfully allocated. The response headers MUST
include X-SNIF-CN: with the value of the allocated {cn}, either a
wildcard starting with "*.", or a single hostname, depending on the
CA Proxy rules. The response content type SHOULD be "text/plain", the
response body SHOULD include the copy of the allocated {cn},
optionally padded with newlines or spaces on the right.</t>
<t>
Any other response: Error, try again later.</t>
</section>
<section anchor="sect-3.4" numbered="true" toc="default">
<name>CSR Submission Request</name>
<dl newline="false" spacing="normal" indent="18">
<dt>Connection from:</dt>
<dd>SNIF Connector</dd>
<dt>Connection to:</dt>
<dd>SNIF CA Proxy</dd>
<dt>Protocol:</dt>
<dd>http</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
PUT http://{cn_host}/snif-cert/{cn_host}.csr
Content-Type: application/pkcs10
]]></artwork>
<t>
{cn_host} is a hostname derived from the {cn} - it is identical to
{cn} in case of a single-host CN, or is the {cn} with truncated
initial "*." in case of a wildcard CN.</t>
<t>
The request body MUST contain a PEM encoded PKCS#10 CSR <xref target="RFC5967" format="default"/>,
the newlines are either <CR><LF> or <LF>, the length of the body
SHOULD NOT exceed 16384 bytes.</t>
<t>
Note that a CSR for the specific allocated CN can be submitted to the
CA Proxy once in a lifetime. In case of an incorrect submission the
Connector should hard reset the storage and restart the flow from the
beginning, including allocating a new CN.</t>
<t>
Response 201: the CSR is successfully submitted. The response headers
MAY include X-SNIF-AuthUrl: with the value of an {authUrl}, that
SHOULD, if possible, be communicated to the user to authorize the
certificate issuance.</t>
<t>
Response 403: the CSR for this CN has already been submitted, or is
denied by the CA Proxy rules. If the Connector receives 403, is
SHOULD hard reset the storage and restart the CA Proxy flow from the
beginning.</t>
<t>
Response 404: the CN was not allocated.</t>
<t>
Any other response: Error, try again later.</t>
</section>
<section anchor="sect-3.5" numbered="true" toc="default">
<name>Certificate Download Request</name>
<dl newline="false" spacing="normal" indent="18">
<dt>Connection from:</dt>
<dd>SNIF Connector</dd>
<dt>Connection to:</dt>
<dd>SNIF CA Proxy</dd>
<dt>Protocol:</dt>
<dd>http</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
GET http://{cn_host}/snif-cert/{cn_host}.crt
]]></artwork>
<t>
{cn_host} is a hostname derived from the {cn} - it is identical to
{cn} in case of a single-host CN, or is the {cn} with truncated
initial "*." in case of a wildcard CN.</t>
<t>
The CA Proxy SHOULD check for a cached previously generated
Certificate chain for the {cn}. If the cached Certificate chain is
found and if it expires in more that 10 days in the future - the
cached Certificate chain SHOULD be returned with status 200.
Otherwise, if the {cn} has a valid CSR and a proper authorization to
issue a certificate - the CA Proxy SHOULD return status 503 and
SHOULD launch a background process that communicates with the CA to
issue or renew the certificate, and caches the issued Certificate
chain for subsequent Certificate Download Requests.</t>
<t>
Response 200: the Certificate chain is returned. The Content-Type of
such response SHOULD be "application/x-x509-ca-cert". The response
body MUST be a PEM encoded X.509 certificate chain, the issued
certificate being the first member, the newlines are either <CR><LF>
or <LF>, the length of the body SHOULD NOT exceed 65535 bytes.</t>
<t>
Response 503: the Certificate is being issued, try later.</t>
<t>
Response 401: Certificate issuance authorization is required. The
response headers MAY include X-SNIF-AuthUrl: with the value of an
{authUrl}, that SHOULD, if possible, be communicated to the user to
authorize the certificate issuance. If the Connector cannot
communicate with the user, the CA Proxy should include external means
of the authorization, not covered by this document.</t>
<t>
Response 404: the CN was not allocated, or the CSR was not submitted.</t>
<t>
Any other response: Error, try again later.</t>
</section>
</section>
<section anchor="sect-4" numbered="true" toc="default">
<name>SNIF Relay Protocol Suite</name>
<t>
Except for SNIF Client Connection, all protocols mentioned below
involve sending and receiving asynchronous SNIF Messages over a
specific type of stream connection.</t>
<t>
<em>SNIF Control Connection Protocol</em> defines communications between SNIF
Relay and SNIF Connector that runs on an IoT device, or other type of
device that provides TLS-based services through SNIF.</t>
<t>
<em>SNIF Service Connection Protocol</em> defines secondary communications
between SNIF Relay and SNIF Connector that include end-to-end TLS
traffic forwarded by the Relay.</t>
<t>
<em>SNIF Client Connection Protocol</em> defines TLS communications between
SNIF Relay and a Client, where the Relay acts as a transparent
end-to-end forwarder.</t>
<t>
<em>SNIF IPC FIFO Protocol</em> defines communications between nodes of a
SNIF Relay cluster, and/or between SNIF Relay and SNIF Peripheral
Processes.</t>
<section anchor="sect-4.1" numbered="true" toc="default">
<name>SNIF Messages</name>
<t>
A SNIF Message consists of a 1 or more ASCII characters excluding
special characters, terminated by <CR><LF>.</t>
<t>
The total length of a SNIF Message, including the terminal <CR><LF>,
SHOULD NOT exceed 4096 bytes.</t>
<t>
8-bit characters are discouraged. If 8-bit characters are used, they
should comply to UTF-8 <xref target="RFC3629" format="default"/>.</t>
<t>
The receiving party SHOULD silently ignore any invalid or malformed
SNIF message.</t>
</section>
<section anchor="sect-4.2" numbered="true" toc="default">
<name>SNIF Control Connection Protocol</name>
<dl newline="false" spacing="normal" indent="18">
<dt>Protocol name:</dt><dd>snif</dd>
<dt>Default port:</dt><dd>TCP 7123</dd>
<dt>Connection from:</dt><dd>SNIF Connector</dd>
<dt>Connection to:</dt><dd>SNIF Relay</dd>
</dl>
<t>
To be able to open a SNIF Control Connection, the SNIF Connector MUST
have a valid trusted TLS/SSL certificate, the CN hostname DNS
pointing to the SNIF Relay or a wildcard CN having a sub-host DNS
pointing to the SNIF Relay, and a Private Key that matches the
Certificate. Normally, the SNIF Connector will generate the Private
Key and use SNIF CA Proxy Protocol (<xref target="sect-3" format="default"/>) to obtain and maintain
the Certificate, although other means can be used.</t>
<t>
To initiate the Control Connection, the SNIF Connector opens a TCP
connection to the hostname matching the Certificate's CN, that points
to the Relay.</t>
<t>
Upon accepting the incoming TCP connection, the SNIF Relay MUST
initiate a reversed TLS session as a client peer.</t>
<t>
The SNIF Connector MUST initiate the TLS as a server peer, using the
Certificate and the Private Key.</t>
<t>
Upon successful TLS negotiation, the SNIF Relay MUST validate the
SNIF Connector's certificate. If the certificate is not trusted, the
SNIF Relay MUST shut down the TLS session and the TCP socket
immediately.</t>
<t>
If the certificate is accepted, both SNIF Relay and SNIF Connector
are ready to accept SNIF Messages from each other over the TLS
connection, as following.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF LISTEN {hostname}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Sent by:</dt><dd>SNIF Connector</dd>
</dl>
<t>
The SNIF LISTEN message informs the Relay that the Connector is ready
to accept incoming TLS connections to {hostname} through the Relay.</t>
<t>
{hostname} MUST specify a single host (no wildcards), and MUST match
the CN of the Connector's TLS certificate - either match a wildcard
CN, or exactly match a single host CN.</t>
<t>
The SNIF LISTEN message SHOULD be send only once per the Control
Connection. The Relay SHOULD ignore any invalid or subsequent SNIF
LISTEN messages.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF CONNECT {conn_id} {dst_host}:{dst_port} {fwd_host}:{fwd_port} {cln_addr}:{cln_port}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Sent by:</dt><dd>SNIF Relay</dd>
</dl>
<t>
The SNIF CONNECT message informs the Connector of an incoming TLS
connection from a Client to the Connector's {dst_host}, TCP port
{dst_port}.</t>
<t>
{conn_id} is a unique alphanumeric connection identifier assigned by
the Relay, {cln_addr}:{cln_port} are the Client's remote IPv4/IPv6
address and TCP port, {cln_addr} is supplied in "[" brackets "]".</t>
<t>
The Relay sends the SNIF CONNECT message to Connectors with
{dst_host} matching the {hostname} the Connector is listening to. The
Connector doesn't need to verify {dst_host}.</t>
<t>
If the Connector decides to accept the connection - it MUST launch a
SNIF Service Connection to {fwd_host}:{fwd_port}. It also SHOULD
send any SNIF message back to the Relay over the Control Connection
to update the keep-alive timer, a copy of the SNIF ACCEPT message
that is sent over the Service Connection can be used.</t>
<t>
In case of a rejection - the Connector SHOULD send SNIF CLOSE with
matching {conn_id}.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF CLOSE {conn_id}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Sent by:</dt><dd>SNIF Connector</dd>
</dl>
<t>
The SNIF CLOSE message instructs the Relay to terminate the Client
connection with matching {conn_id}.</t>
<t>
For SNIF CLOSE received from a Connector, the Relay MUST validate
that the connection was targeted at the Connector's {hostname},
otherwise ignore the message.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF ABUSE {conn_id} {abuse_score}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Sent by:</dt><dd>SNIF Connector</dd>
</dl>
<t>
The SNIF ABUSE message instructs the Relay to increase the DoS
protection abuse counter for the Client that initiated the connection
{conn_id} by {abuse score}.</t>
<t>
{abuse score} SHOULD be an integer from 1 to 255, 1 is the score for
a normal non-abusive connection.</t>
<t>
For SNIF ABUSE received from a Connector, the Relay MUST validate
that the connection was targeted at the Connector's {hostname},
otherwise ignore the message.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF MSG {hostname} {content}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Sent by:</dt><dd>SNIF Connector or SNIF Relay</dd>
</dl>
<t>
The SNIF MSG message is relayed between the Connector and the SNIF
Peripheral Processes attached to the Relay.</t>
<t>
{content} SHOULD NOT contain whitespaces or special characters. Its
semantics is specific to the targeted Peripheral Process, and is not
covered by this document.</t>
<t>
For SNIF MSG received by the Relay from a Connector, the Relay MUST
verify that the {hostname} matches the one associated with the
Connector, forward the message to all IPC FIFOs if matched, ignore
otherwise.</t>
<t>
For SNIF MSG received by the Relay from an IPC FIFO, the Relay SHOULD
forward the message to the Connector(s) with the matching {hostname},
ignore the message if none are found.</t>
<t>
Note that in certain uncommon circumstances a SNIF MSG send by a
Connector might come back to the Connector through a different
Control Connection. The Connector SHOULD be aware of this fact to
avoid a potential message storm.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
NOOP
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Sent by:</dt><dd>SNIF Connector or SNIF Relay</dd>
</dl>
<t>
The NOOP message is not associated with any explicit action, except
that the Relay receiving NOOP from the connector SHOULD promply send
NOOP or any other message back to the Connector. Therefore, the
Connector may use NOOP as a keep-alive ping.</t>
</section>
<section anchor="sect-4.3" numbered="true" toc="default">
<name>SNIF Service Connection Protocol</name>
<dl newline="false" spacing="normal" indent="18">
<dt>Protocol name:</dt><dd>snif-srv</dd>
<dt>Default port:</dt><dd>TCP 7120 (unofficial)</dd>
<dt>Connection from:</dt><dd>SNIF Connector</dd>
<dt>Connection to:</dt><dd>SNIF Relay</dd>
</dl>
<t>
The SNIF Connector opens a TCP connection to the
{fwd_host}:{fwd_port} in response to a SNIF CONNECT message received
from the Relay over the Control Connection.</t>
<t>
The Connector MUST immediately send a SNIF ACCEPT message over the
Service Connection as a plain TCP:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF ACCEPT {conn_id}
]]></artwork>
<t>
The {conn_id} is the one that was received in the SNIF CONNECT
message over the Control Connection.</t>
<t>
Upon sending the SNIF ACCEPT message, the Connector MUST immediately
assign further control and bi-directional traffic of the SNIF Service
Connection to the matching TLS server process.</t>
<t>
If the Relay decides to reject the connection, either because of
invalid message or {conn_id}, or because of reaching the abuse
threshold - the Relay SHOULD terminate the TCP connection
immediately.</t>
<t>
Otherwise, the Relay SHOULD link the Service Connection to the
matched Client Connection, forward to the Service Connection all
buffered TLS data previously received from the Client, and start
bi-directional forwarding between the Client Connection and the
Service Connection.</t>
<t>
When either Client or Service Connection is shut down, or an
inactivity timeout is reached, the Relay SHOULD shut down both the
Client Connection and the Service Connection.</t>
<t>
Once the Relay has linked the Client Connection matching the
{conn_id} to the Service Connection, any further SNIF ACCEPT messages
with the same {conn_id} on other Service Connections MUST be
rejected.</t>
</section>
<section anchor="sect-4.4" numbered="true" toc="default">
<name>SNIF Client Connection Protocol</name>
<dl newline="false" spacing="normal" indent="18">
<dt>Protocol name:</dt><dd>snif-cln</dd>
<dt>Default port:</dt><dd>N/A</dd>
<dt>Connection from:</dt><dd>Any TLS enabled software, such as a web browser or an email client</dd>
<dt>Connection to:</dt><dd>SNIF Relay</dd>
</dl>
<t>
From the Client's perspective, a SNIF Client Connection functions as
a direct TLS connection to the IoT Device.</t>
<t>
The ports the Relay is listening to, can be any well-known ports for
services with persistent TLS, such as https or imaps, or can be any
custom ports agreed among the Relay, the Connectors and the Clients.</t>
<t>
The Relay accepts an incoming TCP connection, receives and buffers
the incoming initial data from the client, and attempts to interpret
the received data as a TLS handshake.</t>
<t>
If the received data is not recognized as a TLS handshake, does not
contain an SNI record in a supported format, or the SNI hostname does
not meet rules defined for the Relay - the Relay SHOULD immediately
reject the TLS session with an appropriate error status, and shut
down the Client Connection.</t>
<t>
If the SNI hostname is found acceptable - the Relay allocates a
unique {conn_id}, checks if there are current Control Connections
that match the SNI hostname, and sends a SNIF CONNECT message over
those connections.</t>
<t>
If there are no active applicable Control Connections, or if the
Relay doesn't receive a response from a SNIF Connector within a
specified timeframe - the Relay SHOULD forward the same SNIF CONNECT
message over IPC FIFOs (if any are open) to alert cluster peer Relays
and Peripheral processes of the incoming Client Connection.</t>
<t>
A Service Connection with a matching SNIF ACCEPT establishes an
end-to-end TLS circuit with the Client Connection. Once established,
the Relay bi-directionally forwards all traffic between the Client
and the Service Connection until either of the connections is closed
or is timed out due to inactivity.</t>
<t>
Upon receiving a matching SNIF CLOSE - the Relay MUST terminate the
Client Connection. If a Service Connection has already been linked it
MUST be terminated too, otherwise the Relay SHOULD attempt to
gracefully reject TLS on the Client Connection with an appropriate
status prior to shutting down TCP.</t>
</section>
<section anchor="sect-4.5" numbered="true" toc="default">
<name>SNIF IPC FIFO Protocol</name>
<dl newline="false" spacing="normal" indent="18">
<dt>Protocol name:</dt><dd>snif-fifo</dd>
<dt>Default port:</dt><dd>N/A</dd>
<dt>Connection from:</dt><dd>SNIF Relay or SNIF Peripheral Service</dd>
<dt>Connection to:</dt><dd>SNIF Relay or SNIF Peripheral Service</dd>
</dl>
<t>
SNIF IPC FIFO is a permanent trusted connection between the SNIF
Relay and a SNIF Peripheral Process, or between a pair of nodes in a
SNIF Relay cluster. An IPC FIFO is usually unidirectional, but a
bidirectional connection can serve as a pair of FIFOs. An IPC FIFO
can be implemented as a Unix FIFO pipe, a TCP socket, an SSH tunnel
or by other means. The mechanism of establishing and maintaining IPC
FIFOs is implementation specific and is not covered by this document.</t>
<t>
The following SNIF Messages are defined over an IPC FIFO from the
perspective of a SNIF Relay:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF CONNECT {conn_id} {dst_host}:{dst_port} {fwd_host}:{fwd_port} {cln_addr}:{cln_port}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Direction:</dt><dd>Send or Receive</dd>
</dl>
<t>
(see SNIF Control Connection, Section 4.2).</t>
<t>
The SNIF CONNECT message is sent by a Relay over an IPC FIFO in case
if the Relay failed to reach the respective Connector through Control
Connections. When sent by a Relay, SNIF CONNECT must be followed up
by one of SNIF CLEAR or SNIF CLOSE to inform the Peripheral Processes
of the further outcome.</t>
<t>
When a SNIF CONNECT message is received by a Relay, the Relay SHOULD
forward it to any matching open Control Connections, or ignore it
otherwise.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF CLEAR {conn_id}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Direction:</dt><dd>Send</dd>
</dl>
<t>
The SNIF CLEAR message should be sent by a Relay only as a followup
to SNIF CONNECT with a matching {conn_id}, in case if the Client
Connection that triggered SNIF CONNECT was accepted by a Service
Connection.</t>
<t>
The purpose of SNIF CLEAR is to advice Peripheral Processes to cease
further attempts of reaching the Connector by external means, not
specified within this document.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF CLOSE {conn_id}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Direction:</dt><dd>Send or Receive</dd>
</dl>
<t>
(see SNIF Control Connection, Section 4.2).</t>
<t>
The SNIF CLOSE message should be sent by a Relay only as a followup
to SNIF CONNECT with a matching {conn_id}, in case if the Client
Connection that triggered SNIF CONNECT was closed without being
accepted.</t>
<t>
When the SNIF CLOSE is received by a Relay, the Relay SHOULD
immediately close the matching Client and/or Service Connection if
any found, ignore the message otherwise.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF ABUSE {conn_id} {abuse_score}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Direction:</dt><dd>Receive</dd>
</dl>
<t>
(see SNIF Control Connection, Section 4.2).</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF MSG {hostname} {content}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Direction:</dt><dd>Send or Receive</dd>
</dl>
<t>
(see SNIF Control Connection, Section 4.2).</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
SNIF CTL {ctl_fd} {hostname} {remote_addr}:{remote_port}
SNIF CTL {ctl_fd}
]]></artwork>
<dl newline="false" spacing="normal" indent="18">
<dt>Direction:</dt><dd>Send</dd>
</dl>
<t>
The SNIF CTL message is sent by a Relay to inform Peripheral
Processes about Control Connections. The first version is sent for
each opening Control Connection, and is followed up by the second
version with the matching {ctl_fd} when the Control Connection is
closed. {ctl_fd} is a numeric descriptor which is unique for open
connections, but can be reused after a connection is closed.</t>
</section>
<section anchor="sect-4.6" numbered="true" toc="default">
<name>Abuse Management</name>
<t>
SNIF Relay SHOULD implement basic protection from denial of service.
A separate abuse count SHOULD be assigned to each remote address,
incremented by 1 on every incoming connection from the address,
incremented by a specified score on every received SNIF ABUSE
message, and periodically decremented or reset at regular time
intervals.</t>
<t>
If the abuse counter for a certain remote address reaches a
specific threshold, the Relay SHOULD drop any further TCP connections
from that address until the abuse counter goes below the threshold.
The Relay MAY allow some grace above the threshold to incoming
SNIF Service Connections, to minimize stalled Client Connections.</t>
<t>
SNIF Connector MAY implement basic protection from denial of service
by limiting the number of accepted connections per period of time
and/or the total number of open connections, and reject connections
over the limit.</t>
</section>
</section>
<section anchor="sect-5" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
All information communicated to/from SNIF CA Proxy over plain
unencrypted HTTP is safe to be exposed to third parties or to
intruders without compromising any private information.</t>
<t>
SNIF Control Connection Protocol communicates all sensitive
information over a TLS connection with a trusted certificate.</t>
<t>
SNIF Service Connection Protocol communicates a randomly generated
{conn_id} over an unsecure TCP connection. Except if used over a
trusted SNIF IPC FIFO, the {conn_id} can be used only once to accept
the Client's TLS connection, which in turn can only be successfully
negotiated by the targeted SNIF Connector. All further communications
are comprised of end-to-end encrypted TLS traffic. The security of
the TLS encrypted content between the Client and the Connector is
specific to the protocols involved. The underlying protocol SHOULD
require proper authentication specific to the protocol before
communicating any sensitive information. Negotiation of the
credentials for such authentification is not covered by this
document.</t>
<t>
SNIF Client Connection is a TLS session with a trusted certificate.
The security of the TLS encrypted content between the Client and the
Connector is specific to the protocols involved.</t>
<t>
SNIF IPC FIFO connections should only be established between mutually
trusted parties, and need to be secured by external means specific to
the implementation, such as filesystem permissions, TLS or SSH
tunnels etc. The security of such external means cannot be assessed
within the scope of this document.</t>
<t>
A compromised SNIF CA Proxy can potentially issue certificates to any
hostnames allocated by the Relay, including a catch-all wildcard,
using an alternative private key, and thus allow a man-in-the-middle
attack on any SNIF Connectors associated with the Relay. This
vulnerability can be mitigated by constant monitoring of public TLS
Transparency logs, such as <xref target="RFC6962" format="default"/>. At least one independent party
SHOULD continuosly monitor TLS Transparency logs for each deployed
SNIF CA Proxy and Relay. Once any duplicate or overlapping
certificates are detected - the corresponding SNIF Relay MUST be
permanently deemed compromised.</t>
</section>
<section anchor="sect-6" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
Protocols "snif", "snif-srv", "snif-cln" and "snif-fifo" are
registered with IANA.</t>
<t>
TCP port 7123 is registered with IANA for protocol "snif".</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC2986" target="https://www.rfc-editor.org/info/rfc2986" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml">
<front>
<title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
<author initials="M." surname="Nystrom" fullname="M. Nystrom">
<organization/>
</author>
<author initials="B." surname="Kaliski" fullname="B. Kaliski">
<organization/>
</author>
<date year="2000" month="November"/>
<abstract>
<t>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2986"/>
<seriesInfo name="DOI" value="10.17487/RFC2986"/>
</reference>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials="D." surname="Cooper" fullname="D. Cooper">
<organization/>
</author>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen">
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization/>
</author>
<date year="2008" month="May"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
<organization/>
</author>
<date year="2011" month="January"/>
<abstract>
<t>This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6066"/>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references>
<references>
<name>Informative References</name>
<reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials="F." surname="Yergeau" fullname="F. Yergeau">
<organization/>
</author>
<date year="2003" month="November"/>
<abstract>
<t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
</abstract>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
<seriesInfo name="DOI" value="10.17487/RFC3629"/>
</reference>
<reference anchor="RFC5967" target="https://www.rfc-editor.org/info/rfc5967" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5967.xml">
<front>
<title>The application/pkcs10 Media Type</title>
<author initials="S." surname="Turner" fullname="S. Turner">
<organization/>
</author>
<date year="2010" month="August"/>
<abstract>
<t>This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5967"/>
<seriesInfo name="DOI" value="10.17487/RFC5967"/>
</reference>
<reference anchor="RFC6962" target="https://www.rfc-editor.org/info/rfc6962" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6962.xml">
<front>
<title>Certificate Transparency</title>
<author initials="B." surname="Laurie" fullname="B. Laurie">
<organization/>
</author>
<author initials="A." surname="Langley" fullname="A. Langley">
<organization/>
</author>
<author initials="E." surname="Kasper" fullname="E. Kasper">
<organization/>
</author>
<date year="2013" month="June"/>
<abstract>
<t>This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</t>
<t>Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6962"/>
<seriesInfo name="DOI" value="10.17487/RFC6962"/>
</reference>
<reference anchor="RFC8555" target="https://www.rfc-editor.org/info/rfc8555" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml">
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author initials="R." surname="Barnes" fullname="R. Barnes">
<organization/>
</author>
<author initials="J." surname="Hoffman-Andrews" fullname="J. Hoffman-Andrews">
<organization/>
</author>
<author initials="D." surname="McCarney" fullname="D. McCarney">
<organization/>
</author>
<author initials="J." surname="Kasten" fullname="J. Kasten">
<organization/>
</author>
<date year="2019" month="March"/>
<abstract>
<t>Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8555"/>
<seriesInfo name="DOI" value="10.17487/RFC8555"/>
</reference>
</references>
</references>
</back>
</rfc>