-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-eckert-anima-brski-discovery.txt
2016 lines (1396 loc) · 86.1 KB
/
draft-eckert-anima-brski-discovery.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
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
ANIMA T. Eckert, Ed.
Internet-Draft Futurewei
Intended status: Standards Track D. von Oheimb
Expires: 21 April 2024 Siemens
E. Dijk
IoTconsultancy.nl
19 October 2023
Discovery for BRSKI variations
draft-eckert-anima-brski-discovery-01
Abstract
This document specifies how BRSKI entities, such as registrars,
proxies, pledges or others that are acting as responders, can be
discovered and selected by BRSKI entities acting as initiators.
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 21 April 2024.
Copyright Notice
Copyright (c) 2023 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 carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Eckert, et al. Expires 21 April 2024 [Page 1]
Internet-Draft BRSKI-discovery October 2023
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Abstracted BRSKI discovery and selection . . . . . . . . 6
3.2. Variation Contexts . . . . . . . . . . . . . . . . . . . 6
3.3. Variation Types and Choices . . . . . . . . . . . . . . . 7
3.4. Variations . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. BRSKI Variations Discovery Registry . . . . . . . . . . . 8
3.5.1. BRSKI Variation Contexts table . . . . . . . . . . . 8
3.5.2. BRSKI Variation Type Choices table . . . . . . . . . 9
3.5.3. BRSKI Discoverable Variations table . . . . . . . . . 10
3.5.4. Extending or modifying the registry . . . . . . . . . 11
3.6. BRSKI Join Proxies support for Variations . . . . . . . . 11
3.6.1. Permissible Variations . . . . . . . . . . . . . . . 12
3.6.2. Join Proxy support for Variations . . . . . . . . . . 12
3.6.3. Co-location of Proxy and Registrar . . . . . . . . . 13
3.7. BRSKI Pledges support for Variations . . . . . . . . . . 14
3.7.1. BRSKI-PLEDGE context . . . . . . . . . . . . . . . . 14
3.8. Variation signaling and encoding rules for different
discovery mechanisms . . . . . . . . . . . . . . . . . . 18
3.8.1. DNS-SD . . . . . . . . . . . . . . . . . . . . . . . 18
3.8.2. GRASP . . . . . . . . . . . . . . . . . . . . . . . . 21
3.8.3. CORE-LF . . . . . . . . . . . . . . . . . . . . . . . 23
4. Updates to existing RFCs . . . . . . . . . . . . . . . . . . 24
4.1. RFC8995 . . . . . . . . . . . . . . . . . . . . . . . . . 24
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24
5.1. BRSKI Variations Discovery Registry (section) . . . . . . 24
5.2. Service Names Registry . . . . . . . . . . . . . . . . . 28
5.3. BRSKI Well-Known URIs fixes (opportunistic) . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
8. Draft considerations . . . . . . . . . . . . . . . . . . . . 30
8.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 30
8.2. Changelog . . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Discovery for constrained BRSKI . . . . . . . . . . 33
A.1. Current constrained text for GRASP . . . . . . . . . . . 33
A.1.1. Issues and proposed change . . . . . . . . . . . . . 35
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
Eckert, et al. Expires 21 April 2024 [Page 2]
Internet-Draft BRSKI-discovery October 2023
1. Terminology
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.
This document relies on the terminology defined in Section 1. The
following terms are described partly in addition.
Context: See Variation Context.
Initiator: A host that is using an IP transport protocol to initiate
a connection or transaction to another host called the responder.
Initiator socket: A socket consisting of an initiators IP or IPv6
address, protocol and protocol port number from which it initiates
connections or transactions to a responder (typically UDP or TCP).
Objective Name: See Service Name.
Resource Type: See Service Name.
Responder: A host that is using an IP transport protocol to respond
to transaction or connection requests from an Initiator.
Responder socket: A socket consisting of a responders IP or IPv6
address, protocol and protocol port number on which it responds to
requests of the protocol (typically UDP or TCP).
Role: In the context of this document, a type of entity in a
variation of BRSKI that can act as a responder and whose supported
variations can be discovered. BRSKI roles relevant in this
document include Join Registrar, Join Proxy and Pledge. The IANA
registry defined by this document allows to specify variations for
any roles. See also Variation Context.
Socket: The combination of am IP or IPv6 address, an IP protocol
that utilizes a port number (such as TCP or UDP) and a port number
of that protocol.
Service Name: The name for (a subset of) the functionality/API
provided by a discoverable responder socket. This term is
inherited from Section 1 but unless otherwise specified also used
in this document to apply to any other discovery functionality/
API. The terminology used by other mechanisms typically differs.
For example, when Section 1 is used to discover a responder socket
Eckert, et al. Expires 21 April 2024 [Page 3]
Internet-Draft BRSKI-discovery October 2023
for BRSKI, the Objective Name carries the equivalent to the
service name. In Section 1, the Resource Type (rt=) carries the
equivalent of the service name.
Type: See Variation Type.
Variation: A combination one one variation choice each for every
variation type applicable to the variation context of one
discoverable BRSKI communications. For example, in the context of
BRSKI, a variation is one choice for "mode", one choice for
"enroll" and once choice for "vformat".
Variation Context: A set of Services for whom the same set of
variations applies
Variation Type: The name for one aspect of a protocol for which two
or more choices exist (or may exist in the future), and where the
choice can technically be combined orthogonal to other variation
types. This document defined the BRSKI variation types "mode",
"enroll" and "vformat".
Variation Type Choice: The name for different values that a
particular variation type may have. For example, this document
does defines the choices "rrm" and "prm" for the BRSKI variation
"mode".
ACP: "An Autonomic Control Plane", [RFC8994].
BRSKI: "Bootstrapping Remote Secure Key Infrastructure", [RFC8995].
BRSKI-AE: "Alternative Enrollment Protocols in Section 1",
[I-D.ietf-anima-brski-ae].
BRSKI-PRM: "Section 1 with Pledge in Responder Mode",
[I-D.ietf-anima-brski-prm].
cBRSKI: "Constrained Bootstrapping Remote Secure Key Infrastructure
(Section 1)", [I-D.ietf-anima-constrained-voucher].
COAP: "The Constrained Application Protocol (CoAP)", [RFC7252].
CORE-LF: "Constrained RESTful Environments (CoRE) Link Format",
[RFC6690].
cPROXY: "Constrained Join Proxy for Bootstrapping Protocols",
[I-D.ietf-anima-constrained-join-proxy].
DNS-SD: "DNS-Based Service Discovery", [RFC6763].
Eckert, et al. Expires 21 April 2024 [Page 4]
Internet-Draft BRSKI-discovery October 2023
EST: "Enrollment over Secure Transport", [RFC7030].
GRASP: "GeneRic Autonomic Signaling Protocol", [RFC8990].
GRASP-DNSSD: "DNS-SD Compatible Service Discovery in GeneRic
Autonomic Signaling Protocol (GRASP)",
[I-D.eckert-anima-grasp-dnssd].
JWS-VOUCHER: "JWS signed Voucher Artifacts for Bootstrapping
Protocols", [I-D.ietf-anima-jws-voucher].
lwCMP: "Lightweight Certificate Management Protocol (CMP) Profile",
[I-D.ietf-lamps-lightweight-cmp-profile].
mDNS: "multicast DNS", [RFC6762].
SCEP: "Simple Certificate Enrolment Protocol", [RFC8894].
2. Overview
The mechanisms described in this document are intended to help solve
the following challenges.
Signaling BRSKI variation for responder selection.
When an initiator such as a proxy or pledge uses a mechanism such as
Section 1 to discover an instance of a role it intends to connect to,
such as a registrar, it may discover more than one such instance. In
the presence of variations of the BRSKI mechanisms that impact
interoperability, performance or security, not all discovered
instances may support exactly what the initiator needs to achieve
interoperability and/or best performance, security or other metrics.
In this case, the service announcement mechanism needs to carry the
necessary additional information beside the name that indicates the
service to aid the initiator in selecting an instance that it can
interoperate and achieve best performance with.
Easier use of additional discovery mechanisms.
In the presence of different discovery mechanisms, such as Section 1,
Section 1, Section 1 or others, the details of how to apply each of
these mechanisms are usually specified individually for each
mechanism, easily resulting in inconsistencies. Deriving as much as
possible the details of discovery from a common specification and
registries can reduce such inconsistencies and easy introduction of
additional discovery mechansisms.
Eckert, et al. Expires 21 April 2024 [Page 5]
Internet-Draft BRSKI-discovery October 2023
Generalization of principles related to discovery and operation of
proxies.
Because of the unified approach to discovery of BRSKI Variations
described in this document, it also allows to use Section 1 for
document for Section 1 and Section 1, which may be of interest in
networks such as Thread, which use Section 1.
3. Specification
3.1. Abstracted BRSKI discovery and selection
In the abstract model of discovery used by this document and intended
to apply to all described discoverymechanisms, an entity operating as
an initiator of a transport connection for a particular BRSKI
protocol role, such as a pledge, discovers one or more responder
sockets (IP/IPv6-address, responder-port, IP-protocol) of entities
acting as responders for the peer BRSKI role, such as registrar. The
initiator uses some discovery mechanism such as Section 1, Section 1
or Section 1. In the the initiator looks for a particular
combination of a Service Name and an IP-protocol, and in return
learns about responder sockets from one or more responders that use
this IP-protocol and serve the requested Service Name type service
across it. It also learns the BRSKI variation(s) supported on the
socket.
Service Name is the name of the protocol element used in Section 1,
unless explicitly specified, it is used as a placeholder for the
equivalent protocol elements in other discovery mechanisms. In
Section 1, it is called objective-name, in Section 1 it is called
Resource Type.
Upon discovery of the available sockets, the initiator selects one,
whose supported variation(s) best match the expectations of the
initiator, including performance, security or other praeferences.
Selection may also include attempting to establish a connection to
the responder socket, and upon connection failure to attempt
connecting to the next best responder socket. This is for example
necessary when discovery information may not be updated in real-time,
and the best responder has gone offline.
3.2. Variation Contexts
A Variation Context is a set of (Discover Mechanism, Service Names,
IP-protocols) across which this document and the registry of
variations defines a common set of variations. The initial registry
defined in this document defines two variation contexts.
Eckert, et al. Expires 21 April 2024 [Page 6]
Internet-Draft BRSKI-discovery October 2023
BRSKI context: context for discovery of BRSKI registrar and proxy
variations by proxies, pledges or agents (as defined in Section 1)
via the Service Names defined for Section 1 and Section 1 via TCP
and hence (by default) TLS (version 1.2 or higher according to
Section 1).
cBRSKI context (constrained BRSKI): context for discovery of BRSKI
registrar and proxy variations by proxies, pledges via the Service
Names defined for Section 1, Section 1 and Section 1 via UDP, and
hence (by default) secure COAP.
Note that the Service Names for cBRSKI include the same Section 1
Service Names as for the BRSKI context, hence enabling the use of
Section 1 with cBRSKI.
This document does not define variations for different end-to-end
ecnryption mechanisms, so only the "(by default)" options exist at
the time of writing this document. However, the mechanisms described
here can also be used to introduce backward incompatible new secure
transport options. For example when responders start to support only
TLS 1.3 or higher in the presence of TLS 1.2 only initiators, then
new variations can be added, such that those initiators will not
select those responders.
This document does not introduce variation contexts for discovery of
other BRSKI roles, such as discovery of pledges by agents (as defined
in Section 1), or discovery of MASA by registrars. However, the
registry introduced by this document is defined such that it can be
extended by such additional contexts through future documents.
3.3. Variation Types and Choices
A Variation Type is a variation in one aspect of the BRSKI connection
between initiator and responder that ideally orthogonal from
variations in other aspects of the BRSKI connection.
A Variation Type Choice is one alternative (aka: value) for its
Variation Type.
This document, and the initial registry documenting the variation
types introduces three variation types as follows:
mode: A variation in the basic sequence of URI endpoints
Eckert, et al. Expires 21 April 2024 [Page 7]
Internet-Draft BRSKI-discovery October 2023
communicated. This document introduces the choices of "rrm" to
indicate the endpoints and sequence as defined in Section 1 and
"prm" to indicate the nedpoints and sequence as defined in
Section 1. Note that registrars also act as responders in "prm".
"rrm" was choosen because the more logical "pim" (pledge initiator
mode) term was feared to cause confusion with other technologies
that use that term.
vformat (voucher format): A variation in the encoding format of the
voucher communicated between registrar and pledge. This document
introduces the choices "cms" as defined in Section 1, "cose" as
defined in Section 1 and "jose" as defined in Section 1.
enroll: A variation in the URI endpoints used for enrollment of the
pledge with keying material (trust anchors and certificate
(chain)). This document introduces the following :choices
* "est" as introduced by Section 1 to indicate the Section 1
protocol, which is default
* "cmp" to indicate the CMP protocol according to the Lightweight
CMP profile (Section 1). The respective adaptations to BRSKI
have been introduced by Section 1.
* "scep" to indicate Section 1. This is only a reservation,
because no specification for the use of Section 1 with BRSKI
exists.
3.4. Variations
A Variation is the combination of one Choice each for every Variation
Type applicable to the Variation Context. In other words, a
variation is a possible instance of BRSKI if supported by initiator
and responder. In Section 1, the default variation is "registrar
responder mode" (rrm) and use of the "cms voucher format" (cms).
3.5. BRSKI Variations Discovery Registry
The IANA "BRSKI Variations Registry" as specified by this document,
see Section 5.1 specifies the defined parameters for discovery of
BRSKI variations.
3.5.1. BRSKI Variation Contexts table
This table, Table 1, defines the BRSKI Variations Contexts.
Eckert, et al. Expires 21 April 2024 [Page 8]
Internet-Draft BRSKI-discovery October 2023
The "Applicable Variation Types" lists the Variation Types from whose
choices a Variation for this context is formed. The "Service
Name(s)" colum lists the discovery mechanisms and their Service
Name(s) that constitute the context.
3.5.2. BRSKI Variation Type Choices table
This table, Table 2, defines the Variations Type Choices.
The "Context" column lists the BRSKI Variation Context(s) to which
this line applies. If it is empty, then the same Context(s) apply as
that of the last prior line with a non-empty Context column.
The "Variation Type" column lists the BRSKi Variation Type to which
this line applies. If it is empty, then the same Variation Type
applies as that of the last prior line with a non-empty Variation
Type column. Variation Types MUST the listed in the order in which
the Variation Types are listed in the Applicable Variation Types
column of the BRSKI Variation Contexts table.
The "Variation Type Choice" column defines a Variation Type Choice
term within the Context(s) of the line. To allow the most flexible
encodings of variations, all Variation Types and Variation Type
Choices MUST be unique strings (across all Variation Types). This
allows to encode Variation Type Choices in a discovery mechanism
without indicating their Variation Type. Variation Types and
Variation Type Choices and MUST be strings from lowercase letters a-z
and digits 0-9 and MUST start with a letter. The maximum length of a
Variation Type Choice is 12 characters.
The "Reference" column specifies the documents which describe the
Variation Type Choice. Relevant specification includes those that
only specify the semantics without referring to the aspects of
discovery and/or those that specify only the Discovery aspects.
Current RFCs for BRSKI variations preceeding this RFC typically only
specify the semantics, and this document adds the discovery aspects.
The "Dflt" Flag specifies a Variation Type Choice that is assumed to
be the default Choice for the Context, such as "rrm" for the BRSKI
context. Such a Variation Type Choice is to be assumed to be
supported in discovery if discovery is performed without indication
of any or an empty signalling element to carry the Variation or
Variation Choices. For example, Section 1 specifies the empty string
"" as the objective-value in Section 1 discovery. Because "rrm",
"est" and "cms" are default in the BRSKI context, this Discovery
signalling indicates the support for those Variation Type Choices.
Eckert, et al. Expires 21 April 2024 [Page 9]
Internet-Draft BRSKI-discovery October 2023
The "Dflt_" Flag specifies a Variation Type Choice that is only
default in a subset of Discovery options in a context. The Note(s)
column has then to explain which subset this is. Like for "Dflt",
the signalling in this subset of Discovery options can then forego
indication of the "Dflt_" Variation Type Choice.
The "Rsvd" Flag specifies a Variation Type Choice for which no
complete specification exist on how to use it within BRSKI (or more
specifically the context), but which is known to be of potential
interest. "Rsvd" Variation Type Choices MUST NOT be considered for
the Discoverable Variations table. They are documented primarily to
reserve the Variation Type Choice term.
The Note(s) section expands the Variation Type Choice terms and
provides additional beneficial specification references beyond the
"Reference" column.
3.5.3. BRSKI Discoverable Variations table
This table Table 3 enumerates the Discoverable Variations and
categorizes them.
The "Context" column lists the BRSKI Variation Context(s) to which
this line applies. If it is empty, then the same Context(s) apply as
that of the last prior line with a non-empty Context column.
The "Spec / Applicability" lists the document(s) that specify the
variation, if the variation is explicitly described. If the
variation is not described explicitly, but rather a combination of
Variation Type Choices from more than one BRSKI related
specification, then this column will indicate "-" if by expert
opinion it is assumed that this variation should work, or "NA", if by
expert opinion, this variation could not work. The "Explanations"
column includes references to the relevant documents and as necessary
additional explanation.
The "Variation" colum lists the Variation Type Choices that form the
Variation. The Variation Type Choices MUST be listed in the order in
which the Variation Types are listed in the Applicable Variation
Types column of the BRSKI Variation Contexts table.
The "Variation String" column has the string term used to indicate
the variation when using the simple encoding of BRSKI Variation
Discovery for GRASP as described in Section 1. It is formed by
concatenating the Choices term from the Variation colum with the "-"
character, excluding those Choices terms (and "-" concatenator) which
are Default for the Context. If this procedure ends up with the
empty string, then this is indicated as "" in the column.
Eckert, et al. Expires 21 April 2024 [Page 10]
Internet-Draft BRSKI-discovery October 2023
The "Explanations" column explains the "Spec / Applicability" status
of the Variation.
3.5.4. Extending or modifying the registry
Unless otherwise specified below, extension or changes to the
registry require standards action.
Additional Variation Type Choices and Variation Context discovery
mechanism Service Names including additional discovery mechanisms
require (only) specification and expert review if they refer to non
standard action protocols and/or protocol variation aspects. For
example, a specification how to use Section 1 with BRSKI would fall
under this clause as it is an informational RFC.
Non standards action Variation Type Choices can not be Default(Dflt).
They can only be Dflt* for non standards action (sub)Contexts.
Reservation of additional Variation Type Choices requires (only)
expert review.
Additional Contexts MUST be added at the end of the BRSKI Variation
Contexts table.
Additional Variation Types MUST be added at the end of the Applicable
Variation Types column of the BRSKI Variation Contexts table and at
the end of existing lines for the Context in the BRSKI Variation Type
Choices. Additional Variation Types MUST be introduced with a
Default (Dflt) Variation Type Choice. These rules ensures that the
rule to create the Variation String for GRASP (and as desired by
othrer discovery mechanism), and it also enables to add new Variation
Type and Choices wthout changing pre-existing Variation Strings: Any
Variations String implicitly include the Default Choice for any
future Variation Types.
When a new Variation Type is added, their Default Choice SHOULD be
added to the Variation Column of existing applicable lines in the
BRSKI Discoverable Variations table. Variations that include new
non-Default Variation Type Choices SHOULD be added at the end of the
existing lines for the Context.
3.6. BRSKI Join Proxies support for Variations
Eckert, et al. Expires 21 April 2024 [Page 11]
Internet-Draft BRSKI-discovery October 2023
3.6.1. Permissible Variations
Variations according to the terminology of this document are those
that do not require changes to BRSKI join proxy operations, but that
can transparently pass across existing join proxies without changes
to them - as long as they support the rules outlined in this
document.
Different choices for e.g.: pledge to registrar encryption
mechanisms, voucher format (vformat), use of different URI endpoints
or enrolment protocol endpoints (mode) are all transparent to join
proxies, and hence join proxies can not only support existing, well-
defined Choices of these Variation Types, but without changes to the
proxies also future ones - and only those are permitted to become
Variation Type Choices.
Changes to the BRSKI mechanism that do require additional changes to
join proxies are not considered Variations according to this document
and MUST NOT use the same discovery protocol signaling elements as
those defined for variations by this document. Instead, they SHOULD
use different combinations of Service Name and Protocol (e.g.: TCP
vs. UDP).
For example, the stateless join proxy mode defined by Section 1 is
such a mechanism that requires explicit join proxy support.
Therefore, registrars sockets that support circuit proxy mode use the
GRASP objective "AN_join_registrar", and registrar sockets that
support stateless join proxy mode use the GRASP objective
"AN_join_registrar_rjp". This enables join proxies to select the
registrar and socket according to what the join proxy supports and
prefers. By not using the same signaling element(s) for variations,
join proxies can support discovery of all variations independent of
their support for stateless join proxy operations.
3.6.2. Join Proxy support for Variations
Join proxies supporting the mechanisms of this document MUST signal
for each socket they announce to initiators via a discovery mechanism
the Variation(s) supported on the socket. These Variation(s) MUST
all be supported by the registrar that the join proxy then uses for
the connection from the initiator (e.g.: pledge). Pledges SHOULD
announce sockets to initiators so that all Variations that are
supported by registrars that the join proxy can interoperate with are
also available to the initiators connecting to the join proxy.
To meet these requirements, join proxies can employ different
implementation option. In the most simple one, a join proxy
allocates a separate responder socket for every Variation for which
Eckert, et al. Expires 21 April 2024 [Page 12]
Internet-Draft BRSKI-discovery October 2023
it discovers one or more registrars supporting this Variation. It
then announces that socket with only that one Variation in the
discovery mechanism, even if the Registrar(s) are all announcing
their socket with multiple Variations. When the join proxy operates
in circuit mode, it can then select one of the registrars supporting
the variation for every new initiator connection based on policies as
specified by BRSKi specifications and/or discovery parameters, such
as priority and weight when Section 1 is used, and redundant
registrars include those parameters.
TBD: insert example of received Registrar annoncement and created
proxy announcement ??
Join proxies MAY reduce the number of sockets announced to initiators
by using a single socket for all Variations for which they have the
same set of registrar sockets supporting those Variations. This
primarily helps to reduce the size of the discovery messages to
initiators and can save socket resources on the join proxy.
Join proxies MAY create multiple sockets in support of other
discovery options, even for the same Variation(s). For example, if
Section 1 is used by two registrars, both announcing the same
priority but different weights, then the join proxy may create a
separate socket for each of these registrars - and their variations,
so that the join proxy can equally announce the same priority and
weight for both sockets to initiators. This allows to maintain the
desired weights of use of registrars, even when the join proxy
operates in stateless mode, in which it can not select a separate
registrar for every client initiating a connection.
3.6.3. Co-location of Proxy and Registrar
In networks using Section 1 and Section 1, registrars must have a co-
located proxy, because pledges can only use single-hop discovery
(DULL-GRASP) and will only discover proxies, but not registrar. Such
a co-located proxy does not constitute additional processing/code on
a registrar supporting circuit mode, it simply implies that the
registrars BRSKI services(s) are announced with a proxy Service Name,
to support pledges, and the registrar service name, to support join
proxies.
To ease consistency of deployment models in the face of different
discovery mechanisms, Variations and non-Variation enhancements to
BRSKI, it is RECOMMENDED that all future options to BRSKI do always
have a Service Name for proxies and a separate Service Name in
support of pledge or other initiators. Pledges and other initiators
SHOULD always only look for the proxy Service Name, and only Proxies
should look for a registrar Service Name. Registrars therefore
Eckert, et al. Expires 21 April 2024 [Page 13]
Internet-Draft BRSKI-discovery October 2023
SHOULD always include the proxy functionaliy according to the prior
paragraph. This only involves additional code on the registrar
beyond the service announcement in case the Registrar would otherwise
not implement circuit mode.
3.7. BRSKI Pledges support for Variations
3.7.1. BRSKI-PLEDGE context
BRSKI-PLEDGE is the context for discovery of pledges by nodes such as
registrar-agents. Pledges supporting Section 1 MUST support it. It
may also be used by other variations of BRSKI when supported by
pledges.
Pledges supporting BRSKI-PLEDGE MUST support DNS-SD for discovery via
mDNS, using link-local scope. For DNS-SD discovery beyond link-local
scope, pledges SHOULD support DNS-SD via [I-D.ietf-dnssd-srp].
TBD: Is there sufficient autoconfiguration support in
[I-D.ietf-dnssd-srp], that pledges without any configuration can use
it, and if so, do we need to raise specific additional requirements
to enable this in pledges ?
These DNS-SD requirements are defaults. Specifications for specific
deployment contexts such as specific type of radio network solutions
may need to specify their own requirements overriding or amending
these requirements.
Pledges MUST support to be discoverable via their service instance
name. They MAY be discoverable via DNS-SD browsing, so that
registrar-agents can find even unexpected pledges through DNS-SD
browsing.
Support for browsing is required to discover over the network pledges
supporting only Section 1, but not Section 1 if they have no known
serial-number information from which their service instance name can
be constructed, so it is a crucial feature for robust enrollment.
See Section 6 for more details about discovery and BRSKI-PLEDGE.
When pledges are discoverable vis DNS-SD browsing, they MUST expect
that a large number of pledges exist in the network at the same time,
such as in the order of 100 or more, and schedule their responses
according to the procedures in Section 1 and Section 1 to avoid
simultaneous reply from all pledges.
TBD: What is the best section in mDNS/DNS-SD to point to for this
timed reply to scale ?
Eckert, et al. Expires 21 April 2024 [Page 14]
Internet-Draft BRSKI-discovery October 2023
Browsing via DNS-SD for a pledge is circumvented by the pledge not
announcing its PTR RR for "brski-registrar". Technically, the
remaining RR may not constitute full DNS-SD service, but they do
provide the required discovery for the known service instance name of
the pledge.
counter measures such as limiting the number and rate of PRM connects
that they accept, ideally on a per-initiator basis (assuming that
DDoS attacks are more harder to mount than single attacker DoS
attacks).
3.7.1.1. Service Instance Name
The servce instance name choosen by a BRSKI pledge MUST be composed
from information which is
* Easily known by BRSKI operations, such as the operational
personnel or software automation, specifically sales integration,
* Available to the pledges BRSKI software itself, for example by
being encoded in some attribute of the IDevID.
Typically, a customer will know the serial number of a product from
sales information, or even from barcode/QR-codes on the product
itself. If this serial number is used as the service instance name
to discover a pledge from a registrar-agent, then this may lead to
possible duplicate replies from two or more pledges having the same
serial number, such as in the following cases:
1. A manufacturer has different product lines and re-uses serial-
numbers across them.
2. Two different manufacturer re-use the same serial-numbers.
If pledges enable browsing of their service instance name, they MAY
support Section 1 specified procedures to create unique service
instance names when they discover such clashes, by appending a space
and serial number, starting with 2 to the service instance name:
"<service-instance-name> (2)", as described in Section 1 Appendix D.
Nevertheless, this approach to resolving conflights is not desirable:
* If browsing of DNS-SD service instance name is not supported,
registrar-agents would have to always (and mostly wrongly) guess
that there is a clash and (mostly unnecessarily) search for
"<service-instance-name> (2)".
Eckert, et al. Expires 21 April 2024 [Page 15]
Internet-Draft BRSKI-discovery October 2023
* If a clash exists between pledges from the same manufacturer, and
even if the registrar-agent then attempts to start enrolling all
pledges with the same clashing service instance name, it may not
have enough information to determine which the correct pledge is.
This would happen especially if the IDevId from both devices (of
different product type), had the same serial number, and the CA of
both was the same (because they come from the same manufacturer).
Even if some other IDevID field was used to distinguish their
device model, the registrar-agent would not be able to determine
that difference without additional vendor specific programming.
In result:
* Vendors MUST document a scheme how their pledges form a service
instance name from information available to the customer of the
pledge.
* These service instance names MUST be unique across all IDevID of
the manufacturer that share the same CA.
The following mechanisms are recommended:
* Pledges SHOULD encode manufacturer unique product instance
information in their subject name serialNumber. [RFC5280] calls
this the X520SerialNumber.
* Pledges SHOULD make this serialNumber information consistent with
easily accessible product instance information when in physcial
posession of the pledge, such as product type code and serial
number on barcode/QR-code to enable Section 1 discovery without
additional backend sales integration. Note that discovery alone
does not allow for enrollment!
* Pledges SHOULD construct their service instance name by
concatenating their X520SerialNumber with a domain name prefix
that is used by the manufacturer and thus allows to disambiguate
devices from different manufacturer using the same serialNumber
scheme, and hence the likelyhood of service instance name clashes.
Eckert, et al. Expires 21 April 2024 [Page 16]
Internet-Draft BRSKI-discovery October 2023
Service Instance Name:
"PID:Model-0815 SN:WLDPC2117A99.example.com"
Manufacturer published Service Instance Name schema:
PID:\<PID>\\ SN:\<SN>.example.com
Pledge IDevID certificate information:
; Format as shown by e.g.: openssh
Subject: serialNumber = "PID:Model-0815 SN:WLDPC2117A99",
O = Example, CN = Model-0815
DNS-SD RR for the pledge:
; PTR RR to support browsing / discovery of service instance name
_brski-pledge._tcp.local IN PTR
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
; SRC and TXT RR for the service instance name
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
IN SRV 1 1
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
IN TXT ""
; AAAA address resolution for the target host name
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local
IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:00a1
Figure 1: Example service instance name data
In Figure 1, the manufacturer "example" identifies device instances
through a product identifier <PID> and a serial number <SN>. Both
are printed on labels on the product/packaging and/or communicated
during purchase of the product.
The service instance name of pledges from this manufacturer are using
the string "PID:<PID> SN:<SN>.example.com". "example.com" is assumed
to be a domain owned by this manufacturer. <PID> and <SN> are
replaced by the actual strings.
The IDevID encodes the service instance name without the domain
ending (".example.com") in the X520SerialNumber field. Other fields
of the IDevID are not used.
The resulting DNS-SD RRs that the pledge announces are shown in the
example. " " and "." characters are escaped as recommended by
Section 1.
Eckert, et al. Expires 21 April 2024 [Page 17]
Internet-Draft BRSKI-discovery October 2023
In this example, the same string as constructed for the service
instance name is also used as the target host name. This is of
course not necessary, but unless the pledge already obtains a host
name through other DNS means, re-using the same name allows to avoid
coming up with a second method to construct a unique name.
3.8. Variation signaling and encoding rules for different discovery
mechanisms
3.8.1. DNS-SD
3.8.1.1. Signaling
The following definitions apply to any instantiation of DNS-SD
including DNS-SD via mDNS as defined in Section 1, but also via
unicast DNS, for example by registering the necessary DNS-SD Resource
Records (RR) via [I-D.ietf-dnssd-srp] (SRP).
The requirements in this document do not guarantee interoperability
when using DNS-SD, instead, they need to be amended with deployment
specific specifications / requirements as to which signaling
variation, such as mDNS or unicast DNS with SRP is to be supported
between initiator and responder. When using unicast DNS (with SRP),
additional mechanisms are required to learn the IP / IPv6 address(es)
of feasible DNS and SRP servers, and deployment may also need
agreements for the (default) domain they want to use in unicast DNS.
Hence, a mandatory to implement (MTI) profile is not feasible because
of the wide range of variations to deploy DNS-SD.
TBD: We could say that mDNS MUST be supported, unless the network
context defines an interoperable mode to support DNS-SD without mDNS
???
3.8.1.2. Encoding
Variation Type Choices defined in the IANA registry Table 3 are
encoded as Section 1 Keys with a value of 1 in the DNS-SD service
instances TXT RR. This is possible because all Variation Type
Choices are required to be unique across all Variation Types. It
also allows to shorten the encoding from "key=1" to just "key" for
every Variation Type Choice, so that the TXT-DATA encoding can be
more compact.
If the TXT Record does not contain a Variation Type Choice for a