BRSKI discovery and variations
draft-ietf-anima-brski-discovery-16
| Document | Type | Active Internet-Draft (anima WG) | |
|---|---|---|---|
| Authors | Toerless Eckert , Esko Dijk | ||
| Last updated | 2026-10-31 | ||
| Replaces | draft-eckert-anima-brski-discovery | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Reviews |
OPSDIR Early review
(of
-13)
by Xiao Min
Has issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-anima-brski-discovery-16
ANIMA T. Eckert, Ed.
Internet-Draft Futurewei
Updates: draft-ietf-anima-brski-prm, rfc6690, E. Dijk
rfc9733 (if approved) IoTconsultancy.nl
Intended status: Standards Track 31 October 2026
Expires: 4 May 2027
BRSKI discovery and variations
draft-ietf-anima-brski-discovery-16
Abstract
This document specifies procedures for variations of the
"Bootstrapping Remote Secure Key Infrastructure" (BRSKI) architecture
of protocols to automatically announce, discover, and select
responders using different discovery mechanisms such as DNS-SD,
GRASP, or CORE-LF. Different variations are not interoperable, so
initiators need to be able to find responders that support the
variation(s) they support. Procedures are defined for BRSKI proxies
that allow proxying of traffic for any current or future variation.
Procedures to discover BRSKI Pledges by their identifier are defined.
Extensibility is provided through a set of IANA registries.
This document updates I-D.ietf-anima-brski-prm, RFC 6690, and RFC
9733.
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 4 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Eckert & Dijk Expires 4 May 2027 [Page 1]
Internet-Draft BRSKI-discovery October 2026
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Scope Limitations . . . . . . . . . . . . . . . . . . . . 8
2.3. Design Rationale . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Simultaneous Deployment of Non-Interoperable
Variations . . . . . . . . . . . . . . . . . . . . . 9
2.3.2. Variation-Agnostic Join Proxies . . . . . . . . . . . 9
2.3.3. Variation Signaling through Discovery Metadata . . . 10
2.3.4. Variation Definition through IANA Registries . . . . 10
2.3.5. Automatic Redundancy and Failover Specification . . . 11
2.3.6. Discovery of Pledges through IDevID . . . . . . . . . 12
2.4. Functional Summary . . . . . . . . . . . . . . . . . . . 12
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Information Model and Registrations . . . . . . . . . . . 13
3.1.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2. Roles and Services . . . . . . . . . . . . . . . . . 14
3.1.3. Service Names . . . . . . . . . . . . . . . . . . . . 14
3.1.4. Variations . . . . . . . . . . . . . . . . . . . . . 14
3.1.5. Variation Types . . . . . . . . . . . . . . . . . . . 15
3.1.6. Variation Type Choices . . . . . . . . . . . . . . . 16
3.1.7. Variation Strings . . . . . . . . . . . . . . . . . . 16
3.1.8. Contexts . . . . . . . . . . . . . . . . . . . . . . 17
3.1.9. Discussion . . . . . . . . . . . . . . . . . . . . . 18
3.1.10. IANA Registry Tables . . . . . . . . . . . . . . . . 19
3.1.10.1. Discovery Mechanisms registry . . . . . . . . . 19
3.1.10.2. Contexts sub-registry . . . . . . . . . . . . . 19
3.1.10.3. Service Names sub-registry . . . . . . . . . . . 20
3.1.10.4. Variation Type Choices sub-registry . . . . . . 20
3.1.10.5. Variations sub-registry . . . . . . . . . . . . 20
3.2. Redundant Discovery and Selection . . . . . . . . . . . . 21
3.2.1. Responder Selection . . . . . . . . . . . . . . . . . 22
3.2.2. Service Announcements . . . . . . . . . . . . . . . . 23
3.2.3. Responder Selection in Proxies . . . . . . . . . . . 24
3.2.4. Protection against malicious service announcements . 25
3.3. Join Proxy Support for Discovery and Variations . . . . . 25
3.3.1. Join Proxy Support for Variations . . . . . . . . . . 25
Eckert & Dijk Expires 4 May 2027 [Page 2]
Internet-Draft BRSKI-discovery October 2026
3.3.2. Join Proxy Operation Modes . . . . . . . . . . . . . 26
3.3.2.1. Direct Connection Mode . . . . . . . . . . . . . 26
3.3.2.2. Best Registrar Selection Mode . . . . . . . . . . 26
3.3.2.3. Proxy in Service Name Only Mode on Registrars . . 28
3.3.2.4. Proxy Mode Discussion . . . . . . . . . . . . . . 28
3.3.3. Extensibility to Non-BRSKI Services . . . . . . . . . 30
3.3.4. Scaling service discovery and selection . . . . . . . 30
3.4. Discoverable BRSKI Pledges . . . . . . . . . . . . . . . 30
3.4.1. BRSKI-PLEDGE context . . . . . . . . . . . . . . . . 31
3.4.2. Service Instance Name . . . . . . . . . . . . . . . . 32
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 34
3.5. Variation signaling and encoding rules for different
discovery mechanisms . . . . . . . . . . . . . . . . . . 37
3.5.1. DNS-SD . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.1.1. Requirements . . . . . . . . . . . . . . . . . . 37
3.5.1.2. Operational considerations . . . . . . . . . . . 38
3.5.1.2.1. DNS Resolver . . . . . . . . . . . . . . . . 38
3.5.1.2.2. DNS Server Redundancy . . . . . . . . . . . . 38
3.5.1.2.3. DNS Server Discovery . . . . . . . . . . . . 39
3.5.1.3. Variation String Encoding . . . . . . . . . . . . 39
3.5.1.4. Service Instance and Host Names . . . . . . . . . 39
3.5.1.5. Examples . . . . . . . . . . . . . . . . . . . . 41
3.5.2. GRASP . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.2.1. Requirements . . . . . . . . . . . . . . . . . . 44
3.5.2.2. Encoding and Examples . . . . . . . . . . . . . . 44
3.5.3. CORE-LF . . . . . . . . . . . . . . . . . . . . . . . 47
3.5.3.1. Overview . . . . . . . . . . . . . . . . . . . . 47
3.5.3.2. Background . . . . . . . . . . . . . . . . . . . 48
3.5.3.3. Specification . . . . . . . . . . . . . . . . . . 50
3.5.3.4. Examples . . . . . . . . . . . . . . . . . . . . 52
3.5.3.5. Resource Type Considerations . . . . . . . . . . 53
3.6. Use of Multiple Discovery Mechanisms . . . . . . . . . . 55
4. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1. Updates to RFC9733 . . . . . . . . . . . . . . . . . . . 55
4.2. Updates to BRSKI-PRM . . . . . . . . . . . . . . . . . . 56
4.3. Updates to RFC6690 . . . . . . . . . . . . . . . . . . . 57
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 57
5.1. Core Parameters . . . . . . . . . . . . . . . . . . . . . 57
5.1.1. Resource Type Link Target Attribute Values . . . . . 57
5.1.2. Target Attributes . . . . . . . . . . . . . . . . . . 58
5.2. Service Names Registry . . . . . . . . . . . . . . . . . 59
5.3. GRASP Objective Names Registry . . . . . . . . . . . . . 59
5.4. BRSKI Discovery Parameters . . . . . . . . . . . . . . . 59
5.4.1. Contexts . . . . . . . . . . . . . . . . . . . . . . 60
5.4.2. Service Names . . . . . . . . . . . . . . . . . . . . 62
5.4.3. Variation Type Choices . . . . . . . . . . . . . . . 65
5.4.4. Variations . . . . . . . . . . . . . . . . . . . . . 67
5.5. BRSKI Well-Known URIs fixes (opportunistic) . . . . . . . 69
Eckert & Dijk Expires 4 May 2027 [Page 3]
Internet-Draft BRSKI-discovery October 2026
6. Security Considerations . . . . . . . . . . . . . . . . . . . 70
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 72
7.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 72
7.2. Change log . . . . . . . . . . . . . . . . . . . . . . . 72
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.1. Normative References . . . . . . . . . . . . . . . . . . 81
8.2. Informative References . . . . . . . . . . . . . . . . . 84
Appendix A. WebPKI derived instance schema . . . . . . . . . . . 86
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document relies on the terminology defined in [BRSKI]. The
following additional terms are also used.
Context: A set of Services for which the same set of variations
applies.
IP, IPv4, IPv6: In this document, IP refers to (inclusively) IPv4 or
IPv6. If a statement applies to only one of the two versions,
then the terms IPv4 or IPv6 are used.
Initiator: A host that uses an IP transport protocol to initiate a
connection or transaction to another host, called the responder.
Initiator socket: A socket, consisting of an initiator's IP address,
protocol (typically UDP or TCP), and protocol port number, from
which the initiator initiates connections or transactions to a
responder.
Objective Name: See Service Name.
Resource Type: See Service Name.
Responder: A host that uses an IP transport protocol to respond to
transaction or connection requests from an initiator.
Responder socket: A socket, consisting of a responder's IP address,
protocol (typically UDP or TCP), and protocol port number, on
which the responder responds to requests of the protocol.
Eckert & Dijk Expires 4 May 2027 [Page 4]
Internet-Draft BRSKI-discovery October 2026
Role: In this document, the functionality of an entity in a
variation of the BRSKI architecture that can act as a responder
and whose supported variations can be discovered. BRSKI roles
relevant to this document include (Join) Registrar, Join Proxy,
and pledge. The IANA registry defined by this document allows
variations to be specified for any role. See also Context.
Socket: The combination of an IP address, an IP protocol that
utilizes a port number (such as TCP or UDP) and a port number of
that protocol.
Service Name: The name for (a subset of) the functionality/API
provided by a discoverable responder socket. This term is
inherited from [DNS-SD], but unless otherwise specified, this
document also uses it for the equivalent element of any other
discovery mechanism. Other mechanisms typically use different
terminology. For example, when [GRASP] is used to discover a
responder socket for BRSKI, the Objective Name carries the
equivalent of the service name. In [CORE-LF], the Resource Type
(rt=) or a target attribute (such as "brski-jp") carries the
equivalent of the service name.
Type: See Variation Type.
Variation: A combination of one variation type choice for each
variation type applicable to the context of a discoverable BRSKI
communication. For example, in the tBRSKI context, a variation is
one choice for "mode", one choice for "enroll", and one choice for
"vformat".
Variation Type: The name for one aspect of a protocol for which two
or more choices exist (or may exist in the future), and whose
choice can technically be combined orthogonally with those of
other variation types. This document defines the tBRSKI variation
types "mode", "enroll", and "vformat".
Variation Type Choice: The name for one of the values that a
particular variation type may have. For example, this document
defines the choices "rrm" and "prm" for the tBRSKI variation type
"mode".
ACP: "An Autonomic Control Plane", [ACP].
BRSKI: "Bootstrapping Remote Secure Key Infrastructure", [BRSKI].
BRSKI-AE: "Alternative Enrollment Protocols in [BRSKI]", [BRSKI-AE].
BRSKI-PRM: "[BRSKI] with Pledge in Responder Mode", [BRSKI-PRM].
Eckert & Dijk Expires 4 May 2027 [Page 5]
Internet-Draft BRSKI-discovery October 2026
cBRSKI: "Constrained Bootstrapping Remote Secure Key Infrastructure
([BRSKI])", [cBRSKI].
COAP: "The Constrained Application Protocol (CoAP)", [COAP].
CORE-LF: "Constrained RESTful Environments (CoRE) Link Format",
[CORE-LF].
cPROXY: "Constrained Join Proxy for Bootstrapping Protocols",
[cPROXY].
DNS-SD: "DNS-Based Service Discovery", [DNS-SD].
EST: "Enrollment over Secure Transport", [EST].
GRASP: "GeneRic Autonomic Signaling Protocol", [GRASP].
GRASP-DNSSD: "DNS-SD Compatible Service Discovery in GeneRic
Autonomic Signaling Protocol (GRASP)",
[I-D.eckert-anima-grasp-dnssd].
JWS-VOUCHER: "JWS signed Voucher Artifacts for Bootstrapping
Protocols", [JWS-VOUCHER].
lwCMP: "Lightweight Certificate Management Protocol (CMP) Profile",
[RFC9483].
mDNS: "Multicast DNS", [mDNS].
SCEP: "Simple Certificate Enrolment Protocol", [RFC8894].
2. Introduction
2.1. Overview
Bootstrapping Remote Secure Key Infrastructure is an architecture of
protocols for automatically and securely enrolling Pledge devices
with an owner's Registrar. It optionally relies on Join Proxies and
Agents to overcome the lack of end-to-end connectivity between
Pledges and Registrars. It also relies on Manufacturer Authorized
Signing Authorities (MASAs) to authenticate or track the ownership of
Pledges, and on Certification Authorities (CAs) to enroll Pledges
into the owner's private PKI.
Eckert & Dijk Expires 4 May 2027 [Page 6]
Internet-Draft BRSKI-discovery October 2026
The BRSKI architecture comprises multiple variations that are not
interoperable with each other, such as its first instance, [BRSKI];
BRSKI with Alternative Enrollment ([BRSKI-AE]); BRSKI with Pledge in
Responder Mode ([BRSKI-PRM]); and Constrained BRSKI ([cBRSKI]). This
lack of interoperability is a direct consequence of the different
market requirements that gave rise to these variations.
Readers are expected to understand the basic protocol machinery of
the BRSKI architecture and the roles of Pledge, Join Proxy, Agent,
Registrar, MASA, and CA. However, this document attempts to explain
all aspects relevant to the discovery problem, so that understanding
the actual protocol details should not be necessary.
Pledges need to discover and select the best interoperable Join Proxy
or Registrar. Join Proxies need to discover all available
Registrars, announce the same protocol variations, and proxy each of
these variations to the appropriate Registrar. Pledges need to be
discoverable by their product identification ("serial number") and
enumerable.
Discovery needs to work with whichever discovery mechanisms are most
easily supported by the network in which the devices are deployed:
[DNS-SD] with mDNS or unicast DNS, the GeneRic Autonomic Signaling
Protocol ([GRASP]), or [CORE-LF], the discovery mechanism used in
networks that rely predominantly on the Constrained Application
Protocol (CoAP).
This document specifies how to meet these requirements. It defines
the discovery, selection, and proxy mechanisms independently of the
encoding used by any specific discovery mechanism, and it defines an
information model, common across discovery mechanisms, that
represents protocol variations and discoverable entities through a
set of IANA registries. These IANA registries allow new variations,
discoverable device types, and discovery mechanisms to be added.
Although this document is specific to BRSKI, many of its mechanisms
may serve as templates for other protocols: resilience and failover
using discovery protocols; signaling of non-interoperable protocol
variations; abstraction of the information model from the encoding
specifics of different discovery mechanisms; and specification of
discoverable entities, variations, and discovery-mechanism-specific
encodings via IANA registries.
Eckert & Dijk Expires 4 May 2027 [Page 7]
Internet-Draft BRSKI-discovery October 2026
2.2. Scope Limitations
Discussion of, or guidelines for, the selection of a discovery
mechanism are outside the scope of this document. Individual RFCs
that specify BRSKI protocol variations do specify a single discovery
mechanism; for example, [BRSKI-PRM] specifies one for DNS-SD. To a
large extent, however, this reflects a decision to limit the scope of
discovery specification in those RFCs. The subject matter is
complex, and there is a risk of repeating the same definitions and
discussions across multiple RFCs that specify variations within the
BRSKI architecture. This is why this document exists.
However, this document does not give recommendations for the
selection of specific discovery mechanisms, because this is highly
dependent on the deployment and use case, and mostly independent of
BRSKI architecture choices. For example, whichever discovery
mechanism is already deployed in a network is most likely also going
to be preferred for further discovery uses.
In the current BRSKI architecture RFCs, discovery of Join Proxies by
Pledges, or of Pledges by Agents, is mostly assumed to happen across
the link layer only. In contrast, discovery of Registrars by Join
Proxies, Agents, or Pledges is mostly assumed to happen across layer
3. For these specifications, discovery of Join Proxies may therefore
rely on a link-local multicast option of the discovery mechanism,
such as mDNS for DNS-SD. The announcement and discovery of
Registrars, however, needs to rely on a layer 3 capable option, such
as SRP/unicast DNS for DNS-SD. These choices are nevertheless
outside the scope of this document, because its definitions do not
need to change based on these transport choices of the discovery
mechanisms. In addition, they are highly deployment-centric, like
the preference for the discovery mechanism itself.
Discovery of instances of CA, MASA, or potentially other future BRSKI
architecture roles is not currently covered by this document, but
could easily be added to the IANA registry tables defined by this
document.
2.3. Design Rationale
This section explains in more detail, with examples, the design
choices of BRSKI architecture discovery and the scope of this
specification. It is aimed at both operators and implementers.
Eckert & Dijk Expires 4 May 2027 [Page 8]
Internet-Draft BRSKI-discovery October 2026
2.3.1. Simultaneous Deployment of Non-Interoperable Variations
As mentioned above, variations are not interoperable. For example,
BRSKI and cBRSKI use different transport stacks: BRSKI uses TLS,
while cBRSKI uses CoAP/DTLS, because memory-constrained devices
already use those protocols and save memory by also relying on them
for bootstrapping.
While implementations for unconstrained devices can support multiple
variations, Pledge vendors will want to implement only those
variation(s) that suit their business goals. Customer networks that
simultaneously use products from different vendors (and market
segments) will therefore need to support different variations at the
same time. This requires a discovery approach in which non-
interoperable variations can coexist and in which each device can
discover peers that support the variation(s) it supports.
For example, one manufacturer of BRSKI Pledges may offer only a
Registrar product supporting BRSKI, which uses [EST] as its
enrollment protocol, whereas another manufacturer may want its
Pledges to support only [BRSKI-AE] with CMP as the enrollment
protocol. Each type of Pledge hence needs to discover a different
Registrar. Third-party Registrars may support multiple or all
variations, but such products may not be viable or may become
available only later.
The ad hoc approach to supporting such variations with existing
discovery mechanisms is to allocate a new, unique, discoverable
"Service Name" for each variation. Such a name is assigned only when
a new variation is specified, and potentially only for the one
discovery mechanism considered most important at that time, in the
hope that all deployments are able and willing to use it.
When another market segment of customers later prefers a different
discovery mechanism, supporting it incurs significant overhead: a
separate specification of the overall discovery procedure details, as
well as the registration of "Service Name" parameters per discovery
mechanism and per variation.
2.3.2. Variation-Agnostic Join Proxies
The second deployment challenge concerns Join Proxies, which are
located in the network between Pledge and Registrar to overcome the
layer 3 connectivity constraints of Pledges. They need to discover
Registrars and announce themselves as Join Proxies to Pledges, and
they need to do so in the presence of variations. Join Proxies
operate only at the transport layer (TCP for BRSKI and UDP for
cBRSKI), so in theory they can proxy the traffic of any current or
Eckert & Dijk Expires 4 May 2027 [Page 9]
Internet-Draft BRSKI-discovery October 2026
future variation. To do so, however, they need to be able to
recognize all current and future variations and to connect a Pledge
to a Registrar that supports the variation(s) requested by the
Pledge.
If variations use unique ad hoc "Service Names", then these "Service
Names" have to be built into or configured on Pledges, which
contradicts the goal of zero-touch deployment.
2.3.3. Variation Signaling through Discovery Metadata
To solve these challenges, BRSKI architecture discovery defines, for
each discovery mechanism and transport option (UDP, TCP), a single
"Service Name" for each discoverable entity (such as a Registrar).
In addition, it defines, for each discovery mechanism, an encoding of
the variation into a unique metadata field of that discovery
mechanism. The string value of this field indicates the variation(s)
and is consistent across all discovery mechanisms.
This design solves both of the deployment challenges described above
for all current and future variations. If a new discovery mechanism
needs to be introduced, it requires a new specification of this
encoding, but no further per-variation work.
2.3.4. Variation Definition through IANA Registries
Variations are combinations of choices for different aspects of the
BRSKI protocol. For example, a BRSKI exchange includes both the
exchange of a voucher ([RFC8366bis]) and an enrollment protocol
operation. The voucher can be formatted using CMS with JSON, COSE,
or JOSE; the enrollment protocol can be a version of [EST], SCEP
([RFC8894]), or another protocol appropriate for the transport stack
(TCP/TLS or CoAP). Voucher format and enrollment protocol are
examples of what this document calls variation types; the specific
format or protocol selected for each is a variation type choice.
Instead of assigning ad hoc variation names whenever they are needed
in deployments, BRSKI architecture discovery defines both the
variation types, such as voucher format and enrollment protocol, and
their values through new IANA registries. It also defines how
variation strings are formed from combinations of variation type
choices.
Eckert & Dijk Expires 4 May 2027 [Page 10]
Internet-Draft BRSKI-discovery October 2026
In addition to registering variations composed of variation type
choices, the IANA registries likewise define all other aspects of
discovery that need to be extensible. This design choice minimizes
the need for future specification and implementation work when
deploying or developing additional variations, in many cases reducing
it to just additional IANA registrations.
2.3.5. Automatic Redundancy and Failover Specification
Automatic resiliency and load sharing are enabled by the use of
discovery mechanisms together with the provisioning of multiple
instances of BRSKI architecture roles, such as Registrars and Join
Proxies. This document specifies the procedures that support load
sharing and (fast) failover upon failure and recovery of redundant
components.
[DNS-SD] is widely deployed, but it is most commonly used in manual
workflows, such as when (human) users browse DNS-SD Service Instance
(Names) through (graphical) user interfaces and select an instance of
a service based on out-of-band criteria ("this printer sounds good").
In BRSKI, selection is meant to be fully automated, for example
performed by the bootstrap code of a Pledge, with no human in the
loop.
Similarly, DNS/DNS-SD libraries are widely available and used, but
predominantly as rather heavyweight code for "desktop" operating
systems. They are less commonly available as lightweight libraries
for the variety of embedded devices targeted by BRSKI, especially
constrained devices or "general-purpose" network equipment such as
Ethernet-connected routers in industrial, enterprise, and service
provider networks.
Third, GRASP and CORE-LF are relatively new discovery mechanisms, for
which little implementation experience and code exist with respect to
automatic redundancy and failover.
For these reasons, this document also describes in detail the
procedures for automatic redundancy and failover. The intent is to
help implementers, to help operators understand the subtleties of
this process, which is important for making BRSKI resilient, and to
achieve implementations that are resilient by failing over
automatically and quickly.
Eckert & Dijk Expires 4 May 2027 [Page 11]
Internet-Draft BRSKI-discovery October 2026
2.3.6. Discovery of Pledges through IDevID
[BRSKI-PRM] requires Pledges to be discoverable on the network. This
specification expands on the details provided in [BRSKI-PRM],
Section 6.2, specifically detailing how to derive the DNS-SD Service
Instance Name from IDevID CommonName fields, using an example of a
recommended IDevID encoding. It also explains why manufacturers need
to document this mapping scheme, so that third parties can develop
BRSKI Agents that discover Pledges using these mechanisms. Finally,
it provides a detailed example.
The procedures for discovering Pledges are documented here only for
DNS-SD, because they rely on the additional (but optional)
functionality of browsing, which is not equally well defined or
explored in other discovery mechanisms. When desired, the IANA
registries introduced by this document can equally be used to add
definitions that support additional discovery mechanisms for this
functionality, assuming additional specifications of the necessary
mechanisms.
2.4. Functional Summary
This document specifies a set of IANA registries for BRSKI discovery.
These registries allow the definition of the attributes that
different discovery mechanisms use to announce and discover the
different BRSKI role responders as well as their variations.
Defining these attributes through registries maximizes consistency
across discovery mechanisms and eases the support of variations
across different discovery mechanisms.
Using the discovery information specified through these registries,
this document specifies the details of selection and failover when
more than one interoperable and available responder is discovered.
These procedures are intended to provide resilience and scalability
of BRSKI services that would not be possible without dynamic
discovery mechanisms.
Finally, this document specifies procedures for Join Proxies to
discover Registrar variations using any discovery mechanism, to
announce them to Pledges, and to connect each Pledge to the
appropriate Registrar based on the variation the Pledge requires.
These procedures allow new protocol variations within the BRSKI
architecture to be introduced without the need to upgrade Join
Proxies.
Eckert & Dijk Expires 4 May 2027 [Page 12]
Internet-Draft BRSKI-discovery October 2026
3. Specification
3.1. Information Model and Registrations
BRSKI architecture discovery is about discovering one or more
instances of responders that support a specific BRSKI architecture
role, and determining whether a responder's variation of BRSKI
protocol options is compatible with, and desired by, the connection
initiator. This section gives the conceptual overview of how this is
achieved.
3.1.1. Summary
The goal of defining an information model, and IANA registration
tables for it, in this section is to make implementing announcement
and discovery of current and future BRSKI architecture variations as
simple as possible. Implementers should not have to painfully work
out which specifications to read, without a central reference for
which mechanisms exist and with possibly inconsistent nomenclature.
Instead, they only need to start with the IANA registration tables
introduced by this document and follow the references from them.
From there, they can easily derive the necessary implementation
steps.
When supporting a new discovery mechanism, the first step is to
understand the basic encoding of BRSKI discovery attributes for that
mechanism. The references for this are listed in the Table 4
registry table. For DNS-SD, GRASP, and CORE-LF, these references
point to sections of this document; for future discovery mechanisms
(or extensions to existing ones), they would point to future
documents.
The next step is to determine, for the discovery mechanism of
interest, the "service name" to use for each of the different roles
(Pledge, Registrar, Join Proxy). This is found in the Table 6
registry table.
The last step is to determine, for each variation of interest, the
Variation String to use in the metadata field of the discovery
mechanism that encodes it. This is found in the Table 8 registry
table.
The remaining tables support the process of adding new variations,
and potentially new BRSKI roles to be discovered, across different
transport stacks for BRSKI in a consistent, backward-compatible
fashion. Implementers do not really need to understand them; they
are only needed by experts, or by new specifications, when adding new
variations through deployment testing and/or additional
Eckert & Dijk Expires 4 May 2027 [Page 13]
Internet-Draft BRSKI-discovery October 2026
specifications. Table 7 defines the vocabulary from which variations
are derived, and Table 5 specifies contexts, which ultimately exist
to allow the same service names to be re-used across disjoint, non-
conflicting communication spaces.
3.1.2. Roles and Services
In this document, a service is a specific functionality provided by a
responder entity to an initiator entity over a responder socket using
a particular transport/security/session stack (such as TCP, UDP,
CoAP, DTLS, TLS, QUIC, ...). The mechanisms of this document enable
initiators to automatically discover responder sockets and to select
one that is interoperable with them.
[BRSKI] defines the roles of pledge, Join Proxy, registrar, and MASA.
[BRSKI-PRM] adds the role of Registrar-Agent. Trust anchor (CA) is a
dependent role required by the BRSKI architecture, provided through
[EST] or other protocols in [BRSKI-AE]. A service is commonly named
after the role of the responder, such as Join Proxy, registrar, or
MASA.
A single entity may implement multiple roles. For example,
registrars often also implement the Join Proxy role, and pledges,
which stop being pledges after enrollment, often then become Join
Proxies. Future BRSKI architecture documents may introduce
additional roles, and many of the definitions in this document should
be extensible to support such additional roles.
3.1.3. Service Names
The role that a responder socket supports is indicated in each
discovery mechanism through an appropriate signaling element.
[DNS-SD] calls this signaling element the Service Name. Because
there is no other equally widely used term for this type of signaling
element across arbitrary discovery mechanisms, this document also
refers to the role signaling element as the Service Name, independent
of the discovery mechanism. IP address, IP transport protocol, and
IP transport protocol port are not part of the Service Name; they are
signaled through discovery-mechanism-specific signaling elements.
3.1.4. Variations
Variations in the BRSKI protocol, such as the choice of message
encoding or of features, could impact interoperability between
initiator and responder. Initiators need to be able to discover and
select responders based not only on the desired role, but also on the
best variation for the initiator.
Eckert & Dijk Expires 4 May 2027 [Page 14]
Internet-Draft BRSKI-discovery October 2026
Variations of a role could be indicated by using a different Service
Name for every variation, but that approach would have two problems:
1. Service Names in different discovery mechanisms are typically not
hierarchical (e.g., not "role.variation"). Relying only on
Service Names would thus require registering every variation as a
separate Service Name in a "flat" name space, and registering it
separately for each discovery mechanism. In addition, the
registry rules of some discovery mechanisms may not look
favorably on the registration of Service Names for such protocol
variations.
2. Whenever a new variation is introduced, all deployed Join Proxies
would need to be configured to also proxy this new variation,
because new Service Names for the same BRSKI role cannot be auto-
discovered by Join Proxies (without additional protocol
mechanisms that would be more complex than the variations
approach). Most Join Proxies, however, should be able to operate
without configuration.
For these reasons, this document introduces the encoding of BRSKI
(role) variations through a secondary signaling element in each
discovery mechanism, enabling Join Proxies to transparently support
any variation of BRSKI role connections for which they support
proxying.
In addition, variations only need to be registered once, in a BRSKI-
specific registry table introduced by this document, rather than once
for each current or future discovery mechanism.
A variation is hence specified as a combination of signaling choices
that a BRSKI connection may use and that affect interoperability
between initiator and responder at the level of message exchange and
encoding.
3.1.5. Variation Types
Today, BRSKI connections can exchange vouchers in one of several
different encoding formats. Independent of that option, a BRSKI
connection may also use different commands (so-called "Endpoints");
today, these depend on whether or not [BRSKI-PRM] is used. Finally,
and also independent of those two options, a BRSKI connection may use
one of several different enrollment protocols.
This document calls these options "Variation Types". The three
variation types above are called "vformat" for the voucher format,
"mode" for the Endpoints used (such as PRM or not), and "enroll" for
the enrollment protocol used.
Eckert & Dijk Expires 4 May 2027 [Page 15]
Internet-Draft BRSKI-discovery October 2026
3.1.6. Variation Type Choices
The actual choices for each of these variation types are called
"Variation Type Choices": "prm" or "rrm" for the variation type
"mode"; "cmsj", "cose", or "jose" for the variation type "vformat";
and "est", "cmp", or "scep" for the variation type "enroll". The
semantics of each Variation Type Choice are described in the Note(s)
column of the Variation Type Choices registry (see Section 5.4.3) and
in the references in its Reference(s) column.
"scep" is an example of the ability of the registry to reserve
values: it is not adopted by any current BRSKI architecture
specification.
3.1.7. Variation Strings
The string name of a variation is formed by concatenating a single
variation type choice for every (necessary) variation type. For
example, "prm-jose" could describe the protocol options used by a
[BRSKI-PRM] connection from Registrar-Agent to registrar, potentially
through a Join Proxy. This string representation of a variation is
called the variation string, and it is used consistently for
signaling across all discovery mechanisms.
In the future, when additional variation types and choices are
introduced, existing variation strings MUST NOT be changed, to allow
full backward compatibility with existing/deployed implementations.
For example, when using BRSKI over UDP, only CoAPS is supported
today, but BRSKI UDP sockets could equally work with QUIC (which runs
on top of UDP). In that case, a new variation type, e.g., "proto",
could be introduced with the variation type choices "coaps" and
"quic". For backward compatibility, "coaps" would then need to be
defined as the default for BRSKI over UDP, which means that existing
variation strings such as "" (for "rrm", "cose", and "est" in cBRSKI)
imply the use of "coaps", whereas the use of QUIC would have to be
indicated explicitly via "quic".
For variation strings to be semantically unambiguous, variation type
choices have distinct names across all variation types, and the order
in which variation type choices are concatenated is the order in
which the variation types are defined in the corresponding registry
table. Hence, new variation types have to be appended to the end of
the list of Variation Types of the Context in the Contexts registry
table (Section 5.4.1).
Eckert & Dijk Expires 4 May 2027 [Page 16]
Internet-Draft BRSKI-discovery October 2026
The fact that a variation name is composed of variation type choices
does not mean that an unspecified variation of (random) variation
type choices can work without new implementation or specification
work, or that it even makes sense. This may or may not be the case.
This is also why this document specifies a registry that explicitly
enumerates all variations that are known to be sufficiently specified
and to work.
For example, [BRSKI-PRM] is indicated through the variation type
value "prm", but it may also require enhancements to the enrollment
protocol used, which is specified by the variation type "enroll",
such as new endpoints in that protocol. The functional semantics
implied by an "enroll" variation type value are thus different in
variations with "prm" than in variations without "prm". Moreover,
[BRSKI-PRM] does not necessarily sufficiently specify these
enhancements for enrollment protocols that were not yet known or
specified when [BRSKI-PRM] was written.
3.1.8. Contexts
Variation strings are defined separately for every group of services
for which the set of variation strings is, or could be, different or
could have different semantics. A group of services for which the
same variation strings are defined is called a Context.
Different lists of variation strings are necessary when services have
different variation types, different variation type values, different
deployed variations, or different defaults for the same variation
type values, and hence different variation strings.
"tBRSKI" is the context covering [BRSKI] connections (which use TCP,
hence the "t") from pledge to Join Proxy or registrar, and from Join
Proxy to registrar.
"cBRSKI" ("c"onstrained BRSKI) is the context covering [cBRSKI]
connections (using UDP) from pledge to Join Proxy or registrar, and
from Join Proxy to registrar.
"BRSKI-PLEDGE" is the context covering pledges that use [BRSKI-PRM],
for connections from Registrar-Agents to pledges. In the future, it
can equally cover, through variations, the discovery of [BRSKI]
pledges for connections to them for other purposes, by introducing
appropriate variation types and values for such additional purposes.
This document does not define variations for different end-to-end
encryption mechanisms. However, the mechanisms described here can
also be used to introduce new, backward-incompatible secure transport
options.
Eckert & Dijk Expires 4 May 2027 [Page 17]
Internet-Draft BRSKI-discovery October 2026
Also, this document does not introduce contexts for the discovery of
BRSKI roles other than those mentioned, such as the discovery of
MASAs by registrars. However, the registries introduced by this
document are defined such that such contexts can also be introduced
later through additional registry entries and specifications.
3.1.9. Discussion
Variations as defined by this document only cover protocol options
that Join Proxies can support transparently, so that the definition
of variations makes Join Proxies automatically extensible.
Other responder selection criteria, such as responder priority or
performance-based selection (called weight in [DNS-SD]), are not
covered by the variation concept, but can be used unchanged in
conjunction with variations. Some selection criteria may also only
work with discovery mechanisms that rely on specific procedures. For
example, network distance to the responder can only be well supported
by discovery mechanisms that support per-hop forwarding between
initiator and responder, such as [GRASP]. All of these criteria work
unchanged with the introduction of variations. Variations are simply
one more selection criterion.
Differences in the supported transport stack of a responder are
typically signaled through a signaling element of the discovery
mechanism: whether TCP, UDP, or another IP transport protocol is
used, and whether the responder uses IP or even another network layer
protocol.
In "sane" services, a change in the transport stack does not imply a
change in the signaled messages and their semantics. For such
services, gateways could transparently proxy from IP to other network
layer protocols and vice versa, or even between TCP and other IP
transport protocols such as SCTP. However, this is out of scope for
this specification.
The procedures specified for constrained BRSKI with a Join Proxy
([cPROXY]) would allow running not only a transport stack of CoAP
over DTLS, but equally any other transport stack over UDP, such as
QUIC. When following the procedures described in this document, this
would not require any changes to the Join Proxy implementation or
configuration. All that would be needed is to introduce appropriate
entries in the registry tables specified in this document (e.g.,
adding a new Variation Type for the transport, with choices such as
"coaps" or "quic").
Eckert & Dijk Expires 4 May 2027 [Page 18]
Internet-Draft BRSKI-discovery October 2026
3.1.10. IANA Registry Tables
This subsection restates and summarizes the information model
introduced above, as it is instantiated in the IANA registry (and
sub-registries) requested by this document, the so-called "BRSKI
Discovery Parameters" registry (Section 5.4).
The detailed requirements for registrations and the initial content
of the registry tables are defined in the corresponding IANA section.
3.1.10.1. Discovery Mechanisms registry
The main Discovery Parameters table (Section 5.4) simply defines the
abbreviations for the discovery mechanisms specified for use with
BRSKI architecture discovery: CORE-LF, DNS-SD, and GRASP. It allows
new discovery mechanisms to be added and tracks where they are
specified, including outside the IETF.
This table is called the "main" table because "BRSKI Discovery
Parameters" is a registry with sub-registries, and one table has to
be associated with the registry itself rather than with a sub-
registry.
3.1.10.2. Contexts sub-registry
The IANA "Contexts" sub-registry (Section 5.4.1) registers names for
different groups of services in the overall BRSKI architecture:
tBRSKI for [BRSKI] Registrar->Proxy->Pledge, cBRSKI for constrained
BRSKI ([cBRSKI] / [cPROXY]) Registrar->(Proxy)->Pledge, and BRSKI-
PLEDGE for [BRSKI-PRM] discovery of pledges.
Grouping services allows registrations/definitions in other registry
tables to be limited to these Contexts, instead of repeating them for
every service (for example, Registrar, Stateless-Registrar, and
Proxy).
Distinguishing tBRSKI from cBRSKI is also necessary so that the
different Transport Stack parameter(s) of the two can be
appropriately included in the registries (see Section 5.4.2).
The Contexts sub-registry also registers the list of Variation Types
defined for each context. The Variation Types are the different
aspects of the BRSKI protocols for which different choices have been,
or could be, specified.
Eckert & Dijk Expires 4 May 2027 [Page 19]
Internet-Draft BRSKI-discovery October 2026
3.1.10.3. Service Names sub-registry
The IANA "Service Names" sub-registry (Section 5.4.2) registers the
"Service Names" used to discover the different BRSKI services for
each context and discovery mechanism. It also specifies the
necessary (Transport Stack) Parameters that need to be used in the
discovery mechanism to indicate the service (i.e., to discover it, or
to recognize it in discovery replies). In the initial table, as
specified by this document, this is primarily used to distinguish
tBRSKI services, which use TCP, from cBRSKI services, which use
CoAPS, represented as UDP in some discovery mechanisms (such as DNS-
SD).
3.1.10.4. Variation Type Choices sub-registry
The IANA "Variation Type Choices" sub-registry (Section 5.4.3) builds
on the definition of Variation Types in the Contexts sub-registry
(Section 5.4.1): it defines the specified choices for each Variation
Type and registers the specification(s) in which they are defined.
Variation Type Choices are registered per Context, so that different
Contexts can have different specifications (and hence procedures) for
the same Variation Type. In the initial registry content requested
by this document, this is used to refer to the separate
specifications for tBRSKI variations and cBRSKI variations.
3.1.10.5. Variations sub-registry
The IANA "Variations" sub-registry (Section 5.4.4) registers the so-
called "Variation String" encoding of variations of BRSKI protocol
services for each Context. This is ultimately the encoding specified
by this document for signaling, across all discovery mechanisms, the
actual Variations supported by a Service Instance. This sub-registry
depends on the definitions in the preceding registry tables, which is
why it is described last.
A Variation is a combination of one Variation Type Choice for every
Variation Type. Effectively, it describes one way in which a
particular BRSKI service can operate. The Variation Types specified
in this document are "mode", "vformat" (voucher format), and "enroll"
(enrollment protocol). With these, it is possible to specify
Variations with different overall procedures. "mode" can be "rrm",
indicating the pledge-driven progression of BRSKI (as in [BRSKI] and
[cBRSKI]), or "prm", as specified in [BRSKI-PRM]. "vformat" specifies
one of the possible encoding options for the voucher exchanged in
BRSKI, and "enroll" specifies the enrollment protocol. The
enrollment protocol is logically separate from BRSKI, but is in
practice included in BRSKI. So far, in most cases, it shares the
Eckert & Dijk Expires 4 May 2027 [Page 20]
Internet-Draft BRSKI-discovery October 2026
secure connection between Pledge and Registrar. It is also an
interoperability requirement between Registrar and Pledge: both need
to support the same encoding for a BRSKI exchange to complete
successfully.
Some Variation Type Choices may actually impact other Variation
Types. For example, "prm" also impacts details of the enrollment
protocol, and [BRSKI-PRM] accordingly specifies how [EST] ("enroll" =
"est") needs to be modified to operate with "prm". For this reason,
the Variations sub-registry only lists Variations that are explicitly
specified somewhere as being a working combination of Variation Type
Choices, instead of simply permitting implementations to announce all
Variation Type Choices separately and hoping that any combination
actually works.
Variations are encoded as Variation Strings, which are formed by
concatenating the Variation Type Choice strings with "-", leaving out
those Variation Type Choices that are the "Default" (Dflt in the sub-
registry). This encoding scheme allows old Variation Strings to
remain unchanged when new Variation Types are introduced in a
backward-compatible fashion. The backward-compatible choice for a
new Variation Type is marked as "Dflt", and hence does not need to be
included in the Variation String. Pre-existing Variation Strings
without the new Variation Type can therefore continue to exist and be
used without changes.
3.2. Redundant Discovery and Selection
The following subsections describe requirements for resilient and
scalable responder selection. Resilience is supported by
automatically selecting the currently best available responder.
Scalability of simultaneous sessions is supported by distributing the
connections from multiple initiators across different responders, if
so desired, through operator configuration of the discovery mechanism
parameters.
At the time of writing of this specification, the relevant initiators
are BRSKI pledges, Join Proxies, and Registrar-Agents, and the
relevant responders are Join Proxies and BRSKI Registrars.
Nevertheless, the rules defined in this document can equally apply to
other BRSKI connections if and when discoverable and redundant
services are desired and added to the registries created by this
document, for example, discovery of MASAs by BRSKI Registrars.
Note that this specification does not mandate support for specific
discovery mechanisms in BRSKI implementations, because this is
specific to the target deployment scenarios - hence the option to
support different discovery mechanisms.
Eckert & Dijk Expires 4 May 2027 [Page 21]
Internet-Draft BRSKI-discovery October 2026
Note that while pledges are discoverable using the mechanisms of this
document, this section and its subsections do not apply to the
discovery of pledges. There is no redundancy involved, and pledges
are selected only by their ID, not by their supported variation.
3.2.1. Responder Selection
If more than one responder is discovered by an initiator, then the
initiator SHOULD be able to sequentially attempt to connect to each
feasible responder exactly once until it successfully connects to
one. If it fails to connect to any feasible responder, the initiator
SHOULD wait until at least 30 seconds have elapsed since the start of
the last round before it restarts connection attempts. Before
restarting, it SHOULD also update its discovered responder
information from the discovery mechanism, if the chosen discovery
mechanism does not already do this automatically.
A responder is feasible if it supports one or more of the variations
requested by the initiator.
The order in which connections to responders are attempted is derived
from two criteria: preference and weight.
Preference order is foremost determined by the initiator's preference
across the variations supported by the responder. Within the set of
responders with the same preference by the initiator because of their
variation, the preference is further determined by discovery-
mechanism-specific preference parameters, such as the "priority"
parameter in DNS-SD, or possible future distance parameters in
discovery mechanisms like GRASP.
If a responder socket offers more than one variation supported by the
initiator, its preference order is derived from the most preferred of
these variations.
Within a set of two or more responders with the same preference, the
initiator MUST pick at random, especially after power-on or other
reboot events. This ensures that those events have a chance to
overcome possible persistent problems that would arise from
persistently choosing the same first responder. If deployments
desire reproducible and predictable ordering of connection attempts
by initiators, then they have to use the discovery-mechanism-specific
mechanisms, such as a different "priority" parameter for each
responder in DNS-SD, to create such a strict ordering across the
different responders.
Eckert & Dijk Expires 4 May 2027 [Page 22]
Internet-Draft BRSKI-discovery October 2026
Initiators SHOULD take discovery-mechanism-specific weighting, such
as the "weight" parameter in DNS-SD, into account when determining
the order of responders with the same preference.
Implementations of the resilient responder selection described so far
SHOULD support selection among at least 4 and no more than 10
responders with one or more supported variations for each supported
IP address family (IPv4 and/or IPv6). If more responders are
discovered for the preferred variation(s) of the initiator, then it
SHOULD pick a random subset of those responder announcements to
select from.
Four responders for a specific variation are a typical minimum
resilience setup in a larger network, in which two responders provide
redundancy at the responder host level, and the other two provide
redundancy against network connectivity failures to the first two.
Intra-DC and inter-DC service redundancy is a simple example of such
a setup.
3.2.2. Service Announcements
Responder selection as described in Section 3.2.1 needs to deal with
unresponsive responders, because service announcements may be stale.
This happens when service announcements only loosely track the
aliveness of a service process.
In typical implementations, service announcements may be activated
when the service process starts, and stopped when it stops. Problems
such as a hanging (unresponsive) service process will not be
reflected in the service announcements. In addition, caching of
service announcements, such as through the DNS TTL field, is a
further possible cause of incorrectly assuming service aliveness.
Only actual connection probing or similar tracking can determine
whether a service responder is responsive to the level of accepting
connections.
Responders intended to be used in resilient deployments SHOULD
therefore ensure that their service announcements are not active when
the responder has died or has failed to successfully accept
connections for 120 seconds or more. This can be implemented, for
example, by connection probing once every 30 seconds and withdrawing
the service announcements when probing fails, or by other forms of
tracking the responsiveness of the responder functionality.
The better service announcements indicate the actual aliveness of
service instances, the faster service selection will be. In
addition, in large networks, backup/standby service instances can
then be implemented by tracking primary service announcements and
Eckert & Dijk Expires 4 May 2027 [Page 23]
Internet-Draft BRSKI-discovery October 2026
activating the backup only when the primary ones fail. Such dynamic
backup can further reduce the overall load on the discovery mechanism
used and on initiators.
3.2.3. Responder Selection in Proxies
Unless amended by the requirements listed below, proxies SHOULD
follow all of the descriptions in Section 3.2.1. Note that the
random selection of responders with the same preference also applies
to stateful proxies, and ensures load balancing (including weighting)
across multiple simultaneously connecting pledges.
Stateful proxies SHOULD optimize the selection of responders for each
variation across connections from multiple pledges. This avoids
restarting the sequence of responders to try from the highest
precedence for every newly connecting pledge, which would repeatedly
run into timeouts for each newly connecting pledge when those primary
responders time out on connection attempts because they are
unresponsive or unreachable. Instead, after a responder first fails
to connect, the Join Proxy SHOULD skip this responder in further
connection attempts for other connecting pledges.
Stateless proxies cannot learn of the unresponsiveness or
unreachability of a responder through connection attempts. Instead,
they SHOULD perform a stateless responsiveness/reachability check for
each responder to which the Join Proxy is actively forwarding packets
from one or more pledges. If no packets are returned from such a
responder for more than 30 seconds, then the responder SHOULD be
considered unreachable for at least 180 seconds. Unreachability
signaling received in response to packets sent to the responder
SHOULD trigger this unreachability status if it persists for 10
seconds.
Load balancing as described in Section 3.2.1 is NOT RECOMMENDED for
stateless proxies, because per-pledge stateless load balancing may
involve more processing complexity than is feasible for proxies on
constrained devices. To avoid changing the selection of active
responders when one responder becomes unresponsive, a "stable hash"
approach would have to be used, such as described in [HRW98], which
is used, for example, by [RFC9722]. Supporting weights with
stateless proxying is even more complex. Instead of relying on load
balancing, responders simply need to be designed to scale to the
maximum number of simultaneous initiator connections necessary when
supporting stateless proxying mode.
Eckert & Dijk Expires 4 May 2027 [Page 24]
Internet-Draft BRSKI-discovery October 2026
3.2.4. Protection against malicious service announcements
Responders, including Join Proxies announcing their own responder
sockets, SHOULD always announce the most preferred priority and
weight parameters possible in the discovery mechanism used that still
allow the desired preference goals to be met. For example, in DNS-
SD, a primary responder should announce the numerically lowest
priority value (0) and the highest weight value possible ([RFC2782]).
This recommendation is intended as protection against erroneous, but
not malicious, service announcements whenever the default priority is
less preferred than the most preferred priority. It can also serve
as weak protection against malicious announcements, because with the
selection rules required by this document, initiators still have the
highest chance of picking the non-malicious announcement.
While weak, this recommendation can still be better than nothing
against such malicious announcements. These recommendations SHOULD
be superseded by better recommendations for more narrowly scoped
deployment scenarios.
3.3. Join Proxy Support for Discovery and Variations
3.3.1. Join Proxy Support for Variations
A Join Proxy compliant with this specification MUST support
announcing its Join Proxy responder socket(s), to which pledges can
connect, via at least one of the discovery mechanisms included in the
registry tables specified in this document. The Join Proxy MUST
announce the variation(s) supported on its responder socket(s)
according to the registry table entries.
A Join Proxy SHOULD support passing packets for any variation for
which it has discovered one or more registrar sockets supporting that
variation, without the variation needing to be known at the time the
Join Proxy is implemented, or configured on the Join Proxy. A Join
Proxy that meets this requirement is said to support "arbitrary
variations". Meeting this requirement requires the Join Proxy to
discover registrar(s) and their supported variation(s) via one or
more of the discovery mechanisms included in the registry tables
specified in this document.
Support for arbitrary variations allows proxies to be deployed once,
and pledges and registrars supporting new variations to be added
later, without upgrading or reconfiguring the proxies.
Eckert & Dijk Expires 4 May 2027 [Page 25]
Internet-Draft BRSKI-discovery October 2026
Every Variation has exactly one Variation String, with one exception
for backward compatibility with [BRSKI]: the GRASP objective
AN_join_registrar uses the objective-value "EST-TLS" for the
Variation String "" in the tBRSKI context (see Note (1) of Table 8).
A Join Proxy MUST treat an AN_join_registrar objective-value of "EST-
TLS" as the Variation String "". All other Variation Strings are
compared as they are, and announced unchanged.
3.3.2. Join Proxy Operation Modes
Proxies may use different approaches to connect to registrars. The
following subsections discuss the most relevant options.
3.3.2.1. Direct Connection Mode
In one Join Proxy implementation option, called "direct connections",
the Join Proxy creates a separate Join Proxy responder socket for
every discovered registrar socket. It announces this socket with the
same set of parameters that it learned from the registrar's service
announcement, except for the appropriate Join Proxy service name and
socket parameters (IP address, port number). When a pledge connects
to that socket, the Join Proxy passes traffic for that pledge's
connection to and from the respective registrar socket.
When using the direct connections approach, the task of selecting the
best registrar socket for a particular variation is left to pledges.
They are exposed to at least as many service announcements from
proxies as proxies see from registrars, and the pledge has to select
the best available one among them.
Proxies using direct connections SHOULD limit the number of registrar
sockets they map to the 4 to 10 best registrar sockets per variation,
as described in Section 3.2.1. This reduces the number of sockets
that these proxies have to announce, and also the number of responder
sockets that they need to maintain.
3.3.2.2. Best Registrar Selection Mode
In the implementation mode "best registrar selection", the Join Proxy
creates one separate responder socket for each set of discovered
registrar sockets that announce support for the same set of
variations.
For pledges to discover the Join Proxy, the Join Proxy then announces
this socket with the parameters of the best discovered registrar
socket. As in the case of a direct connection, it replaces the
service name and network parameters with those of its Join Proxy
responder socket.
Eckert & Dijk Expires 4 May 2027 [Page 26]
Internet-Draft BRSKI-discovery October 2026
When the Join Proxy receives a connection on that socket, it then
connects the pledge to the best available registrar socket from that
set.
When performing best registrar selection for that connection, the
Join Proxy has to select the best available responder as described in
Section 3.2.1.
Stateless proxies supporting best registrar selection must use newly
discovered responders carefully. Consider the following common case.
Service announcements for a primary responder stopped due to network
issues, and the Join Proxy then started to send packets to a
secondary responder. Then the primary responder becomes reachable
again, and the Join Proxy sees service announcements for it. If the
Join Proxy now started to forward packets from pledges to this
primary responder because of its higher precedence, this could
unnecessarily break ongoing connections from clients whose packets
are currently forwarded to the lower-preference responder. Direct
connection mode does not incur this problem, because the pledge can
select another Join Proxy responder socket when it discovers the
first one to be unresponsive or erroneous.
A stateless Join Proxy SHOULD hence only replace a selected responder
with a better one if no packets have been exchanged between pledges
and the currently selected responder through the Join Proxy for more
than 300 seconds. This long timeout is specifically intended to
avoid breaking connections in which the registrar keeps the pledge
waiting for an administrative response, such as an operator
performing a policy validation for enrollment.
In addition, stateful proxies implementing best registrar selection
SHOULD optimize the selection of registrars for each Join Proxy
responder socket across connections from multiple pledges. This
avoids restarting the sequence of responders to try from the highest-
precedence registrar for every newly connecting pledge, which would
repeatedly run into timeouts when one or more of the best registrars
time out on connection attempts because they are unresponsive or
unreachable. Instead, after a responder first fails to connect, the
Join Proxy SHOULD skip this responder in further connection attempts
for other connecting pledges. It SHOULD reconsider it for new
connection attempts only after at least 60 seconds.
Eckert & Dijk Expires 4 May 2027 [Page 27]
Internet-Draft BRSKI-discovery October 2026
3.3.2.3. Proxy in Service Name Only Mode on Registrars
Registrars that support connections from stateful proxies and/or from
pledges may minimize their Join Proxy implementation work. They can
simply announce the same socket with the appropriate service names
for both types of connections: as a registrar for connections from
proxies, and as a Join Proxy for connections from pledges. No
additional sockets or other Join-Proxy-specific packet processing
code are required to support this.
Registrars that support connections from stateless proxies can share
that implementation for connections from pledges by also implementing
a simple UDP<->JPY header conversion (see [cPROXY]). However, they
need to do this via a separate socket, and hence need to announce the
two sockets separately. For connections from pledges, they announce
UDP with the Join Proxy service name. For connections from stateless
proxies, they announce UDP with the JPY header and the stateless
registrar service name.
Proxy functionality implemented on registrars as described here is
called "proxy in service name only mode", because such an
implementation cannot discover, select, and fail over between
different registrars. Such proxies in name only therefore do not
share the requirements regarding the discovery and selection of
registrars described for the previously specified modes.
Like other proxies, proxies in name only SHOULD nevertheless track
the aliveness of their registrar function and withdraw their service
announcements (both as Join Proxy and as registrar) when it is not
running, fails, or becomes unresponsive.
Proxies in name only SHOULD default to the same discovery mechanism
priority and weight parameters as those configured for the registrar
service announcements. This ensures that, in the absence of separate
proxies in the network, the selection of registrars via co-located
proxies follows the same criteria as those used by proxies that rely
on the registrar service announcement parameters.
3.3.2.4. Proxy Mode Discussion
This document defines no requirements regarding the implementation
mode of proxies. These are left to solution or deployment (profile)
specifications. Instead, this section discusses some considerations
for these choices.
The list of modes presented is exemplary and not meant to be
exhaustive. Other modes, such as mixtures of the described modes,
are equally able to meet the requirements. Likewise, new variations
Eckert & Dijk Expires 4 May 2027 [Page 28]
Internet-Draft BRSKI-discovery October 2026
may be introduced not only through arbitrary variation support in
proxies, but also through explicit configuration of variations on
proxies; this all depends on the target deployment environment. The
presented modes were chosen primarily because they provide the most
configuration-free deployment options and the greatest implementation
simplicity for registrars.
If a deployment has a larger number of service announcements and
(extremely) constrained pledges, direct connection mode may be
inappropriate, because it shifts the burden of discovering and
selecting the best available registrar onto the pledge. If, at the
same time, the proxies in such deployments can support more scalable,
complex implementations, then best registrar selection mode may be
most appropriate.
In environments where all pledges are expected to become proxies
after enrollment, implementers may simply want to implement the
option for which pledge and Join Proxy code together are easiest to
implement.
Even on registrars, proxy in service name only mode may not meet
deployment requirements or provide the best redundancy. For example,
the co-located registrar may incur problems that do not apply to
alternative registrars, such as Internet connectivity problems to
MASAs when different registrars have different Internet connectivity.
The Join Proxy co-located with the registrar may then still be the
only Join Proxy available to some candidate pledges. In that case,
this Join Proxy needs to be able to connect to an alternative
registrar, which would not be possible if it were a proxy in service
name only.
Likewise, proxy in service name only mode will hinder the
introduction of new variations on pledges and other registrars in the
network in the following case: the registrar node implementing proxy
in service name only mode becomes a necessary Join Proxy for a pledge
that requires a variation not supported by this registrar, but by
another registrar that is only reachable through this registrar node.
Therefore, Join Proxy in name only mode is best suited for node types
that are not deployed at an edge of the network to which a future
variety of pledges may connect. At such edges, those pledges will
require the use of a Join Proxy.
Eckert & Dijk Expires 4 May 2027 [Page 29]
Internet-Draft BRSKI-discovery October 2026
3.3.3. Extensibility to Non-BRSKI Services
Join Proxy implementations using the procedures described in this
document can easily be reused for any protocols other than BRSKI, as
long as they use TCP or UDP. This simply requires that the Join
Proxy can be configured with pairs of service names other than those
used by tBRSKI/cBRSKI: a service name to discover, and a service name
to use for the service announcements of the Join Proxy responder
socket.
3.3.4. Scaling service discovery and selection
Discovering and selecting an available service instance can become a
design challenge in large networks with many redundant service
announcements.
Consider, for example, the common case of allowing BRSKI enrollment
in a network with many geographically spread-out sites, such as in
enterprise, industrial, or building construction environments.
During the initial bring-up of such sites, Internet connectivity may
be non-existent or intermittent, and hence one or more local
registrars in each such site are highly desirable. Such registrars
may of course require private mobile network connectivity to the
MASA, or rely on out-of-band provisioning of vouchers.
Later, when such a site gets a well-working wide-area network
connection, it may be more appropriate to use more centralized
registrars, but a local registrar may still be considered useful as a
backup. However, the service announcements of such decentralized
per-site registrars might then be discoverable across the whole
geographically spread-out network. This could introduce potentially
significant overhead to the service announcement and discovery
system, for example when more than 100 registrar service
announcements exist in the network and pledges/proxies connect to
them.
Such a large number of redundant service announcements is typically
highly undesirable, and appropriate configurations of the service
discovery mechanisms need to be used to avoid them. For example, in
GRASP, service announcements can be scoped to small hop counts.
Alternatively, anycast addressing can be used to make all
decentralized registrars share the same IP address, and hence the
same service announcement.
3.4. Discoverable BRSKI Pledges
Eckert & Dijk Expires 4 May 2027 [Page 30]
Internet-Draft BRSKI-discovery October 2026
3.4.1. BRSKI-PLEDGE context
BRSKI-PLEDGE is the context for the discovery of pledges by nodes
such as Registrar-Agents. Pledges supporting [BRSKI-PRM] MUST
support it. It may also be used by other variations of the BRSKI
architecture outside of the PRM use case, for example, for
inventorying pledges.
Pledges supporting BRSKI-PLEDGE MUST support DNS-SD for discovery via
mDNS, using link-local scope. For DNS-SD discovery beyond link-local
scope, pledges MAY support DNS-SD via [DNSSD-SRP], using automatic
discovery of the SRP server and registering the DNS-SD data defined
below with it.
These DNS-SD requirements are defaults. Specifications for specific
deployment contexts, such as specific types of radio mesh network
solutions, may need to specify their own requirements that override
or amend these requirements.
Pledges MUST be discoverable via their DNS-SD service instance name.
Pledges SHOULD be discoverable via DNS-SD browsing, so that
Registrar-Agents can find unexpected pledges, or can more easily
enumerate expected pledges, especially in the presence of multiple
different subnets and the use of mDNS. If the owner cannot acquire
the serial-number information of a pledge by the time BRSKI-PRM needs
it (to create a service instance name), the pledge can only be found
by browsing.
When pledges are discoverable via DNS-SD browsing, the "_brski-
pledge" PTR service name is a so-called shared resource record. When
it is requested via mDNS (multicast), all pledges supporting BRSKI-
PLEDGE and browsing will respond simultaneously, potentially creating
congestion/contention. To avoid this, [mDNS] specifies the following
requirement: "each responder SHOULD delay its response by a random
amount of time selected with uniform random distribution in the range
20-120 ms."
It is likewise RECOMMENDED to apply the same random delay rule to
answers to multicast or flooded queries in other discovery mechanisms
that have the same response burst problem, even when they do not
specify such a mechanism themselves, such as GRASP.
Eckert & Dijk Expires 4 May 2027 [Page 31]
Internet-Draft BRSKI-discovery October 2026
If a pledge does not want to support browsing, it simply does not
respond to queries for the "_brski-pledge" service name in mDNS, or
to queries for the equivalent service name in other discovery
mechanisms. When using unicast DNS-SD via [DNSSD-SRP], it does not
register its PTR RR for this service name. This does not affect
operations for the service instance name.
This specification does not introduce procedures to discover pledges
via CORE-LF or GRASP, because it is unclear whether there is
currently demand for this, and because it can easily be added via
additional specifications and registry entries. For CORE-LF,
browsing of entries can be supported via CORE-RD ([RFC9176]), with
appropriate auto-discovery of the CORE-RD server. For GRASP, this
could be done via a method mapping DNS-SD into GRASP, such as
[I-D.eckert-anima-grasp-dnssd], specifically to support browsing of
pledge instance names.
3.4.2. Service Instance Name
The service instance name chosen by a BRSKI pledge MUST be composed
of information that is
* easily known by BRSKI operations, such as operational personnel or
software automation, specifically sales integration backend
software; and
* available to the pledge software itself, for example, by being
encoded in some attribute of the IDevID.
Typically, a customer will know the serial number of a product from
sales information, or even from bar codes/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
potentially (although unlikely) lead to (duplicate) replies from two
or more pledges with the same serial number, such as in the following
cases:
1. A manufacturer has different product lines and re-uses serial
numbers across them.
2. Two different manufacturers use the same serial-number space.
If pledges enable browsing of their service instance name, they MAY
support the procedures specified by DNS-SD to create unique service
instance names when they discover such clashes. These procedures
append a space and a number, starting with 2, to the service instance
name: "<service-instance-name> (2)", as described in [DNS-SD],
Appendix D.
Eckert & Dijk Expires 4 May 2027 [Page 32]
Internet-Draft BRSKI-discovery October 2026
Nevertheless, this approach to resolving conflicts is not desirable:
* If browsing of DNS-SD service instance names is not supported,
Registrar-Agents would always have to (mostly wrongly) guess that
there is a clash and (mostly unnecessarily) search for "<service-
instance-name> (2)".
* If a clash exists between pledges from the same manufacturer, then
even if the Registrar-Agent attempts to start enrolling all
pledges with the same clashing service instance name, it may not
have enough information to distinguish the pledges other than by
the random numbering. This would happen especially if the IDevIDs
of both devices (of different product types) had the same serial
number, and the trust anchor certificate of both was the same
(e.g., the same root CA certificate), which is likely when they
are from the same manufacturer. Even if some other IDevID field
were used to distinguish their device models, the Registrar-Agent
would not be able to determine that difference without additional
vendor-specific programming.
As a result:
* Vendors MUST document how their pledges form a service instance
name from information available to the customer of the pledge.
This may, for example, take the form of a schema as in Figure 1,
point 1.2.
* These service instance names MUST be unique across all IDevIDs
from the manufacturer that share the same trust anchor.
The following mechanisms are recommended:
* Pledges SHOULD encode manufacturer-unique product instance
information in the serialNumber attribute of their subject name.
[RFC5280] calls this the X520SerialNumber.
* Pledges SHOULD make this serialNumber information consistent with
product instance information that is easily accessible when in
physical possession of the pledge, such as the product type code
and serial number on a bar code/QR code, to enable [BRSKI-PRM]
discovery without additional backend sales integration. Note that
discovery alone does not allow for enrollment (so it does not
introduce a security risk by itself)!
Eckert & Dijk Expires 4 May 2027 [Page 33]
Internet-Draft BRSKI-discovery October 2026
* Pledges SHOULD construct their service instance name by
concatenating their X520SerialNumber with a domain name that is
used by the manufacturer, and that thus allows devices from
different manufacturers using the same serialNumber scheme to be
disambiguated, reducing the likelihood of service instance name
clashes that would arise if manufacturer names were not used.
* Pledges MAY re-use the service instance name as their host name in
their AAAA or A RRs.
3.4.3. Example
This section discusses an example manufacturer's approach using the
recommendations above. Figure 1 shows the different data involved in
DNS-SD records for a pledge from the manufacturer "Example".
Eckert & Dijk Expires 4 May 2027 [Page 34]
Internet-Draft BRSKI-discovery October 2026
1. Manufacturer published information:
1.1 IDevID trust anchor certificate.
1.2 IDevID X520 identification schema:
Brand: Example
O = example.com, serialNumber = "PID:Model-<PID> SN:<SN>"
; Explanation:
; SN = Serial Number, PID = Product Identifier
; O = Organization
1.3 DNS-SD Instance Schema:
<X520SerialNumber>.example.com
2. Example Purchase Order Pledge Information
Brand: Example, Model: 0815, Serial: WLDPC2117A99
3. DNS-SD Instance string:
"PID:Model-0815 SN:WLDPC2117A99.example.com"
4. DNS-SD RR for the pledge (using mDNS, and hence .local):
; PTR RR to support discovering the pledge through browsing,
; e.g. when the serial number is not known in advance
_brski-pledge._tcp.local IN PTR
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
; SRV 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
5. Example Pledge IDevID certificate information:
; Format as shown by e.g.: openssl
Subject: serialNumber = "PID:Model-0815 SN:WLDPC2117A99",
O = example.com, CN = Model-0815
Figure 1: Example IDevID and DNS-SD data
Using the information from Figure 1, a Registrar-Agent implementation
operates as follows.
Eckert & Dijk Expires 4 May 2027 [Page 35]
Internet-Draft BRSKI-discovery October 2026
1. Initially, it is configured with the manufacturer-published
information (1.); although not shown, it will likely have a list
of such information for various brands of products.
2. After a pledge has been purchased and initially physically
deployed, the Registrar-Agent is provided with the purchase order
information for the pledge (2.). This order information tells it
that the manufacturer's brand is "Example", that the pledge
product model <PID> is "0815", and that its serial number <SN> is
"WLDPC2117A99".
3. It looks up the IDevID X520 identification schema for brand
"Example" and uses the template value for the serialNumber field,
together with the pledge information values from (2.) for O,
<PID>, and <SN>, to determine the DNS-SD Instance of the pledge
(3.). That instance is the concatenation of the X520
serialNumber value of the pledge with the Organization domain
name of the manufacturer. Because the Organization is a global
DNS domain, "example.com", including it in the Instance makes the
Instance unique across manufacturers.
4. It then uses standard DNS-SD via mDNS to find the pledge, using
the DNS-SD Resource Records (RRs) shown in (4.).
5. Once it receives a response from the device claiming to be the
pledge, it can use any appropriate authentication mechanism to
validate ownership of the IDevID private key. In [BRSKI-PRM],
this is done through the initial TLS handshake, in which it
learns the presumed IDevID of the pledge. When the signature of
the IDevID can be validated with the public key of the desired
manufacturer's trust anchor from (1.1), it trusts that this
pledge is from that manufacturer. When the O and serialNumber of
the certificate match what it constructed in (3.) from the
<PID>/<SN> values of the purchase information, it also trusts
that this is indeed the pledge it was looking for.
Instead of using sales receipt information, the customer may also use
scanned QR code/barcode or RF tag information from packaging after
receiving shipments, for example, for step 2. Scanning packaging
information will likely introduce additional complexity, because the
manufacturer name can often only be derived from information such as
EAN-13 barcodes.
The process steps may also be simpler if the customer can learn the
IDevID of the pledge through the purchase process, instead of having
to match the IDevID against sales receipt information (step 2).
Eckert & Dijk Expires 4 May 2027 [Page 36]
Internet-Draft BRSKI-discovery October 2026
The process steps may also become more complex. The manufacturer may
have multiple brands using the same trust anchor. Or the
manufacturer may have certificate chains, and different production
sub-companies may use different sub-CA certificates in the signing
chain. Or the serialNumber alone may not be unique across the
certificate chain, so that further Subject fields of the certificate
are required for unique identification, such as the O(rganization)
field. That field could, for example, contain one of multiple brand
names that use simple numerical serialNumber formats and hence could
collide. None of these complexities are desirable for new designs,
but they may be necessary to support BRSKI for existing products.
For the described mechanism to work, the manufacturer does not
necessarily have to own a domain name such as "example.com" in the
example. Owning a domain name and using it for the DNS-SD Instance
Schema is just a simple way to ensure the use of a unique Instance
Schema - if all manufacturers agree to use this approach.
The RR used to discover the pledge by its serial number is the "IN
SRV" RR. The "IN PTR" RR is optional and allows the pledge to be
discovered with DNS-SD browsing, which is necessary if the pledge's
serial number information cannot be known by the time the pledge
needs to be enrolled by a Registrar-Agent.
The instance string is also re-used in the host name of the "IN SRV"
RR, and hence in the domain name of the "IN AAAA" RR. This is just
an option; the pledge can use whatever host name it wants.
3.5. Variation signaling and encoding rules for different discovery
mechanisms
3.5.1. DNS-SD
3.5.1.1. Requirements
[DNS-SD] specifies how to use DNS-SD via mDNS and/or via unicast DNS.
Initiator implementations that discover BRSKI services SHOULD support
both mDNS and unicast DNS to discover the desired responders. They
SHOULD support the mechanisms of [DNS-SD], Section 11, to discover
unicast DNS browsing domains. They SHOULD prefer answers discovered
via unicast DNS over those discovered via mDNS.
Eckert & Dijk Expires 4 May 2027 [Page 37]
Internet-Draft BRSKI-discovery October 2026
Implementations of BRSKI responders that are intended to be reachable
over a routed network, such as registrar services, SHOULD support
[DNSSD-SRP] to register their service(s) with unicast DNS, and SHOULD
also announce their services with mDNS. BRSKI responder
implementations that only need to announce their services across
directly connected subnets, such as most proxies, SHOULD only use
mDNS to announce them.
3.5.1.2. Operational considerations
The following subsections discuss and provide recommendations for
specific deployment challenges of DNS. The remaining specifications
in this DNS-SD section apply equally to any instantiation of DNS-SD,
including DNS-SD via mDNS as defined in [DNS-SD], and via unicast
DNS, including registration via [DNSSD-SRP].
3.5.1.2.1. DNS Resolver
Network equipment implementing BRSKI may support a DNS(-SD) resolver
library at the operating system level, because such operating-system-
level DNS resolver functionality is common across many operating
systems, including embedded operating systems for network equipment.
However, operators of such networking equipment often prefer not to
enable this DNS resolver functionality. It typically results in
undesired DNS resolution dependencies in components such as the
operator CLI, resulting in operational or even functional failures of
the network equipment when DNS servers fail. Therefore, it is
RECOMMENDED to implement DNS-SD discovery for BRSKI such that using
it does not result in undesired dependencies on DNS or DNS-SD. This
can be achieved, for example, by limiting the use of DNS-SD resolver
functionality to BRSKI discovery only, unless it is also explicitly
enabled for other functions. Note that these DNS(-SD) resolver
considerations are independent of supporting other DNS functionality,
such as [RFC8106].
3.5.1.2.2. DNS Server Redundancy
Ideally, BRSKI should be able to run as autonomously and reliably as
possible, without depending on any unnecessary manual configuration
or unnecessary single points of failure. Any of the discovery
mechanisms described in this document (especially including DNS-SD
via unicast DNS) allow for fully autonomic redundancy of registrars.
DNS itself, however, relies on DNS servers, and their redundancy and
autonomous operation require additional considerations that are
outside the scope of this specification. Redundant setups of DNS
servers and SRP registrars also require additional, non-standardized
considerations.
Eckert & Dijk Expires 4 May 2027 [Page 38]
Internet-Draft BRSKI-discovery October 2026
3.5.1.2.3. DNS Server Discovery
Except in networks that define additional automated procedures (such
as Thread networks), discovery of DNS servers generally relies on
procedures that require non-automatic configuration of the DNS server
IP addresses, such as IPv6 router discovery as in [RFC8106]. Note
that once DNS servers have been discovered, [DNSSD-SRP] registrars
can be discovered automatically via DNS-SD. Networks that want to
support more automated discovery operations for BRSKI may consider
using GRASP, or using GRASP to auto-configure DNS server information.
These requirements are not optimized for environments with known
deployment profiles, such as wireless mesh networks, and may hence
need to be changed for such networks. For example, Thread networks
use a fully automatic broadcast mechanism to signal the addresses of
DNS servers, which resolves the challenge described above.
3.5.1.3. Variation String Encoding
Variation Strings from the IANA registry Table 8 are encoded as
comma-separated values (CSV) in the value of the "var" key.
A Variation String may be the empty string. The absence of any "var"
key in the TXT RR indicates support for that (empty) Variation
String. Likewise, "var=" indicates support for it. If multiple
Variation Strings are encoded, the empty string SHOULD come first:
"var=,variation2".
Variation strings in DNS-SD are case-insensitive, as required by DNS-
SD. It is RECOMMENDED to only announce lowercase variation strings
in DNS-SD.
3.5.1.4. Service Instance and Host Names
To be able to specify the supported variations as well as the
selection criteria (priority and weight) individually for each
responder socket, each responder socket needs to be represented in
DNS-SD as a service instance name with an SRV and a TXT RR. In
BRSKI-PLEDGE (Section 3.4), the service instance name is significant,
as it is what a Registrar-Agent may need to discover. In tBRSKI and
cBRSKI, however, it is merely an artifact of the DNS-SD encoding.
Unlike in typical user-centric DNS-SD use cases, there are no users
who need to make sense of the meaning of the service instance name,
for example, to know which printer to pick. Only operators may need
to look at them for troubleshooting. The choice of instance name
(the first component of a service instance name) is hence arbitrary.
The same is true for the host names used in the DNS-SD records for
BRSKI.
Eckert & Dijk Expires 4 May 2027 [Page 39]
Internet-Draft BRSKI-discovery October 2026
Registrars SHOULD support automatic generation of their service
instance name for DNS-SD operation, to avoid the need for additional
operator configuration. Registrars SHOULD likewise support the
configuration of such a name, if the operator so desires, to support
operational troubleshooting.
The host on which the registrar is running may already have a DNS
host name for the IP addresses used by the registrar and for the
desired DNS method (mDNS = .local, unicast DNS = default domain). In
that case, the registrar SHOULD be able to use that host name as the
target domain name in the SRV RR. This requirement avoids the
unnecessary addition of DNS A/AAAA RRs for the registrar when usable
RRs already exist.
Alternatively, there may be no such DNS RR, but a DNS host name for a
different DNS method, or for a different set of addresses than those
used by the registrar. In that case, the registrar MAY be able to
use a target domain name derived from that primary domain name by
appending a unique name element. This suggestion helps to avoid the
creation of unnecessarily inconsistent host names.
If no DNS host name exists, the registrar MUST be able to
automatically create a DNS host name and the A and/or AAAA RRs for
the address(es) used by the registrar, for use in the SRV RR target
field. This requirement exists to ensure that operators are not
unnecessarily required to configure a host name on a system that does
not need one - and none is required to run a registrar.
A registrar MAY use any unique identifiers of its host system as its
instance name or host name. This can avoid, or at least minimize,
the need to automatically pick another name in case the chosen name
is already taken by another system. This would happen, for example,
if a registrar tried to use an instance component such as "registrar"
while another registrar already exists. Using a known unique
identifier allows a registrar to raise an alert and claim an
operational error with a high degree of confidence.
MAC addresses are only unique when an application such as a registrar
understands what hardware it is running on, that the MAC address was
assigned by registering its OUI with the IEEE, and that MAC addresses
from the OUI were assigned uniquely. This is, for example, not
necessarily the case for IoT equipment or for registrars running in a
virtual context in the cloud. IP addresses can be assumed to be
unique (enough) when they have global scope or are ULAs.
Registrar software may not know whether other registrar software, or
another instance of the same software, can run on the same host (for
example, when it is packaged as an application). In that case, the
Eckert & Dijk Expires 4 May 2027 [Page 40]
Internet-Draft BRSKI-discovery October 2026
registrar SHOULD NOT assume that a host-unique name is actually
unique. Instead, it SHOULD disambiguate the name by appending an
additional name element, such as the process number of the running
process.
Picking well-known or unique identifiers for registrars also helps
operators to troubleshoot, often by eliminating the need to also know
the IP addresses associated with the name.
Target host names need to follow the requirements for host names. By
those requirements, ":" is not permitted in target host names, for
example, as part of MAC- or IP-address-based host names. Instance
names do not share these syntactical limitations. For operational
simplicity, an implementation SHOULD construct instance names in the
same manner as target host names, for example, by replacing ":" with
"-".
A responder may need to indicate different sockets for different
(sets of) variations, for example, when operating as a Join Proxy
according to Section 3.3.1. It then needs to signal a separate
service instance name for each socket. The SRV record of each
service instance name carries the appropriate port information, and
its TXT record carries the variations supported on that socket. A
responder MAY create the instance and host name for such different
variation sockets by appending the variation string to the previously
determined instance and host names.
3.5.1.5. Examples
These examples use an OUI and IPv6 addresses reserved for
documentation purposes. Do not re-use these addresses in actual
deployments.
Eckert & Dijk Expires 4 May 2027 [Page 41]
Internet-Draft BRSKI-discovery October 2026
# tBRSKI context
_brski-proxy._tcp.local
IN PTR 0000-5e00-5314._brski-proxy._tcp.local
0000-5e00-5314._brski-proxy._tcp.local
IN SRV 1 2 4555 0000-5e00-5314.local
0000-5e00-5314._brski-proxy._tcp.local
IN TXT "var=,prm-jose,cmp"
# cBRSKI
_brski-proxy._udp.local
IN PTR 0000-5e00-5314._brski-proxy._udp.local
0000-5e00-5314._brski-proxy._udp.local
IN SRV 1 2 5684 0000-5e00-5314.local
0000-5e00-5314._brski-proxy._udp.local
IN TXT "var="
# Host name
0000-5e00-5314.local
IN AAAA 2001:DB8:0815::5e00:5314
Figure 2: DNS-SD for single proxy supporting tBRSKI/cBRSKI variations
In Figure 2, a proxy on a router that uses mDNS to be discovered
supports tBRSKI with the "rrm" and "prm" modes across the same TCP
socket port 4555, with "est" and "cmp". This leads to the three
supported, IANA-registry-defined Variation Strings "" (empty), "prm-
jose", and "cmp". For cBRSKI (UDP), it supports the only variation
registered by this document, "" (empty).
Because the proxy announces ",prm-jose,cmp", it must itself have
discovered one or more registrars supporting all three of these
variations. When it connects an incoming connection from a Pledge to
a Registrar, it does not know which of the three announced variations
the Pledge wants to use, so the Registrar must also support all
three.
This proxy implementation is running on a router that otherwise has
no need for a host name registered in DNS or DNS-SD. It therefore
uses its MAC address as its target host name, "0000-5e00-5314.local",
and the same name is used in the proxy service instance names.
Because it is running on a router without modular software, the proxy
knows that no other proxy instances can run on the same host, and
hence the name has no further disambiguating elements.
Note also that there is never a need for two different service
instance names between tBRSKI and cBRSKI, because they are
distinguished by the "_tcp" versus "_udp" component of the service
instance name.
Eckert & Dijk Expires 4 May 2027 [Page 42]
Internet-Draft BRSKI-discovery October 2026
# tBRSKI registrar application
_brski-registrar._tcp.example.org
IN PTR noc-registrar-brski-37253._brski-registrar._tcp.example.org
noc-registrar-brski-37253._brski-registrar._tcp.example.org
IN SRV 1 2 4555 noc-registrar.example.org
noc-registrar-brski-37253._brski-registrar._tcp.example.org
IN TXT "var=,cmp"
# cBRSKI registrar application
_brski-registrar._udp.example.org
IN PTR noc-registrar-cbrski-5376._brski-registrar._udp.example.org
noc-registrar-cbrski-5376._brski-registrar._udp.example.org
IN SRV 1 2 7533 noc-registrar.example.org
noc-registrar-cbrski-5376._brski-registrar._udp.example.org
IN TXT "var="
# tBRSKI, PRM variation application
_brski-registrar._tcp.example.org
IN PTR noc-registrar-prm-9735._brski-registrar._tcp.example.org
noc-registrar-prm-9735._brski-registrar._tcp.example.org
IN SRV 1 2 17355 noc-registrar.example.org
noc-registrar-prm-9735._brski-registrar._tcp.example.org
IN TXT "var=prm-jose"
# Host name
noc-registrar.example.org
IN AAAA 2001:DB8:0815::5e00:5333
Figure 3: DNS-SD for tBRSKI/cBRSKI registrar applications
In the second example, Figure 3, a server system in the NOC of a
customer with the domain example.org is set up as the registrar for
various BRSKI options. It uses [DNSSD-SRP] to register its DNS-SD
names in the example.org domain, which it discovers as the default
domain. The host name of the server is set to noc-
registrar.example.org.
The operator installs three separate registrar applications on this
server: one from a vendor whose pledges use tBRSKI, one from an
integrator supporting pledges from various "IoT" vendors that use
cBRSKI, and one from a manufacturer whose pledges use BRSKI-PRM.
Each of the three applications operates in the same way for
discovery. It opens a socket for its registrar responder and notes
the port number it receives. It determines that SRP is usable, that
the default domain is "example.org", and that the host name is noc-
registrar. It then forms a unique name from noc-registrar by
appending a string abbreviation indicating its mode of operation
Eckert & Dijk Expires 4 May 2027 [Page 43]
Internet-Draft BRSKI-discovery October 2026
("brski", "cbrski", "prm") and its numeric process identifier, just
in case more than one instance of the same application can be
started. It then publishes its PTR, SRV, and TXT DNS RRs, using
these unique service instance names, the respective port number in
the SRV RR, and the variation(s) in the TXT RR.
3.5.2. GRASP
3.5.2.1. Requirements
The requirements of this document for supporting GRASP are specified
solely in Section 3.5.2.2. This document does not specify a
mandatory-to-implement (MTI) "Security and Transport Substrate"
([GRASP], Section 2.5.1). Requirements for it depend on the type of
(constrained) network in which it is to be deployed.
[ACP] specifies one such "Security and Transport Substrate", which is
zero-touch deployable. Initiators and responders implementing the
so-called "Autonomic Network Infrastructure" (ANI) are required to
support it. 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.
3.5.2.2. Encoding and Examples
To announce protocol variations with [GRASP], the supported Variation
is indicated in the objective-value field of the GRASP objective,
using the Variation String formed as described in Section 5.4.4 and
listed in the Variation String column of the Table 8 table.
If more than one Variation is supported, then multiple objectives
have to be announced, each with a different objective-value. If the
different Variations can be supported across the same socket, the
objectives carry the same locator information, because they will all
be connected to the same registrar. Different sockets require
different objective structures in GRASP anyhow.
Compared to DNS-SD, the encoding chosen for GRASP optimizes for
minimum parsing effort, whereas the DNS-SD encoding is optimized for
the most compact encoding, given the size limit for DNS-SD TXT
records.
Eckert & Dijk Expires 4 May 2027 [Page 44]
Internet-Draft BRSKI-discovery October 2026
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]],
[["AN_join_registrar", 4, 255, "prm-jose"],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]],
[["AN_join_registrar", 4, 255, ""],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]],
[["AN_join_registrar_rjp", 4, 255, ""],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_UDP, 4686]]
]
Figure 4: GRASP example for a BRSKI registrar supporting RRM and PRM
Figure 4 is an example of a GRASP service announcement by a
registrar. It supports BRSKI with both "rrm" and "prm" on the same
TCP port 4443, and cBRSKI (CoAP over DTLS) on UDP port 4684 in
stateful mode and port 4686 in stateless mode. The first variation,
for "rrm", uses the objective-value "EST-TLS" for backward
compatibility with [BRSKI], Section 4.3, where it was introduced (see
Note (1) of Table 8). This special case applies only to BRSKI (TCP).
The cBRSKI announcements use the Variation String "" of the cBRSKI
default variation, and are distinguished from BRSKI by IPPROTO_UDP.
Note that one or more complete service instances (four in the
example) can be contained in a single GRASP message. This does not
require any equivalent of 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 RRs. 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.
Eckert & Dijk Expires 4 May 2027 [Page 45]
Internet-Draft BRSKI-discovery October 2026
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_Proxy", 4, 1, ""],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 5553]],
[["AN_Proxy", 4, 1, "prm-jose"],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 5555]],
[["AN_Proxy", 4, 1, ""],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_UDP, 5684]]
]
Figure 5: GRASP example for a BRSKI Join Proxy supporting RRM and PRM
Figure 5 shows a corresponding GRASP service announcement by a Join
Proxy that has discovered the registrar from Figure 4 and is now
announcing the services that it can proxy. Whereas registrar
announcements as in Figure 4 typically use a loop-count of 255 in the
objective to be seen across the whole network, Join Proxy
announcements are only intended to reach link-local neighboring
pledges, and hence use a loop-count of 1.
The Join Proxy uses the AN_Proxy objective with an objective-value of
"" for "rrm" in BRSKI, again for backward compatibility with [BRSKI],
Section 4.1.1. There are no two announcements for cBRSKI, because
there is no stateless mode from Join Proxy to pledge or Registrar-
Agent. Instead, the Join Proxy has to decide whether to connect to
the registrar via stateful or stateless mode, but this decision is
not visible in its GRASP announcements.
Also noteworthy is the use of two different ports for "rrm" versus
"prm". As the Registrar announced support for both variations on the
same TCP port, the Join Proxy could have done the same, but by using
different ports, the Join Proxy can choose independently which
Registrar to connect "rrm" versus "prm" sessions to. For example,
another Registrar could announce itself for only "prm" and might be
preferred by the Join Proxy.
Eckert & Dijk Expires 4 May 2027 [Page 46]
Internet-Draft BRSKI-discovery October 2026
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]],
[["AN_join_registrar", 4, 255, ""],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]
]
[M_FLOOD, 42310815, h'fe800000000000000000000000000001', 180000,
[["AN_join_registrar", 4, 255, "prm-jose"],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 44000]]
]
Figure 6: GRASP example for a BRSKI Registrar supporting RRM and
PRM via separate processes
In Figure 6, a separate application process supports "prm", and hence
uses a separate socket, with port number 44000, from that for "rrm",
with port 4443. Assume that there is no shared GRASP implementation
across the two separate processes, for example, because there is a
separate GRASP process for each. The announcements from both
processes then cannot be merged into a single GRASP packet. Instead,
each one will send its own GRASP announcements separately. This
example primarily serves as a reminder that GRASP receivers need to
support receiving multiple announcements from the same sender not
only within a single packet, but also in separate packets. This is
necessary to support implementation cases just like this one.
For a more extensive, DNS-SD-compatible encoding of the objective-
value that also supports Service Instance Names, see
[I-D.eckert-anima-grasp-dnssd].
3.5.3. CORE-LF
3.5.3.1. Overview
"Web Linking" ([RFC8288]) defines a format, originally for use in
HTTP headers, to link an HTTP document to other URIs. Web Linking is
not a standalone method for the discovery of services for use with
HTTP.
Based on Web Linking, "Constrained RESTful Environments (CoRE) Link
Format" ([CORE-LF]) introduces a standalone method to discover
resources, such as service instances. CORE-LF was introduced
primarily for use with [COAP], but it can equally be used for the
Eckert & Dijk Expires 4 May 2027 [Page 47]
Internet-Draft BRSKI-discovery October 2026
discovery of service instances that use HTTP or any other suitable
(web transfer) protocol. This makes CORE-LF an alternative to DNS-SD
and GRASP for cBRSKI variations.
In CORE-LF, an initiator may send a (link-local) IPv6 multicast UDP
packet to the CoAP port (5683) to discover a possible responder for a
requested resource. The responder will reply via unicast UDP. If
the IPv6 address of a responder has been configured or is otherwise
known to the initiator, it may instead query the parameters of the
desired resource via unicast to the default CoAP UDP or TCP port
(5683).
[RFC9176] defines a "Resource Directory" mechanism for CORE-LF,
abbreviated CORE-RD. Initiators can learn the IPv6 address, protocol
(TCP or UDP), and port number of a CORE-RD server by some other
mechanism (such as DNS-SD). They can 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.
In summary, CORE-LF, including CORE-RD, is a mechanism for
registering and discovering resources, and hence services. It may be
preferred over other options in some deployments, and is equally
applicable to registering/discovering any variation of cBRSKI for any
type of cBRSKI service.
3.5.3.2. Background
[cBRSKI] and [cPROXY] define three CORE-LF discovery exchanges for
cBRSKI. Each of them uses a different CORE-LF signaling element to
indicate the cBRSKI service, which this document considers the
Service Name of that service in CORE-LF (see Section 5.4.2).
[cPROXY] introduces the operation of a CoAP-based Join Proxy in two
forms. The first is a connection-based Join Proxy as in [BRSKI],
only using UDP connections for CoAPS instead of TCP for TLS as in
[BRSKI]. The second is a new, stateless Join Proxy. It eliminates
the need for potentially highly constrained Join Proxy nodes to keep
connection state, and avoids the complexity of protecting that state
against attacks.
1. Pledges discover Join Proxies ([cBRSKI], Section 10.1, and
[cPROXY], Section 5.2) via the target attribute "brski-jp", which
is registered by [cPROXY]. The pledge sends a link-local
multicast query to the "All CoAP Nodes" address ff02::fd. The
value of the attribute is the join-port of the Join Proxy. The
link target is empty ("<>"), and the pledge uses the link-local
Eckert & Dijk Expires 4 May 2027 [Page 48]
Internet-Draft BRSKI-discovery October 2026
source address of the response as the IP address of the Join
Proxy. Because BRSKI is designed so that pledges can be agnostic
of whether they connect to a registrar directly or via a Join
Proxy, a registrar that also accepts connections directly from
pledges announces itself in the same way.
2. Stateful Join Proxies discover registrars ([cPROXY],
Section 5.1.2) via the resource type "brski", which [cBRSKI]
registers as the base resource of all cBRSKI resources. The link
target is the coaps:// URI of that base resource. If the port is
omitted, the default CoAPS port 5684 is implied.
3. Stateless Join Proxies discover registrars ([cPROXY],
Section 5.1.1) via the resource type "brski.rjp", which is
registered by [cPROXY]. The link target is a jpy:// URI with the
IP address and port of the JPY protocol endpoint of the
registrar. The "jpy" scheme is also registered by [cPROXY].
Join Proxies typically send their queries to the site-local "All CoAP
Nodes" address ff05::fd or to smaller scopes, as discussed in
[cPROXY]. The "All CoAP Nodes" addresses are registered in [COAP],
Section 12.8 (see also [RFC7390]). Even when the registrar IP
address is known, the reply still needs to include this address,
because in the [CORE-LF] link format, and per [RFC3986], Section 3.2,
the authority component cannot include a port number unless it also
includes the IP address.
[cPROXY] specifies that Join Proxies only query for the specific
service they need, and do not send wildcard queries such as
"rt=brski*".
Eckert & Dijk Expires 4 May 2027 [Page 49]
Internet-Draft BRSKI-discovery October 2026
Pledge discovering Join Proxies:
REQ: GET coap://[ff02::fd]/.well-known/core?brski-jp=*
RES: 2.05 Content
<>;brski-jp=8485
Stateful Join Proxy discovering registrars:
REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski
RES: 2.05 Content
<coaps://[2001:db8:0:abcd::52]/b>;rt=brski
Stateless Join Proxy discovering registrars:
REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski.rjp
RES: 2.05 Content
<jpy://[2001:db8:0:abcd::52]:7634>;rt=brski.rjp
Figure 7: CORE-LF discovery exchanges of cBRSKI and cPROXY
3.5.3.3. Specification
This section specifies the use of CORE-LF for BRSKI variations.
These specifications are backward-compatible extensions of what is
specified in [cBRSKI] and [cPROXY], except where noted, in which case
the requirements are narrowed. The following explanations use terms
from the ABNF in Section 2 of [CORE-LF] and from [RFC3986] (URI), and
rely on the following template example, Figure 8.
Template:
REQ: GET /.well-known/core?rt=brski-service
RES: 2.05 Content
<scheme://[address]:port path-abempty>;\
rt=brski-service(;var="brski-variation-string(s)");\
pw="priority weight"
REQ: GET /.well-known/core?brski-jp=*
RES: 2.05 Content
<>;brski-jp=join-port(;var="brski-variation-string(s)");\
pw="priority weight"
Figure 8: Template for BRSKI discovery with variations
Eckert & Dijk Expires 4 May 2027 [Page 50]
Internet-Draft BRSKI-discovery October 2026
BRSKI responder sockets indicated by a resource type are indicated in
CORE-LF as a URI-Reference. The URI-Reference SHOULD be a URI with a
scheme, the IP address of the responder socket, and the port used by
the responder. It may optionally be followed by a non-empty path-
abempty.
URI-References SHOULD NOT use a domain name instead of an address, so
that initiators can select a BRSKI responder without requiring DNS
support. Likewise, port and scheme MUST be included, so that the
information can be passed on to consumers without having to modify
it. If this information is omitted, the full information can only be
known in the context of the scheme and port of the connection through
which it was retrieved. Initiators MUST nevertheless accept links
without a port from responders that only follow [cPROXY], in which
case the default CoAPS port 5684 applies ([cPROXY], Section 5.1.2).
Note that these URI-Reference requirements are stronger than those of
[cBRSKI] and [cPROXY], to make extensibility easier. For the target
attribute "brski-jp", the link format is as specified in [cPROXY]:
the link target is empty, and the value of the attribute is the join-
port.
BRSKI responder sockets MUST include a resource type attribute or a
target attribute indicating a BRSKI service, shown as "brski-service"
and "brski-jp" in Figure 8. This value MUST be registered in the
IANA "Resource Type (rt=) Link Target Attribute Values" or "Target
Attributes" registry table, and also referenced in the "Service
Names" registry table (Section 5.4.2).
Discovery of registrar sockets by stateful proxies uses the resource
type "brski". This is used with the coaps:// scheme for cBRSKI.
Stateless registrar sockets use the resource type "brski.rjp". This
currently only supports the jpy:// scheme. By its nature, it can
only be used with schemes that rely on UDP. Join Proxy sockets are
discovered by pledges via the target attribute "brski-jp". These
uses of resource types and target attributes are unchanged from
[cBRSKI] and [cPROXY]. This document does not specify how to
discover BRSKI-PLEDGE via CORE-LF.
Eckert & Dijk Expires 4 May 2027 [Page 51]
Internet-Draft BRSKI-discovery October 2026
The variations supported by a BRSKI responder socket are indicated
via the optional "var" target attribute. The value is a quoted-
string of one or more comma-separated BRSKI variation strings, using
the same encoding as the DNS-SD "var" key (Section 3.5.1.3): if the
empty Variation String is included, it SHOULD come first, as in
var=",cmp". Because a comma separates links in the CoRE Link Format,
the value MUST be encoded as a quoted-string whenever it contains a
comma. The absence of a "var" target attribute indicates support for
only the default variation of the BRSKI context to which the BRSKI
service belongs. This can also be indicated as "var=".
The optional "pw" target attribute indicates priority and weight for
the selection of the resource target, with the semantics and format
defined in [RFC2782] for priority and weight in DNS SRV resource
records. If the pw attribute is absent, it is assumed to be
pw="65535 0". For links with the "brski-jp" target attribute, whose
link target is empty, "pw" applies to the join-port endpoint
indicated by the "brski-jp" attribute of the same link.
A non-empty path-abempty indicates a path prefix for the endpoints
supporting the BRSKI service and variation that is shorter than the
default endpoint paths specified for the service.
3.5.3.4. Examples
REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski
RES: 2.05 Content
Content-Format: 40
Payload:
<coaps://[2001:db8:0:abcd::52]/b>; # [1]
rt=brski;var=",cmp";pw="1 2"
REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski.rjp
RES: 2.05 Content
Content-Format: 40
Payload:
<jpy://[2001:db8:0:abcd::52]:7634>; # [2]
rt=brski.rjp;var=",cmp";pw="1 2"
REQ: GET coap://[ff02::fd]/.well-known/core?brski-jp=*
RES: 2.05 Content
Content-Format: 40
Payload:
<>;brski-jp=61616, # [3]
<>;brski-jp=61617;var=",cmp";pw="1 2" # [4]
Eckert & Dijk Expires 4 May 2027 [Page 52]
Internet-Draft BRSKI-discovery October 2026
Figure 9: CORE-LF examples for cBRSKI variations
Figure 9 shows example cBRSKI variations in CORE-LF format. Note
that the example is pretty-printed through indentation and by
breaking long lines. This additional white space is not compatible
with actual CORE-LF output. Likewise, the text following "#"
consists of editorial comments.
Example [1] is the reply of a registrar to the query of a stateful
Join Proxy. The registrar supports the default cBRSKI variation ""
and the variation "cmp" on its CoAPS socket, on the default port
5684, with the cBRSKI base resource "/b". "pw=" indicates priority
and weight as in DNS-SD. Example [2] is the reply of the same
registrar to the query of a stateless Join Proxy, for its JPY
protocol endpoint on port 7634.
Examples [3] and [4] are the reply of a Join Proxy to the query of a
pledge. The Join Proxy uses join-port 61616 for registrars that
support only the default variation, and join-port 61617 for
registrars, such as the one in [1] and [2], that support both the
default variation and "cmp". A pledge that does not support "var"
can use either join-port for the default variation.
3.5.3.5. Resource Type Considerations
CORE-LF expresses information about resources of a target identified
by a resource type. This specification also encodes BRSKI services
in CORE-LF as resource types (or, for the Join Proxy, as the target
attribute "brski-jp"), as specified in Section 3.5.3.3. For the
purpose of CORE-LF, a BRSKI service is just another resource, except
that it characterizes the overall functionality available across a
connection to the target, composed of a sequence of endpoint
instantiations. In addition, this behavior is further refined by the
list of supported variations indicated.
Often, resources in CORE-LF do not describe a service, but details of
as little as a single endpoint, such as its URL prefix and format
encoding. This fine-grained specification is not a good replacement
for the concept of service and variation. The availability of a set
of endpoints with specific encodings does not indicate whether the
target supports the desired specific sequencing of instantiating
those endpoints. Nor does it indicate whether the target supports
the use of any endpoint encoding option in any combination.
Making such arbitrary combinations a requirement can easily lead to
more generic, but also more costly, implementations and testing
requirements, without necessarily gaining deployment benefits.
Eckert & Dijk Expires 4 May 2027 [Page 53]
Internet-Draft BRSKI-discovery October 2026
BRSKI resource types that are not treated as services according to
this specification, such as those registered by [cBRSKI], can still
be used, if so desired, to amend the discovery of shortened
endpoints, as shown in Figure 10.
RES: 2.05 Content
Content-Format: 40
Payload:
<coaps://[2001:DB8:0815::5e00:5314]:5684/b>; # [1]
rt=brski;var=",cmp";
pw="1 2",
<coaps://[2001:DB8:0815::5e00:5314]:5684/b/rv>; # [2]
rt=brski.rv,
<coaps://[2001:DB8:0815::5e00:5314]:5684/b/vs>; # [3]
rt=brski.vs,
</b/rv>;rt=brski.rv, # [4]
</b/vs>;rt=brski.vs # [5]
Figure 10: CORE-LF resource examples
[1] shows how the prefix for all BRSKI endpoints over "coaps://" can
be shortened from "/.well-known/brski" to "/b".
[2] and [3] show the discovery of the endpoints "/b/rv" and "/b/vs"
via the resource types "brski.rv" and "brski.vs" registered by
[cBRSKI]. By using the resource type prefix "brski." for both of
them, as well as the path prefix "/b", it can be implied that these
endpoints are part of the service specified in [1].
These discovery options can be further compacted, as shown in
examples [4] and [5]: the full socket details can be omitted when
they can be inferred from context.
While these shortenings can be highly useful for frequently used
resources, each endpoint in BRSKI is typically only instantiated once
by a pledge, so the overall savings in communication data from these
shortenings are likely negligible. It is better to define short
endpoint paths in the variation specification if they are likely to
be needed, as is done in [cBRSKI], so that it is not necessary in
cBRSKI to add such shortenings in discovery. For these reasons, this
document does not specify whether or how to use such resource targets
in conjunction with BRSKI discovery, but only discusses possibilities
and limitations here.
Considerations for such non-service resource type use in BRSKI
nevertheless introduce one requirement to avoid conflicts: the names
of BRSKI services MUST NOT duplicate the endpoint names of any
resources specified for BRSKI protocols. This means that the
Eckert & Dijk Expires 4 May 2027 [Page 54]
Internet-Draft BRSKI-discovery October 2026
resource types "brski.rv", "brski.vs", and "brski.es" registered by
[cBRSKI] cannot be used as BRSKI service names, and likewise,
additional BRSKI endpoints cannot be called "rjp" or any other string
registered in the BRSKI discovery registry tables.
3.6. Use of Multiple Discovery Mechanisms
When supporting multiple discovery mechanisms, nodes announcing BRSKI
services SHOULD announce them in each supported discovery mechanism
and transport option. Different options of discovery mechanisms may
require additional features to be deployed in the network in order to
operate, so options that do not work because their prerequisites are
not met cannot be used. For example, in DNS-SD, there is the
transport option of mDNS, which always works, and there is SRP for
DNS-SD via unicast DNS, which only works when the announcing node can
discover (or be configured with) the necessary SRP server information
and potentially credentials.
When attempting to discover a particular service while supporting
multiple discovery mechanisms/transport options, discovery SHOULD be
sequenced according to implementation preferences.
These policies are just fallback recommendations: across all possible
networks, there is no clear prioritization among different discovery
mechanisms, so no more specific recommendations are possible.
However, different types of deployment environments, specifically
different types of IoT networks, will likely benefit from network-
specific policies, outside the scope of this document, with stricter
preferences for specific discovery mechanisms.
4. Updates
4.1. Updates to RFC9733
The following text is to be added to the end of Section 5.1 of
[BRSKI-AE].
NEW:
| For new implementations of BRSKI with CMP and DNS-SD discovery,
| the following is RECOMMENDED.
|
| For DNS-SD, the service name is "brski-registrar" (see [ThisRFC],
| Section 5.4.2) with the TXT key "var" value "cmp" (see [ThisRFC],
| Section 5.4.4). This automatically allows the use of Join Proxies
| through the mechanisms of [ThisRFC]. They will use "brski-proxy"
| with the TXT key "var" value "cmp" to indicate their support for
| also transparently proxying for a CMP-supporting registrar.
Eckert & Dijk Expires 4 May 2027 [Page 55]
Internet-Draft BRSKI-discovery October 2026
|
| Note that these procedures will allow the use of CMP in cBRSKI, as
| both "brski-registrar" and "brski-proxy" are also registered for
| use with UDP.
|
| Likewise, "brski-registrar-rjp" with the TXT key "var" value "cmp"
| and UDP is RECOMMENDED to support CMP with stateless Join Proxies
| that support the mechanisms of [ThisRFC].
|
| The registrations in [ThisRFC], Section 5.4.2, also allow
| Registrars/Proxies for tBRSKI with CMP to be discovered with the
| GRASP discovery mechanism, and Registrars/Proxies for cBRSKI with
| CMP with the GRASP and CORE-LF discovery mechanisms.
|
| If backward compatibility is required, registrars can continue to
| announce "brski-reg-cmp" unchanged.
4.2. Updates to BRSKI-PRM
This document updates [BRSKI-PRM] by adding the following text to the
end of Section 6.1.1.
NEW:
| According to the procedures of [ThisRFC], Registrar-Agents can
| discover Registrars supporting PRM by discovering Registrars that
| announce a variation that includes the Variation Type Choice
| "prm". Because [BRSKI-PRM] specifies the use of JOSE for voucher
| encoding, the correct Variation String to discover is "prm-jose",
| as registered in [ThisRFC], Section 5.4.4. Discovery can use DNS-
| SD or GRASP, using the encodings specified in [ThisRFC] and
| registered in [ThisRFC], Section 5.4.4 for the Variation String
| and [ThisRFC], Section 5.4.2 for the Service Name.
|
| Registrar-Agents MAY use Join Proxies that support the procedures
| of [ThisRFC] to reach Registrars supporting PRM and using the
| procedures of [ThisRFC]. This may be of interest if the network
| available at the location where the Registrar-Agent operates to
| access the Pledge is not fully trusted, but Join Proxies are used
| to only allow connections to Registrars.
This document updates [BRSKI-PRM] by adding the following text to the
end of Section 6.1.2.
NEW:
Eckert & Dijk Expires 4 May 2027 [Page 56]
Internet-Draft BRSKI-discovery October 2026
| For more details about discovering Pledges, including a more
| complete example and suggested documentation details for
| manufacturers' naming schemes, see [ThisRFC], Section 3.4. Those
| procedures are meant to be fully backward compatible with those
| specified in [BRSKI-PRM].
4.3. Updates to RFC6690
The following text adds resource type requirements for "brski", to be
inserted after the second paragraph of Section 7.4 of [CORE-LF].
It recommends that IANA document this addition as indicated in
Section 5.1.1.
NEW:
| For the Resource Type (rt=) Link Target Attribute table, values
| starting with the characters "brski" are also subject to the
| requirements in the following paragraph.
|
| Resource Type values with the "brski" prefix that identify a BRSKI
| service SHOULD support BRSKI discovery as specified in [ThisRFC].
| The specification of such a Resource Type SHOULD NOT prohibit or
| conflict with the ability to combine variation type values as
| established by [ThisRFC]. The specification SHOULD include, or
| point to, a definition of how the Resource Type is to be included
| in the "Service Names" sub-registry of the BRSKI Discovery
| Parameters registry (Section 5.4.2). Review of these requirements
| is to be coordinated between the Designated Experts for the CoRE
| parameters (core-parameters@ietf.org) and those for the BRSKI
| Discovery Parameters registry (Section 5.4).
5. IANA considerations
5.1. Core Parameters
5.1.1. Resource Type Link Target Attribute Values
This document introduces additional requirements for the registration
of CoRE Resource Type values with the prefix "brski" in the "Resource
Type (rt=) Link Target Attribute Values" sub-registry of the
"Constrained RESTful Environments (CoRE) Parameters" registry, as
specified in Section 4.3.
IANA is requested to document these additions by adjusting the
registration procedure table for the "Resource Type (rt=) Link Target
Attribute Values" sub-registry as shown in Table 1.
Eckert & Dijk Expires 4 May 2027 [Page 57]
Internet-Draft BRSKI-discovery October 2026
+==============+=========================+=========================+
| Range | Registration Procedures | Note |
+==============+=========================+=========================+
| value starts | IETF Review | |
| with "core" | | |
+--------------+-------------------------+-------------------------+
| value starts | Specification Required | Additional requirements |
| with "brski" | | in ThisRFC Section 4.3 |
+--------------+-------------------------+-------------------------+
| all other | Specification Required | |
| values | | |
+--------------+-------------------------+-------------------------+
Table 1: Suggested updated registration procedure table for Core
(rt=) Link Target Ranges
5.1.2. Target Attributes
+===========+======================+============+===========+
| Attribute | Brief Description | Change | Reference |
| Name | | Controller | |
+===========+======================+============+===========+
| var | List of supported | IETF | [ThisRFC] |
| | variations of target | | |
+-----------+----------------------+------------+-----------+
| pw | DNS SRV compatible | IETF | [ThisRFC] |
| | priority and weight | | |
| | of resource target | | |
+-----------+----------------------+------------+-----------+
Table 2: Target Variation and Priority/Weight Attributes
IANA is asked to add entries for "var" and "pw" to the "Target
Attributes" table, according to Table 2.
The "var" target attribute is intended to be used in links for BRSKI
services as specified in this document (Section 3.5.3.3). It is also
intended to be usable in other links, if so desired, to indicate
variations of the service or resource of the link. For links that do
not indicate a BRSKI service, the format of the value may differ from
that specified for BRSKI.
The "pw" target attribute indicates priority and weight for the
selection of the resource target, with the semantics and format
defined in [RFC2782] for priority and weight in DNS SRV resource
records. If the pw attribute is absent, it is assumed to be
pw="65535 0".
Eckert & Dijk Expires 4 May 2027 [Page 58]
Internet-Draft BRSKI-discovery October 2026
5.2. Service Names Registry
IANA is asked to modify and amend the "Service Name and Transport
Protocol Port Number Registry" (https://www.iana.org/assignments/
service-names-port-numbers/service-names-port-numbers.txt) as
follows.
* brski-proxy, brski-registrar, and brski-registrar-rjp are to be
added as Service Names for the "udp" protocol, using ThisRFC,
Section 5.4.2, as the reference.
* The registrations of brski-proxy and brski-registrar for the "tcp"
protocol are to be updated to also include ThisRFC, Section 5.4.2,
as their reference.
* The Defined TXT keys column for brski-proxy and brski-registrar
for the "tcp" and "udp" protocols, and for brski-registrar-rjp for
the "udp" protocol, is to state the following text:
Defined TXT keys: var= comma separated <variation-string(s)>, See
ThisRFC Section 3.5.1.3, Section 5.4.4
5.3. GRASP Objective Names Registry
IANA is asked to add the following entry to the "GRASP Objective
Names" registry on the "GeneRic Autonomic Signaling Protocol (GRASP)
Parameters" registry page.
+=======================+========================+
| Objective Name | Reference |
+=======================+========================+
| AN_join_registrar_rjp | ThisRFC, Section 5.4.2 |
+-----------------------+------------------------+
Table 3: GRASP Objective Names Registry addition
5.4. BRSKI Discovery Parameters
IANA is asked to add a registry called "BRSKI Discovery Parameters"
to the "Bootstrapping Remote Secure Key Infrastructures (BRSKI)
Parameters" registry page (https://www.iana.org/assignments/brski-
parameters/brski-parameters.xhtml).
The BRSKI Discovery Parameters registry includes several sub-
registries that depend on each other. Because the registry has sub-
registries, one table has to be chosen to represent the overall
registry. The table used to represent the BRSKI Discovery Parameters
registry is the list of supported discovery mechanisms.
Eckert & Dijk Expires 4 May 2027 [Page 59]
Internet-Draft BRSKI-discovery October 2026
The Registration Procedure for this registry is Specification
Required, where the Expert Review has to ensure that entries comply
with the following rules.
Additions to this registry require a specification of the use of the
newly registered discovery mechanism with BRSKI discovery procedures,
in the way they are specified in this document for DNS-SD, GRASP, and
CORE-LF.
Changes/extensions to the procedures for any existing registered
discovery mechanism, including DNS-SD, GRASP, or CORE-LF, can be made
by adding such a specification to the Reference(s) column.
Any incremental changes to the procedures of a discovery mechanism
require the same or a higher level of specification as the one that
first introduced the discovery mechanism. Changes to the procedures
for DNS-SD, GRASP, or CORE-LF hence require an IETF Standards Track
specification.
The initial content is as follows.
Designated Experts: TBD.
Registration Procedure: Specification Required.
Notes: See [ThisRFC], Section 5.4
+=====================+==============+===============+
| Discovery Mechanism | Reference(s) | Notes |
+=====================+==============+===============+
| DNS-SD | ThisRFC | Section 3.5.1 |
+---------------------+--------------+---------------+
| GRASP | ThisRFC | Section 3.5.2 |
+---------------------+--------------+---------------+
| CORE-LF | ThisRFC | Section 3.5.3 |
+---------------------+--------------+---------------+
Table 4: Discovery Mechanisms initial registry table
5.4.1. Contexts
IANA is asked to create a sub-registry called "Contexts" in the
"BRSKI Discovery Parameters" registry.
The Registration Procedure for this registry is Specification
Required, where the Expert Review has to ensure the feasibility of
entries with respect to the following behavior/rules.
Eckert & Dijk Expires 4 May 2027 [Page 60]
Internet-Draft BRSKI-discovery October 2026
A Context is a name for a group of one or more BRSKI services. This
sub-registry registers a Context name and the list of Variation Types
defined for the Context.
Variation Types are case-insensitive, consist only of the letters a-z
and the digits 0-9, must start with a letter, and must be at most 12
characters long.
Registration of new Contexts MUST include a specification of how to
use discovery with the new Context, using the specifications for
tBRSKI, cBRSKI, and BRSKI-PLEDGE in this document as examples.
Technically, Contexts with the same set of Variation Types exist, for
example, to allow different protocol stacks for otherwise logically
the same type of services to be registered, and hence discovered;
otherwise, a tBRSKI pledge might discover a cBRSKI registrar. See
Section 5.4.2 for more details.
The order of Variation Types defines the order in which Variation
Type Values are concatenated to generate Variation Strings, as
described in Section 5.4.4. Therefore, once registered, Variation
Types SHOULD NOT be changed or deleted, so that new Variation Strings
will be constructed consistently with old ones. New Variation Types
may only be appended through registration updates.
Registration of additional Variation Types MUST include a
specification of how they map to specific functions of the services
that use them, as this specification does for tBRSKI, cBRSKI, and
BRSKI-PLEDGE.
Registrations of a new Context MAY initially not define any Variation
Types, if Variations are not yet considered for that Context.
The initial content of this sub-registry is as follows.
Designated Experts: TBD.
Registration Procedure: Specification Required.
Notes: See [ThisRFC], Section 5.4.1
Eckert & Dijk Expires 4 May 2027 [Page 61]
Internet-Draft BRSKI-discovery October 2026
+==============+=======================+==============+=============+
| Context | Variation Types | Reference(s) | Notes |
+==============+=======================+==============+=============+
| tBRSKI | mode, vformat, | ThisRFC | See Section |
| | enroll | | 3.1.8 |
+--------------+-----------------------+--------------+-------------+
| cBRSKI | mode, vformat, | ThisRFC | See Section |
| | enroll | | 3.1.8 |
+--------------+-----------------------+--------------+-------------+
| BRSKI-PLEDGE | mode, vformat, | ThisRFC | See Section |
| | enroll | | 3.4.1 |
+--------------+-----------------------+--------------+-------------+
Table 5: Contexts initial sub-registry table
5.4.2. Service Names
IANA is asked to create a sub-registry called "Service Names" in the
"BRSKI Discovery Parameters" registry.
The Registration Procedure for this registry is Specification
Required, where the Expert Review has to ensure the feasibility of
entries with respect to the following behavior/rules.
Each entry registers a Service Name intended for the discovery of a
BRSKI-related service using a specific discovery mechanism. The
service is to be accessed via specific service (transport) stack
Parameter(s) that need to be known to the discovery mechanism.
Depending on the discovery mechanism, the Service Name represents a
different signaling element of the discovery mechanism, as follows.
* For DNS-SD, the Service Name in the table is the DNS-SD Service
Name, which MUST also be registered in the IANA "Service Name and
Transport Protocol Port Number Registry" for use with the DNS-SD
protocol indicated in the Parameter(s) column.
* For GRASP, the Service Name is the GRASP Objective Name, which
MUST also be registered in the IANA "GeneRic Autonomic Signaling
Protocol (GRASP) Parameters" / "GRASP Objective Names" registry.
Eckert & Dijk Expires 4 May 2027 [Page 62]
Internet-Draft BRSKI-discovery October 2026
* For CORE-LF, the Service Name is either a CoRE Resource Type (rt=)
value, which MUST be registered in the IANA "Constrained RESTful
Environments (CoRE) Parameters" / "Resource Type (rt=) Link Target
Attribute Values" registry, or the name of a CoRE target attribute
(indicated as "(target attribute)" in the Parameter(s) column),
which MUST be registered in the IANA "Constrained RESTful
Environments (CoRE) Parameters" / "Target Attributes" registry
([RFC9423]).
A Context is a grouping of one or more services with the same set of
Variation Types and Values, as defined in Section 5.4.1. Re-use of
the same Service Name across multiple Contexts requires the services
to be distinguished through Parameter(s) that are used as additional
distinguishers (besides the Service Name) in the discovery mechanism.
For example, AN_Proxy is used as the GRASP Objective (aka "Service
Name") to discover [BRSKI] Join Proxies and connect to them via TCP.
This is indicated through the IPPROTO_TCP parameter in GRASP.
Likewise, when a constrained BRSKI proxy as described in [cPROXY] is
to be discovered via GRASP, IPPROTO_UDP is to be used in GRASP to
distinguish such a cBRSKI Proxy from a BRSKI Proxy.
Informal names for services are best documented in the Notes column.
In addition to the registrations from other BRSKI RFCs, the initial
registry table adds registrations for discovering cBRSKI stateful and
stateless Registrars and Join Proxies via GRASP and DNS-SD. The
necessary additional registrations for these are included in
Section 5.2 for DNS-SD and Section 5.3 for GRASP. With these
registrations, tBRSKI services can use DNS-SD or GRASP, and cBRSKI
services can use DNS-SD, GRASP, or CORE-LF for discovery. This
document does not specify CORE-LF discovery for tBRSKI, because the
existing CoRE registrations for BRSKI are specific to cBRSKI and
CoAPS.
The initial content of this sub-registry is as follows.
Designated Experts: TBD.
Registration Procedure: Specification Required.
Notes: See [ThisRFC], Section 5.4.2
Eckert & Dijk Expires 4 May 2027 [Page 63]
Internet-Draft BRSKI-discovery October 2026
+=====================+=======+=========+============+============+===========+
|Service Name(s) |Context|Discovery|Parameter(s)|Reference(s)|Notes |
| | |Mechanism| | | |
+=====================+=======+=========+============+============+===========+
|brski-proxy |tBRSKI |DNS-SD |tcp |RFC8995 |Proxy |
+---------------------+-------+---------+------------+------------+-----------+
|brski-registrar |tBRSKI |DNS-SD |tcp |RFC8995 |Registrar |
| | | | | |(stateful) |
+---------------------+-------+---------+------------+------------+-----------+
|AN_Proxy |tBRSKI |GRASP |IPPROTO_TCP |RFC8995 |Proxy |
+---------------------+-------+---------+------------+------------+-----------+
|AN_join_registrar |tBRSKI |GRASP |IPPROTO_TCP |RFC8995 |Registrar |
| | | | | |(stateful) |
+---------------------+-------+---------+------------+------------+-----------+
|brski-jp |cBRSKI |CORE-LF |coaps |I-D.ietf- |Proxy |
| | | |(target |anima- | |
| | | |attribute) |constrained-| |
| | | | |join-proxy | |
+---------------------+-------+---------+------------+------------+-----------+
|brski |cBRSKI |CORE-LF |coaps |I-D.ietf- |Registrar |
| | | | |anima- |(stateful) |
| | | | |constrained-| |
| | | | |voucher, I- | |
| | | | |D.ietf- | |
| | | | |anima- | |
| | | | |constrained-| |
| | | | |join-proxy | |
+---------------------+-------+---------+------------+------------+-----------+
|brski.rjp |cBRSKI |CORE-LF |jpy |I-D.ietf- |Registrar |
| | | | |anima- |(stateless)|
| | | | |constrained-| |
| | | | |join-proxy | |
+---------------------+-------+---------+------------+------------+-----------+
|AN_Proxy |cBRSKI |GRASP |IPPROTO_UDP |THIS-RFC |Proxy |
+---------------------+-------+---------+------------+------------+-----------+
|AN_join_registrar |cBRSKI |GRASP |IPPROTO_UDP |THIS-RFC |Registrar |
| | | | | |(stateful) |
+---------------------+-------+---------+------------+------------+-----------+
|AN_join_registrar_rjp|cBRSKI |GRASP |IPPROTO_UDP |THIS-RFC |Registrar |
| | | | | |(stateless)|
+---------------------+-------+---------+------------+------------+-----------+
|brski-proxy |cBRSKI |DNS-SD |udp |THIS-RFC |Proxy |
+---------------------+-------+---------+------------+------------+-----------+
|brski-registrar |cBRSKI |DNS-SD |udp |THIS-RFC |Registrar |
| | | | | |(stateful) |
+---------------------+-------+---------+------------+------------+-----------+
|brski-registrar-rjp |cBRSKI |DNS-SD |udp |THIS-RFC |Registrar |
| | | | | |(stateless)|
Eckert & Dijk Expires 4 May 2027 [Page 64]
Internet-Draft BRSKI-discovery October 2026
+---------------------+-------+---------+------------+------------+-----------+
|brski-pledge |BRSKI- |DNS-SD |tcp |I-D.anima- | |
| |PLEDGE | | |brski-prm, | |
| | | | |THIS-RFC | |
+---------------------+-------+---------+------------+------------+-----------+
Table 6: Service Name(s) initial sub-registry table
5.4.3. Variation Type Choices
IANA is asked to create a sub-registry called "Variation Type
Choices" in the "BRSKI Discovery Parameters" registry.
The Registration Procedure for this registry is Specification
Required, where the Expert Review has to ensure the feasibility of
entries with respect to the following expectations/rules.
Each row registers one Variation Type Choice for one Context (as
registered in Section 5.4.1), and specifies the Variation Type (also
as registered in Section 5.4.1) for which it is a choice.
All Variation Type Choices MUST be unique across all Variation Types,
so that the Variation Type can always be deduced from the Variation
Type Choice. This permits future encodings that do not necessarily
have to use the Variation String representation (as registered in
Section 5.4.4), and also makes it easier to recognize erroneous
variation representations.
Because they are used in protocol encodings, Variation Type Choices
MUST be as simple as possible. They MUST consist only of the
characters a-z and 0-9.
The "Dflt" flag indicates that the Variation Type Choice is the
default choice for its Variation Type. Default choices are not
included in the Variation String encoding of Variations. When new
Variation Types are added to a Context to introduce variations of a
new aspect of BRSKI, the backward-compatible choice has to become the
default choice for that new Variation Type.
The "Rsvd" flag indicates a choice that has not been sufficiently
vetted/specified to allow its use in Variations (Section 5.4.4), but
that is known to be a possible candidate and is reserved to track
that possible extension through future specification work.
References in parentheses specify the necessary functionality for a
Variation Type Choice, but do not specify the actual registration of
the Variation Type Choice.
Eckert & Dijk Expires 4 May 2027 [Page 65]
Internet-Draft BRSKI-discovery October 2026
The initial content is as follows.
Designated Experts: TBD.
Registration Procedure: Specification required.
+=====+=========+=========+=======+============================+===========+
|Flags|Variation|Variation|Context|Reference(s) |Note(s) |
| |Type |Type | | | |
| |Choice | | | | |
+=====+=========+=========+=======+============================+===========+
|Dflt |rrm |mode |tBRSKI |(RFC8995),ThisRFC |Registrar |
| | | | | |Responder |
| | | | | |Mode |
+-----+---------+---------+-------+----------------------------+-----------+
| |prm |mode |tBRSKI |(I-D.ietf-anima-brski- |Pledge |
| | | | |prm),ThisRFC |Responder |
| | | | | |Mode |
+-----+---------+---------+-------+----------------------------+-----------+
|Dflt |cmsj |vformat |tBRSKI |(RFC8366bis,RFC8995),ThisRFC|CMS-signed |
| | | | | |JSON |
| | | | | |Voucher |
+-----+---------+---------+-------+----------------------------+-----------+
| |jose |vformat |tBRSKI |(I-D.ietf-anima-jws- |JOSE-signed|
| | | | |voucher),ThisRFC |JSON |
+-----+---------+---------+-------+----------------------------+-----------+
| |cose |vformat |tBRSKI |ThisRFC |CBOR with |
| | | | | |COSE |
| | | | | |signature |
+-----+---------+---------+-------+----------------------------+-----------+
|Dflt |est |enroll |tBRSKI |(RFC7030,RFC8995),ThisRFC |Enrollment |
| | | | | |over Secure|
| | | | | |Transport |
+-----+---------+---------+-------+----------------------------+-----------+
| |cmp |enroll |tBRSKI |(RFC9733,RFC9483),ThisRFC |Lightweight|
| | | | | |CMP Profile|
| | | | | |/ BRSKI-AE |
+-----+---------+---------+-------+----------------------------+-----------+
|Rsvd |scep |enroll |tBRSKI |ThisRFC |common |
| | | | | |legacy |
| | | | | |option |
+-----+---------+---------+-------+----------------------------+-----------+
|Dflt |rrm |mode |cBRSKI |(I-D.anima-constrained- |Registrar |
| | | | |voucher),ThisRFC |Responder |
| | | | | |Mode |
+-----+---------+---------+-------+----------------------------+-----------+
|Dflt |cose |vformat |cBRSKI |(I-D.ietf-anima-constrained-|CBOR with |
| | | | |voucher),ThisRFC |COSE |
Eckert & Dijk Expires 4 May 2027 [Page 66]
Internet-Draft BRSKI-discovery October 2026
| | | | | |signature |
+-----+---------+---------+-------+----------------------------+-----------+
| |cmsj |vformat |cBRSKI |ThisRFC |CMS-signed |
| | | | | |JSON |
| | | | | |Voucher |
+-----+---------+---------+-------+----------------------------+-----------+
| |jose |vformat |cBRSKI |ThisRFC |JOSE-signed|
| | | | | |JSON |
+-----+---------+---------+-------+----------------------------+-----------+
|Dflt |est |enroll |cBRSKI |[RFC9148], ThisRFC |Enroll via |
| | | | | |EST over |
| | | | | |COAP |
+-----+---------+---------+-------+----------------------------+-----------+
| |cmp |enroll |cBRSKI |(RFC9733,RFC9483),ThisRFC |Lightweight|
| | | | | |CMP Profile|
| | | | | |/ BRSKI-AE |
+-----+---------+---------+-------+----------------------------+-----------+
|Dflt |prm |mode |BRSKI- |(I-D.ietf-anima-brski- |Pledge |
| | | |PLEDGE |prm),ThisRFC |responder |
| | | | | |Mode |
+-----+---------+---------+-------+----------------------------+-----------+
|Dflt |jose |vformat |BRSKI- |(I-D.ietf-anima-brski- |JOSE-signed|
| | | |PLEDGE |prm),ThisRFC |JSON |
+-----+---------+---------+-------+----------------------------+-----------+
|Rsvd |cmsj |vformat |BRSKI- |(I-D.ietf-anima-brski- |CMS-signed |
| | | |PLEDGE |prm),ThisRFC |JSON |
| | | | | |Voucher |
+-----+---------+---------+-------+----------------------------+-----------+
|Rsvd |cose |vformat |BRSKI- |(I-D.ietf-anima-brski- |CBOR with |
| | | |PLEDGE |prm),ThisRFC |COSE |
| | | | | |signature |
+-----+---------+---------+-------+----------------------------+-----------+
|Dflt |est |enroll |BRSKI- |(I-D.ietf-anima-brski- |Enroll via |
| | | |PLEDGE |prm),ThisRFC |EST |
| | | | | |modified |
| | | | | |for PRM |
+-----+---------+---------+-------+----------------------------+-----------+
| |cmp |enroll |BRSKI- |(RFC9733,RFC9483,I-D.ietf- |Lightweight|
| | | |PLEDGE |anima-brski-prm),ThisRFC |CMP Profile|
| | | | | |with PRM |
+-----+---------+---------+-------+----------------------------+-----------+
Table 7: Variation Type Choices initial sub-registry table
5.4.4. Variations
IANA is asked to create a sub-registry called "Variations" in the
"BRSKI Discovery Parameters" registry.
Eckert & Dijk Expires 4 May 2027 [Page 67]
Internet-Draft BRSKI-discovery October 2026
The Registration Procedure for this registry is Specification
Required, where the Expert Review has to ensure the feasibility of
entries with respect to the following behavior/rules.
Each row registers one or more Variation String(s) that represent one
Variation in one Context, and specifies the combination of Variation
Type Values indicated by that Variation.
Variation Type Values MUST be listed in the order in which their
Variation Types appear in Section 5.4.1, including the default
Variation Type Values for the Variation Types known at the time of
registration. Once a Variation String for a Context is registered,
its listed Variation Type Values SHOULD NOT be modified (except to
correct an erroneous registration).
The primary Variation String SHOULD be derived by concatenating the
listed Variation Type Values, separated by "-", except for default
values. This is called the standard Variation String construction
rule. The empty string is represented as "".
Any Variation String that does not follow this construction rule
SHOULD receive a note explaining why.
When new Variation Types are later introduced into the Contexts table
(Section 5.4.1), they will not lead to a change in the Variation
String(s); instead, it is understood that the Variation represents
the default Variation Type Values for any such additional Variation
Types.
This registry table exists to document which specification(s) use
specific Variations, so that implementations do not have to consider
supporting arbitrary possible (but not validated by specification)
Variations.
The sub-registries specified above register the permissible Context
and Variation Type Values.
The initial content is as follows.
Designated Experts: TBD.
Registration Procedure: Specification required.
Notes: (1) For backward compatibility with [BRSKI], Section 4.3, the
Eckert & Dijk Expires 4 May 2027 [Page 68]
Internet-Draft BRSKI-discovery October 2026
objective-value of the GRASP objective AN_join_registrar for this
Variation MUST be the exact (uppercase) string "EST-TLS", and
receivers MUST treat an AN_join_registrar objective-value of "EST-
TLS" as this Variation. In all other cases, including the GRASP
objective AN_Proxy ([BRSKI], Section 4.1.1), this Variation is
signaled with the Variation String "".
+=========+=======+=========+===========================+==========+
|Variation|Context|Variation| Specification(s) |Notes |
|String | | | | |
+=========+=======+=========+===========================+==========+
|"" |tBRSKI |rrm cmsj | RFC8995 |See Note |
| | |est | |(1) |
+---------+-------+---------+---------------------------+----------+
|cmp |tBRSKI |rrm cmsj | RFC9733 | |
| | |cmp | | |
+---------+-------+---------+---------------------------+----------+
|prm-jose |tBRSKI |prm jose | (I-D.ietf-anima-jws- |I-D.ietf- |
| | |est | voucher,I-D.ietf-anima- |anima- |
| | | | brski-prm),ThisRFC |brski-prm |
| | | | |also |
| | | | |includes |
| | | | |required |
| | | | |extensions|
| | | | |to EST |
+---------+-------+---------+---------------------------+----------+
|"" |cBRSKI |rrm cose | I-D.ietf-anima- | |
| | |est | constrained-voucher | |
+---------+-------+---------+---------------------------+----------+
|cmp |cBRSKI |rrm cose | (RFC9733,RFC9483),ThisRFC | |
| | |cmp | | |
+---------+-------+---------+---------------------------+----------+
|"" |BRSKI- |prm jose | I-D.ietf-anima-brski-prm | |
| |PLEDGE |est | | |
+---------+-------+---------+---------------------------+----------+
Table 8: Variations initial sub-registry table
5.5. BRSKI Well-Known URIs fixes (opportunistic)
The following change requests to "https://www.iana.org/assignments/
brski-parameters/brski-parameters.xhtml#brski-well-known-uris" are
cosmetic in nature, and are included in this document solely because
the mechanisms specified in this document imply support for Endpoint
URIs, and the existing registry has these cosmetic issues.
Eckert & Dijk Expires 4 May 2027 [Page 69]
Internet-Draft BRSKI-discovery October 2026
1. IANA is asked to change the name of the first column of the table
from "URI" to "URI Suffix". This aligns with other table columns
with the same syntax/semantics, such as in
"https://www.iana.org/assignments/well-known-uris/well-known-
uris.xhtml".
2. IANA is asked to change the Reference from "RFC8995" to "RFC8995,
Section 8.3.1".
3. IANA is asked to include the following "Note" text: "The
following table contains the assigned BRSKI protocol Endpoint URI
suffixes under "/.well-known/brski"." This note is added to
introduce the term "Endpoint" into the registry table, as that is
the term commonly used (instead of URI) in several of the memos
for which this discovery document was written. It is meant to
help readers map the registry to the terminology used in those
documents.
6. Security Considerations
This document only discusses the use of discovery for BRSKI within
well-controlled networks, not across the Internet. Procedures for
BRSKI across the Internet are covered in
[I-D.ietf-anima-brski-cloud]. That document can support the
discovery of Registrars (only) for trusted DNS names and trust
anchors that are hard-coded into the discovering Pledges (such as
those from their manufacturer or its agents), but not the more
flexible framework of this document.
None of the attacks possible via discovery can result in a successful
BRSKI enrollment, because of the PKI authentication used. Instead,
all attack vectors are Denial-of-Service attacks: generating fake
service announcements to distract from correct announcements, or
overloading the network or service-announcing nodes with traffic or
requests. None of these attacks are specific to or new with BRSKI
discovery; they are all well-understood issues of the discovery
mechanisms used, and they are manageable, as shown by the use of
those discovery mechanisms.
In [BRSKI-PRM], pledges are more easily subject to DoS attacks than
in [BRSKI], because attackers can act as initiators. They can delay
or prevent the enrollment of a pledge by opening so many connections
to the pledge that a valid Registrar-Agent's connection to the pledge
may not be possible. Discovery of the pledge via DNS-SD increases
the ability of attackers to find pledges against which such DoS
attacks can be attempted.
Eckert & Dijk Expires 4 May 2027 [Page 70]
Internet-Draft BRSKI-discovery October 2026
Especially when supporting DNS-SD browsing across unicast DNS,
pledges MUST implement DoS prevention measures, such as limiting the
number and rate of accepted TCP connections on a per-initiator basis.
If feasible for the implementation, simultaneous connections SHOULD
be possible, so that an ongoing attacker connection will not delay a
valid Registrar-Agent connection. When accepting connections, a
strategy such as LRU MAY be used to ensure that an attacker will not
be able to monopolize connections.
Browsing via DNS-SD, especially via unicast DNS, which makes
information available network-wide, also introduces a passive attack:
gathering intelligence about the type and serial number of devices
installed in the network. Whether or not this is seen as a relevant
risk is highly installation dependent. Networks SHOULD implement
filtering measures at the mDNS and/or DNS RR/service level to prevent
such data collection if there is a risk and it is seen as an
undesirable attack vector.
Service instance names as defined in Section 3.4 are used to discover
pledges by their manufacturer-assigned serial numbers. Today, DNS-SD
does not provide security against impersonation of such service
instance names. Instead, impersonation can only be, and will only
be, discovered after performing BRSKI connections to the pledge. It
should be noted that the scheme used by Section 3.4 could actually be
used to protect against impersonation when [DNSSD-SRP] is used with
some security extension. Pledges would need to authenticate their
SRP registrations with their IDevID. The SRP server would need to
have the same manufacturer Service Instance Name schema and
manufacturer trust anchor information as BRSKI registrars. It could
then allow only the permissible service instance name DNS-SD RRs for
this pledge. In fact, the SRP server could create all the DNS-SD RRs
required by Section 3.4 from the IDevID information, even if the
pledge itself does not request them or requests other DNS-SD RRs.
Definition of these procedures is, however, outside the scope of this
specification.
None of the discovery mechanisms (DNS-SD, GRASP, or CORE-LF) is
necessarily secure. Instead, how trustworthy service announcements
are is a matter of their deployment. In an unprotected deployment
with DNS-SD via mDNS, for example, an attacker could attract
connections from initiators by announcing itself with the best
priority value. When a deployment instead uses a secure domain
deployment model, such as an [ACP], a secured wireless mesh
technology, or discovery via a secured DNS server, then service
announcements, and with them their service parameters, are typically
assumed to be trustworthy. In those deployments, the security
question is then primarily about the attack vectors for impairing
such a responder to make it behave in undesirable ways.
Eckert & Dijk Expires 4 May 2027 [Page 71]
Internet-Draft BRSKI-discovery October 2026
Encrypted and authenticated transports for discovery mechanisms, such
as DoT ([RFC7858]) or DoQ ([RFC9250]), are useful to have, but they
require trust anchors, usually those of the WebPKI. Most service-
announcing entities inside many controlled networks will not be able
to provide such trust anchors, due to an intentional lack of Internet
connectivity. These trust anchors may also be fragile with respect
to expiry for requesting devices such as Pledges, which may sit on
shelves for a decade before being activated.
7. Acknowledgments
Many thanks for reviews by Arthur Hecker and Steffen Fries, and for
discussions/feedback from Brian Carpenter, Michael Richardson,
Michael Kovatsch, and Stuart Cheshire. Special thanks to Amanda
Barber for her IANA section review. Thanks a lot for Russ Housley's
IOTDIR review, Xiao Min's OPSDIR review, and Daniele Ceccarelli's
RTGDIR review.
7.1. Limitations
[RFC Editor: please remove this section.]
In version -16 of this document, transport-independent discovery via
CORE-LF had to be dropped, because the pre-existing CoRE
registrations for BRSKI are specific to CoAPS: the target attribute
"brski-jp" that [cPROXY] registers for the discovery of Join Proxies
by pledges is defined only for CoAPS endpoints (coaps://host:port),
and the resource type "brski" registered by [cBRSKI] is defined as
the base resource of the cBRSKI resources. Hence, this version of
the document also removes CORE-LF support for tBRSKI.
Updating these IANA registrations to be transport-independent (for
example, by letting the scheme of the link determine the transport)
may open the path to simple, transport-independent resource types
again. It is unclear, however, what impact this would have on pre-
existing implementations.
7.2. Change log
[RFC Editor: please remove this section.]
WG draft 16:
Semantic fixes from claude.ai:
* simplify encoding to remove unnecessary variation string aliases
to simplify coding
Eckert & Dijk Expires 4 May 2027 [Page 72]
Internet-Draft BRSKI-discovery October 2026
- fix inconsistencies in specification of EST-TLS backward
compatibility: "EST-TLS" is now only used (and required) as the
GRASP AN_join_registrar objective-value for the default BRSKI
variation, everywhere else this variation is signaled as "".
Removed the "est-tls" alternative Variation String.
- Variation Strings: removed the recommendation for non-empty
alternative Variation Strings, so every Variation has exactly
one Variation String, constructed by the standard rule (default
Variation Type Choices omitted). Fixed examples accordingly:
"rrm-cmsj-est" -> "prm-jose" (Variation Strings section) and ""
(QUIC example), "rrm-cose" and cBRSKI "rrm" -> "", "prm" ->
"prm-jose".
- Variations registry: BRSKI-PLEDGE Variation String "prm-jose"
-> "" (both "prm" and "jose" are defaults in that context).
Note (1) rewritten for the GRASP "EST-TLS" exception.
- CORE-LF: "var=" value is now comma-separated (same as DNS-SD)
instead of space-separated, so that the empty Variation String
can be included in a list. The value MUST be a quoted-string
when it contains a comma.
- Join Proxy support for Variations: added requirement (MUST) for
Join Proxies to treat an AN_join_registrar objective-value of
"EST-TLS" as the Variation String "".
* Variations registry: added cBRSKI Variation "cmp" (rrm cose cmp),
as already assumed by the update to RFC9733.
* CORE-LF: reworked to align with draft-ietf-anima-constrained-join-
proxy-21 and draft-ietf-anima-constrained-voucher-31
- Join Proxy discovery by pledges now uses the target attribute
"brski-jp" (replacing the obsolete resource type "brski.jp").
- Stateful registrar discovery now uses the resource type "brski"
(the non-existent "brski.rs" is removed).
- Stateless registrar discovery uses the resource type
"brski.rjp" with scheme "jpy" (replacing "brski.rjpy",
"brski.jpy" and "coaps+jpy").
- "var" and "pw" are specified as additional target attributes on
these links (for "brski-jp" links, "pw" applies to the
indicated join-port); the template now queries for a specific
service instead of the wildcard "rt=brski.*" (not sent per
cPROXY).
Eckert & Dijk Expires 4 May 2027 [Page 73]
Internet-Draft BRSKI-discovery October 2026
- Service Names registry: updated CORE-LF rows accordingly; CORE-
LF Service Names can now also be target attributes.
- Endpoint shortening example: updated to the resource types
registered in cBRSKI (brski, brski.rv, brski.vs).
- Fixed RFC6690 update text to refer to the Service Names sub-
registry instead of the Contexts sub-registry.
* removed CORE-LF discovery for tBRSKI (https), because the pre-
existing CoRE registrations of cPROXY ("brski-jp") and cBRSKI
("brski") are CoAPS/cBRSKI specific. Removed the tBRSKI CORE-LF
rows from the Service Names registry and adjusted text and
examples. Added section "Limitations" explaining this.
* registry fixes
- Contexts registry: Notes column now references the section
specifying each context.
- Service Names registry: Notes for brski-registrar-rjp corrected
from "Proxy (stateless)" to "Registrar (stateless)".
- Service Names registry: removed a misplaced paragraph about
Variation Type Choice syntax (belongs to, and is already
covered by, the Variation Type Choices registry).
- Service Name registry update: Defined TXT keys text for brski-
registrar-rjp now only refers to "udp".
- Variation String ordering: it is the order of Variation Types
in the Contexts registry (not of Variation Type Choices) that
matters; fixed in the Variation Strings section and the
Variations registry text.
* other fixes
- Protection against malicious service announcements: the
recommendation is for responders (not initiators), and now
refers to the most preferred values (in DNS-SD, the lowest
priority value and the highest weight) instead of the highest
numerical values.
- DNS-SD operational considerations: moved text so that "DNS
Server Redundancy" and "DNS Server Discovery" contain the
matching content.
Eckert & Dijk Expires 4 May 2027 [Page 74]
Internet-Draft BRSKI-discovery October 2026
- Security considerations: SRP does not use TLS; reworded the
IDevID authentication of SRP registrations.
- Renamed section "Registrar Operations Modes" to "Join Proxy
Operation Modes".
- Appendix (WebPKI): removed stray ">".
- DNS-SD requirements: "adjacent subnets" -> "directly connected
subnets" (mDNS is link-local).
- Roles and Services: removed "These functionalities are called
roles", which incorrectly equated services with roles, and
removed the duplicate definition of "service" (moving its
remaining sentence into the second paragraph).
- Updates to RFC9733: fixed typo "MRSI" -> "BRSKI".
- Updates to BRSKI-PRM: "the procedures of this document" -> "the
procedures of [ThisRFC]", because the text is inserted into
BRSKI-PRM.
- GRASP Join Proxy example text: "TTL" -> "loop-count" (the GRASP
objective field name).
- Fixed reviewer names in Acknowledgments and change log.
* renamed Context "BRSKI" to "tBRSKI" in all registry tables and in
text referring to the context, consistent with the context name
already used in the text (since WG draft 07).
* fix GRASP examples
- fixed capitalization of objective names "AN_Join_Registrar" ->
"AN_join_registrar" (as in RFC8995 and the registry tables).
- fixed M_FLOOD syntax to follow the flood-message CDDL of
RFC8990 (no extra list around the objective/locator pairs,
missing/extra commas, locator option misplaced inside the
objective in the separate-processes example).
- Join Proxy example: changed objective name from
"AN_join_registrar" to "AN_Proxy", because the announcing node
is a Join Proxy, and removed the "AN_join_registrar_rjp"
announcement, because stateless (rjp) objectives are only
announced by registrars, not by Join Proxies towards pledges
(as the text already stated).
Eckert & Dijk Expires 4 May 2027 [Page 75]
Internet-Draft BRSKI-discovery October 2026
- registrar example text: corrected the number of service
instances in the example (four, not three).
WG draft 15:
English language fixup from claude.ai including shortening of long
sentences
WG draft 14:
Incorporated replies for IOTDIR early review from Russ Housley.
* Shortened abstract
* Rewrote most parts of chapter 2 to better focus on design
rationale and remove redundancies
* Changed title of Section 3.1 to "Information Model and
Registrations"
* Various details.
* Moved 3.4.4 WebPKI discussion into appendix
* Changed title of 3.5.1.1 to "Requirements"
* Enhanced titles of further 3.5.1.x subsections
* changed title of 3.5.2.1 to "Requirements"
* Fixed "MUST" / "SHOULD NOT" capitalization
* Changed formatting of section 4.1 (Updates to prior RFC) text to
use indentation with "|" marking and adjusted text so it reads as
if text is insserted into the original (updated) RFC.
* Added paragraphs to security consideration about this being for
controlled networks and that attacks known can not break the
authentication mechanisms, just create DoS.
* Added paragraph about problematic benefits of authenticated
discovery mechanisms.
Incorporated replies for RTGDIR early review from Daniele Ceccarelli.
* Added section 2.2 Scope Limitations
Eckert & Dijk Expires 4 May 2027 [Page 76]
Internet-Draft BRSKI-discovery October 2026
* Added section 3.1.1 "Summary" as a cheat sheet how to read the
document, specifically for developers
* changed example 3.5.1.5 to discovery of brski-proxy because that's
where the used .local addresses make sense , enhanced text.
* 3.1.6 added explanation for semantic of variation type choices.
* 5.4 added section references into registration table
Incorporated replies for Xiao Min's OPSDIR review - added 3.6 use of
multiple discovery mechanisms - various other fixes just also found
and fixed for Russ first (random order of processing reviews)
Incorporated RTGDIR
WG draft 13:
3nd run with claude.ai: "Please fix spelling mistakes in this
document including fixing real bad sentences." 2 incorrect fixes
(recurring from WG-draft 10): "SHOULD/MUST not" -> "SHOULD/MUST NOT".
"perpass" -> "passive". Now hopefully fixed to happen again with
editorial note for claude.ai.
WG draft 12:
Third part for Stuart Cheshire review:
Rewrote abstract to be shorter
Rewrote initial part of introduction to be better.
Added "Discovery Challenges" section to Introduction covering the
reasons for why this document does discuss DNS-SD library internals.
Expanded abbreviations on first use.
WG draft 11:
Second part for Stuart Cheshire review:
New intro for Overview section.
Re-did section 3.5.1.1 answering to concerns of Stuart that it was
discussing details only of interest to DNS-SD library developers.
Eckert & Dijk Expires 4 May 2027 [Page 77]
Internet-Draft BRSKI-discovery October 2026
Changed variation encoding for DNS-SD to be fully compliant with DNS-
SD RFC. Keys can only be 9 charcters long (SHOULD really means MUST
- there will be pre-existing implementations that will not allow
longer key strings!), so we can not make variation strings keys. Now
it's "var={variation,}".
WG draft 10:
First part for Stuart Cheshire review: Run draft through claude.ai
prompt: "please fix up the english with minimum amount of changes in
the following krmdown-rfc format file:. 50++ small fixes. 2
incorrect: "SHOULD not" -> "SHOULD NOT". "perpass" -> "passive".
WG draft 09:
Small editorial fix. Table incorrectly split by empty lines.
WG draft 08:
Overhauled IANA section after IANA early review. Changed tables so
every table has only one key registered item which is usually in the
first column. Eliminated formatting based registration, eg.: no more
"multi-line" registration - does not work because the registries are
databased. Removed optical beautification of keeping cells empty to
indicate repetition of previous row content. This too does not work
for IANA registry because they allow re-ordering of rows by column.
Also rewrote/shortened the Registry Data Model section to fit the new
IANA section. Put Discussions section before IANA discussion so it
is clear it is part of the overall data model, not the IANA
representation.
Added updates to BRSKI-AE and BRSKI-PRM text that details how BRSKI
Discovery is to be used for both RFCs mechanisms. Also made this doc
an update to BRSKI-AE to ensure it is tracked that way.
Moved all other IANA consideration before the ask for the new BRSKI
Discovery Parameters, as this looks more logical - except for the
opportunistic ask.
As a result of creating more tables and hence removing columns, the
tables "should" actually fit into the 72 character TXT rendering as
soon as the I-D... draft references in them are replaced by RFC
references, which should happen in RFC editor queue before this
document gets published (hope, hope...).
Removed appendix "possible future variations"
Eckert & Dijk Expires 4 May 2027 [Page 78]
Internet-Draft BRSKI-discovery October 2026
Made document update to rfc6690 to allow formalizing request to
update CORE RT= parameter range table with BRSKI entries, see section
4.1.1.
WG draft 07:
Defined document to be update to draft-ietf-anima-brski-prm (for the
specification of IDevID derived DNS-SD discovery of pledges)
Resolved open Q text whether SRP allows discovery of SRP server.
According to Stuart Cheshire this is supported.
Incorporated initial Feedback from Michael Kovatsch
Added section explaining that there is no spec for how to do pledge
discovery via CORE-LF or GRASP.
* Rewrote 2.1 Challenges to now be a more comprehensive set of 3
example deployment issues without this work.
Incorporated review by Arthur Hecker
* Rewrote abstract to more comprehensively (and easier
understandable) describe the scope of this document
* Simplified terminology: removed "variation context", now only
calling it "context".
* changed name of BRSKI context in IANA registry to 'tBRSKI' (TCP
BRSKI) - to make it easier to know when text refers to BRSKI as an
overall concept or specifically to the TCP based set of variations
of BRSKI.
* Removed duplicate text paragraphs in proxy sections.
* Added note about (in)security of discovery mechanisms in general
and how deployments typically defer to the "secure domain" context
to overcome this issue.
* Large number of textual fixes (thanks a lot for the thorough
read!).
WG draft 06:
Initial overview review feedback from Michael Kovatsch and Arthur
Hecker
Eckert & Dijk Expires 4 May 2027 [Page 79]
Internet-Draft BRSKI-discovery October 2026
Made abstract and Challenges introduction hopefully better explaining
the scope of the document and motivate its need.
Review Steffen Fries:
Cleaned up terminology IP/IPv6 -> IP/IPv4/IPv6.
CA -> trust anchor
BRSKI proxy -> Join Proxy for consistency with RFC8995.
Added mentioning of Registrar-Agent from BRSKI-PRM where appropriate
Rewrote 2.1.3 to make the functionality of variation agnostic
proxying clearer (hopefully)
Rewrote 3.1.1 to more clearly define role and services and
distinguish them.
Changed "cms" to "cmsj"(as well as derived variation strings) so that
it is clear that this variation type does not mean all possible
encoding options for CMS but only JSON.
Added explanation about the fact that a variation may introduce
changes to a variation type component that shares the same name
(3.1.6)
Noted that discovery of pledges does not apply in 3.2 which talks
about redundant service discovery/selection.
removed last paragraph from 3.3.2.2 - duplicate from earlier section.
Improved 3.4.3 by better structuring the example figure and rewriting
the explanation text as a step-by-step explanation how a Registrar-
Agent would perform the steps.
Fixed small bugs in GRASP example section 3.5.2.2 but ended up
improving examples a lot and make them more useful (registrar AND
proxy )
Eckert & Dijk Expires 4 May 2027 [Page 80]
Internet-Draft BRSKI-discovery October 2026
Still can not figure out how to nicely get hotlinks to the
terminology section definitions. They just show up in text format as
"Section 1" or the like. Giving up on the idea. TBD: Maybe ask RFC
editor/RSWG. Likewise, i can not have references to BRSKI RFCs both
with a logical name like BRSKI-PRM and in other places references
with the RFC number. I need to define both as references and then
the same RFC will have two entries. Stupid. Now i only have logical
references, but in all places where i need to actually reference the
RFC by number, such as IANA registries or pictures, i do not use
references anymore.
WG draft 05:
Major update to specify resilience aspects in selection of
responders.
Major update/simplification of CORE-LF section.
WG draft 02/03:
Fix up tables to be correctly rendered by html output.
WG draft 01:
Core-LF improvements / interim work.
WG draft 00:
Added section for CORE-LF. Still missing to update existing text
with the CORE-LF definitions.
Individual version 01:
Various enhancements
Individual version 00:
Initial version.
8. References
8.1. Normative References
[ACP] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/rfc/rfc8994>.
Eckert & Dijk Expires 4 May 2027 [Page 81]
Internet-Draft BRSKI-discovery October 2026
[BRSKI] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.
[BRSKI-AE] von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "BRSKI
with Alternative Enrollment (BRSKI-AE)", RFC 9733,
DOI 10.17487/RFC9733, March 2025,
<https://www.rfc-editor.org/rfc/rfc9733>.
[BRSKI-PRM]
Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
with Pledge in Responder Mode (BRSKI-PRM)", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-prm-23, 3
June 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-anima-brski-prm-23>.
[cBRSKI] Richardson, M., Van der Stok, P., Kampanakis, P., and E.
Dijk, "Constrained Bootstrapping Remote Secure Key
Infrastructure (cBRSKI)", Work in Progress, Internet-
Draft, draft-ietf-anima-constrained-voucher-31, 8 June
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
anima-constrained-voucher-31>.
[CORE-LF] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/rfc/rfc6690>.
[cPROXY] Dijk, E., Richardson, M., Van der Stok, P., and P.
Kampanakis, "Join Proxy for Onboarding of Constrained
Network Elements", Work in Progress, Internet-Draft,
draft-ietf-anima-constrained-join-proxy-21, 21 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima-
constrained-join-proxy-21>.
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
[DNSSD-SRP]
Lemon, T. and S. Cheshire, "Service Registration Protocol
for DNS-Based Service Discovery", RFC 9665,
DOI 10.17487/RFC9665, June 2025,
<https://www.rfc-editor.org/rfc/rfc9665>.
Eckert & Dijk Expires 4 May 2027 [Page 82]
Internet-Draft BRSKI-discovery October 2026
[EST] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/rfc/rfc7030>.
[GRASP] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
Autonomic Signaling Protocol (GRASP)", RFC 8990,
DOI 10.17487/RFC8990, May 2021,
<https://www.rfc-editor.org/rfc/rfc8990>.
[JWS-VOUCHER]
Werner, T. and M. Richardson, "JWS signed Voucher
Artifacts for Bootstrapping Protocols", Work in Progress,
Internet-Draft, draft-ietf-anima-jws-voucher-16, 15
January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-jws-voucher-16>.
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/rfc/rfc6762>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/rfc/rfc2782>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Eckert & Dijk Expires 4 May 2027 [Page 83]
Internet-Draft BRSKI-discovery October 2026
[RFC8366bis]
Watsen, K., Richardson, M., Dijk, E., Eckert, T. T., and
Q. Ma, "A Voucher Artifact for Onboarding Protocols", Work
in Progress, Internet-Draft, draft-ietf-anima-rfc8366bis-
39, 26 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima-
rfc8366bis-39>.
[RFC9148] van der Stok, P., Kampanakis, P., Richardson, M., and S.
Raza, "EST-coaps: Enrollment over Secure Transport with
the Secure Constrained Application Protocol", RFC 9148,
DOI 10.17487/RFC9148, April 2022,
<https://www.rfc-editor.org/rfc/rfc9148>.
[RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
P. van der Stok, "Constrained RESTful Environments (CoRE)
Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
2022, <https://www.rfc-editor.org/rfc/rfc9176>.
[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", RFC 9483,
DOI 10.17487/RFC9483, November 2023,
<https://www.rfc-editor.org/rfc/rfc9483>.
8.2. Informative References
[COAP] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[HRW98] Thaler, D. D. and C. V. Ravishankar, "Using Name-Based
Mappings to Increase Hit Rates", 1998,
<https://www.microsoft.com/en-us/research/wp-
content/uploads/2017/02/HRW98.pdf>.
[I-D.eckert-anima-grasp-dnssd]
Eckert, T. T., Boucadair, M., Jacquenet, C., and M. H.
Behringer, "DNS-SD Compatible Service Discovery in GeneRic
Autonomic Signaling Protocol (GRASP)", Work in Progress,
Internet-Draft, draft-eckert-anima-grasp-dnssd-09, 14
October 2026, <https://datatracker.ietf.org/doc/html/
draft-eckert-anima-grasp-dnssd-09>.
[I-D.ietf-anima-brski-cloud]
Friel, O., Shekh-Yusef, R., and M. Richardson,
"Bootstrapping Remote Secure Key Infrastructure (BRSKI)
Cloud Registrar", Work in Progress, Internet-Draft, draft-
Eckert & Dijk Expires 4 May 2027 [Page 84]
Internet-Draft BRSKI-discovery October 2026
ietf-anima-brski-cloud-19, 9 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima-
brski-cloud-19>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/rfc/rfc7390>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/rfc/rfc7858>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/rfc/rfc8106>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/rfc/rfc8288>.
[RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol",
RFC 8894, DOI 10.17487/RFC8894, September 2020,
<https://www.rfc-editor.org/rfc/rfc8894>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/rfc/rfc9250>.
[RFC9423] Bormann, C., "Constrained RESTful Environments (CoRE)
Target Attributes Registry", RFC 9423,
DOI 10.17487/RFC9423, April 2024,
<https://www.rfc-editor.org/rfc/rfc9423>.
[RFC9722] Brissette, P., Sajassi, A., Burdet, LA., Ed., Drake, J.,
and J. Rabadan, "Fast Recovery for EVPN Designated
Forwarder Election", RFC 9722, DOI 10.17487/RFC9722, May
2025, <https://www.rfc-editor.org/rfc/rfc9722>.
[RFC9799] Misell, Q., Ed., "Automated Certificate Management
Environment (ACME) Extensions for ".onion" Special-Use
Domain Names", RFC 9799, DOI 10.17487/RFC9799, June 2025,
<https://www.rfc-editor.org/rfc/rfc9799>.
Eckert & Dijk Expires 4 May 2027 [Page 85]
Internet-Draft BRSKI-discovery October 2026
Appendix A. WebPKI derived instance schema
There is currently no automated mechanism to avoid the configuration
of manufacturer trust anchor certificates in BRSKI components that
need to authenticate pledges. However, the configuration of
additional instance schemas for different manufacturer device names
in BRSKI equipment could be avoided, if vendors and operators of
BRSKI-PLEDGE installations deem it appropriate to rely on WebPKI
trust anchors.
The trust anchor certificate itself (or a sub-CA in the certificate
chain) would then need to have a WebPKI trust anchor signature and a
DNS name that can easily be identified as being used for IDevIDs,
such as "*.idevid.example.com". The implied schema for the instance
string is then "<<X520SerialNumber>.DNS-name>", authenticating
instance names of the format "<X520SerialNumber>.idevid.example.com".
The added effort for manufacturers in this scheme is obtaining a
WebPKI signature, from a WebPKI trust anchor, for their trust anchor
for these wildcard domain names. This likely requires similar
alignment with the CA/Browser Forum, as the ACME extensions for
.onion did ([RFC9799]).
Contributors
Thomas Werner
Siemens AG
Germany
Email: thomas-werner@siemens.com
URI: https://www.siemens.com/
Steffen Fries
Siemens AG
Germany
Email: steffen.fries@siemens.com
URI: https://www.siemens.com/
Hendrik Brockhaus
Siemens AG
Germany
Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com/
Michael Richardson
Canada
Eckert & Dijk Expires 4 May 2027 [Page 86]
Internet-Draft BRSKI-discovery October 2026
Phone: +41 44 878 9200
Email: mcr+ietf@sandelman.org
David von Oheimb
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
Email: david.von.oheimb@siemens.com
URI: https://www.siemens.com/
Authors' Addresses
Toerless Eckert (editor)
Futurewei USA
United States of America
Email: tte@cs.fau.de
Esko Dijk
IoTconsultancy.nl
Email: esko.dijk@iotconsultancy.nl
Eckert & Dijk Expires 4 May 2027 [Page 87]