BRSKI discovery and variations
draft-ietf-anima-brski-discovery-05
| Document | Type | Active Internet-Draft (anima WG) | |
|---|---|---|---|
| Authors | Toerless Eckert , Esko Dijk | ||
| Last updated | 2024-10-21 | ||
| Replaces | draft-eckert-anima-brski-discovery | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-05
ANIMA T. Eckert, Ed.
Internet-Draft Futurewei
Intended status: Standards Track E. Dijk
Expires: 24 April 2025 IoTconsultancy.nl
21 October 2024
BRSKI discovery and variations
draft-ietf-anima-brski-discovery-05
Abstract
This document specifies how BRSKI entities, such as registrars,
proxies, pledges or others that are acting as responders, can be
discovered and selected by BRSKI entities acting as initiators,
especially in the face of variations in the protocols that can
introduce non-interoperability when not equally supported by both
responder and initiator.
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 24 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Eckert & Dijk Expires 24 April 2025 [Page 1]
Internet-Draft BRSKI-discovery October 2024
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Challenges . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Signaling BRSKI variation for responder selection. . 6
2.1.2. Consistent support for variations across different
discovery mechanisms. . . . . . . . . . . . . . . . . 7
2.1.3. Variation agnostic support for BRSKI proxies . . . . 7
2.2. Functional Summary . . . . . . . . . . . . . . . . . . . 8
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Data Model . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Service Names . . . . . . . . . . . . . . . . . . . . 9
3.1.3. Variations . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. Variation Types . . . . . . . . . . . . . . . . . . . 10
3.1.5. Variation Type Choices . . . . . . . . . . . . . . . 10
3.1.6. Variation Strings . . . . . . . . . . . . . . . . . . 10
3.1.7. Contexts . . . . . . . . . . . . . . . . . . . . . . 11
3.1.8. Registry Tables . . . . . . . . . . . . . . . . . . . 12
3.1.8.1. Variation Contexts Registry Table . . . . . . . . 12
3.1.8.2. Variation Type and Choices Registry Table . . . . 12
3.1.8.3. Variations and Variation String Registry Table . 14
3.1.9. Discussion . . . . . . . . . . . . . . . . . . . . . 14
3.2. Redundant Discovery and Selection . . . . . . . . . . . . 15
3.2.1. Responder Selection . . . . . . . . . . . . . . . . . 15
3.2.2. Service Announcements . . . . . . . . . . . . . . . . 17
3.2.3. Responder Selection in Proxies . . . . . . . . . . . 17
3.2.4. Protection against malicious service announcements . 19
3.3. Join Proxies Support for Discovery and Variations . . . . 19
3.3.1. Join Proxy support for Variations . . . . . . . . . . 19
3.3.2. Registrar Operations Modes . . . . . . . . . . . . . 20
3.3.2.1. Direction Connections Mode . . . . . . . . . . . 20
3.3.2.2. Best Registrar Selection Mode . . . . . . . . . . 20
3.3.2.3. Proxy in Name Only Mode on Registrars . . . . . . 22
3.3.2.4. Proxy Mode Discussion . . . . . . . . . . . . . . 23
3.3.3. Extensibility to non BRSKI services . . . . . . . . . 24
3.3.4. Scaling service discovery and selection . . . . . . . 24
3.4. Discoverable BRSKI Pledges . . . . . . . . . . . . . . . 25
Eckert & Dijk Expires 24 April 2025 [Page 2]
Internet-Draft BRSKI-discovery October 2024
3.4.1. BRSKI-PLEDGE context . . . . . . . . . . . . . . . . 25
3.4.2. Service Instance Name . . . . . . . . . . . . . . . . 26
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.4. WebPKI derived instance schema . . . . . . . . . . . 31
3.5. Variation signaling and encoding rules for different
discovery mechanisms . . . . . . . . . . . . . . . . . . 31
3.5.1. DNS-SD . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.1.1. Signaling . . . . . . . . . . . . . . . . . . . . 32
3.5.1.2. Variation String Encoding . . . . . . . . . . . . 32
3.5.1.3. Service Instance and Host Names . . . . . . . . . 33
3.5.1.4. Examples . . . . . . . . . . . . . . . . . . . . 34
3.5.2. GRASP . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2.1. Signaling . . . . . . . . . . . . . . . . . . . . 37
3.5.2.2. Encoding and Examples . . . . . . . . . . . . . . 37
3.5.3. CORE-LF . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.3.1. Overview . . . . . . . . . . . . . . . . . . . . 39
3.5.3.2. Background . . . . . . . . . . . . . . . . . . . 40
3.5.3.3. Specification . . . . . . . . . . . . . . . . . . 41
3.5.3.4. Examples . . . . . . . . . . . . . . . . . . . . 43
3.5.3.5. Resource Type Considerations . . . . . . . . . . 44
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 46
4.1. Core Parameters . . . . . . . . . . . . . . . . . . . . . 46
4.1.1. Resource Type Link Target Attribute Values . . . . . 46
4.1.2. Target Attributes . . . . . . . . . . . . . . . . . . 46
4.2. BRSKI Discovery Parameters Registry (section) . . . . . . 47
4.2.1. BRSKI Variation Context Registry Table . . . . . . . 47
4.2.2. BRSKI Variation Type and Choices Registry Table . . . 48
4.2.3. BRSKI Variations and Variation Strings . . . . . . . 50
4.3. Service Names Registry . . . . . . . . . . . . . . . . . 50
4.4. BRSKI Well-Known URIs fixes (opportunistic) . . . . . . . 51
5. Security Considerations . . . . . . . . . . . . . . . . . . . 51
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
7. Draft considerations . . . . . . . . . . . . . . . . . . . . 52
7.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 52
7.2. Change log . . . . . . . . . . . . . . . . . . . . . . . 53
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.1. Normative References . . . . . . . . . . . . . . . . . . 53
8.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Possible future variations . . . . . . . . . . . . . 57
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
Eckert & Dijk Expires 24 April 2025 [Page 3]
Internet-Draft BRSKI-discovery October 2024
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document relies on the terminology defined in Section 1. The
following terms are described partly in addition.
Context: See Variation Context.
Initiator: A host that is using an IP transport protocol to initiate
a connection or transaction to another host called the responder.
Initiator socket: A socket consisting of an initiators IP or IPv6
address, protocol and protocol port number from which it initiates
connections or transactions to a responder (typically UDP or TCP).
Objective Name: See Service Name.
Resource Type: See Service Name.
Responder: A host that is using an IP transport protocol to respond
to transaction or connection requests from an Initiator.
Responder socket: A socket consisting of a responders IP or IPv6
address, protocol and protocol port number on which it responds to
requests of the protocol (typically UDP or TCP).
Role: In the context of this document, a type of entity in a
variation of BRSKI that can act as a responder and whose supported
variations can be discovered. BRSKI roles relevant in this
document include Join Registrar, Join Proxy and Pledge. The IANA
registry defined by this document allows to specify variations for
any roles. See also Variation Context.
Socket: The combination of am IP or IPv6 address, an IP protocol
that utilizes a port number (such as TCP or UDP) and a port number
of that protocol.
Service Name: The name for (a subset of) the functionality/API
provided by a discoverable responder socket. This term is
inherited from Section 1 but unless otherwise specified also used
in this document to apply to any other discovery functionality/
API. The terminology used by other mechanisms typically differs.
For example, when Section 1 is used to discover a responder socket
Eckert & Dijk Expires 24 April 2025 [Page 4]
Internet-Draft BRSKI-discovery October 2024
for BRSKI, the Objective Name carries the equivalent to the
service name. In Section 1, the Resource Type (rt=) carries the
equivalent of the service name.
Type: See Variation Type.
Variation: A combination one one variation choice each for every
variation type applicable to the variation context of one
discoverable BRSKI communications. For example, in the context of
BRSKI, a variation is one choice for "mode", one choice for
"enroll" and once choice for "vformat".
Variation Context: A set of Services for whom the same set of
variations applies
Variation Type: The name for one aspect of a protocol for which two
or more choices exist (or may exist in the future), and where the
choice can technically be combined orthogonal to other variation
types. This document defined the BRSKI variation types "mode",
"enroll" and "vformat".
Variation Type Choice: The name for different values that a
particular variation type may have. For example, this document
does defines the choices "rrm" and "prm" for the BRSKI variation
"mode".
ACP: "An Autonomic Control Plane", [RFC8994].
BRSKI: "Bootstrapping Remote Secure Key Infrastructure", [RFC8995].
BRSKI-AE: "Alternative Enrollment Protocols in Section 1",
[I-D.ietf-anima-brski-ae].
BRSKI-PRM: "Section 1 with Pledge in Responder Mode",
[I-D.ietf-anima-brski-prm].
cBRSKI: "Constrained Bootstrapping Remote Secure Key Infrastructure
(Section 1)", [I-D.ietf-anima-constrained-voucher].
COAP: "The Constrained Application Protocol (CoAP)", [RFC7252].
CORE-LF: "Constrained RESTful Environments (CoRE) Link Format",
[RFC6690].
cPROXY: "Constrained Join Proxy for Bootstrapping Protocols",
[I-D.ietf-anima-constrained-join-proxy].
DNS-SD: "DNS-Based Service Discovery", [RFC6763].
Eckert & Dijk Expires 24 April 2025 [Page 5]
Internet-Draft BRSKI-discovery October 2024
EST: "Enrollment over Secure Transport", [RFC7030].
GRASP: "GeneRic Autonomic Signaling Protocol", [RFC8990].
GRASP-DNSSD: "DNS-SD Compatible Service Discovery in GeneRic
Autonomic Signaling Protocol (GRASP)",
[I-D.eckert-anima-grasp-dnssd].
JWS-VOUCHER: "JWS signed Voucher Artifacts for Bootstrapping
Protocols", [I-D.ietf-anima-jws-voucher].
lwCMP: "Lightweight Certificate Management Protocol (CMP) Profile",
[I-D.ietf-lamps-lightweight-cmp-profile].
mDNS: "multicast DNS", [RFC6762].
SCEP: "Simple Certificate Enrolment Protocol", [RFC8894].
2. Overview
2.1. Challenges
BRSKI is a protocol with several current variations of aspects of the
protocol. These variations exist to best serve different use-cases,
product development and solution deployment preferences. Additional/
new use-case preferences may prefer even further variations. All
these current and future variations introduce challenges with
interoperability, that the mechanisms defined in this document intent
to help sove. These challenges are as follows.
2.1.1. Signaling BRSKI variation for responder selection.
When an initiator such as a BRSKI proxy or BRSKI pledge uses a
mechanism such as Section 1 to discover an instance of a role it
intends to connect to, such as a registrar, it may discover more than
one such instance.
Eckert & Dijk Expires 24 April 2025 [Page 6]
Internet-Draft BRSKI-discovery October 2024
When an initiator uses a discovery mechanism such as Section 1 to
discover an instance of the BRSKI role that it intends to connect to,
it may discover more than one such instance. FOr example, BRSKI
pledges want to discover BRSKI proxies or registrars. In the
presence of variations of the BRSKI mechanisms that impact
interoperability, performance or security, not all discovered
instances may support exactly what the initiator needs to achieve
interoperability or they may not provide the best desired metric. To
support choosing an interoperable/best responder, the service
announcement mechanism needs to carry the necessary additional
information beside the service name that indicates the service/role
of the responder.
2.1.2. Consistent support for variations across different discovery
mechanisms.
Different BRSKI deployments may prefer different discovery
mechanisms, such as Section 1, Section 1, Section 1 or others. Any
variation in discovery already defined for one discovery mechanism
usually has to be re-specified individually for every other discovery
mechanism. This make it often cumbersome to select the preferred
discovery mechanism for a specific type of deployment, because such
additional specification work can take a long time. Indepedent
specification of variations for different discovery mechanisms can
also easily lead to inconsistencies and hence the inability to
equally support all variations across all discovery mechanisms.
2.1.3. Variation agnostic support for BRSKI proxies
BRSKI proxies can be agnostic to variations of BRSKI because those
variations only impact the payload of messages carried across TCP or
UDP connections; but not the proxying of those TCP or UDP connections
by the proxy. Nevertheless, if a pledge requires a specific BRSKI
variation from a registrar, then this variation needs to be passed on
by the proxy so that the pledge can connect via the proxy in such a
way that the proxy connects to a registrar supporting the desired
variation. This proxying for variations needs to be defined such
that proxies do not require software or configuration updates when
new variations are introduced. Likewise, this variation agnostic
proxying should also work across any supported discovery mechanism.
Eckert & Dijk Expires 24 April 2025 [Page 7]
Internet-Draft BRSKI-discovery October 2024
2.2. Functional Summary
This document specifies a set of IANA registry tables for BRSKI.
These tables allow to define the attributes for different registry
mechanisms to announce and discover different BRSKI role responders
as well as their variations. Defining these via registry tables
maximizes consistency across discovery mechanisms and makes support
for variations across different discovery mechanisms easier and
consistent.
Using the discovery information specified through these tables, this
document specifies details of selection and fail-over when
discovering more than one interoperable and available responder,
These procedures intend to provide resilience and scalability of
BRSKI services not possible without dynamic discovery mechanisms.
Finally, this document specifies procedures for BRSKI proxies to
discover variations of registrars using any discovery mechanism,
annnounce them to pledges - and connect a pledge accordingly to the
right registrar based on the variation required by the pledge. These
procedures allow to introduce new variations of BRSKI without need to
upgrade proxies.
3. Specification
3.1. Data Model
BRSKI Discovery is about discovery of one or more instances of
responders supporting specific a specific BRSKI role - and
determining whether that responders variation of BRSKI protocol
options is compatible with / desired by the connection initiator.
This section gives the conceptual overview of how this is achieved.
3.1.1. Roles
In BRSKI, a connection initiator needs to discover the transport
parameters of a feasible connection responder: IP/IPv6 address, IP
transport protocol (such as primarily UDP or TCP) and the IP
transport protocol port. This is also called a responder socket.
This document calls the type of responder the "BRSKI role" or "BRSKI
service". BRSKI roles for which this document defines variation
discovery are registrar, proxy and pledge. Discovery for other BRSKI
roles such as MASA or other future roles can be added through the
registry tables introduced by this document.
Eckert & Dijk Expires 24 April 2025 [Page 8]
Internet-Draft BRSKI-discovery October 2024
3.1.2. Service Names
The role that a responder socket supports is indicated in each
discovery mechanism through an appropriate signalling element.
Section 1 calls this signalling element the Service Name. Due to the
absence of another equally widely used term for this type of
signalling element across arbitrary discovery mechanisms, this
document also refers to the role signaling element as the service
name, independent of the discovery mechanism. IP/IPv6 Address, IP
transport protocol and IP transport protocol port are not part of the
Service name and signalled across discovery mechanisms specific
signaling elements.
3.1.3. Variations
Variations in the BRSKI protocol such as the choice of encoding of
messages or features could impact interoperability between initiator
and responder. Initiators need be able to discover and select
responders based not only on the desired role, but also based on the
best variation for the initiator.
Variations of a role could be indicated by using a different Service
Name for every variation, but that approach would have two challenges
1. Service Names in different discovery mechanisms are typically not
hierarchical (e.g.: not "role.variation"). Relying only on
Service Names would thus require the registration for every
variation as a separate Service Name in a "flat" name space; and
register them once for each discovery mechanism. In addition,
not all discovery mechanism registry rules may look favorably at
the registration of Service Names for such protocol variations.
2. Whenever a new variation is introduced, all deployed BRKSI
proxies would need to be configured to also proxy this new
variation - because new Service Names for the same BRSKI role can
be auto discovered by proxies (without additional protocol
mechanisms that would be more complex than the variations
approach). Most BRSKI proxies should be able to operate without
configuration though.
For these reasons, this document introduces the encoding of BRSKI
(role) variations through a secondary signaling element in each
discovery method, enabling proxies to transparently support any
variation of BRSKI role connections for which they supports proxying.
In addition, variations only need to be registered once in a BRSKI
specific registry table introduced by this document, and not once for
each current or future discovery method.
Eckert & Dijk Expires 24 April 2025 [Page 9]
Internet-Draft BRSKI-discovery October 2024
A variation is hence specified as describing a combination of
signaling choices that a BRSKI connection may use and that impacts
interoperability between initiator and responder at the message
exchange and encoding level.
3.1.4. Variation Types
Today, BRSKI connections can exchange vouchers in one out of multiple
different encoding formats. Independent of that option, the BRSKI
connection may also use different commands (so called "Endpoints").
Todays these are based on whether Section 1 is used or not. Finally,
and also independent of those two options, the BRSKI connection may
use one out of multiple different enrollment protocol options.
This document calls these options "Variation Type", and the above
three variation types are called "vformat" for the voucher format,
"mode" for the Endpoints being used (such as PRM or not), and
"enroll" for the enrollment protocol used.
3.1.5. Variation Type Choices
The actual choices for each of these variation types are hence called
"Variation Type Choices": "prm" or "rrm" for the variation type
"mode". "cms", "cose" or "jose" for the variation type "vformat".
"est", "cmp" or "scep" for the variation type "enroll".
"scep" is an example for the ability of the registration to reserve
values: it is not adopted by any current BRSKI specification.
3.1.6. Variation Strings
A variation is encoded as a string concatenating a single variation
type choice for every (necessary) variation type. For example "rrm-
cms-est" could be describing the protocol options used by a RFC8995
BRSKI connection pledge to registrar - potentially through a proxy.
This string representation of a variation is called the variation
string and it is consistently used for signalling across any
discovery mechanisms.
When in the future, 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, today only COAPS is
supported, but BRSKI UDP sockets could equally work with QUIC (which
runs on top of UDP). At that time, a new variation type of e.g.:
"proto" could be introduced with variation type choices "coaps" and
"quic". For backward compatibility, "coaps" then needs to be defined
Eckert & Dijk Expires 24 April 2025 [Page 10]
Internet-Draft BRSKI-discovery October 2024
to be the default for BRSKI over UDP, which means that existing
variation strings such as "rrm-cms-est" imply the use of "coaps",
whereas the use of QUIC would have to be indicated explicitly via
"rrm-cms-est-quic".
For variation strings to be semantically unambiguous, the variation
type choices across all variation types have distinct names, and the
order in which variation type choices are concatenated is the order
in which variation types are defined in the according registry table.
Hence new variation type choices have to be tail added to the
registry table.
3.1.7. 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 list 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.
"BRSKI" is the context covering [RFC8995] connections pledge to proxy
or registrar and proxy to registrar connections using TCP.
"cBRSKI" (constrained BRSKI) is the context covering
[I-D.ietf-anima-constrained-voucher] connections pledge to proxy or
registrar and proxy to registrar connections using UDP.
"BRSKI-PLEDGE" is the context covering pledges using
[I-D.ietf-anima-brski-prm] for connections from agents. It can
equally cover in the future through variations the discovery of
[RFC8995] pledges for connections to them for other purposes - by
introduction of 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 backward incompatible new secure transport
options.
Eckert & Dijk Expires 24 April 2025 [Page 11]
Internet-Draft BRSKI-discovery October 2024
This document does also not introduce variation contexts for
discovery of other BRSKI roles, such as discovery of pledges by
agents (as defined in Section 1), or discovery of MASA by registrars.
However, the registries introduced by this document are defined such
that those can be introduced later as well through additional
registry entries and specification.
3.1.8. Registry Tables
This document defines three IANA registry tables to register and
document the parameters required for BRSKI discovery in an extensible
fashion. The following sections explain these registry tables. The
registry tables themselves are listed in the IANA considerations
section, see Section 4.2.
3.1.8.1. Variation Contexts Registry Table
The IANA "BRSKI Variations Contexts" registry table, see Table 2, as
defined by this document, defines which Service Names and signaling
parameters (e.g.: UDP vs. TCP) in each supported discovery mechanism
are used to discover which role for different BRSKI protocol options.
In addition, the table specifies for each context the applicable
variation types because these may differ by context (they do not
differ yet with the registrations specified in this document though).
The order in which variation types are specified in this table
defines the order in which variation type values are concatenated to
form variation strings.
3.1.8.2. Variation Type and Choices Registry Table
The IANA "BRSKI Variations and Variation Strings" registry table, see
Table 3, as defined by this document, defines for each context and
variation type the defined choices of that variation type and whether
a particular choice is a default choice, in which case it does not
need to be included in the variation strings for the context.
This registry also registers the authoritative documentation defining
the specific choices. These specifications may differ for the same
choice across different contexts, such as for "est" between BRSKI and
cBRSKI.
The "Context" column lists the BRSKI Variation Context(s) to which
this line applies. If it is empty, then the same Context(s) apply as
that of the last prior line with a non-empty Context column.
Eckert & Dijk Expires 24 April 2025 [Page 12]
Internet-Draft BRSKI-discovery October 2024
The "Variation Type" column lists the BRSKI Variation Type to which
this line applies. If it is empty, then the same Variation Type
applies as that of the last prior line with a non-empty Variation
Type column.
The "Variation Type Choice" column defines a Variation Type Choice
for the current context. All Variation Types and Variation Type
Choices MUST be unique strings across all Variation Types so that
variation strings are non-ambiguous.
Variation Types and Variation Type Choices and MUST be strings from
lowercase letters a-z and digits 0-9 and MUST start with a letter.
The maximum length of a Variation Type Choice is 12 characters.
The "Reference" column specifies the primary documents which defines
the Variation Type Choice use in the rows context. Further
references go into the Note(s) column.
The "Dflt" Flag specifies a Variation Type Choice that is assumed to
be the default Choice for the Context, such as "rrm" for the BRSKI
context. Such a Variation Type Choice is assumed to be supported by
responders in discovery if discovery is performed without support of
variations. This applies of course only to responders which support
such discovery.
For example, Section 1 specifies the empty string "" as the
objective-value in Section 1 discovery. Because "rrm", "est" and
"cms" are default in the BRSKI context, discovery without indication
of a variation can support exactly only this variation of "rrm" with
"est" and "cms" in the BRSKI context.
The "Dflt_" Flag specifies a Variation Type Choice that is only
default in a subset of Discovery options in a context. The Note(s)
column has then to explain which subset this is. Like for "Dflt",
the signaling in this subset of Discovery options can then forego
indication of the "Dflt_" Variation Type Choice.
The "Rsvd" Flag specifies a Variation Type Choice for which no
complete specification exist on how to use it within BRSKI (or more
specifically the context), but which is assumed to be of potential
implementation interest. "Rsvd" Variation Type Choices MUST NOT be
considered for the Discoverable Variations table. They are
documented primarily to reserve the Variation Type Choice string.
Eckert & Dijk Expires 24 April 2025 [Page 13]
Internet-Draft BRSKI-discovery October 2024
3.1.8.3. Variations and Variation String Registry Table
The IANA "BRSKI Variations and Variation Strings" registry table, see
Table 4, as defined by this document, defines for every necessary
context in the "Variation" column the variations which are known to
be desired by implementations as a space separated sequence of
variation type values, and as a "-" concatenated variation string in
the "Variation String" column. The space separated sequence does not
take defaults into account, the variation string does.
Variation strings may include additional "one-off" variation strings
in support of backward compatibility when the standard scheme does
not work.
The "Context" column lists the BRSKI Variation Context(s) to which a
line applies. If it is empty, then the same Context(s) apply as that
of the last prior line with a non-empty Context column.
The "Reference" column lists the document(s) that specify the
variation, if that variation is explicitly described. If the
variation is not described explicitly, but rather a combination of
Variation Type Choices from more than one BRSKI related
specification, then this has to be explained in the "Explanation /
Notes" column.
3.1.9. Discussion
Variations as defined by this document only cover protocol options
that proxies can transparently support so that the definition of
variations allows to make proxies automatically extensible.
Other responder selection criteria such as different responder
priority or performance based selection (called weight in Section 1)
are not covered by the variation concept but can be used without
change in conjunction with variations. Some selection criteria may
also only work with discovery mechanisms that rely on specific
procedures. Network distance to responder can for example only be
well supported by discovery mechanisms that can support per-hop
forwarding between initiator and responder, such as Section 1. Any
of these criteria will work unchanged with the introduction of
Variations. Variations are simply one more selection criteria.
Differences in the supported transport stack of a responder are
typically included as a signaling element of the discovery method:
Whether TCP or UDP or another IP transport protocol is used, and
whether the responder uses IPv4 or IPv6 or even another network layer
protocol.
Eckert & Dijk Expires 24 April 2025 [Page 14]
Internet-Draft BRSKI-discovery October 2024
In "sane" services where a change in transport spec does not imply a
change in signalled messages and their semantics, gateways could
transparently proxy from IPv4 to IPv6 and vice versa or even between
TCP and some other IP transport protocols such as SCTP. However,
this is out of scope of this specification.
The procedures specified in [I-D.ietf-anima-constrained-join-proxy]
would allow not only to run a transport stack of COAP over DTLS, but
equally any other transport stack over UDP, such as QUIC - without
any changes to the proxy implementation or configuration when
following the procedures described in this dcoument. All that is
needed would be to introduce appropriate registration entries for the
registry tables specified in this document (e.g.: add new Variation
Type for transport and choices such as "coaps" or "quic" ).
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 is supported through distributing the connections from
multiple initiators to different responders if so desired through
operator configuration of the discovery methods parameters.
At the time of this specification, the relevant initiators are
pledges and proxies, the relevant responders proxies and registrars.
Nevertheless, the rules can equally apply to other BRSKI connections
if and when discoverable, redundant services are desired and added to
the registries created by this document. For example discovery of
MASA by registrars.
Note that this specification does not mandate support for specific
discovery methods in BRSKI implementations, because this is specific
do the target deployment scenarios - hence the option to support
different discovery methods.
3.2.1. Responder Selection
If more than one responder is discovered by an initiator, then the
initiator SHOULD support 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 and update its discoverable responder information from
the discovery mechanism if that is not already happening
automatically by the chosen discovery method before it restarts
connection attempts.
Eckert & Dijk Expires 24 April 2025 [Page 15]
Internet-Draft BRSKI-discovery October 2024
A responder is feasible if it supports one or more of the variations
requested by the inititor.
The order of responders to attempt connections to is derived from two
criteria: preference and weight.
Preference order is foremost determined by the responders preference
across the variations it supports. Within the set of of responders
with the same preference by the initiator because of their variation,
the preference is further determined from discovery method 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 calculated from the most preferred
variation supported by it.
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 is to ensure that those events have the chance
to overcome possible persistent problems when persistently choosing
the same first responder. If deployments desire reproducable and
predictable ordering of connection attempts by initiators then they
have to use the discovery specific mechanisms, such as a different
priority" parameter for each responder in DNS-SD to create such a
strict ordering across the different responder.
Initiators SHOULD support to take discovery mechanism specific
weighting into account when determining the order of responders with
the same preference, such as the "weight" parameter in DNS-SD.
Support for the so far described resilient selection of responders
SHOULD support selection amongst at least 4 and no more than 10
responders with one or more supported variation for each supported IP
address family (IP 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.
4 Responders for a specific variation are a typical minimum
resilience setup in a larger network setup, in which 2 responders
serve as redundancy at the responder host level and the other 2
responders provide redundancy against network connectivity failure to
those first two responders. Intra-DC and Inter-DC service redundany
is a simple example of such a setup.
Eckert & Dijk Expires 24 April 2025 [Page 16]
Internet-Draft BRSKI-discovery October 2024
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 aliveness
of a service process.
In typical implementations, service announcement may be activated
when the service process starts, and stopped, when it stops.
Problems such as a hanging/unresponsible service process will not be
reflected in the service announcement setup. In addition, caching of
service announcements, such as through the DNS TTL field are a
further possible cause of assuming service aliveness that is not
correct. Only actual connection probing or other similar tracking
can determine if 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 did or would have failed to successfully accept
connection for 120 seconds or more. This can be implemented for
example by connection probing once every 30 seconds and withdrawing
the service announcements when this fails or by other forms of
tracking responsiveness of the responder functionality.
The better service announcements indicate actual aliveness of the
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 announcemements and
activating the backup only when the primary ones fail. Such dynamic
backup can further reduce the overall load on the discovery mechanism
system used and on initiators.
3.2.3. Responder Selection in Proxies
Unless amended by the requirements listed below, proxies SHOULD
follow all the descripton from Section 3.2.1. Note that the randomn
selection of responders with the same preference also applies to
stateful proxies and ensures load balancing (including weighting)
across multiple simultaneously connecting pledges.
Eckert & Dijk Expires 24 April 2025 [Page 17]
Internet-Draft BRSKI-discovery October 2024
Stateful proxies SHOULD optimize selection of responders for each
variation across connections for multiple pledges instead of starting
the sequence of responders to try from the highest precedence anew
for every new connecting pledge - and repeatedly run into timeouts
for each new 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 proxy SHOULD
skip this responder in further connection attempts for other
connecting pledges.
Stateless proxies can not learn unresponsiveness or unreachability of
a responder through connection attempts. Instead, they SHOULD
perform a stateless responsivness/reachability check for each
responder that the proxy is actively forwarding packets to from one
or more pledges. If no packets are returned from such a responder
over a period of 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 after it persists for 10
seconds.
Using newly discovered responders in stateless proxies must be done
carefully. Consider the common case that service annuncements for a
primary responder did stop due to network issue, the proxy starts to
send packets to a secondary responder, and then the primary responder
becomes reachable and the proxy sees service announcements for it.
If the proxy would now start to forward packets from pledges to this
primary responder due to its higher precedence, then this could
unnecessarily break ongoing connections from clients whose packets
are currently forwarded to the lower preference proxy.
Replacing to use a selected responder in a stateless proxy with a
better one SHOULD hence only be done if no packets have been
exchanged between pleges and the current selected responder through
the proxy for more than 300 seconds. This long timeout specifically
intends to not break connections in which the registrar keeps the
pledge waiting for an administrative response such as an operator
performing a policy validation for enrollment.
Eckert & Dijk Expires 24 April 2025 [Page 18]
Internet-Draft BRSKI-discovery October 2024
Load balancing is NOT RECOMMENDED for stateless proxies because per-
pledge stateless load balancing may involve more processing
complexity than 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
[I-D.ietf-bess-evpn-fast-df-recovery]. Supporting weights with
stateless proxying is even more complex. Instead of load balancing,
responders simply need to be designed to scale to the maximum amount
of simultaneous initiator connections necessary when supporting
stateless proxying mode.
3.2.4. Protection against malicious service announcements
Initiators including proxies SHOULD always pick the highest possible
priority and weight parameters possible in the discovery mechanism
used that allows to support the desired preference goals. For
example, any primary initiator should select the highest numerical
values possible.
This recommendation is intended as a protection against erroneous,
but not malicious service announcements whenever the default
priorities are lower than the maximum priority. It can also serve as
a 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 being weak, this recommendation can still be better than
nothing against such malicious announcement. These recommendations
SHOULD be superceeded by better recommendations for more narrowly
scoped deployment scenarios.
3.3. Join Proxies Support for Discovery and Variations
3.3.1. Join Proxy support for Variations
A join proxy compliant with this specification MUST support
announcing its proxy responder socket(s) to which pledges can connect
via at least one of the discovery methods 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 proxy SHOULD support to pass packets for any variation for which it
has discovered one or more registrar sockets supporting that
variation without the need for the variation to be known at the time
of implementation of the proxy or configured on the proxy. If a
proxy supports this requirements, this is called support for
Eckert & Dijk Expires 24 April 2025 [Page 19]
Internet-Draft BRSKI-discovery October 2024
"arbitrary variations". Supporting this requirement requires the
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.
Arbitrary variations support allows to deploy proxies once and add
pledges and registrars supporting new variations later - without
upgrade or change of configuration of proxies.
3.3.2. Registrar Operations Modes
Proxies may use different approaches to connect to registrars. The
following subsections discuss the primary relevant options.
3.3.2.1. Direction Connections Mode
In one proxy implementation option called "direct connections", the
proxy creates for every discovered registrar socket a separate proxy-
responder socket. It announces this socket with the same set of
parameters as it did learn from the registrars service announcement,
except for the appropriate proxy service name and socket parameters
(IP/IPv6 address, port number). When a pledge connects to that
socket, the proxy passes traffic for that pledges 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
because they are exposed to at least the same number of service
announcements from proxies as proxies see service announcements from
registrars - and the pledge has to select the best available one from
them.
To reduce the number of sockets that have to be announced by proxies
when using direct connections and to also reduce the number of
responder sockets that need to be maintained by a proxy operating in
this approach, these proxies SHOULD limit the number of registrar
sockets it maps to between 4 and 10 best registrar sockets as
described in Section 3.2.1 per variation.
3.3.2.2. Best Registrar Selection Mode
In the implementation mode "best registrar selection", the proxy
creates a separate socket for a set of all registrar sockets that it
discovers and that announce support for the same set of variations.
It then connects pledges to the best available registrar socket from
that set.
Eckert & Dijk Expires 24 April 2025 [Page 20]
Internet-Draft BRSKI-discovery October 2024
It then announces this socket with the parameters of the best
discovered registrar socket, replacing the service name and network
parameter names with those for its proxy-responder socket as in the
case of a direct connection.
When performing best registrar selection, the proxy has to perform
selection of the best availalable responder as described in
Section 3.2.1.
In addition, stateful proxies implementing best registrar selection
SHOULD optimize selection of registrar for each proxy responder
socket across connections for multiple pledges instead of starting
the sequence of responders to try anew from the highest precedence
registrar for every new connecting pledge - and repeatedly run into
timeouts when one or more of the best registrar time out on
connection attempts because they are unresponsive or unreachable.
Instead, after a responder first fails to connect, the proxy SHOULD
skip this responder in further connection attempts for other
connecting pledges and re-consider it only for new connection
attempts after at least 60 seconds.
Stateless proxies can not learn unresponsiveness or unreachability of
a responder through connection attempts. Instead, they SHOULD
perform a stateless responsivness/reachability check for each
responder that the proxy is actively forwarding packets to from one
or more pledges. If no packets are returned from such a responder
over a period of 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 after it persists for 10
seconds.
Using newly discovered responders in stateless proxies supporting
best registrar selection must be done carefully. Consider the common
case that service annuncements for a primary responder did stop due
to network issues, now the proxy starts to send packets to a
secondary responder, and then the primary responder becomes reachable
and the proxy sees service announcements for it. If the proxy would
now start to forward packets from pledges to this primary responder
due to its higher precedence, then this could unnecessarily break
ongoing connections from clients whose packets are currently
forwarded to the lower preference proxy. Direct connection mode does
not incur this problem, because the pledge can select another proxy-
responder socket when it discovers the first one to be unresponsive
or erroneous.
Eckert & Dijk Expires 24 April 2025 [Page 21]
Internet-Draft BRSKI-discovery October 2024
Replacing to use a selected responder in a stateless proxy with a
better one SHOULD hence only be done if no packets have been
exchanged between pleges and the current selected responder through
the proxy for more than 300 seconds. This long timeout specifically
intends to not break connections in which the registrar keeps the
pledge waiting for an administrative response such as an operator
performing a policy validation for enrollment.
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 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 [I-D.ietf-bess-evpn-fast-df-recovery].
Supporting weights with stateless proxying is even more complex.
Instead of load balancing, responders simply need to be designed to
scale to the maximum amount of simultaneous initiator connections
necessary when supporting stateless proxying mode.
3.3.2.3. Proxy in Name Only Mode on Registrars
Registrars that implement support for connections from stateful
proxies and/or from pledges may minimize their proxy implementation
work by only implementing the appropriate service name announcements
for the same socket to support connections from both: announcements
as a registrar for connections from proxies and announcements as a
proxy for connections from pledges. No additional sockets or other
proxy specific packet processing code is required to support this.
Registrars that implement support for connections from stateless
proxies can share that implementation for connections from pledges by
also implementing simple UDP<->JPY header conversion. Nevertheless,
they do need to do this via a separate socket and hence need to
announce the two sockets separately: UDP for connections pledges with
the proxy service name, and UDP with JPY header for connections from
stateless proxies with the stateless registrar service name.
Proxy functionality that is implemented as described here on
registrars is called "proxy in name only mode", because such an
implementation can not discover, select and fail over between
different registrars. Such proxies in name only therefore do not
share requirements against discovering and selecting registrars
described for the prior specified modes.
Eckert & Dijk Expires 24 April 2025 [Page 22]
Internet-Draft BRSKI-discovery October 2024
Like other proxies, proxies in name only SHOULD nevertheless track
aliveness of their registrar function and withdraw its service
announcements (both as proxy as well as as registrar) when it does
not run, fails or becomes unresponsive.
Proxies in name only SHOULD default to the same discovery method
priority and weight parameter as those configured for the registrar
service announcements. This is so that in the absence of separate
proxies in the network selection of registrars co-located proxies
would follow the same criteria as those used by proxies and which use
the registrar service announcement parameters.
3.3.2.4. Proxy Mode Discussion
This document defines no requirements against the implementation mode
for proxies. Those are left for solution or deployment (profile)
specifications. Instead, this section discusses some considerations
for those choices.
The list of possible modes presented is exemplary and not meant to be
exhaustive. Other modes are equally able to support the
requirements, such as mixtures of the described modes. Likewise,
introduction of new variations may not only work well via arbitrary
variation support in proxies, but through explicit configuration of
variations on proxies - this all depends on the target deployment
environment. The presented modes where choosen primarily as the ones
providing most configuration free deployment options and for
registrar implementations most simplicity in implementation.
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 best available
discovery and selection and onto the pledge. If simultaneously
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 both pledge and proxy code together is easiest to
implement.
Even on registrars, proxy in name only mode may not suffice
deployment requirements or provide best redundancy. For example, the
co-located registrar may incur problems, not applicable to
alternative registrars, such as for example Internet connectivity
problems to MASAs when different registrars have different Internet
connectivity. If the registrar co-located proxy is then still the
Eckert & Dijk Expires 24 April 2025 [Page 23]
Internet-Draft BRSKI-discovery October 2024
only proxy available to some candidate pledges, then this proxy needs
to be able to connect to an alternative registrar, which would not be
possible if it was a a proxy in name only.
Likewise, proxy in name only mode will disturb the introduction of
new variations on pledges and other registrars in the network if the
registrar node implementing proxy in name only mode becomes a
necessary proxy for a pledge requiring a variation not supported by
this registrar, but by another registrar that would only be reachable
through this registrar node. Therefore, proxy in name only mode is
best suited for node types not deployed on an edge of the network
where a future variety of pledges may connect to, and those pledges
will require the use of a proxy.
3.3.3. Extensibility to non BRSKI services
BRSKI proxy implementations using the procedures described in this
document can easily be reused for any other protocols beside BRSKI as
long as they use TCP or UDP. For this, it would simply be required
that the BRSKI proxy can be configured with pairs of service names
other than those used by BRSKI/cBRSKI: A service name to discover,
and a service name to use for the proxy responder socket service
announcements.
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 cade of allowing BRSKI registration
in a network with many geographically spread out sites such as in
enterprise, industrial or building construction environments. During
initial bringup of such sites, Internet connectivity may be non-
existing, or intermittant, and hence one or more local registrar in
each such site is higly desirable. Such registrars may of course
require private mobile network connectivity to MASA, or rely on out-
of-band provisioning of vouchers.
Eckert & Dijk Expires 24 April 2025 [Page 24]
Internet-Draft BRSKI-discovery October 2024
Later, when such a site does get a well working wide-area network
connection, it may be more appropriate to use more centralized
registrars, but a local registrar as a backup may be considered
useful. However, if the service announcements of such per-site
decentralized registrars would be discoverable across the whole
geographically spread out network, then this could introduce a
potentially significant overhead to the service announce and
discovery system when for example more than 100 registrar service
announcments exist in the network, and pledges/proxies connect to
them.
Such large number of redundant service announcements is typically
highly undesirable, and appropriate configurations of service
discovery mechanisms need to be used to avoid them. For example, in
GRASP, service announcements can be scoped to small hop counts,
Anycast addressing can be used to make all decentralized registrars
overload the same ip address, and hence make them all share the same
service announcement.
3.4. Discoverable BRSKI Pledges
3.4.1. BRSKI-PLEDGE context
BRSKI-PLEDGE is the context for discovery of pledges by nodes such as
registrar-agents. Pledges supporting Section 1 MUST support it. It
may also be used by other variations of BRSKI outside of the PRM use
case, for example for inventorizing 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 [I-D.ietf-dnssd-srp].
DNS-SD WG Question TBD: Is there sufficient auto-configuration
support in [I-D.ietf-dnssd-srp], that pledges without any
configuration can use it, and if so, do we need to raise specific
additional requirements to enable this in pledges ?
These DNS-SD requirements are defaults. Specifications for specific
deployment contexts such as specific type of radio mesh network
solutions may need to specify their own requirements overriding or
amending these requirements.
Pledges MUST support to be discoverable via their DNS-SD service
instance name.
Pledges SHOULD support to be discoverable via DNS-SD browsing, so
that registrar-agents can find unexpected pledges or can easier
enumerate expected pleges, especially in the presence of multiple
Eckert & Dijk Expires 24 April 2025 [Page 25]
Internet-Draft BRSKI-discovery October 2024
different subnets and use of mDNS. A pledge can also only be found
by browsing if it is not possible for the owner to aquire serial-
number information of a pledge by the time BRSKI-PRM needs it (to
create a service instance name).
When pledges are discoverable vis DNS-SD browsing, the "brski-
registrar" 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, Section 1 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 equally RECOMMENDED to apply the same random delay rule for
answers to multicasted or flooded queries in other discovery
mechanisms that have the same response burst problem - even when they
do not specify such a mechanism, such as in GRASP.
If browsing is not desired by a pledge, the pledge does simply not
respond to queries for the "brski-registrar" service name in mDNS or
other discovery mechanism queries for the equivalent service name, or
does not register its PTR RR for this service name when using unicast
DNS-SD via [I-D.ietf-dnssd-srp]. This does not affect operations for
the service instance name.
3.4.2. Service Instance Name
The service instance name chosen by a BRSKI pledge MUST be composed
from information which is
* Easily known by BRSKI operations, such as the operational
personnel or software automation, specifically sales integration
backend software.
* 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-code/QR-codes on the product
itself. If this serial number is used as the service instance name
to discover a pledge from a registrar-agent, then this may
potentially (but unlikely) lead to (duplicate) replies from two or
more pledges having the same serial number, such as in the following
cases:
1. A manufacturer has different product lines and re-uses serial-
numbers across them.
Eckert & Dijk Expires 24 April 2025 [Page 26]
Internet-Draft BRSKI-discovery October 2024
2. Two different manufacturer re-use the same serial-number space.
If pledges enable browsing of their service instance name, they MAY
support DNS-SD specified procedures to create unique service instance
names when they discover such clashes, by appending a space and
serial number, starting with 2 to the service instance name:
"<service-instance-name> (2)", as described in Section 1 Appendix D.
Nevertheless, this approach to resolving conflicts is not desirable:
* If browsing of DNS-SD service instance name is not supported,
registrar-agents would have to always (and mostly wrongly) guess
that there is a clash and (mostly unnecessarily) search for
"<service-instance-name> (2)".
* If a clash exists between pledges from the same manufacturer, and
even if the registrar-agent then attempts to start enrolling all
pledges with the same clashing service instance name, it may not
have enough information to distinguish pledges other than by the
randomn numbering. This would happen especially if the IDevID
from both devices (of different product type), had the same serial
number, and the CA of both was the same, which is likely when they
are from the same manufacturer. Even if some other IDevID field
was used to distinguish their device model, the registrar-agent
would not be able to determine that difference without additional
vendor specific programming.
In result:
* Vendors MUST document a scheme how their pledges form a service
instance name from information available to the customer of the
pledge.
* These service instance names MUST be unique across all IDevID of
the manufacturer that share the same CA.
The following mechanisms are recommended:
* Pledges SHOULD encode manufacturer unique product instance
information in their subject name serialNumber. [RFC5280] calls
this the X520SerialNumber.
Eckert & Dijk Expires 24 April 2025 [Page 27]
Internet-Draft BRSKI-discovery October 2024
* Pledges SHOULD make this serialNumber information consistent with
easily accessible product instance information when in physical
possession of the pledge, such as product type code and serial
number on bar-code/QR-code to enable Section 1 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)!
* Pledges SHOULD construct their service instance name by
concatenating their X520SerialNumber with a domain name that is
used by the manufacturer and thus allows to disambiguate devices
from different manufacturer using the same serialNumber scheme,
and hence the likelihood of service instance name clashes if
manufacturer names are 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 manufacturers approach using the
recommendations from above. Figure 1 shows the different data
involved in DNS-SD records for a pledge from manufacturer "Example".
Eckert & Dijk Expires 24 April 2025 [Page 28]
Internet-Draft BRSKI-discovery October 2024
Pledge IDevID certificate information:
; Format as shown by e.g.: openssh
Subject: serialNumber = "PID:Model-0815 SN:WLDPC2117A99",
O = example.com, CN = Model-0815
Manufacturer published LDevID identification schema:
Brand: Example: O = example.com, serialNumber = "PID:<PID> SN:<SN>"
SN = Serial Number, PID = Product Identifier
Manufacturer published DNS-SD Instance Schema (options):
<X520SerialNumer>.example.com
DNS-SD Instance:
"PID:Model-0815 SN:WLDPC2117A99.example.com"
DNS-SD RR for the pledge (using mDNS, hand hence .local):
; PTR RR to support browsing / discovery of service instance name
_brski-pledge._tcp.local IN PTR
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
; SRC and TXT RR for the service instance name
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
IN SRV 1 1
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
IN TXT ""
; AAAA address resolution for the target host name
PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local
IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:00a1
Figure 1: Example IDevID and DNS-SD data
"Pledge IDevID certificate information" shows the relevant parts of
an IDevID. As defined in Section 1, the serial number of the pledge
is the value of the X520SerialNumber field, shown as the value after
"serialNumber =" in openssh. BRSKI components perform cryptographic
authentication of the IDevID and determine the manufacturer from the
trust anchor (root CA) of the certificate (chain) that has signed the
IDevID. Normally, the serialNumber is unique within the scope of the
root-CA certificate used by the manufacturer.
In this normal case, a BRSKI component only needs to be configured
with a list of root CA certificates that the BRSKI component trusts
to provide pledges with IDevIDs and configure a manufacturer-name for
each. The identity of a pledge after successful IDevID
authentication is then (manufacturer-name, serialNumber).
Eckert & Dijk Expires 24 April 2025 [Page 29]
Internet-Draft BRSKI-discovery October 2024
Unique identification may be more complex though. A manufacturer may
have certificate chains and different production sub-companies may
use different sub-CA certificates in the signing chain. Or the
serialNumber alone is not unique across the certificate chain, but
further Subject fields of the certificate are required for a unique
identification, such as the O)rganization field. It could contain
for example one out of multiple brand names that use simple numerica
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, their IDevID and signing
chains.
Typically, an owner will not know the IDevID of a pledge before being
able to connect to it. Instead, it needs to match the certificate
content with identification information from on-device or on-
packaging labels and/or backend information such as sales receipts.
The owner needs to be able to convert this identification information
into the relevant fields such as X520SerialNumber to then match those
fields against the fields found in the LDevID - of course after the
cryptographic authentication of the LDevIDs signature by the
manufacturers root CA certificate.
In the example, the manufacturer identifies pledges of the brand
"Example" in sales receipts with information like "Model: Model-0815,
Serial Number: WLDPC2117A99". The "Manufacturer published LDevID
identification schema" is then the example information needed by
BRSKI components of the owner to be able to convert such backend
identification information the fields to be match in the LDevID. In
this case not only the serialNumber, but also the Organization field
to identify the brand - just in case the manufacturer re-uses the
same root CA across multiple brands with not necessarily unique
serial numbers across brands.
Understanding the identification via the IDevID is important to
understand the security of the instance string used by a
manufacturer. In this example, the manufacturer owns the DNS domain
name "example.com". It uses and publishes the DNS-SD instance scheme
"<X520SerialNumer>.example.com", in other words: the instance string
is a concatenation of the X250 serial number of the pledge and
".example.com". Note that owning the domain name "example.com" is
not a requirement for this approach to work, but instead it merely
allows the owner to be more confident that there will be no
serialNumber clash with other manufacturers pledges.
A BRSKI component discovering such a pledge by its service instance
name can then determine the root CA of the pledge from it's IDevID
and then match/authenticate the instance string from the instance
schema.
Eckert & Dijk Expires 24 April 2025 [Page 30]
Internet-Draft BRSKI-discovery October 2024
Authorizing a pledge in a registrar or other beckend management
system interacting with the registrar will likely require to match
the relevant fields of the LDevID with some non-cryptographic
identification of the pledge, such as from a sales receipt or label/
code on the device itself or its packaging.
In the example, such identification could be written out for example
as "Product: Model-0815, Serial Number: WLDPC2117A99". For
validation of the IDevID, any such information needs to be converted
into the values of the field (or fields of the certificate). The
second example
Finally in the example, the same string that is used as the instance
string is also used as the host name and hence appears in the SRV and
AAAA RR. This host name could be any other choice, but re-using the
instance string also allows to avoid DNS name conflicts across at
least all pledges using this choice - as it does for the instance
string.
3.4.4. WebPKI derived instance schema
There is currently no automated mechanism to avoid the configuration
of manufacturer root CA 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 it is deemed appropriate by vendors and
operators of BRSKI-PLEDGE installations to rely on WebPKI trust
anchors.
The root CA certificate itself (or a sub-CA in the certificate chain)
would then have to have a WebPKI trust anchor signature and a DNS
Name that can easily be identified as being used for IDevID, such as
"*.idevid.example.com". And the implied schema for the instance
string is then "<<X520SerialNumer>.DNS-name>", authenticating
instance names of the format "<X520SerialNumer>.idevid.example.com>".
Obtaining a WebPKI signature for their root CA for these wildcard
domain names from a WebPKI trust anchor is the added effort for
manufacturer of this scheme.
3.5. Variation signaling and encoding rules for different discovery
mechanisms
3.5.1. DNS-SD
Eckert & Dijk Expires 24 April 2025 [Page 31]
Internet-Draft BRSKI-discovery October 2024
3.5.1.1. Signaling
The following definitions apply to any instantiation of DNS-SD
including DNS-SD via mDNS as defined in Section 1, but also via
unicast DNS, for example by registering the necessary DNS-SD Resource
Records (RR) via [I-D.ietf-dnssd-srp] (SRP).
Because of the different options of how to run DNS-SD, the
requirements in this document do not guarantee interoperability when
using DNS-SD. One side could use unicast DNS-SD, the other mDNS, and
there may be no mapping between the two. Therefore the
recommendations in this document need to be amended with deployment
specific specifications / requirements as to which signaling
variation, such as mDNS or unicast DNS with SRP is to be supported
between initiator and responder. When using unicast DNS (with SRP),
additional mechanisms are required to learn the IP / IPv6 address(es)
of feasible DNS and SRP servers, and deployment may also need
agreements for the (default) domain they want to use in unicast DNS.
Hence, a mandatory to implement (MTI) profile is not feasible because
of the wide range of variations to deploy DNS-SD.
In the absence of overriding deployment profile requirements,
implementations are RECOMMENDED to support mDNS and MAY support
[I-D.ietf-dnssd-srp] and fall back to mDNS if [I-D.ietf-dnssd-srp]
fails to work, e.g.: it fails to discover SRP server and/or default
domain.
3.5.1.2. Variation String Encoding
Variation Strings from the IANA registry Table 4 are encoded as DNS-
SD Keys with a value of 1 in the DNS-SD service instances TXT RR
using the shortened encoding of "key" instead of "key=1". In result,
the value of the TXT RR is a sequence of zero terminated strings,
each one indicating a single supported variation type choice.
A variation may have the option of being represented by the empty
string "". This is not allowed in the DNS-SD encoding, and instead
the alternative variation string MUST always be used for DNS-SD.
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.
The use of variation strings can easily break the DNS-SD rule that
they keys should be no more than 9 characters long. This is
justified by the absence of value fields to keep the total length of
the TXT RR reasonably short.
Eckert & Dijk Expires 24 April 2025 [Page 32]
Internet-Draft BRSKI-discovery October 2024
3.5.1.3. Service Instance and Host Names
To be able to specify for each responder socket individually its
supported variations as well as its selection criteria (priority
weight), it needs to be represented in DNS-SD as a service instance
name with an SRV and TXT RR. In BRSKI-PLEDGE Section 3.4 the service
instance name is significant as it is what a registrar agent may need
to to discover, but in BRSKI and cBRSKI it is merely an artefact of
DNS-SD encoding: Unlike typical user-centric DNS-SD use-cases, there
are no users that need to make sense of the meaning of the service
instance name, for example to know, which printer to 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.
Registrars SHOULD support automatic generation of their service
instance name for their DNS-SD operation to avoid additional need for
operator configurations. Registrars SHOULD likewise support the
configuration of such a name - if the operator so desires to support
operational troubleshooting.
If the host on which the registrar is running already has a DNS host
name for the IP/IPv6 addresses used by the registrar and for the
desired DNS method (mDNS = .local, unicast DNS = default domain),
then the registar 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 because of the registrar, when useable RRs
already exist.
If such a DNS RR does not exist, but a DNS host name for a different
DNS method, or a different set of addresses than used by the
registrar, then the registrar MAY be able to use a target domain name
derived from that primary domain name by appending a unique name
element. This requirement exist 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
unnecessary 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 for example would happen if a
Eckert & Dijk Expires 24 April 2025 [Page 33]
Internet-Draft BRSKI-discovery October 2024
registrar tried to use an instance component such as "registrar" and
there is already another registrar. 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
understand what hardware it is running on, and that the MAC address
was assigned by registering its OUI with IEEE and that MAC addresses
from the OUI where assigned uniquely. This is for example not
necessarily the case for IoT equipment or registrars running in a
virtual context in the cloud. IP/IPv6 addresses can be assumed to be
unique (enough) when they have globals scope or ULA.
When registrar software does not know that no other registrar
software or instance of the same software may run on the same host
(for example when being packaged as an application), the registrar
SHOULD not assume that a host unique name, is actually unique, but
instead disambiguate it by appending an additional name element to
make it unique, such as a process number of the running process.
Picking well-known or unique identifiers for registrar also helps
operator to troubleshoot by often eliminating the need to also know
the IP/IPv6 addresses associated with the name.
Target host names need to follow the requirements for host names. By
those requirements, it is not permitted to use ":" in target host
names, for example as part of MAC or IP address based host names.
instance names do not share this limitation, but it SHOULD be useful
to pick the same host name requirements based encoding format for
both type of DNS RR nams when using encoded addresses in them. For
example by replacing ":" as commonly used with "-".
If the responder needs to indicate different sockets for different
(set of) variations, for example, when operating as a proxy,
according to Section 3.3.1, then it needs to signal for each socket a
separate service instance name with the appropriate port information
in its SRV record and the supported variations for that socket in the
TXT Record of that service instance name. 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.4. Examples
These example use OUI and IPv6 addresses reserved for documentation
purposes. Do not re-use these addresses in actual deployments
Eckert & Dijk Expires 24 April 2025 [Page 34]
Internet-Draft BRSKI-discovery October 2024
# BRSKI
_brski-registrar._tcp.local
IN PTR 0000-5e00-5314._brski-registrar._tcp.local
0000-5e00-5314._brski-registrar._tcp.local
IN SRV 1 2 4555 0000-5e00-5314.local
0000-5e00-5314._brski-registrar._tcp.local
IN TXT "est-tls" "prm-jose" "cmp"
# cBRSKI
_brski-registrar._udp.local
IN PTR 0000-5e00-5314._brski-registrar._udp.local
0000-5e00-5314._brski-registrar._udp.local
IN SRV 1 2 5684 0000-5e00-5314.local
0000-5e00-5314._brski-registrar._udp.local
IN TXT "rrm-cose"
# Host name
0000-5e00-5314.local
IN AAAA 2001:DB8:0815::5e00:5314
Figure 2: DNS-SD for single registrar supporting BRSKI/cBRSKI
variations
In example Figure 2, a registrar on a router, that is using mDNS for
being discovered supports BRSKI with "rrm" and "prm" modes across the
same TCP socket port 4555, with "est" and "cmp". This leads to the
three supported and IANA registry defined variations "est-tls", "prm-
jose", and "cmp". For cBRSKI (UDP), it supports the only variation
registered through this document, "rrm-cose".
Such a registrar implementation might even support a combination of
"prm" with "jose" and "cmp", but at the time of this specification,
this exact interoperability aspects of such a combination have at the
time of writing of this spec not been investigated and hence it is
not listed in the IANA registry. Nevertheless, this may happen
later, so it is useful for registrar implementations to allow
configuration of variations for its service announcements to allow
operational modifications.
This registrar implementation is running on a router that otherwise
has no for a host name registered in DNS or DNS-SD, so it is using
it's MAC-address as its target host name, "0000-5e00-5314.local", the
same name is used in the registrar service instance names. Running
on a router without modular software, the registrar knows that no
other registrar instances can run on the same host and hence the name
has no further disambiguating elements.
Eckert & Dijk Expires 24 April 2025 [Page 35]
Internet-Draft BRSKI-discovery October 2024
Note also that there is never a need for two different service
instance names between BRSKI and cBRSKI, because they are
distinguished bt the "_tcp" versus "_udp" component of the service
instance name.
# BRSKI 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 "est-tls" "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 "rrm-cose"
# BRSKI-PRM 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 "prm"
# Host name
noc-registrar.example.org
IN AAAA 2001:DB8:0815::5e00:5333
Figure 3: DNS-SD for a BRSKI registrar applications
In the second example Figure 3, a server system in the NOC of
customer with domain example.org is set up as the registrar for
various BRSKI options. It uses [I-D.ietf-dnssd-srp] to register its
DNS-SD names into 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 BRSKI, one from an
integrator supporting pledges from various "IoT" vendors that
usecBRSKI, and one from a manufacturer that has pledges using BRSKI-
PRM.
Eckert & Dijk Expires 24 April 2025 [Page 36]
Internet-Draft BRSKI-discovery October 2024
Each of the three applications operates 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 useable, 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
appening some string abbreviation indicating its mode of operation
("brski", "cbrski", "prm"), and it's 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-RR, using these
creates 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. Signaling
This document does not specify a mandatory to implement set of
signaling options to guarantee interoperability of discovery between
initiator and responders when using GRASP. Like for the other
discovery mechanisms, these requirements will have to come from other
specifications that outline what in Section 1 is called the "security
and transport substrate" to be used for GRASP.
[RFC8994] specifies one such "security and transport substrate",
which is zero-touch deployable. It is mandatory to support for
initiators and responders implementing the so-called "Autonomic
Network Infrastructure" (ANI). DULL GRASP is used for link-local
discovery of proxies, and the ACP is used to automatically and
securely build the connectivity for multi-hop discovery of registrars
by proxies.
3.5.2.2. Encoding and Examples
To announce protocol variations with Section 1, the supported
Variation is indicated in the objective-value field of the GRASP
objective, using the method of forming the Variation string term in
Section 3.1.8.3, and listed in the Variation String column of the
Table 4 table.
If more than one Variation is supported, then multiple objectives
have to be announced, each with a different objective-value, but the
same location information if the different Variations are supported
across the same socket. Different sockets require different
objective structures in GRASP anyhow.
Compared to DNS-SD, the choice of encoding for GRASP optimizes for
minimum parsing effort, whereas the DNS-SD encoding is optimized for
most compact encoding given the limit for DNS-SD TXT records.
Eckert & Dijk Expires 24 April 2025 [Page 37]
Internet-Draft BRSKI-discovery October 2024
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_Proxy", 4, 1, "",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
["AN_Proxy", 4, 1, "prm",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
["AN_Proxy", 4, 1, "",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]
]
Figure 4: GRASP example for a BRSKI registrar supporting RRM and PRM
Figure 4 is an example for a GRASP service announcement for
"AN_Proxy" in support of BRSKI with both "rrm" and "prm" supported on
the same TCP port 4443 and for cBRSKI with COAP over DTLS on UDP port
4684.
Note that one or more complete service instances (in the example 3)
can be contained within a single GRASP message without the need for
any equivalent to the Service Instance Name of the DNS-SD PTR RR or
the Target name of the DNS-SD SRV RR. DNS-SD requires them because
its encoding is decomposed into different RR, but it also
intentionally introduces the Service Instance Name as an element for
human interaction with selection (browsing and/or diagnostics of
selection), something that the current GRASP objective-value encoding
does not support.
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_Proxy", 4, 1, "",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
["AN_Proxy", 4, 1, "",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]
]
[M_FLOOD, 42310815, h'fe800000000000000000000000000001', 180000,
[["AN_Proxy", 4, 1, "prm",
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_TCP, 44000]]
]
Figure 5: GRASP example with two different processes
Eckert & Dijk Expires 24 April 2025 [Page 38]
Internet-Draft BRSKI-discovery October 2024
In Figure 5, A separate application process supports "prm" and hence
uses a separate socket, with example TCP port 44000. In this case,
there is no need nor significant benefit to merge all service
instance announcements into a single GRASP message. Instead, the
BRSKI-"rrm"/cBRSKI process would be able to generate and send its
own, first, message shown in the example, and the second process
would send its own, second message in the example.
For a more extensive, DNS-SD compatible encoding of the objective-
value that also support Service Instance Names, see
[I-D.eckert-anima-grasp-dnssd].
3.5.3. CORE-LF
3.5.3.1. Overview
"Web Linking", [RFC5988] defines a format, originally for use with
HTTP headers, to link an HTTP document against other URIs. Web
linking is not a standalone method for discovery of services for use
with HTTP.
Based on Web Linking, "Constrained RESTful Environments (CoRE) Link
Format", Section 1 introduces a stand alone method to discover
resources, such as service instances. CORE-LF was introduced
primarily for use with Section 1 but it can equally be used for
discovery of service instances that use HTTP or any other suitable
(web transfer) protocols. This makes CORE-LF an alternative to DNS-
SD and GRASP for any of the BRSKI variations.
In CORE-LF, an initiator may use (link-local) IPv6 multicast UDP
packet to the COAP port (5683) to discover a possible responder for a
requested resource. The responder will reply with unicast UDP. If
the IPv6 address of a responder has been configured or is otherwise
known to the initiator, it may instead of multicast equally 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 which
is 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) and then use a unicast UDP or TCP
COAP connection to the CORE-RD server to discover CORE-LF resources
available on other systems. Resource providers can likewise register
their resources with the resource directory server using CORE-RD
registration procedures.
Eckert & Dijk Expires 24 April 2025 [Page 39]
Internet-Draft BRSKI-discovery October 2024
In summaery, CORE-LF including CORE-RD is a mechanism for
registration and discovery of resources and hence services which may
be preferred in deployments over other options and can equally be
applicable to register/discover any variation of BRSKI for any type
of BRSKI service.
3.5.3.2. Background
Section 1 specifies the use of CORE-LF as the reference method for
pledges to discover registrars - in the absence of any proxies, to
allow deployments of scenarios where no proxies are needed - and
hence also where Section 1 is not needed. Because BRSKI is designed
so that pledges can be agnostic of whether they connect to a
registrar directly or via a proxy, the resource/service that the
pledge needs to discover is nevertheless called "(brski) join proxy
(for pleges)", and encoded in CORE-LF as the value "brski.jp" for the
resource type attribute ("rt=resource-type") according to Section 1.
The following picture, Figure 6 shows the encoding and an example of
this discovery. "ff02::fd" is the link-local scope address for "All
Coap Nodes" in IPv6, as introduced in [RFC7390], which also defines
IPv6 and site-scoped address options.
Template:
REQ: GET coap://[All_Coap_Nodes_IP_multicast_addr]/.well-known/core?rt=brski.jp
RES: 2.05 Content
<coaps://[Responder_IP_unicast_address]:join-port>; rt="brski.jp"
Example:
REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp
RES: 2.05 Content
<coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp
Figure 6: CORE-LF discovery of registrar/proxy by pledges
Section 1 introduces the operations of a CoAP based join proxy both
as a connection based proxy as in Section 1 (only using UDP
connections for COAPs instead of TCP for TLS as in Section 1), but
also as a new, stateless join proxy - to eliminate the need for
potentially highly constrained join proxy nodes to keep connection
state and avoid the complexity of protecting that state against
attacks. The new resource type "brski.rjp" is defined to support
stateless join proxies to discover registrars and their UDP port
number that support the stateless, so-called JPY protocol.
Eckert & Dijk Expires 24 April 2025 [Page 40]
Internet-Draft BRSKI-discovery October 2024
The following picture, Figure 7 shows the encoding and an example of
this discovery. Section 1 introduces the new scheme "coaps+jpy" for
the packet header used by the stateless JPY" protocol. The request
in the template is assumed to be based on unicast, relying on another
method to discover the IP address of the registrar first. It could
equally use COAP site-scoped IP multicast, but in general, the
assumeption is that registrar will not necessarily be link-local
connected to proxies (this may be different in specific deployments).
Even though the registrar IP address is hence known, the reply still
needs to include this address again because in the [RFC6690] link
format, and [RFC3986], Section 3.2, the authority attribute can not
include a port number unless it also includes the IP address.
Template:
REQ: GET /.well-known/core?rt=brski.jpy
RES: 2.05 Content
<coaps+jpy://[Responder_IP_unicast_address]:join-port>;rt=brski.jpy
Example:
REQ: GET /.well-known/core?rt=brski.jpy
RES: 2.05 Content
<coaps+jpy://[2001:db8:0:abcd::52]:7633>;rt=brski.jpy
Figure 7: CORE-LF discovery of registrars that support stateless
JPY protocll by proxies
3.5.3.3. Specification
This section specifies the use of CORE-LF for BRSKI variations.
These specifications are backward compatible extensions to what was
is specified in [I-D.ietf-anima-constrained-voucher] and
[I-D.ietf-anima-constrained-join-proxy], except for noted exceptions,
where the requirements are narrowed. This document does not specifiy
how to discover It uses terms from the ABNF in section 2 of Section 1
and from [RFC3986] (URI) for explanations and relies on the following
template example, Figure 8.
Eckert & Dijk Expires 24 April 2025 [Page 41]
Internet-Draft BRSKI-discovery October 2024
Template:
REQ: GET /.well-known/core?rt=brski.*
RES: 2.05 Content
<scheme://[address]:port path-abempty>;\
rt=brski-service(;var="brski-variation-string(s)");\
pw="priority weight"
Figure 8: Template for BRSKI discovery with variations
BRSKI responder sockets are indicated in CORE-LF as a URI-Reference.
The URI-Reference SHOULD be a URI with a scheme, the IPv4 or IPv6
address of the responder socket and the port used by the responder.
It may optionally be followed by a non-empty path-abempty.
URL-references SHOULD not use a domain name instead of an address to
allow responders to 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. When omitting this information, the full information can only be
known in the context of the connections scheme and port through which
it was retrieved.
Note that these URL-Reference requirements are stronger than those
from [I-D.ietf-anima-constrained-voucher] and
[I-D.ietf-anima-constrained-join-proxy] to make extensibility easier.
BRSKI responder sockets MUST include a resource type field indicating
a resource type value indicating a BRSKI service, indicated as
"brski-service" in Figure 8. This MUST be registered in the IANA
"Resource Type Link Target Attribute Values" registry table, and also
referenced in the "BRSKI Variation Contexts" registry table Table 2.
A brski-service is a string without "." (single component string).
Discovery of registrar sockets by stateful proxies uses the resource
type "brski.rs". This can be used in conjunction with any scheme:
https:// for BRSKI and coaps:// for cBRSKI. Stateless registrar
sockets use the resource type "brski.rjpy". This currently only
support the coaps+jpy:// scheme. By its nature, it can only be used
with schemes that rely on UDP. These resource type uses are no
change over [I-D.ietf-anima-constrained-voucher] and
[I-D.ietf-anima-constrained-join-proxy]. This document does not
specifiy how to discover BRSKI-PLEDGE via CORE-LF.
The variations supported by a BRSKI responder socket are indicated
via the optional "var=" link-extension. The value is a quoted-string
of one or more space contatenated BRSKI variation strings. The
Eckert & Dijk Expires 24 April 2025 [Page 42]
Internet-Draft BRSKI-discovery October 2024
absence of a "var=" link-extension indicates support for only the
default variation for 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 semantic and format
defined in [RFC2782] for priority and weight in DNS SRV resource
records. If the attribute pw is absent, then it is assumed to mean
pw="65535 0".
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 /.well-known/core?rt=brski.*
01234567890123456789012345678901234567890123456789012345678901234567890123456789
RES: 2.05 Content
Content-Format: 40
Payload:
<https://[2001:DB8:0815::5e00:5314]:4555>; # [1]
rt=brski.rs;var="est-tls prm-jose cmp";
pw="1 2",
<https://[2001:DB8:0815::5e00:5314]:4555>; # [2]
rt=brski.jp;var="est-tls prm-jose cmp";
pw="1 2",
<coaps://[2001:DB8:0815::5e00:5314]:5684/b>; # [3]
rt=brski.rs;var=,
pw="1 2",
<coaps://[2001:DB8:0815::5e00:5314]:5684/b>; # [4]
rt=brski.jp;var=,
pw="1 2",
<coaps+jpy://[2001:DB8:0815::5e00:5314]:6534/b>; # [5]
rt=brski.rjpy;var=,
pw="1 2"
Figure 9: CORE-LF examples for BRSKI variations
Figure 9 shows example BRSKI variations in CORE-LF format. Note that
the example is pretty-printed through indentation and breaking long
lines. This additional white space is not compatible with actual
CORE-LF output. Likewise, the text following "#" are editorial
comments.
Eckert & Dijk Expires 24 April 2025 [Page 43]
Internet-Draft BRSKI-discovery October 2024
Example [1] is the equivalent announcement for a BRSKI registrar
service as shown for DNS-SD in Figure 2 except for the absence of any
service instance. Note the use of "var=" to indicate the list of
variation strings supported and "pw=" to indicate priority and weight
as in DNS-SD.
[3] is likewise the comparable example for the cBRSKI registar
example with DNS-SD. Note that here, a non-empty path-abempty "/b"
is used to indicate a shortened endpoint prefix path for the service.
There is no equivalent in DNS-SD defined. When discovering a service
via DNS-SD, the service will need to use the (longer) pre-defined
endpoint prefixes, such as "/brski" and "/est" instead of "/b".
Example [2] is the same socket as [1], but announced as a join proxy
socket for pledges. Likewise, [4] is the same socket as [2]
announced as a join proxy socket for pledges. Finally, [5] announces
the registrars socket in support of stateless BRSKI proxies using the
JPY header encapsulation.
3.5.3.5. Resource Type Considerations
CORE-LF expresses information about resources of a target identified
by a resource type. This specification encodes BRSKI services in
CORE-LF also as a resource types, 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 - instead of a service - describe
details of as little as a single endpoint, such as its URL prefix and
format encoding. The reason why this fine-grained specification is
not a good replacement for the concept of service and variation is
that the avilability of a set of endpoints with specific encodings
does not imply whether the target does support the desired specific
sequencing of instantiating those endpoints, including 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 benefit.
BRSKI resource types which are not treated as services according to
this specification can still be used if so desired to amend the
discovery of shortened endpoints, as shown in Figure 10.
Eckert & Dijk Expires 24 April 2025 [Page 44]
Internet-Draft BRSKI-discovery October 2024
RES: 2.05 Content
Content-Format: 40
Payload:
<https://[2001:DB8:0815::5e00:5314]:4555/b>; # [1]
rt=brski.rs;var="est-tls prm-jose cmp";
pw="1 2",
<https://[2001:DB8:0815::5e00:5314]:4555/b/rv>; # [2]
rt=brski.rs.requestvoucher,
<https://[2001:DB8:0815::5e00:5314]:4555/b/vs>; # [3]
rt=brski.rs.voucher_status,
</b/rv>;rt=brski.rs.rv, # [4]
</b/vs>;rt=brski.rs.vs, # [5]
Figure 10: CORE-LF resource examples
[1] shows how the prefix for all BRSKI endpoints over "https://" can
be shortened from "/.well-known/brski" to "/b". Nevertheless, this
would still make it necessary to use "/b/requestvoucher" and "/b/
voucher_status" as endpoints.
[2] and [3] show how to shorten those two endpoints to "/b/rv" and
"/b/rs" by creating resource types "brski.rs.rv" and "brski.rs.vs".
By using resource type prefix "brski.rs." for both of them as well as
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 such as shown in
example [4] and [5] when assuming that the abbreviations "rv" and
"vs" are also known even by BRSKI implementations from
[I-D.ietf-anima-constrained-voucher]. Likewise, the full socket
details can be avoided when one can infer it from context.
While these shortenings can be highly useful in often called
resources, each endpoint in BRSKI is typically only instantiated once
by a pledge, so the overall savings in communication data becauseof
these shortenings is likely negligible, and it is better to define
short endpoint paths into the variation specification if they are
likely needed, such as done in [I-D.ietf-anima-constrained-voucher],
such that it is not necessary in cBRKSI to add such shortenings in
discovery. For these reasons, this document does not specify if or
how to use such resource targets in cunjunction with BRSKI discovery
but only discusses possibilities and limitations here.
Considerations for such non-service resource type use in BRSKI
nevertheless introduces 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 "rv" or
"vs" can not be used to create BRSKI service name resource types
Eckert & Dijk Expires 24 April 2025 [Page 45]
Internet-Draft BRSKI-discovery October 2024
"brski.rv" or "brski.rs", and likewise, Additional BRSKI endpoints
can not be called "rs", "jp", "jpy" or any other string registered in
the BRSKI discover registry tables.
4. IANA considerations
4.1. Core Parameters
4.1.1. Resource Type Link Target Attribute Values
IANA is asked to reserve all resource type values starting with
"brski." in the "Resource Type (rt=) Link Target Attribute Values"
table. Resources with this prefix are meant to be required for
discovery of BRSKI services and resources (see Section 3.5.3.5) and
hence SHOULD be listed in the BRSKI Variation Contexts registry table
for use with CORE-LF, if they indicate a service, or be specified in
a BRSKI specification if they are resources but not services.
4.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 1: Target Variation and Priority/Weight Attributes
IANA is asked to add an entries for "var" and "pw" according to above
Table 1 to the "Target Attributes" table.
The "var" target attribute is meant to be used for BRSKI targets as
specified in this document. It is also meant to be useable for other
targets if so desired - to indicate variations of the resource type
of the target. For targets with a non-BRSKI resource target (not
using "rt=brski.*"), the format of the value may be different than
specified for BRSKI.
The "pw" target attribute indicates priority and weight for the
selection of the resource target with the semantic and format defined
in [RFC2782] for priority and weight in DNS SRV resource records. If
the attribute pw is absent, then it is assumed to mean pw="65535 0".
Eckert & Dijk Expires 24 April 2025 [Page 46]
Internet-Draft BRSKI-discovery October 2024
4.2. BRSKI Discovery Parameters Registry (section)
This document requests a new section named "BRSKI Variations
Discovery Parameters" in the "Bootstrapping Remote Secure Key
Infrastructures (BRSKI) Parameters" registry
(https://www.iana.org/assignments/brski-parameters/brski-
parameters.xhtml). Its initial content is as follows.
[ RFC editor. Please remove the following sentence. Note to IANA:
This section contains three tables according to the specifications of
this document. Each of these tables should include the table title
so that they can be more easily distinguished. If it is not possible
to introduce more than one table per section, then we will modify the
request accordingly for three sections, but given how the three
tables are tightly linked, that would be unfortunate. ]
Registration Procedure(s): Standards action or expert review based on
registration. See ThisRFC.
Experts: TBD.
Reference: ThisRFC.
Notes:
Dflt flag: Indicates a Variation Type Choice that is assumed to be
used if the service discover/selection mechanism does not indicate
any variation.
Rsvd Flag: Indicates a Variation Type Choice that is reserved for
use with the mechanism described in the Note(s) column, but for
which no specification yet exists.
Spec / Applicability: A "-" indicates that the variation is
considered to be feasible through existing specifications, but not
explicitly mentioned in them. An "NA" indicates that the
combination is assumed to be not working with the currently
available specifications.
4.2.1. BRSKI Variation Context Registry Table
+=======+==========+=========+=======================+=======================================+
|Context|Applicable|Discovery|Service Name(s) / |Reference(s) |
| |Variation |Mechanism|Transport | |
| |Types | | | |
+=======+==========+=========+=======================+=======================================+
|BRSKI |mode |GRASP |"AN_join_registrar" / |[RFC8995] |
| |vformat | |"AN_Proxy" | |
Eckert & Dijk Expires 24 April 2025 [Page 47]
Internet-Draft BRSKI-discovery October 2024
| |enroll | |with IPPROTO_TCP | |
+-------+----------+---------+-----------------------+---------------------------------------+
| | |DNS-SD |"brski-registrar" / |[RFC8995] |
| | | |"brski-proxy" | |
| | | |with TCP | |
+-------+----------+---------+-----------------------+---------------------------------------+
| | |CORE-LF |"rt=brski.jp" / |[THIS-RFC\ |
| | | |"rt=brski.rs" with | |
| | | |https | |
+-------+----------+---------+-----------------------+---------------------------------------+
|cBRSKI |mode |CORE-LF |rt=brski.jp with coaps |[I-D.ietf-anima-constrained-voucher] |
| |vformat | | | |
| |enroll | | | |
+-------+----------+---------+-----------------------+---------------------------------------+
| | | |rt=brski.rs / |[I-D.ietf-anima-constrained-join-proxy]|
| | | |rt=brski.rjpy with | |
| | | |coaps | |
+-------+----------+---------+-----------------------+---------------------------------------+
| | |DNS-SD |"brski-proxy" |[THIS-RFC] |
| | | |/ | |
| | | |"brski-registrar" / | |
| | | |"brski-registrar-rpy" | |
| | | |with UDP | |
+-------+----------+---------+-----------------------+---------------------------------------+
| | |GRASP |"AN_join_registrar" / |[THIS-RFC] |
| | | |"AN_join_registrar_rjp"| |
| | | |/ | |
| | | |"AN_Proxy" | |
| | | |with IPPROTO_UDP | |
+-------+----------+---------+-----------------------+---------------------------------------+
|BRSKI- |mode |DNS-SD |"brski-pledge" with TCP|[THIS-RFC] |
|PLEDGE |vformat | | | |
| |enroll | | | |
+-------+----------+---------+-----------------------+---------------------------------------+
Table 2: BRSKI Variation Contexts
4.2.2. BRSKI Variation Type and Choices Registry Table
+=======+=========+=========+=========+=====+=========================================+
|Context|Variation|Variation|Reference|Flags|Note(s) |
| |Type |Type | | | |
| | |Choice | | | |
+=======+=========+=========+=========+=====+=========================================+
|BRSKI, |mode |rrm |[RFC8995]|Dflt |Registrar Responder Mode |
|cBRSKI | | |ThisRFC | |the mode specified in [RFC8995] |
+-------+---------+---------+---------+-----+-----------------------------------------+
| | |prm |ThisRFC | |Pledge Responder Mode |
Eckert & Dijk Expires 24 April 2025 [Page 48]
Internet-Draft BRSKI-discovery October 2024
| | | | | |[I-D.ietf-anima-brski-prm] |
+-------+---------+---------+---------+-----+-----------------------------------------+
|BRSKI |vformat |cms |[RFC8368]|Dflt |CMS-signed JSON Voucher |
| | | |ThisRFC | | |
+-------+---------+---------+---------+-----+-----------------------------------------+
| | |cose |ThisRFC | |CBOR with COSE signature |
+-------+---------+---------+---------+-----+-----------------------------------------+
|cBRSKI | |cose |ThisRFC |Dflt |CBOR with COSE signature |
| | | | | |[I-D.ietf-anima-constrained-voucher] |
+-------+---------+---------+---------+-----+-----------------------------------------+
| | |cms |[RFC8368]| |CMS-signed JSON Voucher |
| | | |ThisRFC | | |
+-------+---------+---------+---------+-----+-----------------------------------------+
|BRSKI, | |jose |ThisRFC |Dflt*|JOSE-signed JSON, Default when prm is |
|cBRSKI | | | | |used |
| | | | | |[I-D.ietf-anima-jws-voucher], |
| | | | | |[I-D.ietf-anima-brski-ae] |
+-------+---------+---------+---------+-----+-----------------------------------------+
|BRSKI- |mode |prm |ThisRFC |Dflt |Pledge responder Mode |
|PLEDGE | | | | |[I-D.ietf-anima-brski-prm] |
+-------+---------+---------+---------+-----+-----------------------------------------+
| |vformat |jose |ThisRFC |Dflt |JOSE-signed JSON, Default when prm is |
| | | | | |used |
| | | | | |[I-D.ietf-anima-jws-voucher], |
| | | | | |[I-D.ietf-anima-brski-ae] |
+-------+---------+---------+---------+-----+-----------------------------------------+
| | |cms |ThisRFC |Rsvd |CMS-signed JSON Voucher, not specified. |
+-------+---------+---------+---------+-----+-----------------------------------------+
| | |cose |ThisRFC |Rsvd |CBOR with COSE signature, not specified. |
+-------+---------+---------+---------+-----+-----------------------------------------+
|BRSKI, |enroll |est |[RFC8995]|Dflt |Enroll via EST |
|BRSKI- | | |[RFC7030]| |as specified in [RFC8995], extension for |
|PLEDGE | | | | |Section 1 when used in context BRSKI- |
| | | | | |PLEDGE |
+-------+---------+---------+---------+-----+-----------------------------------------+
|cBRSKI | |est |ThisRFC |Dflt |Enroll via EST over COAP, [RFC9148] |
+-------+---------+---------+---------+-----+-----------------------------------------+
|BRSKI, | |cmp |ThisRFC | |Lightweight CMP Profile |
|BRSKI- | | | | |[I-D.ietf-anima-brski-ae], |
|PLEDGE | | | | |[I-D.ietf-lamps-lightweight-cmp-profile].|
+-------+---------+---------+---------+-----+-----------------------------------------+
|BRSKI | |scep |ThisRFC |Rsvd |[RFC8894] |
+-------+---------+---------+---------+-----+-----------------------------------------+
Table 3: BRSKI Variation Type and Choices
Eckert & Dijk Expires 24 April 2025 [Page 49]
Internet-Draft BRSKI-discovery October 2024
4.2.3. BRSKI Variations and Variation Strings
+=======+====================================+=========+=========+============+
|Context|Reference |Variation|Variation|Explanations|
| | |String | |/ Notes |
+=======+====================================+=========+=========+============+
|BRSKI |[RFC8995] |"" / |rrm cms |Note 1 |
| | |"EST-TLS"|est | |
+-------+------------------------------------+---------+---------+------------+
| |[I-D.ietf-anima-brski-ae] |cmp |rrm cms | |
| | | |cmp | |
+-------+------------------------------------+---------+---------+------------+
| |[I-D.ietf-anima-brski-prm] |prm-jose |prm jose | |
| | | |est | |
+-------+------------------------------------+---------+---------+------------+
|BRSKI- |[I-D.ietf-anima-brski-prm] |"" / |prm jose | |
|PLEDGE | |"prm- |est | |
| | |jose" | | |
+-------+------------------------------------+---------+---------+------------+
|cBRSKI |[I-D.ietf-anima-constrained-voucher]|"" / |rrm cose | |
| | |"rrm- |est | |
| | |cose" | | |
+-------+------------------------------------+---------+---------+------------+
Table 4: BRSKI Variation and Variation Strings
Note 1: The Variation String "EST-TLS" is equivalent to the
Variation String "" and is required and only permitted for the
AN_join_registrar objective value in GRASP for backward
compatibility with RFC8995, where it is used for this variation.
Note that AN_proxy uses "".
4.3. Service Names Registry
IANA is asked to modify and amend the "Service Name and Transport
Protocol Port Number Registry" registry
(https://www.iana.org/assignments/service-names-port-numbers/service-
names-port-numbers.txt) as follows:
brski-proxy and brski-registrar are to be added as Service Names for
the "udp" protocol using ThisRFC as the reference.
The registrations for brski-proxy and brski-registrar for the "tcp"
protocol are to be updated to also include ThisRFC as their
reference.
The Defined TXT keys column for brski-proxy and brski-registrar for
both "tcp" and "udp" protocols are to state the following text:
Eckert & Dijk Expires 24 April 2025 [Page 50]
Internet-Draft BRSKI-discovery October 2024
See ThisRFC and the "BRSKI Variation Type Choices" table in the
"Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters"
registry.
TBD: This request likely does not include all the necessary
formatting.
4.4. 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
support for Endpoint URIs is implied by the mechanisms specified in
this document and the existing registry has these cosmetic issues.
1. IANA is asked to change the name of the first column of the table
from "URI" to "URI Suffix". This is in alignment with other
table columns with the same syntax/semantic, such as
"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.
5. Security Considerations
In Section 1, pledges are easier subject to DoS attacks than in
Section 1, because attackers can be initiators and delay or prohibit
enrollment of a pledge by opening so many connections to the pledge
that a valid registrar-agents connection to the pledge may not be
possible. Discovery of the pledge via DNS-SD increases the ability
of attackers to discover pledges against which such DoS attacks can
be attempted.
Eckert & Dijk Expires 24 April 2025 [Page 51]
Internet-Draft BRSKI-discovery October 2024
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 does also introduce a perpass
attack, gathering intelligence against what type and serial number of
devices are installed in the network. Whether or not this is seen as
a relevant risk is highly installation dependent. Networks SHOULD
implement filtering measures at mDNS and/or DNS RR/services level to
prohibit such data collection if there is a risk, and this is seen as
an undesirable attack vector.
Service instance names as defined in Section 3.4 are used to discover
pledges by their manufacturer assiged serial numbers. Today, DNS-SD
does not provide security against impersonation of such service
instance names. Instead, impersonation can 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 [I-D.ietf-dnssd-srp]
with some security extension is used: Pledges need to signal their
IDevID for their SRP TLS connection, and the SRV server needs to have
the same manufacturer Service Instance Name schema and manufacturer
root CA information as BRSKI registrars and can then allow only the
permissible service instance name DNS-SD RRs for this pledge. In
fact, the SRP server could create the all necessary Section 3.4
required DNS-SD RRs from the IDevID information even if the pledge
itself is not requesting them or is requesting other DNS-SD RRs.
Definition of these procedures is outside the scope of this
specification though.
6. Acknowledgments
TBD.
7. Draft considerations
7.1. Open Issues
Questions to the DNS-SD community.
TBD
Eckert & Dijk Expires 24 April 2025 [Page 52]
Internet-Draft BRSKI-discovery October 2024
7.2. Change log
[RFC Editor: please remove this section.]
WG draft 05:
Mayor update to specifiy resilience aspects in selection of
responders.
Mayor update/simpliciation 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
[I-D.ietf-anima-brski-ae]
von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE:
Alternative Enrollment Protocols in BRSKI", Work in
Progress, Internet-Draft, draft-ietf-anima-brski-ae-13, 17
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-ae-13>.
Eckert & Dijk Expires 24 April 2025 [Page 53]
Internet-Draft BRSKI-discovery October 2024
[I-D.ietf-anima-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-15,
26 August 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-brski-prm-15>.
[I-D.ietf-anima-constrained-join-proxy]
Richardson, M., Van der Stok, P., and P. Kampanakis, "Join
Proxy for Bootstrapping of Constrained Network Elements",
Work in Progress, Internet-Draft, draft-ietf-anima-
constrained-join-proxy-15, 6 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima-
constrained-join-proxy-15>.
[I-D.ietf-anima-constrained-voucher]
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-25, 8 July
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
anima-constrained-voucher-25>.
[I-D.ietf-anima-jws-voucher]
Werner, T. and M. Richardson, "JWS signed Voucher
Artifacts for Bootstrapping Protocols", Work in Progress,
Internet-Draft, draft-ietf-anima-jws-voucher-12, 12
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-anima-jws-voucher-12>.
[I-D.ietf-dnssd-srp]
Lemon, T. and S. Cheshire, "Service Registration Protocol
for DNS-Based Service Discovery", Work in Progress,
Internet-Draft, draft-ietf-dnssd-srp-25, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-
srp-25>.
[I-D.ietf-lamps-lightweight-cmp-profile]
Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
Certificate Management Protocol (CMP) Profile", Work in
Progress, Internet-Draft, draft-ietf-lamps-lightweight-
cmp-profile-21, 17 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
lightweight-cmp-profile-21>.
Eckert & Dijk Expires 24 April 2025 [Page 54]
Internet-Draft BRSKI-discovery October 2024
[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>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/rfc/rfc6690>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
[RFC7030] 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>.
[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>.
[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 24 April 2025 [Page 55]
Internet-Draft BRSKI-discovery October 2024
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/rfc/rfc8368>.
[RFC8990] 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>.
[RFC8994] 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>.
[RFC8995] 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>.
[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>.
8.2. Informative References
[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-07, 7 July
2024, <https://datatracker.ietf.org/doc/html/draft-eckert-
anima-grasp-dnssd-07>.
Eckert & Dijk Expires 24 April 2025 [Page 56]
Internet-Draft BRSKI-discovery October 2024
[I-D.ietf-bess-evpn-fast-df-recovery]
Brissette, P., Sajassi, A., Burdet, L. A., Drake, J., and
J. Rabadan, "Fast Recovery for EVPN Designated Forwarder
Election", Work in Progress, Internet-Draft, draft-ietf-
bess-evpn-fast-df-recovery-11, 15 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-fast-df-recovery-11>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/rfc/rfc5988>.
[RFC7252] 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>.
[RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol",
RFC 8894, DOI 10.17487/RFC8894, September 2020,
<https://www.rfc-editor.org/rfc/rfc8894>.
Appendix A. Possible future variations
The following table Table 5 shows possible future entries for
"Variation String" if there is an interest for such a variation.
Thesew would be subject to expert review and could hence require
appropriate additional specification so that interoperability based
on that variation string can be guaranteed.
Eckert & Dijk Expires 24 April 2025 [Page 57]
Internet-Draft BRSKI-discovery October 2024
+=======+=========+=========+==========+========================================+
|Context|Reference|Variation|Variations|Explanations / Notes |
| | |String | | |
+=======+=========+=========+==========+========================================+
|BRSKI |- |jose |rrm jose |possible variation of [RFC8995] with |
| | | |est |voucher according to |
| | | | |[I-D.ietf-anima-jws-voucher] |
+-------+---------+---------+----------+----------------------------------------+
| |- |jose-cmp |rrm jose |possible variation of [RFC8995] with |
| | | |cmp |voucher according to |
| | | | |[I-D.ietf-anima-jws-voucher] and |
| | | | |enrollment according to |
| | | | |[I-D.ietf-lamps-lightweight-cmp-profile]|
+-------+---------+---------+----------+----------------------------------------+
| |- |cose |rrm cose |possible variation of [RFC8995] with |
| | | |est |voucher according to |
| | | | |[I-D.ietf-anima-constrained-voucher] |
+-------+---------+---------+----------+----------------------------------------+
| |- |cose-cmp |rrm cose |possible variation of [RFC8995] with |
| | | |cmp |voucher according to |
| | | | |[I-D.ietf-anima-constrained-voucher] and|
| | | | |enrollment according to |
| | | | |[I-D.ietf-lamps-lightweight-cmp-profile]|
+-------+---------+---------+----------+----------------------------------------+
| |- |prm-cmp |prm jose |possible variation of |
| | | |cmp |[I-D.ietf-anima-brski-prm] and |
| | | | |[I-D.ietf-anima-brski-ae] |
+-------+---------+---------+----------+----------------------------------------+
| |- |prm-cose |prm cose |possible variation of |
| | | |est |[I-D.ietf-anima-brski-prm] and |
| | | | |[I-D.ietf-anima-constrained-voucher] |
+-------+---------+---------+----------+----------------------------------------+
| |- |prm-cose-|prm cose |possible variation of |
| | |cmp |cmp |[I-D.ietf-anima-brski-prm], |
| | | | |[I-D.ietf-anima-constrained-voucher] and|
| | | | |[I-D.ietf-anima-brski-ae] |
+-------+---------+---------+----------+----------------------------------------+
Table 5
Contributors
Thomas Werner
Siemens AG
Germany
Email: thomas-werner@siemens.com
URI: https://www.siemens.com/
Eckert & Dijk Expires 24 April 2025 [Page 58]
Internet-Draft BRSKI-discovery October 2024
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
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 24 April 2025 [Page 59]