-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-ietf-anima-constrained-join-proxy.txt
1904 lines (1305 loc) · 76.4 KB
/
draft-ietf-anima-constrained-join-proxy.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 Working Group M. Richardson
Internet-Draft Sandelman Software Works
Intended status: Standards Track P. van der Stok
Expires: 20 July 2025 vanderstok consultancy
P. Kampanakis
Cisco Systems
E. Dijk
IoTconsultancy.nl
16 January 2025
Join Proxy for Bootstrapping of Constrained Network Elements
draft-ietf-anima-constrained-join-proxy-16
Abstract
This document extends the constrained Bootstrapping Remote Secure Key
Infrastructures (cBRSKI) onboarding protocol by adding a new network
function, the constrained Join Proxy. This function can be
implemented by a constrained node [RFC7228]. The goal of the Join
Proxy is to help new constrained nodes ("Pledges") securely onboard
into a new IP network using the cBRSKI protocol. It acts as a
circuit proxy for User Datagram Protocol (UDP) packets that carry the
onboarding messages. The solution is extendible to support other
UDP-based onboarding protocols as well. The Join Proxy functionality
is designed for use in constrained networks [RFC7228], including IPv6
over Low-Power Wireless Personal Area Networks (6LoWPAN) [RFC4944]
based mesh networks in which the onboarding authority server
("Registrar") may be multiple IP hops away from a Pledge. Despite
this distance, the Pledge only needs to use link-local UDP
communication to complete cBRSKI onboarding. Two modes of Join Proxy
operation are defined, stateless and stateful, to allow implementers
to make different trade-offs regarding resource usage, implementation
complexity and security.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-join-
proxy/.
Discussion of this document takes place on the anima Working Group
mailing list (mailto:[email protected]), which is archived at
https://mailarchive.ietf.org/arch/browse/anima/. Subscribe at
https://www.ietf.org/mailman/listinfo/anima/.
Richardson, et al. Expires 20 July 2025 [Page 1]
Internet-Draft Join Proxy January 2025
Source for this draft and an issue tracker can be found at
https://github.com/anima-wg/constrained-join-proxy.
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 20 July 2025.
Copyright Notice
Copyright (c) 2025 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Join Proxy Problem Statement and Solution . . . . . . . . . . 6
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6
3.2. Solution . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Forming 6LoWPAN Mesh Networks with cBRSKI . . . . . . . . 8
4. Join Proxy Specification . . . . . . . . . . . . . . . . . . 9
4.1. Mode Implementation and Configuration Requirements . . . 9
4.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Stateful Join Proxy . . . . . . . . . . . . . . . . . . . 11
4.4. Stateless Join Proxy . . . . . . . . . . . . . . . . . . 13
4.5. JPY Protocol and Messages . . . . . . . . . . . . . . . . 15
Richardson, et al. Expires 20 July 2025 [Page 2]
Internet-Draft Join Proxy January 2025
4.5.1. JPY Message Structure . . . . . . . . . . . . . . . . 16
4.5.2. JPY Message Port Usage . . . . . . . . . . . . . . . 17
4.5.3. JPY Message Overhead and MTU Size . . . . . . . . . . 17
4.5.4. JPY Message Security . . . . . . . . . . . . . . . . 17
4.5.5. Example Format for JPY Header Data . . . . . . . . . 18
4.5.6. Processing by Registrar . . . . . . . . . . . . . . . 18
5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Join Proxy Discovers Registrar . . . . . . . . . . . . . 19
5.1.1. Stateless Case . . . . . . . . . . . . . . . . . . . 19
5.1.2. Stateful Case . . . . . . . . . . . . . . . . . . . . 20
5.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 21
5.2. Pledge Discovers Join Proxy . . . . . . . . . . . . . . . 21
6. Comparison of Stateless and Stateful Modes . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8.1. Resource Type Attributes Registry . . . . . . . . . . . . 25
8.2. coaps+jpy Scheme Registration . . . . . . . . . . . . . . 25
8.3. Service Name and Transport Protocol Port Number
Registry . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Stateless Proxy payload examples . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
described in [RFC8995] provides a solution for a secure zero-touch
(automated) bootstrap of new, unconfigured devices. In the context
of BRSKI, new devices, called "Pledges", are equipped with a factory-
installed Initial Device Identifier (IDevID) [ieee802-1AR], and are
enrolled into a network. BRSKI makes use of Enrollment over Secure
Transport (EST) [RFC7030] with [RFC8366bis] signed vouchers to
securely enroll devices. A Registrar provides the trust anchor of
the network domain to which a Pledge enrolls.
[cBRSKI] defines a version of BRSKI that is suitable for constrained
nodes ([RFC7228]) and for operation on constrained networks
([RFC7228]) including Low-Power and Lossy Networks (LLN) [RFC7102].
It uses Constrained Application Protocol (CoAP) [RFC7252] messages
secured by Datagram Transport Layer Security (DTLS) [RFC9147] to
implement the BRSKI functions defined by [RFC8995].
Richardson, et al. Expires 20 July 2025 [Page 3]
Internet-Draft Join Proxy January 2025
In this document, cBRSKI is extended such that a cBRSKI Pledge can
connect to a Registrar via a constrained Join Proxy. In particular,
this solution is intended to support IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPAN) [RFC4944] mesh networks. 6TiSCH
networks are not in scope of this document since these use the CoJP
[RFC9031] proxy mechanism.
The Join Proxy as specified in this document is one of the Join Proxy
options referred to in Section 2.5.2 of [RFC8995] as future work.
However, in IP networks that require node authentication, such as
those using 6LoWPAN [RFC4944], data to and from the Pledge will not
be routable over the IP network before it is properly authenticated
to the network. A new Pledge can initially only use a link-local
IPv6 address to communicate with a mesh neighbor [RFC6775] until it
receives the necessary network configuration parameters.
Before it can receive these parameters, the Pledge needs to be
authenticated and authorized to onboard the
network. This is done in cBRSKI through an end-to-end encrypted DTLS
session with a domain Registrar.
When this Registrar is not a direct (link-local) neighbor of the
Pledge but several hops away, the Pledge needs to discover a link-
local neighbor that is operating as a constrained Join Proxy, which
helps
forward the DTLS messages of the session between Pledge and
Registrar.
Because the Join Proxy is a regular network node that has already
been onboarded onto the network, it can send IP packets to the
Registrar which are then routed over one or more hops over the mesh
network -- and potentially over other IP networks too, before
reaching the Registrar. Likewise, the Registrar sends its response
IP packets which are routed back to the Join Proxy over the mesh
network.
Once a Pledge has enrolled onto the network in this manner, it can
optionally be configured itself as a new constrained Join Proxy. In
this role it can help other Pledges perform the cBRSKI onboarding
process.
Two modes of operation for a constrained Join Proxy are specified:
1. A stateful Join Proxy that locally stores UDP connection state
per Pledge.
Richardson, et al. Expires 20 July 2025 [Page 4]
Internet-Draft Join Proxy January 2025
2. A stateless Join Proxy that does not locally store UDP connection
state, but stores it in the header of a message that is exchanged
between the Join Proxy and the Registrar.
Similar to the difference between storing and non-storing Modes of
Operations (MOP) in RPL [RFC6550], the stateful and stateless modes
differ in the way that they store the state required to forward
return UDP packets from the Registrar back to the Pledge.
2. 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.
The following terms are defined in [RFC8366bis] and [RFC8995], and
are used identically in this document: artifact, Circuit Proxy, Join
Proxy, domain, imprint, Registrar, Pledge, and Voucher.
The term "installation" refers to all devices in the network and
their interconnections, including Registrar, enrolled nodes (with and
without constrained Join Proxy functionality) and Pledges (not yet
enrolled).
(Installation) IP addresses are assumed to be routable over the whole
installation network, except for link-local IP addresses.
The term "Join Proxy" is used in this document with the same
definition as in [RFC8995]. However, in this document it refers
specifically to a Join Proxy that can support Pledges to onboard
using a UDP-based protocol, such as the cBRSKI protocol [cBRSKI].
This protocol operates over an end-to-end secured DTLS session
between a Pledge and a cBRSKI Registrar.
The acronym "JPY" is used to refer to a new protocol and JPY message
format defined by this document. The message can be seen as a "Join
Proxy Yoke": connecting two data items and letting these travel
together over a network.
Because UDP does not have the notion of a connection, the term "UDP
connection" in this document refers to a pseudo-connection, whose
establishment on the Join Proxy is triggered by receipt of a first
UDP packet from a new Pledge source.
The term "endpoint" is used as defined in [RFC7252].
Richardson, et al. Expires 20 July 2025 [Page 5]
Internet-Draft Join Proxy January 2025
The terms "6LoWPAN Router" (6LR), "6LoWPAN Border Router" (6LBR) and
"6LoWPAN link" are used as defined in [RFC6775].
Details of the IP address and port notation used in the Join Proxy
specification are provided in Section 4.2.
3. Join Proxy Problem Statement and Solution
3.1. Problem Statement
As depicted in Figure 1, the Pledge (P), in a network such as a
6LoWPAN [RFC4944] mesh network
can be more than one hop away from the Registrar (R) and it is not
yet authenticated to the network. Also, the Pledge does not possess
any key material to encrypt or decrypt link-layer data transmissions.
In this situation, the Pledge can only communicate one-hop to its
neighbors, such as the constrained Join Proxy (J), using link-local
IPv6 addresses and using no link-layer encryption. However, the
Pledge needs to communicate with end-to-end security with a Registrar
to authenticate and obtain its domain identity/credentials. In the
case of cBRSKI, the domain identity is an X.509 certificate. Domain
credentials may include key material for network access.
multi-hop mesh
.---. IPv6
| R +---. +-----+ +---+ link-local +---+
| | \ | 6LR +----+ J |..............| P |
'---' `--+ | | | | |
+-----+ +---+ +---+
Registrar Join Proxy Pledge
Figure 1: Multi-hop cBRSKI onboarding scenario in a 6LoWPAN mesh
network
So one problem is that there is no IP routability between the Pledge
and the Registrar, via intermediate nodes such as 6LoWPAN Routers
(6LRs), despite the need for an end-to-end secured session between
both.
Furthermore, the Pledge is not be able to discover the IP address of
the Registrar because it is not yet allowed onto the network.
Richardson, et al. Expires 20 July 2025 [Page 6]
Internet-Draft Join Proxy January 2025
3.2. Solution
To overcome these problems, the constrained Join Proxy is introduced.
This is specific functionality that all, or a specific subset of,
authenticated nodes in an IP network can implement. When the Join
Proxy functionality is enabled in a node, it can help a neighboring
Pledge securely onboard the network.
The Join Proxy performs relaying of UDP packets from the Pledge to
the intended Registrar, and relaying of the subsequent return
packets. An authenticated Join Proxy can discover the routable IP
address of the Registrar, as specified in this document. Future
methods of Registrar discovery can also be easily added.
The Join Proxy acts as a packet-by-packet proxy for UDP packets
between Pledge and Registrar. The cBRSKI protocol between Pledge and
Registrar [cBRSKI] which this Join Proxy supports uses UDP messages
with DTLS-encrypted CoAP payloads, but the Join Proxy as described
here is unaware of these payloads. The Join Proxy solution can
therefore be easily extended to work for other UDP-based protocols,
as long as these protocols are agnostic to (or can be made to work
with) the change of the IP and UDP headers
performed by the Join Proxy.
In summary, the following steps are typically taken for the
onboarding process of a Pledge:
1. Join Proxies in the network learn the IP address and UDP port of
the Registrar.
2. A new Pledge arrives: it discovers one or more Join Proxies and
selects one.
3. The Pledge sends a link-local UDP message to the selected Join
Proxy.
4. The Join Proxy relays the message to the Registrar (and port)
discovered in step 1.
5. The Registrar sends a response UDP message back to the Join
Proxy.
6. The Join Proxy relays the message back to the Pledge.
7. Step 3 to 6 repeat as needed, for multiple messages, to complete
the onboarding protocol.
Richardson, et al. Expires 20 July 2025 [Page 7]
Internet-Draft Join Proxy January 2025
8. The Pledge uses its obtained domain identity/credentials to join
the domain network.
To reach the Registrar in step 4, the Join Proxy needs to be either
configured with a Registrar address or needs to dynamically discover
a Registrar as detailed in Section 5.1. This configuration/discovery
is specified here as step 1. Alternatively, in case of automated
discovery it can also happen on-demand in step 4, at the moment that
the Join Proxy has data to send to the Registrar. For step 1, it is
out of scope how a Join Proxy selects a Registrar when it discovers
two or more. That is the subject of future work.
3.3. Forming 6LoWPAN Mesh Networks with cBRSKI
The Join Proxy has been specifically designed to set up an entire
6LoWPAN mesh network using cBRSKI onboarding. This section outlines
how this process works and highlights the role that the Join Proxy
plays in forming the mesh network.
Typically, the first node to be set up is a 6LoWPAN Border Router
(6LBR) which will form the new mesh network and decide on the
network's configuration. The 6LBR may be configured using for
example one of the below methods. Note that multiple methods may be
used within the scope of a single installation.
1. Manual administrative configuration
2. Use non-constrained BRSKI [RFC8995] to automatically onboard over
its high-speed network interface when it gets powered on.
3. Use cBRSKI [cBRSKI] to automatically onboard over its high-speed
network interface when it gets powered on.
Once the 6LBR is enabled, it requires an active Registrar reachable
via IP communication to onboard any Pledges. Once cBRSKI onboarding
is enabled (either administratively, or automatically) on the 6BLR,
it can support
the onboarding of 6LoWPAN-enabled Pledges, via its 6LoWPAN network
interface. This 6LBR may host the cBRSKI Registrar itself, but the
Registrar may also be hosted elsewhere on the installation network.
At the time the Registrar and the 6LBR are enabled, there may be zero
Pledges, or there may be already one or more installed and powered
Pledges waiting - periodically attempting to discover a Join Proxy
over their 6LoWPAN network interface.
Richardson, et al. Expires 20 July 2025 [Page 8]
Internet-Draft Join Proxy January 2025
A Registrar hosted on the 6LBR will, per [cBRSKI], make itself
discoverable as a Join Proxy so that Pledges can use it for cBRSKI
onboarding over a 6LoWPAN link (one hop). Note that only some of
Pledges waiting to onboard may be direct neighbors of the
Registrar/6LBR. Other Pledges would need their traffic to be relayed
by Join Proxies across one or more enrolled mesh devices (6LR, see
Figure 1) in order to reach the Registrar/6LBR. For this purpose,
all or a subset of the enrolled Pledges start to act as Join Proxies
themselves. Which subset is selected, and when the Join Proxy
function is enabled by a node, is out of scope of this document.
The desired end state of the installation includes a network with a
Registrar and all Pledges successfully enrolled in the network domain
and connected to one of the 6LoWPAN mesh networks that are part of
the installation. New Pledges may also be added by future network
maintenance work on the installation.
Pledges employ link-local communication until they are enrolled, at
which point they stop being a "Pledge". A Pledge will periodically
try to discover a Join Proxy using for example link-local discovery
requests, as defined in [cBRSKI]. Pledges that are neighbors of the
Registrar will discover the Registrar itself (which is posing as a
Join Proxy) and will be enrolled first, using cBRSKI. The Pledges
that are not a neighbor of the Registrar will at first fail to find a
Join Proxy. Later on, they will eventually discover a Join Proxy so
that they can be enrolled with cBRSKI too. While this continues,
more and more Join Proxies with a larger hop distance to the
Registrar will emerge. The mesh network auto-configures in this way,
such that at the end of the onboarding process, all Pledges are
enrolled into the network domain and connected to the mesh network.
4. Join Proxy Specification
A Join Proxy can operate in two modes:
1. Stateful mode
2. Stateless mode
The advantages and disadvantages of the two modes are presented in
Section 6.
4.1. Mode Implementation and Configuration Requirements
For a Join Proxy implementation on a node, there are three possible
scenarios:
Richardson, et al. Expires 20 July 2025 [Page 9]
Internet-Draft Join Proxy January 2025
1. Both stateful and stateless modes are implemented. The Join
Proxy can switch between these modes, depending on configuration.
2. Only stateful mode is implemented.
3. Only stateless mode is implemented.
An application profile or ecosystem standard that integrates the Join
Proxy functionality as defined in this document MAY define any of
these three options. In particular, option 2 or 3 has the advantage
of reducing code size and testing efforts, when all devices under the
application profile/standard adhere to the same choice.
A generic Join Proxy that is not adhering to such an application
profile/standard MUST implement both modes.
A cBRSKI Registrar by design necessarily implements the stateful
mode, and it SHOULD implement support for Join Proxies operating in
the stateless mode. The exception case here is a cBRSKI Registrar
that is implemented for a particular dedicated application profile/
standard which specifies only the stateful mode.
If a Join Proxy implements both modes, then it MUST use only the mode
that is currently configured for the network (by a method or profile
outside the scope of this document) or the mode individually
configured for the device. If the mode is not configured, the device
MUST NOT operate as a Join Proxy.
For a Join Proxy to be operational, the node on which it is running
has to be able to talk to a Registrar (exchange UDP messages with
it). Establishing this connectivity can happen fully automatically
if the Join Proxy node first enrolls itself as a Pledge, and then
discovers the Registrar IP address/port and if applicable its desired
mode of operation (stateful or stateless), through a discovery
mechanism (see Section 5). Other methods, such as provisioning the
Join Proxy are out of scope for this document but equally feasible.
Independent of the mode of the Join Proxy, the Pledge first discovers
(see Section 5.2) and selects the most appropriate Join Proxy. From
the discovery result, the Pledge learns a Join Proxy's link-local IP
address and UDP join-port. Details of this discovery are defined by
the onboarding protocol and are not in scope of this document. For
cBRSKI, this is defined in Section 10 of [cBRSKI].
4.2. Notation
The following notation is used in this section in both text and
figures:
Richardson, et al. Expires 20 July 2025 [Page 10]
Internet-Draft Join Proxy January 2025
* The colon (:) separates IP address and port number (<IP>:<port>).
* IP_P denotes the link-local IP address of the Pledge. For
simplicity, it is assumed here that the Pledge only has one
network interface.
* IP_R denotes the routable IP address of the Registrar.
* IP_Jl denotes the link-local IP address of the Join Proxy on the
interface that connects it to the Pledge.
* IP_Jr denotes the routable IP address of the Join Proxy.
* p_P denotes the UDP port used by the Pledge for its onboarding/
joining protocol, which may be cBRSKI. The Pledge acts in a UDP
client role, specifically as a DTLS client for the case of cBRSKI.
* p_Jl denotes the join-port of the Join Proxy.
* p_Jr denotes the client port of the Join Proxy that it uses to
forward packets to the Registrar.
* p_R denotes the server port of the Registrar on which it serves
the onboarding protocol, such as cBRSKI.
* p_Rj denotes the server port of the Registrar on which it serves
the JPY protocol.
* JPY[H( ),C( )] denotes a JPY message, as defined by the JPY
protocol, with header H and content C indicated in between the
parentheses.
4.3. Stateful Join Proxy
In stateful mode, the Join Proxy acts as a UDP circuit proxy that
does not change the UDP payload (called "data octets" in [RFC768])
but only rewrites the IP and UDP headers of each UDP packet it
forwards between a Pledge and a Registrar.
The UDP flow mapping state maintained by the Join Proxy can be
represented as a list of tuples, one for each active Pledge, as
follows:
Local UDP state Routable UDP state Time state
(IP_P:p_P, IP_Jl:p_Jl) <===> (IP_Jr:p_Jr, IP_R:p_R) (Exp-timer)
Richardson, et al. Expires 20 July 2025 [Page 11]
Internet-Draft Join Proxy January 2025
In case a Join Proxy has multiple network interfaces that accept
Pledges, an interface identifier needs to be added on the leftmost
tuple component. If a Join Proxy has multiple network interfaces to
connect to (one or more) Registrars, an interface identifier needs to
be added to the rightmost tuple component. Both of these are not
shown further in this section, for better readability.
The establishment of the UDP connection state on the Join Proxy is
solely triggered by receipt of a UDP packet from a Pledge with an
IP_P:p_P link-local source and IP_Jl:p_Jl link-local destination for
which no mapping state exists, and that is terminated by a connection
expiry timer.
Figure 2 depicts an example DTLS session via the Join Proxy, to show
how this state is used in practice. In this case the Join Proxy
knows the IP address of the Registrar (IP_R) and the default CoAPS
port (P_R = 5684) on the Registrar is used to access cBRSKI
resources.
+------------+------------+-------------+--------------------------+
| Pledge | Join Proxy | Registrar | UDP Message |
| (P) | (J) | (R) | Src_IP:port | Dst_IP:port|
+------------+------------+-------------+-------------+------------+
| ---ClientHello--> | IP_P:p_P | IP_Jl:p_Jl |
| ---ClientHello--> | IP_Jr:p_Jr| IP_R:5684 |
| | | |
| <--ServerHello--- | IP_R:5684 | IP_Jr:p_Jr |
| : | | |
| <--ServerHello--- : | IP_Jl:p_Jl| IP_P:p_P |
| : : | : | : |
| [DTLS messages] | : | : |
| : : | : | : |
| ---Finished--> : | IP_P:p_P | IP_Jl:p_Jl |
| ---Finished--> | IP_Jr:p_Jr| IP_R:5684 |
| | | |
| <--Finished--- | IP_R:5684 | IP_Jr:p_Jr |
| <--Finished--- | IP_Jl:p_Jl| IP_P:p_P |
| : : | : | : |
+---------------------------------------+-------------+------------+
Figure 2: Example of the message flow of a DTLS session via a
stateful Join Proxy.
Richardson, et al. Expires 20 July 2025 [Page 12]
Internet-Draft Join Proxy January 2025
The Join Proxy MUST allocate a unique IP_Jr:p_Jr for every unique
Pledge that it serves. This is typically done by selecting a unique
available port P_Jr for each Pledge. Doing so enables the Join Proxy
to correctly map the UDP packets received from the Registrar back to
the corresponding Pledges. Also, it enables the Registrar to
correctly distinguish multiple DTLS clients by means of IP address/
port tuples.
The default timeout for clearing the state for a Pledge MUST be 30
seconds after the last relayed packet was sent on a UDP connection
associated to that Pledge, in either direction. The default timeout
MAY be overridden by another value that is either configured, or
discovered in some way out of scope of this document.
When a Join Proxy receives an ICMP [RFC792] / ICMPv6 [RFC4443] error
from the Registrar, this may signal a permanent change of the
Registrar's IP address and/or port, or it may signal a temporary
disruption of the network. In such case, the Join Proxy SHOULD send
an equivalent ICMP error message (with same Type and Code) to the
Pledge. The specific Pledge can be determined from the IP/UDP header
information that is contained in the ICMP error message body, if
included. In case the ICMP message body is empty, or insufficient
information is included there, the Join Proxy does not send the ICMP
error message to the Pledge because the intended recipient cannot be
determined.
To protect itself and the Registrar against malfunctioning Pledges
and/or denial of service (DoS) attacks, the Join Proxy SHOULD limit
the number of simultaneous state tuples for a given IP_p to at most
2, and it SHOULD limit the number of simultaneous state tuples per
network interface to at most 10.
When a new Pledge connection is received and the Join Proxy is unable
to build new mapping state for it, for example due to the above
limits, the Join Proxy SHOULD return an ICMP Type 1 "Destination
Unreachable" error message with Code 1, "Communication with
destination administratively prohibited".
4.4. Stateless Join Proxy
Stateless Join Proxy operation eliminates the need and complexity to
maintain per-Pledge UDP connection mapping state on the proxy and the
machinery to build, maintain and remove this mapping state. It also
removes the need to protect this mapping state against DoS attacks
and may also reduce memory and CPU requirements on the proxy.
Richardson, et al. Expires 20 July 2025 [Page 13]
Internet-Draft Join Proxy January 2025
Stateless Join Proxy operations work by introducing a new JPY message
used in communication between Proxy and Registrar. This message will
store the state "in the network". It consists of two parts:
* Header (H) field: contains state information about the Pledge (P)
such as the link-local IP address and UDP port.
* Contents (C) field: the original UDP payload (data octets
according to [RFC768]) received from the Pledge, or destined to
the Pledge.
When the join proxy receives a UDP message from a Pledge, it encodes
the Pledge's link-local IP address, interface ID and UDP (source)
port of the UDP packet into the Header field and the UDP payload into
the Contents field and sends the packet to the Registrar from a fixed
source UDP port. When the Registrar sends packets for the Pledge, it
MUST return the Header field unchanged, so that the join proxy can
decode the Header to reconstruct the Pledge's link-local IP address,
interace and UDP (destination) port for the return UDP packet.
Figure 3 shows this per-packet mapping on the join proxy for a DTLS
session.
The Registrar transiently stores the Header field information. The
Registrar uses the Contents field to execute the Registrar
functionality. When the Registrar replies, it wraps its DTLS message
in a JPY message and sends it back to the Join Proxy. The Registrar
SHOULD NOT assume that it can decode the Header Field of a received
JPY message, it MUST simply replicate it when responding. The Header
of a reply JPY message contains the original source link-local
address and port of the Pledge from the transient state stored
earlier and the Contents field contains the DTLS payload created by
the Registrar.
On receiving the JPY message, the Join Proxy retrieves the two parts.
It uses the Header field information to send a link-local UDP message
containing the (DTLS) payload retrieved from the Contents field to a
particular Pledge.
When the Registrar receives such a JPY message, it MUST treat the
Header H as a single additional opaque identifier of all packets
associated to a UDP connection with a Pledge. Whereas in the
stateful proxy case, all packets with the same 4-tuple (IP_Jr:p_Jr,
IP_R:p_R) belong to a single Pledge's UDP connection, in the
stateless proxy case only the packets with the same 5-tuple
(IP_Jr:p_Jr, IP_R:p_Rj, H) belong to a single Pledge's UDP
connection. The JPY message Contents field contains the UDP payload
of the packet for that Pledge's UDP connection. Packets with
different header H belong to different Pledge's UDP connections.
Richardson, et al. Expires 20 July 2025 [Page 14]
Internet-Draft Join Proxy January 2025
In the stateless mode, the Registrar MUST offer the JPY protocol on a
discoverable UDP port (p_Rj). There is no default port number
available for the JPY protocol, unlike in the stateful mode where the
Registrar can host all its services on the CoAPS default port.
+--------------+------------+---------------+-----------------------+
| Pledge | Join Proxy | Registrar | UDP Message |
| (P) | (J) | (R) |Src_IP:port|Dst_IP:port|
+--------------+------------+---------------+-----------+-----------+
| ---ClientHello---> | IP_P:p_P |IP_Jl:p_Jl |
| ---JPY[H(IP_P:p_P), --> | IP_Jr:p_Jr|IP_R:p_Rj |
| C(ClientHello)] | | |
| <--JPY[H(IP_P:p_P), --- | IP_R:p_Rj |IP_Jr:p_Jr |
| C(ServerHello)] | | |
| <---ServerHello--- | IP_Jl:p_Jl|IP_P:p_P |
| : | : | : |
| [ DTLS messages ] | : | : |
| : | : | : |
| ---Finished---> | IP_P:p_P |IP_Jr:p_Jr |
| ---JPY[H(IP_P:p_P), --> | IP_Jl:p_Jl|IP_R:p_Rj |
| C(Finished)] | | |
| <--JPY[H(IP_P:p_P), --- | IP_R:p_Rj |IP_Jr:p_Jr |
| C(Finished)] | | |
| <---Finished-- | IP_Jl:p_Jl|IP_P:p_P |
| : | : | : |
+-------------------------------------------+-----------+-----------+
Figure 3: Example of the message flow of a DTLS session via a
stateless Join Proxy.
When a Join Proxy receives an ICMP [RFC792] / ICMPv6 [RFC4443] error
from the Registrar, this may signal a permanent change of the
Registrar's IP address and/or port, or it may signal a temporary
disruption of the network.
Unlike a stateful Join Proxy, the stateless Join Proxy cannot
determine the Pledge to which this ICMP error should be mapped,
because the JPY header containing this information is not included in
the ICMP error message. Therefore, it cannot inform the Pledge of
the specific error that occurred.
4.5. JPY Protocol and Messages
JPY messages are used by a stateless Join Proxy to carry required
state information in the relayed UDP messages, such that it does not
need to store this state in memory. JPY messages are carried
directly over the UDP layer. So, there is no CoAP or DTLS layer used
between the JPY messages and the UDP layer.
Richardson, et al. Expires 20 July 2025 [Page 15]
Internet-Draft Join Proxy January 2025
A Registrar that supports the JPY protocol also uses JPY message to
return relayed UDP messages to the stateless Join Proxy, including
the state information that it needs.
4.5.1. JPY Message Structure
Each JPY message consists of one CBOR [RFC8949] array with 2
elements:
1. The Header (H) with the Join Proxy's per-message state data:
wrapped in a CBOR byte string. The state data SHOULD be at most
32 bytes.
2. The Content (C) field: the binary (DTLS) payload being relayed,
wrapped in a CBOR byte string. The payload is encrypted. The
Join Proxy cannot decrypt it and therefore has no knowledge of
any transported (CoAP) messages, or the URI paths or media types
within the CoAP messages.
Using CDDL [RFC8610], the CBOR array that constitutes the JPY message
can be formally defined as:
jpy_message =
[
jpy_header : bstr,
jpy_content : bstr,
]
Figure 4: CDDL representation of a JPY message
The jpy_header state data is to be reflected (unmodified) by the
Registrar when sending return JPY messages to the Join Proxy. The
header's internal representation is not standardized: it can be
constructed by the Join Proxy in whatever way. It is to be used by
the Join Proxy to record state for the included jpy_content field,
which includes the information which Pledge the data in jpy_content
came from.
This state data stored in the JPY message is similar to the "state
object" mechanism described in Section 7.1 of [RFC9031]. However,
since the CoAP protocol layer (if any) is inside the DTLS layer, so
end-to-end encrypted between the Pledge and the Registrar, it is not
possible for the Join Proxy to act as a CoAP proxy per Section 5.7 of
[RFC7252].
Richardson, et al. Expires 20 July 2025 [Page 16]
Internet-Draft Join Proxy January 2025
4.5.2. JPY Message Port Usage
For the JPY messages sent to the Registrar, the Join Proxy SHOULD use
the same UDP source port and IP source address for the JPY messages
sent on behalf of all Pledges.
Although a Join Proxy MAY vary the UDP source port, doing so creates
more local state. A Join Proxy with multiple CPUs (unlikely in a
constrained system, but possible) could, for instance, use different
UDP source port numbers to demultiplex connections across CPUs.
4.5.3. JPY Message Overhead and MTU Size
The use of the JPY message CBOR encoding adds a 3-6 byte overhead on
top of the data carried within the Header and Contents fields. The
Header state data itself (up to 32 bytes) also adds an overhead on
each UDP message exchanged between Join Proxy and Registrar.
Therefore, a protocol using the stateless Join Proxy MUST use (UDP)
payloads that are bounded in size, such that the maximum payload
length used minus the maximum overhead size (38 bytes) stays below
the MTU size of the network. cBRSKI is designed to work even for the
minimum IPv6 MTU of 1280 bytes, by configuring the DTLS maximum
fragment length and using CoAP blockwise transfer for large resource
transfers [cBRSKI].
At the CoAP level, using the cBRSKI [cBRSKI] and the EST-CoAPS
[RFC9148] protocols, the CoAP blockwise options [RFC7959] are often
used to split large payloads into multiple data blocks. The
Registrar and the Pledge MUST select a block size that would allow
the addition of the JPY message structure
without violating MTU sizes.
4.5.4. JPY Message Security
The Join Proxy SHOULD encrypt the state data prior to wrapping it in
a CBOR byte string in jpy_header. It SHOULD be encrypted with a
symmetric key known only to the Join Proxy itself. This key need not
persist on a long-term basis, and MAY be changed periodically.
The Join Proxy MUST maintain identical jpy_header data for all
communications from the same Pledge and same UDP source port. This
implies that the encryption key used either does not change during
the onboarding attempt of the Pledge, or that when it does, it is
acceptable to break any onboarding connections that have not yet
completed.
Richardson, et al. Expires 20 July 2025 [Page 17]
Internet-Draft Join Proxy January 2025
4.5.5. Example Format for JPY Header Data
A typical JPY message header format, prior to encryption, could be
constructed using the following CDDL grammar. This is illustrative
only: the format of the data inside jpy_header is not subject to
standardization and may vary across Pledges.
jpy_header_plaintext = [
family: uint .bits 1,
ifindex: uint .bits 8,
srcport: uint .bits 16,
iid: bstr .bits 64,
]
This results in a total plaintext size of 96 bits, or 12 bytes. The
data structure stores the Pledge's UDP source port (srcport), the IID
bits of the Pledge's originating IPv6 link-Local address (iid), the
IPv4/IPv6 family (as a single bit) and an interface index (ifindex)
to provide the link-local scope for the case that the Join Proxy has
multiple network interfaces. This size fits nicely into a single
AES128 CBC block for instance, resulting in a 16 byte block of
encrypted state data, jpy_header_ciphertext. This
jpy_header_ciphertext data is then wrapped in a CBOR byte string to
form the jpy_header element. So for the example jpy_header_plaintext
of 12 bytes, we get a jpy_header_ciphertext of 16 bytes, and finally
a jpy_header CBOR element of 17 bytes which includes a 1-byte
overhead to encode the data as a CBOR byte string of length 16.
Note: when IPv6 is used only the lower 64-bits of the source IPv6
address need to be recorded,
because they must be by design all IPv6 link-Local addresses, so the
upper 64-bits are just "fe80::" and can be elided. For IPv4, a link-
Local IPv4 address [RFC3927] would be used, and it would always fit
into the 64 bits of the iid field. On media where the Interface
IDentifier (IID) is not 64-bits, a different field size for iid will
be necessary.
A detailed example using this format is shown in Appendix A. (TBD:
update Appendix A example.)
4.5.6. Processing by Registrar
On reception of a JPY message by the Registrar, the Registrar MUST
verify that the number of CBOR array elements is 2 or more. To