-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-anima-brski-discovery.xml
2781 lines (2382 loc) · 149 KB
/
draft-ietf-anima-brski-discovery.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 2.6.10) -->
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<?rfc compact="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-anima-brski-discovery-03" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="BRSKI-discovery">Discovery for BRSKI variations</title>
<author initials="T." surname="Eckert" fullname="Toerless Eckert" role="editor">
<organization abbrev="Futurewei">Futurewei USA</organization>
<address>
<postal>
<country>USA</country>
</postal>
<email>tte@cs.fau.de</email>
</address>
</author>
<author initials="E." surname="Dijk" fullname="Esko Dijk">
<organization>IoTconsultancy.nl</organization>
<address>
<email>esko.dijk@iotconsultancy.nl</email>
</address>
</author>
<date year="2024"/>
<area>Operations and Management</area>
<workgroup>ANIMA</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 95?>
<t>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.</t>
</abstract>
</front>
<middle>
<?line 100?>
<section anchor="terminology"><name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
<t>This document relies on the terminology defined in <xref target="BRSKI"/>. The following terms are described partly in addition.</t>
<dl>
<dt>Context:</dt>
<dd>
<t>See Variation Context.</t>
</dd>
<dt>Initiator:</dt>
<dd>
<t>A host that is using an IP transport protocol to initiate a connection or transaction to another host called the responder.</t>
</dd>
<dt>Initiator socket:</dt>
<dd>
<t>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).</t>
</dd>
<dt>Objective Name:</dt>
<dd>
<t>See Service Name.</t>
</dd>
<dt>Resource Type:</dt>
<dd>
<t>See Service Name.</t>
</dd>
<dt>Responder:</dt>
<dd>
<t>A host that is using an IP transport protocol to respond to transaction or connection requests from an Initiator.</t>
</dd>
<dt>Responder socket:</dt>
<dd>
<t>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).</t>
</dd>
<dt>Role:</dt>
<dd>
<t>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.</t>
</dd>
<dt>Socket:</dt>
<dd>
<t>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.</t>
</dd>
<dt>Service Name:</dt>
<dd>
<t>The name for (a subset of) the functionality/API provided by a discoverable responder socket. This term is inherited from <xref target="DNS-SD"/> 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 <xref target="GRASP"/> is used to discover a responder socket for BRSKI, the Objective Name carries the equivalent to the service name. In <xref target="CORE-LF"/>, the Resource Type (rt=) carries the equivalent of the service name.</t>
</dd>
<dt>Type:</dt>
<dd>
<t>See Variation Type.</t>
</dd>
<dt>Variation:</dt>
<dd>
<t>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".</t>
</dd>
<dt>Variation Context:</dt>
<dd>
<t>A set of Services for whom the same set of variations applies</t>
</dd>
<dt>Variation Type:</dt>
<dd>
<t>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".</t>
</dd>
<dt>Variation Type Choice:</dt>
<dd>
<t>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".</t>
</dd>
<dt anchor="ACP">ACP:</dt>
<dd>
<t>"An Autonomic Control Plane", <xref target="RFC8994"/>.</t>
</dd>
<dt anchor="BRSKI">BRSKI:</dt>
<dd>
<t>"Bootstrapping Remote Secure Key Infrastructure", <xref target="RFC8995"/>.</t>
</dd>
<dt anchor="BRSKI-AE">BRSKI-AE:</dt>
<dd>
<t>"Alternative Enrollment Protocols in <xref target="BRSKI"/>", <xref target="I-D.ietf-anima-brski-ae"/>.</t>
</dd>
<dt anchor="BRSKI-PRM">BRSKI-PRM:</dt>
<dd>
<t>"<xref target="BRSKI"/> with Pledge in Responder Mode", <xref target="I-D.ietf-anima-brski-prm"/>.</t>
</dd>
<dt anchor="cBRSKI">cBRSKI:</dt>
<dd>
<t>"Constrained Bootstrapping Remote Secure Key Infrastructure (<xref target="BRSKI"/>)", <xref target="I-D.ietf-anima-constrained-voucher"/>.</t>
</dd>
<dt anchor="COAP">COAP:</dt>
<dd>
<t>"The Constrained Application Protocol (CoAP)", <xref target="RFC7252"/>.</t>
</dd>
<dt anchor="CORE-LF">CORE-LF:</dt>
<dd>
<t>"Constrained RESTful Environments (CoRE) Link Format", <xref target="RFC6690"/>.</t>
</dd>
<dt anchor="cPROXY">cPROXY:</dt>
<dd>
<t>"Constrained Join Proxy for Bootstrapping Protocols", <xref target="I-D.ietf-anima-constrained-join-proxy"/>.</t>
</dd>
<dt anchor="DNS-SD">DNS-SD:</dt>
<dd>
<t>"DNS-Based Service Discovery", <xref target="RFC6763"/>.</t>
</dd>
<dt anchor="EST">EST:</dt>
<dd>
<t>"Enrollment over Secure Transport", <xref target="RFC7030"/>.</t>
</dd>
<dt anchor="GRASP">GRASP:</dt>
<dd>
<t>"GeneRic Autonomic Signaling Protocol", <xref target="RFC8990"/>.</t>
</dd>
<dt anchor="GRASP-DNSSD">GRASP-DNSSD:</dt>
<dd>
<t>"DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP)", <xref target="I-D.eckert-anima-grasp-dnssd"/>.</t>
</dd>
<dt anchor="JWS-VOUCHER">JWS-VOUCHER:</dt>
<dd>
<t>"JWS signed Voucher Artifacts for Bootstrapping Protocols", <xref target="I-D.ietf-anima-jws-voucher"/>.</t>
</dd>
<dt anchor="lwCMP">lwCMP:</dt>
<dd>
<t>"Lightweight Certificate Management Protocol (CMP) Profile", <xref target="I-D.ietf-lamps-lightweight-cmp-profile"/>.</t>
</dd>
<dt anchor="mDNS">mDNS:</dt>
<dd>
<t>"multicast DNS", <xref target="RFC6762"/>.</t>
</dd>
<dt anchor="SCEP">SCEP:</dt>
<dd>
<t>"Simple Certificate Enrolment Protocol", <xref target="RFC8894"/>.</t>
</dd>
</dl>
</section>
<section anchor="overview"><name>Overview</name>
<t>The mechanisms described in this document are intended to help solve the following challenges.</t>
<t>Signaling BRSKI variation for responder selection.</t>
<t>When an initiator such as a proxy or pledge uses a mechanism such as
<xref target="DNS-SD"/> 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 inter operate and achieve best performance with.</t>
<t>Easier use of additional discovery mechanisms.</t>
<t>In the presence of different discovery mechanisms, such as <xref target="DNS-SD"/>, <xref target="GRASP"/>,
<xref target="CORE-LF"/> 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 mechanisms.</t>
<t>Generalization of principles related to discovery and operation of proxies.</t>
<t>Because of the unified approach to discovery of BRSKI Variations described in this document,
it also allows to use <xref target="DNS-SD"/> for document for <xref target="cBRSKI"/> and <xref target="cPROXY"/>, which may be
of interest in networks such as Thread, which use <xref target="DNS-SD"/>.</t>
</section>
<section anchor="specification"><name>Specification</name>
<section anchor="abstracted-brski-discovery-and-selection"><name>Abstracted BRSKI discovery and selection</name>
<t>In the abstract model of discovery used by this document and intended to apply to all described discovery mechanisms, 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 <xref target="DNS-SD"/>, <xref target="GRASP"/> or <xref target="CORE-LF"/>. 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.</t>
<t>Service Name is the name of the protocol element used in <xref target="DNS-SD"/>, unless explicitly specified, it is used
as a placeholder for the equivalent protocol elements in other discovery mechanisms. In <xref target="GRASP"/>, it is called
objective-name, in <xref target="CORE-LF"/> it is called Resource Type.</t>
<t>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 preferences. 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.</t>
</section>
<section anchor="variation-contexts"><name>Variation Contexts</name>
<t>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.</t>
<dl>
<dt>BRSKI context:</dt>
<dd>
<t>context for discovery of BRSKI registrar and proxy variations by proxies, pledges or agents
(as defined in <xref target="BRSKI-PRM"/>) via the Service Names defined for <xref target="DNS-SD"/> and <xref target="GRASP"/> via
TCP and hence (by default) TLS (version 1.2 or higher according to <xref target="BRSKI"/>).</t>
</dd>
<dt>cBRSKI context (constrained BRSKI):</dt>
<dd>
<t>context for discovery of BRSKI registrar and proxy variations by proxies, pledges
via the Service Names defined for <xref target="DNS-SD"/>, <xref target="GRASP"/> and <xref target="CORE-LF"/> via UDP, and hence (by default) secure COAP.</t>
</dd>
</dl>
<t>Note that the Service Names for cBRSKI include the same <xref target="DNS-SD"/> Service Names as for the BRSKI context,
hence enabling the use of <xref target="DNS-SD"/> with cBRSKI.</t>
<t>This document does not define variations for different end-to-end encryption 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.</t>
<t>This document does not introduce variation contexts for discovery of other BRSKI roles, such as discovery
of pledges by agents (as defined in <xref target="BRSKI-PRM"/>), 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.</t>
</section>
<section anchor="variation-types-and-choices"><name>Variation Types and Choices</name>
<t>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.</t>
<t>A Variation Type Choice is one alternative (aka: value) for its Variation Type.</t>
<t>This document, and the initial registry documenting the variation types introduces three variation types as follows:</t>
<dl>
<dt>mode:</dt>
<dd>
<t>A variation in the basic sequence of URI endpoints communicated. This document introduces the choices of
"rrm" to indicate the endpoints and sequence as defined in <xref target="BRSKI"/> and "prm" to indicate the endpoints and sequence
as defined in <xref target="BRSKI-PRM"/>. Note that registrars also act as responders in "prm". "rrm" was chosen because the
more logical "pim" (pledge initiator mode) term was feared to cause confusion with other technologies that use that term.</t>
</dd>
<dt>vformat (voucher format):</dt>
<dd>
<t>A variation in the encoding format of the voucher communicated between registrar and pledge. This document introduces
the choices "cms" as defined in <xref target="BRSKI"/>, "cose" as defined in <xref target="cBRSKI"/> and "jose" as defined in <xref target="JWS-VOUCHER"/>.</t>
</dd>
<dt>enroll:</dt>
<dd>
<t>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
</t>
<t><list style="symbols">
<t>"est" as introduced by <xref target="BRSKI"/> to indicate the <xref target="EST"/> protocol, which is default</t>
<t>"cmp" to indicate the CMP protocol according to the Lightweight CMP profile (<xref target="lwCMP"/>). The respective adaptations to BRSKI have been introduced by <xref target="BRSKI-AE"/>.</t>
<t>"scep" to indicate <xref target="SCEP"/>. This is only a reservation, because no specification for the use of <xref target="SCEP"/> with BRSKI exists.</t>
</list></t>
</dd>
</dl>
</section>
<section anchor="variations"><name>Variations</name>
<t>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 <xref target="BRSKI"/>,
the default variation is "registrar responder mode" (rrm) and use of the "cms voucher format" (cms).</t>
</section>
<section anchor="brski-variations-discovery-registry"><name>BRSKI Variations Discovery Registry</name>
<t>The IANA "BRSKI Variations Registry" as specified by this document, see <xref target="registry"/> specifies the
defined parameters for discovery of BRSKI variations.</t>
<section anchor="brski-variation-contexts-table"><name>BRSKI Variation Contexts table</name>
<t>This table, <xref target="fig-contexts"/>, defines the BRSKI Variations Contexts.</t>
<t>The "Applicable Variation Types" lists the Variation Types from whose choices a Variation for this
context is formed. The "Service Name(s)" column lists the discovery mechanisms and their Service Name(s)
that constitute the context.</t>
</section>
<section anchor="brski-variation-type-choices-table"><name>BRSKI Variation Type Choices table</name>
<t>This table, <xref target="fig-choices"/>, defines the Variations Type Choices.</t>
<t>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.</t>
<t>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 <bcp14>MUST</bcp14> the listed in the order in which the Variation Types are listed in the Applicable Variation Types
column of the BRSKI Variation Contexts table.</t>
<t>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 <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be strings from lowercase letters a-z and digits 0-9 and <bcp14>MUST</bcp14> start with a letter. The
maximum length of a Variation Type Choice is 12 characters.</t>
<t>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 preceding this RFC typically
only specify the semantics, and this document adds the discovery aspects.</t>
<t>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 signaling element to carry the Variation or
Variation Choices. For example, <xref target="BRSKI"/> specifies the empty string "" as the objective-value in <xref target="GRASP"/>
discovery. Because "rrm", "est" and "cms" are default in the BRSKI context, this Discovery signaling
indicates the support for those Variation Type Choices.</t>
<t>The "Dflt<em>" 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 signaling in
this subset of Discovery options can then forego indication of the "Dflt</em>" Variation Type Choice.</t>
<t>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 <bcp14>MUST NOT</bcp14> be considered for the Discoverable Variations table. They are documented
primarily to reserve the Variation Type Choice term.</t>
<t>The Note(s) section expands the Variation Type Choice terms and provides additional beneficial specification
references beyond the "Reference" column.</t>
</section>
<section anchor="variation"><name>BRSKI Discoverable Variations table</name>
<t>This table <xref target="fig-variations"/> enumerates the Discoverable Variations and categorizes them.</t>
<t>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.</t>
<t>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.</t>
<t>The "Variation" column lists the Variation Type Choices that form the Variation. The Variation Type Choices
<bcp14>MUST</bcp14> be listed in the order in which the Variation Types are listed in the Applicable Variation Types
column of the BRSKI Variation Contexts table.</t>
<t>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 <xref target="GRASP"/>. It is formed by
concatenating the Choices term from the Variation column 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.</t>
<t>The "Explanations" column explains the "Spec / Applicability" status of the Variation.</t>
</section>
<section anchor="extending-or-modifying-the-registry"><name>Extending or modifying the registry</name>
<t>Unless otherwise specified below, extension or changes to the registry require standards action.</t>
<t>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 <xref target="SCEP"/> with BRSKI would
fall under this clause as it is an informational RFC.</t>
<t>Non standards action Variation Type Choices can not be Default(Dflt). They can only be Dflt* for non standards action
(sub)Contexts.</t>
<t>Reservation of additional Variation Type Choices requires (only) expert review.</t>
<t>Additional Contexts <bcp14>MUST</bcp14> be added at the end of the BRSKI Variation Contexts table.</t>
<t>Additional Variation Types <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> 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 other discovery mechanism), and it also enables to add new Variation Type and Choices
without changing pre-existing Variation Strings: Any Variations String implicitly include the Default Choice for
any future Variation Types.</t>
<t>When a new Variation Type is added, their Default Choice <bcp14>SHOULD</bcp14> 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 <bcp14>SHOULD</bcp14> be added at the end of the existing lines for the Context.</t>
</section>
</section>
<section anchor="brski-join-proxies-support-for-variations"><name>BRSKI Join Proxies support for Variations</name>
<section anchor="permissible-variations"><name>Permissible Variations</name>
<t>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.</t>
<t>Different choices for e.g.: pledge to registrar encryption mechanisms, voucher format (vformat), use of different URI endpoints or enrollment
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.</t>
<t>Changes to the BRSKI mechanism that do require additional changes to join proxies are not considered Variations
according to this document and <bcp14>MUST NOT</bcp14> use the same discovery protocol signaling elements as those defined for variations
by this document. Instead, they <bcp14>SHOULD</bcp14> use different combinations of Service Name and Protocol (e.g.: TCP vs. UDP).</t>
<t>For example, the stateless join proxy mode defined by <xref target="cPROXY"/> 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.</t>
</section>
<section anchor="proxy"><name>Join Proxy support for Variations</name>
<t>Join proxies supporting the mechanisms of this document <bcp14>MUST</bcp14> signal for each socket they announce to initiators via a discovery
mechanism the Variation(s) supported on the socket. These Variation(s) <bcp14>MUST</bcp14> all be supported by the registrar that the join
proxy then uses for the connection from the initiator (e.g.: pledge). Pledges <bcp14>SHOULD</bcp14> 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.</t>
<t>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 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 <xref target="DNS-SD"/> is used,
and redundant registrars include those parameters.</t>
<t>TBD: insert example of received Registrar announcement and created proxy announcement ??</t>
<t>Join proxies <bcp14>MAY</bcp14> 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.</t>
<t>Join proxies <bcp14>MAY</bcp14> create multiple sockets in support of other discovery options, even for the same Variation(s).
For example, if <xref target="DNS-SD"/> 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.</t>
</section>
<section anchor="colo"><name>Co-location of Proxy and Registrar</name>
<t>In networks using <xref target="BRSKI"/> and <xref target="ACP"/>, 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.</t>
<t>To ease consistency of deployment models in the face of different discovery mechanisms, Variations and
non-Variation enhancements to BRSKI, it is <bcp14>RECOMMENDED</bcp14> 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 <bcp14>SHOULD</bcp14> always only look for the proxy Service Name, and only Proxies should look
for a registrar Service Name. Registrars therefore <bcp14>SHOULD</bcp14> always include the proxy functionality 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.</t>
</section>
</section>
<section anchor="brski-pledges-support-for-variations"><name>BRSKI Pledges support for Variations</name>
<section anchor="brski-pledge-context"><name>BRSKI-PLEDGE context</name>
<t>BRSKI-PLEDGE is the context for discovery of pledges by nodes such as registrar-agents.
Pledges supporting <xref target="BRSKI-PRM"/> <bcp14>MUST</bcp14> support it. It may also be used by other variations of BRSKI
when supported by pledges.</t>
<t>Pledges supporting BRSKI-PLEDGE <bcp14>MUST</bcp14> support DNS-SD for discovery via mDNS, using link-local scope.
For DNS-SD discovery beyond link-local scope, pledges <bcp14>SHOULD</bcp14> support DNS-SD via <xref target="I-D.ietf-dnssd-srp"/>.</t>
<t>TBD: Is there sufficient auto-configuration support in <xref target="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 ?</t>
<t>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.</t>
<t>Pledges <bcp14>MUST</bcp14> support to be discoverable via their service instance name. They <bcp14>MAY</bcp14> be discoverable
via DNS-SD browsing, so that registrar-agents can find even unexpected pledges through DNS-SD browsing.</t>
<t>Support for browsing is required to discover over the network pledges supporting only <xref target="BRSKI-PRM"/>,
but not <xref target="BRSKI"/> 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 <xref target="security-considerations"/>
for more details about discovery and BRSKI-PLEDGE.</t>
<t>When pledges are discoverable vis DNS-SD browsing, they <bcp14>MUST</bcp14> 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 <xref target="mDNS"/> and <xref target="DNS-SD"/> to avoid simultaneous reply from all pledges.</t>
<t>TBD: What is the best section in mDNS/DNS-SD to point to for this timed reply to scale ?</t>
<t>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.</t>
<t>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).</t>
<section anchor="service-instance-name"><name>Service Instance Name</name>
<t>The service instance name chosen by a BRSKI pledge <bcp14>MUST</bcp14> be composed from information which is</t>
<t><list style="symbols">
<t>Easily known by BRSKI operations, such as the operational personnel or software automation,
specifically sales integration,</t>
<t>Available to the pledges BRSKI software itself, for example by being encoded in some attribute of the IDevID.</t>
</list></t>
<t>Typically, a customer will know the serial number of a product from sales information, or even
from bar-code/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:</t>
<t><list style="numbers">
<t>A manufacturer has different product lines and re-uses serial-numbers across them.</t>
<t>Two different manufacturer re-use the same serial-numbers.</t>
</list></t>
<t>If pledges enable browsing of their service instance name, they <bcp14>MAY</bcp14> support <xref target="DNS-SD"/> 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 <xref target="DNS-SD"/> Appendix D.</t>
<t>Nevertheless, this approach to resolving conflicts is not desirable:</t>
<t><list style="symbols">
<t>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)".</t>
<t>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.</t>
</list></t>
<t>In result:</t>
<t><list style="symbols">
<t>Vendors <bcp14>MUST</bcp14> document a scheme how their pledges form a service instance name from
information available to the customer of the pledge.</t>
<t>These service instance names <bcp14>MUST</bcp14> be unique across all IDevID of the manufacturer that
share the same CA.</t>
</list></t>
<t>The following mechanisms are recommended:</t>
<t><list style="symbols">
<t>Pledges <bcp14>SHOULD</bcp14> encode manufacturer unique product instance information in their
subject name serialNumber. <xref target="RFC5280"/> calls this the X520SerialNumber.</t>
<t>Pledges <bcp14>SHOULD</bcp14> make this serialNumber information consistent with easily accessible
product instance information when in physical possession of the pledge, such as
product type code and serial number on bar-code/QR-code to enable <xref target="BRSKI-PRM"/> discovery
without additional backend sales integration. Note that discovery alone does not
allow for enrollment!</t>
<t>Pledges <bcp14>SHOULD</bcp14> 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 likelihood of service instance name clashes.</t>
</list></t>
<figure title="Example service instance name data" anchor="service-name-example"><artwork><![CDATA[
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
]]></artwork></figure>
<t>In <xref target="service-name-example"/>, 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.</t>
<t>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.</t>
<t>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.</t>
<t>The resulting DNS-SD RRs that the pledge announces are shown in the example.
" " and "." characters are escaped as recommended by <xref target="DNS-SD"/>.</t>
<t>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.</t>
</section>
</section>
</section>
<section anchor="variation-signaling-and-encoding-rules-for-different-discovery-mechanisms"><name>Variation signaling and encoding rules for different discovery mechanisms</name>
<section anchor="dns-sd"><name>DNS-SD</name>
<section anchor="signaling"><name>Signaling</name>
<t>The following definitions apply to any instantiation of DNS-SD including DNS-SD via mDNS as defined in
<xref target="DNS-SD"/>, but also via unicast DNS, for example by registering the necessary DNS-SD Resource Records (RR) via <xref target="I-D.ietf-dnssd-srp"/> (SRP).</t>
<t>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.</t>
<t>TBD: We could say that mDNS <bcp14>MUST</bcp14> be supported, unless the network context defines an interoperable
mode to support DNS-SD without mDNS ???</t>
</section>
<section anchor="encoding"><name>Encoding</name>
<t>Variation Type Choices defined in the IANA registry <xref target="fig-variations"/> are encoded as <xref target="DNS-SD"/> 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.</t>
<t>If the TXT Record does not contain a Variation Type Choice for a particular applicable Variation Type, then this indicates
support for the Default Choice of this Variation Type in the context of the DNS-SD Service Name. For example, if the TXT
Record is "jose", then this indicates support for "rrm" and "est", if the Service Name is brski-registrar or brski-proxy and the
protocol is TCP (BRSKI Context), but also when the protocol is UDP (cBRSKI context), because "rrm" and "est" are defaults
in both contexts.</t>
<t>If multiple Variation Type Choices for the same Variation Type are indicated, then this implies
that either of these Variation Type Choices is supported in conjunction with any of the other
Variation Type Choices in the same TXT Record. For example, if the TXT Record is "prm" "rrm" "cms" "jose", then
this implies support for rrm-cms-est, rrm-jose-est, prm-cms-est and prm-jose-est. This example also shows
that if the default Variation Type Choice, such as "rrm" and another Choice of the same Variation Type ("prm") are to
be indicated as supported, then both need to be included in the TXT Record.</t>
<t>In <xref target="DNS-SD"/>, a responder does not only indicate a Service Name, but also its Service Instance Name, which needs
to be unique across the domain to support initiators selecting a responder. This specification makes no recommendation
for choosing the Instance portion of that name. Usually it is the same, or derived from some form of pre-existing system name.</t>
<t>Registrars <bcp14>SHOULD</bcp14> support support their configuration without specifying a name to use in the Service Instance Name to minimize the
amount of configuration required. Registrars <bcp14>SHOULD</bcp14> support the configuration of such a name.</t>
<t>If the responder needs to indicate different sockets for different (set of) Variations, for example,
when operating as a proxy, according to <xref target="proxy"/>, then it needs to signal for each socket a separate Service Instance Name
with the appropriate port information in its SRV Record and the supported Variations for that socket in the TXT Record of that
Service Instance Name. In this case, it is <bcp14>RECOMMENDED</bcp14> that the Instance Name includes the Variation it supports,
such as in the format specified in <xref target="variation"/> and used in the Variation String column of the <xref target="fig-variations"/> table.</t>
<figure title="DNS-SD for a simple BRSKI and cBRSKI registrar" anchor="dnssd-example-1"><artwork><![CDATA[
_brski-registrar._tcp.local
IN PTR 0200:0000:7400._brski-registrar._tcp.local
0200:0000:7400._brski-registrar._tcp.local
IN SRV 1 2 4555 0200:0000:7400.local
0200:0000:7400._brski-registrar._tcp.local IN TXT "rrm" "prm"
0200:0000:7400.local
IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:0001
_brski-registrar._udp.local
IN PTR 0200:0000:7400._brski-registrar._udp.local
0200:0000:7400._brski-registrar._udp.local
IN SRV 1 2 5684 0200:0000:7400.local
0200:0000:7400._brski-registrar._udp.local IN TXT ""
]]></artwork></figure>
<t>In the above example <xref target="dnssd-example-2"/>, a registrar supports BRSKI with "rrm" and "prm" modes across the same TCP socket, port 4555.
It uses "cms" voucher format and "est" enrollment, which are not included in the TXT strings because both are default for
_brski-registrar._tcp. The registrar also offers cBRSKI with "rrm" mode, "cose" voucher and "est" enrollment on UDP port 5684,
the COAP over DTLS default port. The TXT RR for this has only an empty string because "rrm", "cose" and
"est" are default for cBRSKI.</t>
<t>As the instance name, the registrar uses in this example the MAC address "0200:0000:7400", which is
MAC address of the interface on which the registrar has the IPv6 address "fda3:79a6:f6ee:0000::0200:0000:6400:0001".
The registrar should know that this MAC address is globally unique (assigned by IEEE). Else it should instead
use its IPv6 address as the Instance Name. For example, if the registrar is just a software application not
knowing the specifics of the hardware it is running on, the MAC address <bcp14>MUST NOT</bcp14> be used. If only mDNS is used
(as in this example), then the IPv6 link-local address would also suffice as the Instance Name.</t>
<t>In this example, a single Instance Name suffices, because BRSKI and cBRSKI are two separate service
contexts: they are distinguished by different protocols: TCP vs. UDP.</t>
<figure title="DNS-SD for a BRSKI registrar supporting RRM and PRM" anchor="dnssd-example-2"><artwork><![CDATA[
0123456789012345678901234567890123456789012345678901234567890123456789
_brski-registrar._tcp.local
IN PTR 0200:0000:7400-rrm._brski-registrar._tcp.local
0200:0000:7400-rrm._brski-registrar._tcp.local
IN SRV 1 2 4555 0200:0000:7400-rrm.local
0200:0000:7400-rrm._brski-registrar._tcp.local IN TXT ""
0200:0000:7400-rrm.local
IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:0001
_brski-registrar._tcp.local
IN PTR 0200:0000:7400-prm._brski-registrar._tcp.local
0200:0000:7400-prm._brski-registrar._tcp.local
IN SRV 1 2 4555 0200:0000:7400-prm.local
0200:0000:7400-prm._brski-registrar._tcp.local
IN TXT "prm" "cmp"
0200:0000:7400-prm.local
IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:0001
]]></artwork></figure>
<t>In the second example <xref target="dnssd-example-2"/>, a registrar needs to use two different Instance Names, because both
share the same service context: BRSKI - TCP with service name brski-registrar. In this example, the registrar
offers "rrm" mode with "cms" voucher and "est" enrollment. It also offers "prm" mode with "cms" voucher,
but (only) with "cmp" enrollment protocol. Because the registrar does not offer "rrm" with "cmp", or
"prm" with "est", it is not possible to coalesce all variations under one Instance Name, so instead, two
Instance Names have to be created, and with them the necessary (duplicate) RR.</t>
<t>Note that the "-rrm" and "-prm" in the Instance Names are only explanatory and could be any mutually unique
strings - as is true for the whole Instance Name.</t>
<t>Note too, that because both Instances share the same port number 4555 (and hence TCP socket), they both have
to be provided by the same BRSKI application. If two separate applications where to be started on the
dame host, one for "rrm", the other for "prm", then they would have separate sockets and hence port numbers.</t>
</section>
</section>
<section anchor="grasp"><name>GRASP</name>
<section anchor="signaling-1"><name>Signaling</name>
<t>This document does not specify a mandatory to implement set of signaling options to guarantee
interoperability of discovery between initiator and responders when using GRASP. Like for the
other discovery mechanisms, these requirements will have to come from other specifications
that outline what in <xref target="GRASP"/> is called the "security and transport substrate" to be used for
GRASP.</t>
<t><xref target="RFC8994"/> specifies one such "security and transport substrate", which is zero-touch deployable.
It is mandatory to support for initiators and responders implementing the so-called
"Autonomic Network Infrastructure" (ANI). DULL GRASP is used for link-local discovery of
proxies, and the ACP is used to automatically and securely build the connectivity for multi-hop discovery
of registrars by proxies.</t>
</section>
<section anchor="encoding-1"><name>Encoding</name>
<t>To announce protocol variations with <xref target="GRASP"/>, the supported Variation is indicated in the
objective-value field of the GRASP objective, using the method of forming the Variation string term
in <xref target="variation"/>, and listed in the Variation String column of the <xref target="fig-variations"/> table.</t>
<t>If more than one Variation is supported, then multiple objectives have to be announced, each with
a different objective-value, but the same location information if the different Variations are
supported across the same socket. Different sockets require different objective structures in GRASP anyhow.</t>
<t>Compared to DNS-SD, the choice of encoding for GRASP optimizes for minimum parsing effort, whereas
the DNS-SD encoding is optimized for most compact encoding given the limit for DNS-SD TXT records.</t>
<figure title="GRASP example for a BRSKI registrar supporting RRM and PRM" anchor="grasp-example-1"><artwork><![CDATA[
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_Proxy", 4, 1, "",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
["AN_Proxy", 4, 1, "prm",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
["AN_Proxy", 4, 1, "",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]
]
]]></artwork></figure>
<t><xref target="grasp-example-1"/> is an example for a GRASP service announcement for "AN_Proxy" in support of BRSKI
with both "rrm" and "prm" supported on the same socket (TCP port number) and for cBRSKI with
COAP over DTLS.</t>
<t>Note that one or more complete service instances (in the example 3) can be contained within a single GRASP message
without the need for any equivalent to the Service Instance Name of the DNS-SD PTR RR or the
Target name of the DNS-SD SRV RR. DNS-SD requires them because its encoding is
decomposed into different RR, but it also intentionally introduces the Service Instance Name
as an element for human interaction with selection (browsing and/or diagnostics of selection),
something that the current GRASP objective-value encoding does not support.</t>
<t>Because this GRASP encoding does not support service instance name, examples such as</t>
<figure title="GRASP example with two different processes" anchor="grasp-example-2"><artwork><![CDATA[
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_Proxy", 4, 1, "",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
["AN_Proxy", 4, 1, "",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]
]
[M_FLOOD, 42310815, h'fe800000000000000000000000000001', 180000,
[["AN_Proxy", 4, 1, "prm",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 44000]]
]
]]></artwork></figure>
<t>In <xref target="grasp-example-2"/>, A separate application process supports "prm" and hence
uses a separate socket, with example TCP port 44000. In this case, there is
no need nor significant benefit to merge all service instance announcements into
a single GRASP message. Instead, the BRSKI-"rrm"/cBRSKI process would be
able to generate and send its own, first, message shown in the example, and the
second process would send its own, second message in the example.</t>
<t>For a more extensive, DNS-SD compatible encoding of the objective-value that also
support Service Instance Names, see <xref target="I-D.eckert-anima-grasp-dnssd"/>.</t>
</section>
</section>
<section anchor="core-lf"><name>CORE-LF</name>
<t>"Web Linking", <xref target="RFC5988"/> defines a format, originally for use with
HTTP headers, to link an HTTP document against other URIs. Web linking is not a standalone
method for discovery of services for use with HTTP.</t>
<t>Based on Web Linking, "Constrained RESTful Environments (CoRE) Link Format", <xref target="CORE-LF"/> introduces a
stand alone method to discover services instances, which are called resources in CORE-LF;
primarily for use with <xref target="COAP"/> but equally for use with, for use with HTTP or any other suitable web transfer protocols.</t>
<t>In CORE-LF, an initiator may use (link-local) IPv6 multicast UDP packet to the COAP port (5683)
to discover a a possible responder for a specifically requested resource. The responder will reply with unicast UDP.
If the IPv6 address of a responder has been configured or is otherwise known to the initiator, it
may equally query the parameters of the desired resource via unicast to the default COAP UDP or
TCP port (5683).</t>
<t>A service such as BRSKI registrar, join proxy or pledge can be considered to be a resource, but it
can equally be broken down into a set of component resources resources, in which case the group
can be requested. As mentioned above, CORE-LF can equally be used to request and discover resources
not using COAP, but any other suitable protocol.</t>
<t><xref target="RFC9176"/> defines a "Resource Directory" mechanism for CORE-LF which is abbreviated CORE-RD. Initiators
can learn the IPv6 address protocol (TCP or UDP) and port numberaof a CORE-RD server by some other
mechanism (such as DNS-SD) and then use a unicast UDP or TCP COAP connection to the CORE-RD server
to discover CORE-LF resources available on other systems. Resource providers can likewise register
their resources with the resource directory server using CORE-RD registration procedures.</t>
<t>In summaery, CORE-LF including CORE-RD is a mechanism for registration and discovery of resources and
hence services which may be preferred in deployments over other options and can equally be applicable
to register/discover any variation of BRSKI for any type of BRSKI service.</t>
<section anchor="signaling-2"><name>Signaling</name>
<section anchor="existing-definitions"><name>Existing definitions</name>
<t><xref target="cBRSKI"/> specifies the use of CORE-LF as a reference methods
for pledges to discover registrars - in the absence of any proxies, to allow deployments
of scenarios where no proxies are needed - and hence also where <xref target="cBRSKI"/>.
is not needed. Because BRSKI is designed so that pledges can be agnostic of whether they connect
to a registrar directly or via a proxy, the resource/service that the pledge needs to discover
is nevertheless called "(brski) join proxy (for pleges)", and encoded in CORE-LF as the value
"brski.jp" for the resource type attribute ("rt=resource-type") according to <xref target="CORE-LF"/>.</t>
<t>The following picture, <xref target="corelf-example-1"/> shows the encoding and an example of this discovery.
"ff02::fd" is the link-local scope address for "All Coap Nodes" in IPv6, as introduced in <xref target="RFC7390"/>,
which also defines IPv6 and site-scoped address options.</t>
<figure title="CORE-LF discovery of registrar/proxy by pledges" anchor="corelf-example-1"><artwork><![CDATA[
Template:
REQ: GET coap://[All_Coap_Nodes_IP_multicast_addr]/.well-known/core?rt=brski.jp
RES: 2.05 Content
<coaps://[Responder_IP_unicast_address]:join-port>; rt="brski.jp"
Example:
REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp
RES: 2.05 Content
<coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp
]]></artwork></figure>
<t><xref target="cPROXY"/> introduces the operations of a CoAP based join proxy
both as a connection based proxy as in <xref target="BRSKI"/> (only using UDP connections for COAPs instead
of TCP for TLS as in <xref target="BRSKI"/>), but also as a new, stateless join proxy - to eliminate the
need for potentially highly constrained join proxy nodes to keep connection state and avoid
the complexity of protecting that state against attacks. The new resource type "brski.rjp" is
defined to support stateless join proxies to discover registrars and their UDP port number
that support the stateless, so-called JPY protocol.</t>
<t>The following picture, <xref target="corelf-example-2"/> shows the encoding and an example of this discovery.
<xref target="cPROXY"/> introduces the new scheme "coaps+jpy" for the packet
header used by the stateless JPY" protocol. The request in the template is assumed to be
based on unicast, relying on another method to discover the IP address of the registrar first.
It could equally use COAP site-scoped IP multicast, but in general, the assumeption is that
registrar will not necessarily be link-local connected to proxies (this may be different in
specific deployments). Even though the registrar IP address is hence known, the reply still
needs to include this address again because in the <xref target="RFC6690"/> link format, and <xref target="RFC3986"/>, Section 3.2, the
authority attribute can not include a port number unless it also includes the IP address.</t>
<figure title="CORE-LF discovery of registrars that support stateless JPY protocll by proxies" anchor="corelf-example-2"><artwork><![CDATA[
Template:
REQ: GET /.well-known/core?rt=brski.jpy
RES: 2.05 Content
<coaps+jpy://[Responder_IP_unicast_address]:join-port>;rt=brski.jpy
Example:
REQ: GET /.well-known/core?rt=brski.jpy
RES: 2.05 Content
<coaps+jpy://[2001:db8:0:abcd::52]:7633>;rt=brski.jpy
]]></artwork></figure>
</section>
<section anchor="new-variation-discovery"><name>New variation discovery</name>
<t>This document expands the above summarized existing CORE-LF definitions from
<xref target="cBRSKI"/> and <xref target="cPROXY"/> as follows.</t>
<t>Discovery of stateful sockets on a registrar uses the resource type "brski.rs" (for