BRSKI discovery and variations

2.3.1. Simultaneous Deployment of Non-Interoperable Variations

As mentioned above, variations are not interoperable. For example, BRSKI and cBRSKI use different transport stacks: BRSKI uses TLS, while cBRSKI uses CoAP/DTLS, because memory-constrained devices already use those protocols and save memory by also relying on them for bootstrapping.¶

While implementations for unconstrained devices can support multiple variations, Pledge vendors will want to implement only those variation(s) that suit their business goals. Customer networks that simultaneously use products from different vendors (and market segments) will therefore need to support different variations at the same time. This requires a discovery approach in which non-interoperable variations can coexist and in which each device can discover peers that support the variation(s) it supports.¶

For example, one manufacturer of BRSKI Pledges may offer only a Registrar product supporting BRSKI, which uses [EST] as its enrollment protocol, whereas another manufacturer may want its Pledges to support only [BRSKI-AE] with CMP as the enrollment protocol. Each type of Pledge hence needs to discover a different Registrar. Third-party Registrars may support multiple or all variations, but such products may not be viable or may become available only later.¶

The ad hoc approach to supporting such variations with existing discovery mechanisms is to allocate a new, unique, discoverable "Service Name" for each variation. Such a name is assigned only when a new variation is specified, and potentially only for the one discovery mechanism considered most important at that time, in the hope that all deployments are able and willing to use it.¶

When another market segment of customers later prefers a different discovery mechanism, supporting it incurs significant overhead: a separate specification of the overall discovery procedure details, as well as the registration of "Service Name" parameters per discovery mechanism and per variation.¶

2.3.2. Variation-Agnostic Join Proxies

The second deployment challenge concerns Join Proxies, which are located in the network between Pledge and Registrar to overcome the layer 3 connectivity constraints of Pledges. They need to discover Registrars and announce themselves as Join Proxies to Pledges, and they need to do so in the presence of variations. Join Proxies operate only at the transport layer (TCP for BRSKI and UDP for cBRSKI), so in theory they can proxy the traffic of any current or future variation. To do so, however, they need to be able to recognize all current and future variations and to connect a Pledge to a Registrar that supports the variation(s) requested by the Pledge.¶

If variations use unique ad hoc "Service Names", then these "Service Names" have to be built into or configured on Pledges, which contradicts the goal of zero-touch deployment.¶

2.3.3. Variation Signaling through Discovery Metadata

To solve these challenges, BRSKI architecture discovery defines, for each discovery mechanism and transport option (UDP, TCP), a single "Service Name" for each discoverable entity (such as a Registrar). In addition, it defines, for each discovery mechanism, an encoding of the variation into a unique metadata field of that discovery mechanism. The string value of this field indicates the variation(s) and is consistent across all discovery mechanisms.¶

This design solves both of the deployment challenges described above for all current and future variations. If a new discovery mechanism needs to be introduced, it requires a new specification of this encoding, but no further per-variation work.¶

2.3.4. Variation Definition through IANA Registries

Variations are combinations of choices for different aspects of the BRSKI protocol. For example, a BRSKI exchange includes both the exchange of a voucher ([RFC8366bis]) and an enrollment protocol operation. The voucher can be formatted using CMS with JSON, COSE, or JOSE; the enrollment protocol can be a version of [EST], SCEP ([RFC8894]), or another protocol appropriate for the transport stack (TCP/TLS or CoAP). Voucher format and enrollment protocol are examples of what this document calls variation types; the specific format or protocol selected for each is a variation type choice.¶

Instead of assigning ad hoc variation names whenever they are needed in deployments, BRSKI architecture discovery defines both the variation types, such as voucher format and enrollment protocol, and their values through new IANA registries. It also defines how variation strings are formed from combinations of variation type choices.¶

In addition to registering variations composed of variation type choices, the IANA registries likewise define all other aspects of discovery that need to be extensible. This design choice minimizes the need for future specification and implementation work when deploying or developing additional variations, in many cases reducing it to just additional IANA registrations.¶

2.3.5. Automatic Redundancy and Failover Specification

Automatic resiliency and load sharing are enabled by the use of discovery mechanisms together with the provisioning of multiple instances of BRSKI architecture roles, such as Registrars and Join Proxies. This document specifies the procedures that support load sharing and (fast) failover upon failure and recovery of redundant components.¶

[DNS-SD] is widely deployed, but it is most commonly used in manual workflows, such as when (human) users browse DNS-SD Service Instance (Names) through (graphical) user interfaces and select an instance of a service based on out-of-band criteria ("this printer sounds good"). In BRSKI, selection is meant to be fully automated, for example performed by the bootstrap code of a Pledge, with no human in the loop.¶

Similarly, DNS/DNS-SD libraries are widely available and used, but predominantly as rather heavyweight code for "desktop" operating systems. They are less commonly available as lightweight libraries for the variety of embedded devices targeted by BRSKI, especially constrained devices or "general-purpose" network equipment such as Ethernet-connected routers in industrial, enterprise, and service provider networks.¶

Third, GRASP and CORE-LF are relatively new discovery mechanisms, for which little implementation experience and code exist with respect to automatic redundancy and failover.¶

For these reasons, this document also describes in detail the procedures for automatic redundancy and failover. The intent is to help implementers, to help operators understand the subtleties of this process, which is important for making BRSKI resilient, and to achieve implementations that are resilient by failing over automatically and quickly.¶

2.3.6. Discovery of Pledges through IDevID

[BRSKI-PRM] requires Pledges to be discoverable on the network. This specification expands on the details provided in [BRSKI-PRM], Section 6.2, specifically detailing how to derive the DNS-SD Service Instance Name from IDevID CommonName fields, using an example of a recommended IDevID encoding. It also explains why manufacturers need to document this mapping scheme, so that third parties can develop BRSKI Agents that discover Pledges using these mechanisms. Finally, it provides a detailed example.¶

The procedures for discovering Pledges are documented here only for DNS-SD, because they rely on the additional (but optional) functionality of browsing, which is not equally well defined or explored in other discovery mechanisms. When desired, the IANA registries introduced by this document can equally be used to add definitions that support additional discovery mechanisms for this functionality, assuming additional specifications of the necessary mechanisms.¶

3.1.1. Summary

The goal of defining an information model, and IANA registration tables for it, in this section is to make implementing announcement and discovery of current and future BRSKI architecture variations as simple as possible. Implementers should not have to painfully work out which specifications to read, without a central reference for which mechanisms exist and with possibly inconsistent nomenclature. Instead, they only need to start with the IANA registration tables introduced by this document and follow the references from them. From there, they can easily derive the necessary implementation steps.¶

When supporting a new discovery mechanism, the first step is to understand the basic encoding of BRSKI discovery attributes for that mechanism. The references for this are listed in the Table 4 registry table. For DNS-SD, GRASP, and CORE-LF, these references point to sections of this document; for future discovery mechanisms (or extensions to existing ones), they would point to future documents.¶

The next step is to determine, for the discovery mechanism of interest, the "service name" to use for each of the different roles (Pledge, Registrar, Join Proxy). This is found in the Table 6 registry table.¶

The last step is to determine, for each variation of interest, the Variation String to use in the metadata field of the discovery mechanism that encodes it. This is found in the Table 8 registry table.¶

The remaining tables support the process of adding new variations, and potentially new BRSKI roles to be discovered, across different transport stacks for BRSKI in a consistent, backward-compatible fashion. Implementers do not really need to understand them; they are only needed by experts, or by new specifications, when adding new variations through deployment testing and/or additional specifications. Table 7 defines the vocabulary from which variations are derived, and Table 5 specifies contexts, which ultimately exist to allow the same service names to be re-used across disjoint, non-conflicting communication spaces.¶

3.1.2. Roles and Services

In this document, a service is a specific functionality provided by a responder entity to an initiator entity over a responder socket using a particular transport/security/session stack (such as TCP, UDP, CoAP, DTLS, TLS, QUIC, ...). The mechanisms of this document enable initiators to automatically discover responder sockets and to select one that is interoperable with them.¶

[BRSKI] defines the roles of pledge, Join Proxy, registrar, and MASA. [BRSKI-PRM] adds the role of Registrar-Agent. Trust anchor (CA) is a dependent role required by the BRSKI architecture, provided through [EST] or other protocols in [BRSKI-AE]. A service is commonly named after the role of the responder, such as Join Proxy, registrar, or MASA.¶

A single entity may implement multiple roles. For example, registrars often also implement the Join Proxy role, and pledges, which stop being pledges after enrollment, often then become Join Proxies. Future BRSKI architecture documents may introduce additional roles, and many of the definitions in this document should be extensible to support such additional roles.¶

3.1.3. Service Names

The role that a responder socket supports is indicated in each discovery mechanism through an appropriate signaling element. [DNS-SD] calls this signaling element the Service Name. Because there is no other equally widely used term for this type of signaling element across arbitrary discovery mechanisms, this document also refers to the role signaling element as the Service Name, independent of the discovery mechanism. IP address, IP transport protocol, and IP transport protocol port are not part of the Service Name; they are signaled through discovery-mechanism-specific signaling elements.¶

3.1.4. Variations

Variations in the BRSKI protocol, such as the choice of message encoding or of features, could impact interoperability between initiator and responder. Initiators need to be able to discover and select responders based not only on the desired role, but also on the best variation for the initiator.¶

Variations of a role could be indicated by using a different Service Name for every variation, but that approach would have two problems:¶

1. Service Names in different discovery mechanisms are typically not hierarchical (e.g., not "role.variation"). Relying only on Service Names would thus require registering every variation as a separate Service Name in a "flat" name space, and registering it separately for each discovery mechanism. In addition, the registry rules of some discovery mechanisms may not look favorably on the registration of Service Names for such protocol variations.¶

2. Whenever a new variation is introduced, all deployed Join Proxies would need to be configured to also proxy this new variation, because new Service Names for the same BRSKI role cannot be auto-discovered by Join Proxies (without additional protocol mechanisms that would be more complex than the variations approach). Most Join Proxies, however, should be able to operate without configuration.¶

For these reasons, this document introduces the encoding of BRSKI (role) variations through a secondary signaling element in each discovery mechanism, enabling Join Proxies to transparently support any variation of BRSKI role connections for which they support proxying.¶

In addition, variations only need to be registered once, in a BRSKI-specific registry table introduced by this document, rather than once for each current or future discovery mechanism.¶

A variation is hence specified as a combination of signaling choices that a BRSKI connection may use and that affect interoperability between initiator and responder at the level of message exchange and encoding.¶

3.1.5. Variation Types

Today, BRSKI connections can exchange vouchers in one of several different encoding formats. Independent of that option, a BRSKI connection may also use different commands (so-called "Endpoints"); today, these depend on whether or not [BRSKI-PRM] is used. Finally, and also independent of those two options, a BRSKI connection may use one of several different enrollment protocols.¶

This document calls these options "Variation Types". The three variation types above are called "vformat" for the voucher format, "mode" for the Endpoints used (such as PRM or not), and "enroll" for the enrollment protocol used.¶

3.1.6. Variation Type Choices

The actual choices for each of these variation types are called "Variation Type Choices": "prm" or "rrm" for the variation type "mode"; "cmsj", "cose", or "jose" for the variation type "vformat"; and "est", "cmp", or "scep" for the variation type "enroll". The semantics of each Variation Type Choice are described in the Note(s) column of the Variation Type Choices registry (see Section 5.4.3) and in the references in its Reference(s) column.¶

"scep" is an example of the ability of the registry to reserve values: it is not adopted by any current BRSKI architecture specification.¶

3.1.7. Variation Strings

The string name of a variation is formed by concatenating a single variation type choice for every (necessary) variation type. For example, "prm-jose" could describe the protocol options used by a [BRSKI-PRM] connection from Registrar-Agent to registrar, potentially through a Join Proxy. This string representation of a variation is called the variation string, and it is used consistently for signaling across all discovery mechanisms.¶

In the future, when additional variation types and choices are introduced, existing variation strings MUST NOT be changed, to allow full backward compatibility with existing/deployed implementations.¶

For example, when using BRSKI over UDP, only CoAPS is supported today, but BRSKI UDP sockets could equally work with QUIC (which runs on top of UDP). In that case, a new variation type, e.g., "proto", could be introduced with the variation type choices "coaps" and "quic". For backward compatibility, "coaps" would then need to be defined as the default for BRSKI over UDP, which means that existing variation strings such as "" (for "rrm", "cose", and "est" in cBRSKI) imply the use of "coaps", whereas the use of QUIC would have to be indicated explicitly via "quic".¶

For variation strings to be semantically unambiguous, variation type choices have distinct names across all variation types, and the order in which variation type choices are concatenated is the order in which the variation types are defined in the corresponding registry table. Hence, new variation types have to be appended to the end of the list of Variation Types of the Context in the Contexts registry table (Section 5.4.1).¶

The fact that a variation name is composed of variation type choices does not mean that an unspecified variation of (random) variation type choices can work without new implementation or specification work, or that it even makes sense. This may or may not be the case. This is also why this document specifies a registry that explicitly enumerates all variations that are known to be sufficiently specified and to work.¶

For example, [BRSKI-PRM] is indicated through the variation type value "prm", but it may also require enhancements to the enrollment protocol used, which is specified by the variation type "enroll", such as new endpoints in that protocol. The functional semantics implied by an "enroll" variation type value are thus different in variations with "prm" than in variations without "prm". Moreover, [BRSKI-PRM] does not necessarily sufficiently specify these enhancements for enrollment protocols that were not yet known or specified when [BRSKI-PRM] was written.¶

3.1.8. Contexts

Variation strings are defined separately for every group of services for which the set of variation strings is, or could be, different or could have different semantics. A group of services for which the same variation strings are defined is called a Context.¶

Different lists of variation strings are necessary when services have different variation types, different variation type values, different deployed variations, or different defaults for the same variation type values, and hence different variation strings.¶

"tBRSKI" is the context covering [BRSKI] connections (which use TCP, hence the "t") from pledge to Join Proxy or registrar, and from Join Proxy to registrar.¶

"cBRSKI" ("c"onstrained BRSKI) is the context covering [cBRSKI] connections (using UDP) from pledge to Join Proxy or registrar, and from Join Proxy to registrar.¶

"BRSKI-PLEDGE" is the context covering pledges that use [BRSKI-PRM], for connections from Registrar-Agents to pledges. In the future, it can equally cover, through variations, the discovery of [BRSKI] pledges for connections to them for other purposes, by introducing appropriate variation types and values for such additional purposes.¶

This document does not define variations for different end-to-end encryption mechanisms. However, the mechanisms described here can also be used to introduce new, backward-incompatible secure transport options.¶

Also, this document does not introduce contexts for the discovery of BRSKI roles other than those mentioned, such as the discovery of MASAs by registrars. However, the registries introduced by this document are defined such that such contexts can also be introduced later through additional registry entries and specifications.¶

3.1.9. Discussion

Variations as defined by this document only cover protocol options that Join Proxies can support transparently, so that the definition of variations makes Join Proxies automatically extensible.¶

Other responder selection criteria, such as responder priority or performance-based selection (called weight in [DNS-SD]), are not covered by the variation concept, but can be used unchanged in conjunction with variations. Some selection criteria may also only work with discovery mechanisms that rely on specific procedures. For example, network distance to the responder can only be well supported by discovery mechanisms that support per-hop forwarding between initiator and responder, such as [GRASP]. All of these criteria work unchanged with the introduction of variations. Variations are simply one more selection criterion.¶

Differences in the supported transport stack of a responder are typically signaled through a signaling element of the discovery mechanism: whether TCP, UDP, or another IP transport protocol is used, and whether the responder uses IP or even another network layer protocol.¶

In "sane" services, a change in the transport stack does not imply a change in the signaled messages and their semantics. For such services, gateways could transparently proxy from IP to other network layer protocols and vice versa, or even between TCP and other IP transport protocols such as SCTP. However, this is out of scope for this specification.¶

The procedures specified for constrained BRSKI with a Join Proxy ([cPROXY]) would allow running not only a transport stack of CoAP over DTLS, but equally any other transport stack over UDP, such as QUIC. When following the procedures described in this document, this would not require any changes to the Join Proxy implementation or configuration. All that would be needed is to introduce appropriate entries in the registry tables specified in this document (e.g., adding a new Variation Type for the transport, with choices such as "coaps" or "quic").¶

3.1.10. IANA Registry Tables

This subsection restates and summarizes the information model introduced above, as it is instantiated in the IANA registry (and sub-registries) requested by this document, the so-called "BRSKI Discovery Parameters" registry (Section 5.4).¶

The detailed requirements for registrations and the initial content of the registry tables are defined in the corresponding IANA section.¶

3.2.1. Responder Selection

If more than one responder is discovered by an initiator, then the initiator SHOULD be able to sequentially attempt to connect to each feasible responder exactly once until it successfully connects to one. If it fails to connect to any feasible responder, the initiator SHOULD wait until at least 30 seconds have elapsed since the start of the last round before it restarts connection attempts. Before restarting, it SHOULD also update its discovered responder information from the discovery mechanism, if the chosen discovery mechanism does not already do this automatically.¶

A responder is feasible if it supports one or more of the variations requested by the initiator.¶

The order in which connections to responders are attempted is derived from two criteria: preference and weight.¶

Preference order is foremost determined by the initiator's preference across the variations supported by the responder. Within the set of responders with the same preference by the initiator because of their variation, the preference is further determined by discovery-mechanism-specific preference parameters, such as the "priority" parameter in DNS-SD, or possible future distance parameters in discovery mechanisms like GRASP.¶

If a responder socket offers more than one variation supported by the initiator, its preference order is derived from the most preferred of these variations.¶

Within a set of two or more responders with the same preference, the initiator MUST pick at random, especially after power-on or other reboot events. This ensures that those events have a chance to overcome possible persistent problems that would arise from persistently choosing the same first responder. If deployments desire reproducible and predictable ordering of connection attempts by initiators, then they have to use the discovery-mechanism-specific mechanisms, such as a different "priority" parameter for each responder in DNS-SD, to create such a strict ordering across the different responders.¶

Initiators SHOULD take discovery-mechanism-specific weighting, such as the "weight" parameter in DNS-SD, into account when determining the order of responders with the same preference.¶

Implementations of the resilient responder selection described so far SHOULD support selection among at least 4 and no more than 10 responders with one or more supported variations for each supported IP address family (IPv4 and/or IPv6). If more responders are discovered for the preferred variation(s) of the initiator, then it SHOULD pick a random subset of those responder announcements to select from.¶

Four responders for a specific variation are a typical minimum resilience setup in a larger network, in which two responders provide redundancy at the responder host level, and the other two provide redundancy against network connectivity failures to the first two. Intra-DC and inter-DC service redundancy is a simple example of such a setup.¶

3.2.2. Service Announcements

Responder selection as described in Section 3.2.1 needs to deal with unresponsive responders, because service announcements may be stale. This happens when service announcements only loosely track the aliveness of a service process.¶

In typical implementations, service announcements may be activated when the service process starts, and stopped when it stops. Problems such as a hanging (unresponsive) service process will not be reflected in the service announcements. In addition, caching of service announcements, such as through the DNS TTL field, is a further possible cause of incorrectly assuming service aliveness. Only actual connection probing or similar tracking can determine whether a service responder is responsive to the level of accepting connections.¶

Responders intended to be used in resilient deployments SHOULD therefore ensure that their service announcements are not active when the responder has died or has failed to successfully accept connections for 120 seconds or more. This can be implemented, for example, by connection probing once every 30 seconds and withdrawing the service announcements when probing fails, or by other forms of tracking the responsiveness of the responder functionality.¶

The better service announcements indicate the actual aliveness of service instances, the faster service selection will be. In addition, in large networks, backup/standby service instances can then be implemented by tracking primary service announcements and activating the backup only when the primary ones fail. Such dynamic backup can further reduce the overall load on the discovery mechanism used and on initiators.¶

3.2.3. Responder Selection in Proxies

Unless amended by the requirements listed below, proxies SHOULD follow all of the descriptions in Section 3.2.1. Note that the random selection of responders with the same preference also applies to stateful proxies, and ensures load balancing (including weighting) across multiple simultaneously connecting pledges.¶

Stateful proxies SHOULD optimize the selection of responders for each variation across connections from multiple pledges. This avoids restarting the sequence of responders to try from the highest precedence for every newly connecting pledge, which would repeatedly run into timeouts for each newly connecting pledge when those primary responders time out on connection attempts because they are unresponsive or unreachable. Instead, after a responder first fails to connect, the Join Proxy SHOULD skip this responder in further connection attempts for other connecting pledges.¶

Stateless proxies cannot learn of the unresponsiveness or unreachability of a responder through connection attempts. Instead, they SHOULD perform a stateless responsiveness/reachability check for each responder to which the Join Proxy is actively forwarding packets from one or more pledges. If no packets are returned from such a responder for more than 30 seconds, then the responder SHOULD be considered unreachable for at least 180 seconds. Unreachability signaling received in response to packets sent to the responder SHOULD trigger this unreachability status if it persists for 10 seconds.¶

Load balancing as described in Section 3.2.1 is NOT RECOMMENDED for stateless proxies, because per-pledge stateless load balancing may involve more processing complexity than is feasible for proxies on constrained devices. To avoid changing the selection of active responders when one responder becomes unresponsive, a "stable hash" approach would have to be used, such as described in [HRW98], which is used, for example, by [RFC9722]. Supporting weights with stateless proxying is even more complex. Instead of relying on load balancing, responders simply need to be designed to scale to the maximum number of simultaneous initiator connections necessary when supporting stateless proxying mode.¶

3.2.4. Protection against malicious service announcements

Responders, including Join Proxies announcing their own responder sockets, SHOULD always announce the most preferred priority and weight parameters possible in the discovery mechanism used that still allow the desired preference goals to be met. For example, in DNS-SD, a primary responder should announce the numerically lowest priority value (0) and the highest weight value possible ([RFC2782]).¶

This recommendation is intended as protection against erroneous, but not malicious, service announcements whenever the default priority is less preferred than the most preferred priority. It can also serve as weak protection against malicious announcements, because with the selection rules required by this document, initiators still have the highest chance of picking the non-malicious announcement.¶

While weak, this recommendation can still be better than nothing against such malicious announcements. These recommendations SHOULD be superseded by better recommendations for more narrowly scoped deployment scenarios.¶

3.3.1. Join Proxy Support for Variations

A Join Proxy compliant with this specification MUST support announcing its Join Proxy responder socket(s), to which pledges can connect, via at least one of the discovery mechanisms included in the registry tables specified in this document. The Join Proxy MUST announce the variation(s) supported on its responder socket(s) according to the registry table entries.¶

A Join Proxy SHOULD support passing packets for any variation for which it has discovered one or more registrar sockets supporting that variation, without the variation needing to be known at the time the Join Proxy is implemented, or configured on the Join Proxy. A Join Proxy that meets this requirement is said to support "arbitrary variations". Meeting this requirement requires the Join Proxy to discover registrar(s) and their supported variation(s) via one or more of the discovery mechanisms included in the registry tables specified in this document.¶

Support for arbitrary variations allows proxies to be deployed once, and pledges and registrars supporting new variations to be added later, without upgrading or reconfiguring the proxies.¶

Every Variation has exactly one Variation String, with one exception for backward compatibility with [BRSKI]: the GRASP objective AN_join_registrar uses the objective-value "EST-TLS" for the Variation String "" in the tBRSKI context (see Note (1) of Table 8). A Join Proxy MUST treat an AN_join_registrar objective-value of "EST-TLS" as the Variation String "". All other Variation Strings are compared as they are, and announced unchanged.¶

3.3.2. Join Proxy Operation Modes

Proxies may use different approaches to connect to registrars. The following subsections discuss the most relevant options.¶

3.3.3. Extensibility to Non-BRSKI Services

Join Proxy implementations using the procedures described in this document can easily be reused for any protocols other than BRSKI, as long as they use TCP or UDP. This simply requires that the Join Proxy can be configured with pairs of service names other than those used by tBRSKI/cBRSKI: a service name to discover, and a service name to use for the service announcements of the Join Proxy responder socket.¶

3.3.4. Scaling service discovery and selection

Discovering and selecting an available service instance can become a design challenge in large networks with many redundant service announcements.¶

Consider, for example, the common case of allowing BRSKI enrollment in a network with many geographically spread-out sites, such as in enterprise, industrial, or building construction environments. During the initial bring-up of such sites, Internet connectivity may be non-existent or intermittent, and hence one or more local registrars in each such site are highly desirable. Such registrars may of course require private mobile network connectivity to the MASA, or rely on out-of-band provisioning of vouchers.¶

Later, when such a site gets a well-working wide-area network connection, it may be more appropriate to use more centralized registrars, but a local registrar may still be considered useful as a backup. However, the service announcements of such decentralized per-site registrars might then be discoverable across the whole geographically spread-out network. This could introduce potentially significant overhead to the service announcement and discovery system, for example when more than 100 registrar service announcements exist in the network and pledges/proxies connect to them.¶

Such a large number of redundant service announcements is typically highly undesirable, and appropriate configurations of the service discovery mechanisms need to be used to avoid them. For example, in GRASP, service announcements can be scoped to small hop counts. Alternatively, anycast addressing can be used to make all decentralized registrars share the same IP address, and hence the same service announcement.¶

3.4.1. BRSKI-PLEDGE context

BRSKI-PLEDGE is the context for the discovery of pledges by nodes such as Registrar-Agents. Pledges supporting [BRSKI-PRM] MUST support it. It may also be used by other variations of the BRSKI architecture outside of the PRM use case, for example, for inventorying pledges.¶

Pledges supporting BRSKI-PLEDGE MUST support DNS-SD for discovery via mDNS, using link-local scope. For DNS-SD discovery beyond link-local scope, pledges MAY support DNS-SD via [DNSSD-SRP], using automatic discovery of the SRP server and registering the DNS-SD data defined below with it.¶

These DNS-SD requirements are defaults. Specifications for specific deployment contexts, such as specific types of radio mesh network solutions, may need to specify their own requirements that override or amend these requirements.¶

Pledges MUST be discoverable via their DNS-SD service instance name.¶

Pledges SHOULD be discoverable via DNS-SD browsing, so that Registrar-Agents can find unexpected pledges, or can more easily enumerate expected pledges, especially in the presence of multiple different subnets and the use of mDNS. If the owner cannot acquire the serial-number information of a pledge by the time BRSKI-PRM needs it (to create a service instance name), the pledge can only be found by browsing.¶

When pledges are discoverable via DNS-SD browsing, the "_brski-pledge" PTR service name is a so-called shared resource record. When it is requested via mDNS (multicast), all pledges supporting BRSKI-PLEDGE and browsing will respond simultaneously, potentially creating congestion/contention. To avoid this, [mDNS] specifies the following requirement: "each responder SHOULD delay its response by a random amount of time selected with uniform random distribution in the range 20-120 ms."¶

It is likewise RECOMMENDED to apply the same random delay rule to answers to multicast or flooded queries in other discovery mechanisms that have the same response burst problem, even when they do not specify such a mechanism themselves, such as GRASP.¶

If a pledge does not want to support browsing, it simply does not respond to queries for the "_brski-pledge" service name in mDNS, or to queries for the equivalent service name in other discovery mechanisms. When using unicast DNS-SD via [DNSSD-SRP], it does not register its PTR RR for this service name. This does not affect operations for the service instance name.¶

This specification does not introduce procedures to discover pledges via CORE-LF or GRASP, because it is unclear whether there is currently demand for this, and because it can easily be added via additional specifications and registry entries. For CORE-LF, browsing of entries can be supported via CORE-RD ([RFC9176]), with appropriate auto-discovery of the CORE-RD server. For GRASP, this could be done via a method mapping DNS-SD into GRASP, such as [I-D.eckert-anima-grasp-dnssd], specifically to support browsing of pledge instance names.¶

3.4.2. Service Instance Name

The service instance name chosen by a BRSKI pledge MUST be composed of information that is¶

• easily known by BRSKI operations, such as operational personnel or software automation, specifically sales integration backend software; and¶

• available to the pledge software itself, for example, by being encoded in some attribute of the IDevID.¶

Typically, a customer will know the serial number of a product from sales information, or even from bar codes/QR codes on the product itself. If this serial number is used as the service instance name to discover a pledge from a Registrar-Agent, then this may potentially (although unlikely) lead to (duplicate) replies from two or more pledges with the same serial number, such as in the following cases:¶

1. A manufacturer has different product lines and re-uses serial numbers across them.¶

2. Two different manufacturers use the same serial-number space.¶

If pledges enable browsing of their service instance name, they MAY support the procedures specified by DNS-SD to create unique service instance names when they discover such clashes. These procedures append a space and a number, starting with 2, to the service instance name: "<service-instance-name> (2)", as described in [DNS-SD], Appendix D.¶

Nevertheless, this approach to resolving conflicts is not desirable:¶

• If browsing of DNS-SD service instance names is not supported, Registrar-Agents would always have to (mostly wrongly) guess that there is a clash and (mostly unnecessarily) search for "<service-instance-name> (2)".¶

• If a clash exists between pledges from the same manufacturer, then even if the Registrar-Agent attempts to start enrolling all pledges with the same clashing service instance name, it may not have enough information to distinguish the pledges other than by the random numbering. This would happen especially if the IDevIDs of both devices (of different product types) had the same serial number, and the trust anchor certificate of both was the same (e.g., the same root CA certificate), which is likely when they are from the same manufacturer. Even if some other IDevID field were used to distinguish their device models, the Registrar-Agent would not be able to determine that difference without additional vendor-specific programming.¶

As a result:¶

• Vendors MUST document how their pledges form a service instance name from information available to the customer of the pledge. This may, for example, take the form of a schema as in Figure 1, point 1.2.¶

• These service instance names MUST be unique across all IDevIDs from the manufacturer that share the same trust anchor.¶

The following mechanisms are recommended:¶

• Pledges SHOULD encode manufacturer-unique product instance information in the serialNumber attribute of their subject name. [RFC5280] calls this the X520SerialNumber.¶

• Pledges SHOULD make this serialNumber information consistent with product instance information that is easily accessible when in physical possession of the pledge, such as the product type code and serial number on a bar code/QR code, to enable [BRSKI-PRM] discovery without additional backend sales integration. Note that discovery alone does not allow for enrollment (so it does not introduce a security risk by itself)!¶

• Pledges SHOULD construct their service instance name by concatenating their X520SerialNumber with a domain name that is used by the manufacturer, and that thus allows devices from different manufacturers using the same serialNumber scheme to be disambiguated, reducing the likelihood of service instance name clashes that would arise if manufacturer names were not used.¶

• Pledges MAY re-use the service instance name as their host name in their AAAA or A RRs.¶

3.4.3. Example

This section discusses an example manufacturer's approach using the recommendations above. Figure 1 shows the different data involved in DNS-SD records for a pledge from the manufacturer "Example".¶

    1. Manufacturer published information:

      1.1 IDevID trust anchor certificate.

      1.2 IDevID X520 identification schema:
        Brand: Example
          O = example.com, serialNumber = "PID:Model-<PID> SN:<SN>"
          ; Explanation:
          ; SN = Serial Number, PID = Product Identifier
          ; O = Organization

      1.3 DNS-SD Instance Schema:
        <X520SerialNumber>.example.com

    2. Example Purchase Order Pledge Information
       Brand: Example, Model: 0815, Serial: WLDPC2117A99

    3. DNS-SD Instance string:
      "PID:Model-0815 SN:WLDPC2117A99.example.com"

    4. DNS-SD RR for the pledge (using mDNS, and hence .local):
      ; PTR RR to support discovering the pledge through browsing,
      ; e.g. when the serial number is not known in advance
      _brski-pledge._tcp.local  IN PTR
        PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local

      ; SRV and TXT RR for the service instance name
      PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
        IN SRV 1 1
        PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local
      PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
        IN TXT ""

      ; AAAA address resolution for the target host name
      PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local
        IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:00a1

    5. Example Pledge IDevID certificate information:
        ; Format as shown by e.g.: openssl
        Subject: serialNumber = "PID:Model-0815 SN:WLDPC2117A99",
         O = example.com, CN = Model-0815

Using the information from Figure 1, a Registrar-Agent implementation operates as follows.¶

1. Initially, it is configured with the manufacturer-published information (1.); although not shown, it will likely have a list of such information for various brands of products.¶

2. After a pledge has been purchased and initially physically deployed, the Registrar-Agent is provided with the purchase order information for the pledge (2.). This order information tells it that the manufacturer's brand is "Example", that the pledge product model <PID> is "0815", and that its serial number <SN> is "WLDPC2117A99".¶

3. It looks up the IDevID X520 identification schema for brand "Example" and uses the template value for the serialNumber field, together with the pledge information values from (2.) for O, <PID>, and <SN>, to determine the DNS-SD Instance of the pledge (3.). That instance is the concatenation of the X520 serialNumber value of the pledge with the Organization domain name of the manufacturer. Because the Organization is a global DNS domain, "example.com", including it in the Instance makes the Instance unique across manufacturers.¶

4. It then uses standard DNS-SD via mDNS to find the pledge, using the DNS-SD Resource Records (RRs) shown in (4.).¶

5. Once it receives a response from the device claiming to be the pledge, it can use any appropriate authentication mechanism to validate ownership of the IDevID private key. In [BRSKI-PRM], this is done through the initial TLS handshake, in which it learns the presumed IDevID of the pledge. When the signature of the IDevID can be validated with the public key of the desired manufacturer's trust anchor from (1.1), it trusts that this pledge is from that manufacturer. When the O and serialNumber of the certificate match what it constructed in (3.) from the <PID>/<SN> values of the purchase information, it also trusts that this is indeed the pledge it was looking for.¶

Instead of using sales receipt information, the customer may also use scanned QR code/barcode or RF tag information from packaging after receiving shipments, for example, for step 2. Scanning packaging information will likely introduce additional complexity, because the manufacturer name can often only be derived from information such as EAN-13 barcodes.¶

The process steps may also be simpler if the customer can learn the IDevID of the pledge through the purchase process, instead of having to match the IDevID against sales receipt information (step 2).¶

The process steps may also become more complex. The manufacturer may have multiple brands using the same trust anchor. Or the manufacturer may have certificate chains, and different production sub-companies may use different sub-CA certificates in the signing chain. Or the serialNumber alone may not be unique across the certificate chain, so that further Subject fields of the certificate are required for unique identification, such as the O(rganization) field. That field could, for example, contain one of multiple brand names that use simple numerical serialNumber formats and hence could collide. None of these complexities are desirable for new designs, but they may be necessary to support BRSKI for existing products.¶

For the described mechanism to work, the manufacturer does not necessarily have to own a domain name such as "example.com" in the example. Owning a domain name and using it for the DNS-SD Instance Schema is just a simple way to ensure the use of a unique Instance Schema - if all manufacturers agree to use this approach.¶

The RR used to discover the pledge by its serial number is the "IN SRV" RR. The "IN PTR" RR is optional and allows the pledge to be discovered with DNS-SD browsing, which is necessary if the pledge's serial number information cannot be known by the time the pledge needs to be enrolled by a Registrar-Agent.¶

The instance string is also re-used in the host name of the "IN SRV" RR, and hence in the domain name of the "IN AAAA" RR. This is just an option; the pledge can use whatever host name it wants.¶

3.5.1. DNS-SD

# tBRSKI context
_brski-proxy._tcp.local
               IN PTR  0000-5e00-5314._brski-proxy._tcp.local
0000-5e00-5314._brski-proxy._tcp.local
               IN SRV  1 2 4555 0000-5e00-5314.local
0000-5e00-5314._brski-proxy._tcp.local
               IN TXT  "var=,prm-jose,cmp"

# cBRSKI
_brski-proxy._udp.local
                IN PTR  0000-5e00-5314._brski-proxy._udp.local
0000-5e00-5314._brski-proxy._udp.local
                IN SRV  1 2 5684 0000-5e00-5314.local
0000-5e00-5314._brski-proxy._udp.local
                IN TXT  "var="

# Host name
0000-5e00-5314.local
               IN AAAA  2001:DB8:0815::5e00:5314

# tBRSKI registrar application
_brski-registrar._tcp.example.org
     IN PTR  noc-registrar-brski-37253._brski-registrar._tcp.example.org
noc-registrar-brski-37253._brski-registrar._tcp.example.org
     IN SRV  1 2 4555 noc-registrar.example.org
noc-registrar-brski-37253._brski-registrar._tcp.example.org
     IN TXT "var=,cmp"

# cBRSKI registrar application
_brski-registrar._udp.example.org
     IN PTR  noc-registrar-cbrski-5376._brski-registrar._udp.example.org
noc-registrar-cbrski-5376._brski-registrar._udp.example.org
     IN SRV  1 2 7533 noc-registrar.example.org
noc-registrar-cbrski-5376._brski-registrar._udp.example.org
     IN TXT "var="

# tBRSKI, PRM variation application
_brski-registrar._tcp.example.org
               IN PTR noc-registrar-prm-9735._brski-registrar._tcp.example.org
noc-registrar-prm-9735._brski-registrar._tcp.example.org
               IN SRV 1 2 17355 noc-registrar.example.org
noc-registrar-prm-9735._brski-registrar._tcp.example.org
               IN TXT "var=prm-jose"

# Host name
noc-registrar.example.org
               IN AAAA  2001:DB8:0815::5e00:5333

3.5.2. GRASP

[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
    [["AN_join_registrar", 4, 255, "EST-TLS"],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]],

    [["AN_join_registrar", 4, 255, "prm-jose"],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]],

    [["AN_join_registrar", 4, 255, ""],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]],

    [["AN_join_registrar_rjp", 4, 255, ""],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_UDP, 4686]]
]

[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
    [["AN_Proxy", 4, 1, ""],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_TCP, 5553]],

    [["AN_Proxy", 4, 1, "prm-jose"],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_TCP, 5555]],

    [["AN_Proxy", 4, 1, ""],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_UDP, 5684]]
]

[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
    [["AN_join_registrar", 4, 255, "EST-TLS"],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]],

    [["AN_join_registrar", 4, 255, ""],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]
]

[M_FLOOD, 42310815, h'fe800000000000000000000000000001', 180000,
    [["AN_join_registrar", 4, 255, "prm-jose"],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_TCP, 44000]]
]

3.5.3. CORE-LF

Pledge discovering Join Proxies:

REQ: GET coap://[ff02::fd]/.well-known/core?brski-jp=*

RES: 2.05 Content
     <>;brski-jp=8485

Stateful Join Proxy discovering registrars:

REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski

RES: 2.05 Content
     <coaps://[2001:db8:0:abcd::52]/b>;rt=brski

Stateless Join Proxy discovering registrars:

REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski.rjp

RES: 2.05 Content
     <jpy://[2001:db8:0:abcd::52]:7634>;rt=brski.rjp

Template:

REQ: GET /.well-known/core?rt=brski-service

RES: 2.05 Content
     <scheme://[address]:port path-abempty>;\
       rt=brski-service(;var="brski-variation-string(s)");\
       pw="priority weight"

REQ: GET /.well-known/core?brski-jp=*

RES: 2.05 Content
     <>;brski-jp=join-port(;var="brski-variation-string(s)");\
       pw="priority weight"

REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski

RES: 2.05 Content
Content-Format: 40
Payload:
 <coaps://[2001:db8:0:abcd::52]/b>;               # [1]
        rt=brski;var=",cmp";pw="1 2"

REQ: GET coap://[ff05::fd]/.well-known/core?rt=brski.rjp

RES: 2.05 Content
Content-Format: 40
Payload:
 <jpy://[2001:db8:0:abcd::52]:7634>;              # [2]
        rt=brski.rjp;var=",cmp";pw="1 2"

REQ: GET coap://[ff02::fd]/.well-known/core?brski-jp=*

RES: 2.05 Content
Content-Format: 40
Payload:
 <>;brski-jp=61616,                               # [3]
 <>;brski-jp=61617;var=",cmp";pw="1 2"            # [4]

RES: 2.05 Content
Content-Format: 40
Payload:
 <coaps://[2001:DB8:0815::5e00:5314]:5684/b>;      # [1]
        rt=brski;var=",cmp";
        pw="1 2",
 <coaps://[2001:DB8:0815::5e00:5314]:5684/b/rv>;   # [2]
        rt=brski.rv,
 <coaps://[2001:DB8:0815::5e00:5314]:5684/b/vs>;   # [3]
        rt=brski.vs,
 </b/rv>;rt=brski.rv,                              # [4]
 </b/vs>;rt=brski.vs                               # [5]

5.1.1. Resource Type Link Target Attribute Values

This document introduces additional requirements for the registration of CoRE Resource Type values with the prefix "brski" in the "Resource Type (rt=) Link Target Attribute Values" sub-registry of the "Constrained RESTful Environments (CoRE) Parameters" registry, as specified in Section 4.3.¶

IANA is requested to document these additions by adjusting the registration procedure table for the "Resource Type (rt=) Link Target Attribute Values" sub-registry as shown in Table 1.¶

5.1.2. Target Attributes

IANA is asked to add entries for "var" and "pw" to the "Target Attributes" table, according to Table 2.¶

The "var" target attribute is intended to be used in links for BRSKI services as specified in this document (Section 3.5.3.3). It is also intended to be usable in other links, if so desired, to indicate variations of the service or resource of the link. For links that do not indicate a BRSKI service, the format of the value may differ from that specified for BRSKI.¶

The "pw" target attribute indicates priority and weight for the selection of the resource target, with the semantics and format defined in [RFC2782] for priority and weight in DNS SRV resource records. If the pw attribute is absent, it is assumed to be pw="65535 0".¶

5.4.1. Contexts

IANA is asked to create a sub-registry called "Contexts" in the "BRSKI Discovery Parameters" registry.¶

The Registration Procedure for this registry is Specification Required, where the Expert Review has to ensure the feasibility of entries with respect to the following behavior/rules.¶

A Context is a name for a group of one or more BRSKI services. This sub-registry registers a Context name and the list of Variation Types defined for the Context.¶

Variation Types are case-insensitive, consist only of the letters a-z and the digits 0-9, must start with a letter, and must be at most 12 characters long.¶

Registration of new Contexts MUST include a specification of how to use discovery with the new Context, using the specifications for tBRSKI, cBRSKI, and BRSKI-PLEDGE in this document as examples.¶

Technically, Contexts with the same set of Variation Types exist, for example, to allow different protocol stacks for otherwise logically the same type of services to be registered, and hence discovered; otherwise, a tBRSKI pledge might discover a cBRSKI registrar. See Section 5.4.2 for more details.¶

The order of Variation Types defines the order in which Variation Type Values are concatenated to generate Variation Strings, as described in Section 5.4.4. Therefore, once registered, Variation Types SHOULD NOT be changed or deleted, so that new Variation Strings will be constructed consistently with old ones. New Variation Types may only be appended through registration updates.¶

Registration of additional Variation Types MUST include a specification of how they map to specific functions of the services that use them, as this specification does for tBRSKI, cBRSKI, and BRSKI-PLEDGE.¶

Registrations of a new Context MAY initially not define any Variation Types, if Variations are not yet considered for that Context.¶

The initial content of this sub-registry is as follows.¶

Designated Experts:

TBD.¶

Registration Procedure:

Specification Required.¶

Notes:

See [ThisRFC], Section 5.4.1¶

5.4.2. Service Names

IANA is asked to create a sub-registry called "Service Names" in the "BRSKI Discovery Parameters" registry.¶

The Registration Procedure for this registry is Specification Required, where the Expert Review has to ensure the feasibility of entries with respect to the following behavior/rules.¶

Each entry registers a Service Name intended for the discovery of a BRSKI-related service using a specific discovery mechanism. The service is to be accessed via specific service (transport) stack Parameter(s) that need to be known to the discovery mechanism.¶

Depending on the discovery mechanism, the Service Name represents a different signaling element of the discovery mechanism, as follows.¶

• For DNS-SD, the Service Name in the table is the DNS-SD Service Name, which MUST also be registered in the IANA "Service Name and Transport Protocol Port Number Registry" for use with the DNS-SD protocol indicated in the Parameter(s) column.¶

• For GRASP, the Service Name is the GRASP Objective Name, which MUST also be registered in the IANA "GeneRic Autonomic Signaling Protocol (GRASP) Parameters" / "GRASP Objective Names" registry.¶

• For CORE-LF, the Service Name is either a CoRE Resource Type (rt=) value, which MUST be registered in the IANA "Constrained RESTful Environments (CoRE) Parameters" / "Resource Type (rt=) Link Target Attribute Values" registry, or the name of a CoRE target attribute (indicated as "(target attribute)" in the Parameter(s) column), which MUST be registered in the IANA "Constrained RESTful Environments (CoRE) Parameters" / "Target Attributes" registry ([RFC9423]).¶

A Context is a grouping of one or more services with the same set of Variation Types and Values, as defined in Section 5.4.1. Re-use of the same Service Name across multiple Contexts requires the services to be distinguished through Parameter(s) that are used as additional distinguishers (besides the Service Name) in the discovery mechanism.¶

For example, AN_Proxy is used as the GRASP Objective (aka "Service Name") to discover [BRSKI] Join Proxies and connect to them via TCP. This is indicated through the IPPROTO_TCP parameter in GRASP. Likewise, when a constrained BRSKI proxy as described in [cPROXY] is to be discovered via GRASP, IPPROTO_UDP is to be used in GRASP to distinguish such a cBRSKI Proxy from a BRSKI Proxy.¶

Informal names for services are best documented in the Notes column.¶

In addition to the registrations from other BRSKI RFCs, the initial registry table adds registrations for discovering cBRSKI stateful and stateless Registrars and Join Proxies via GRASP and DNS-SD. The necessary additional registrations for these are included in Section 5.2 for DNS-SD and Section 5.3 for GRASP. With these registrations, tBRSKI services can use DNS-SD or GRASP, and cBRSKI services can use DNS-SD, GRASP, or CORE-LF for discovery. This document does not specify CORE-LF discovery for tBRSKI, because the existing CoRE registrations for BRSKI are specific to cBRSKI and CoAPS.¶

The initial content of this sub-registry is as follows.¶

Designated Experts:

TBD.¶

Registration Procedure:

Specification Required.¶

Notes:

See [ThisRFC], Section 5.4.2¶

5.4.3. Variation Type Choices

IANA is asked to create a sub-registry called "Variation Type Choices" in the "BRSKI Discovery Parameters" registry.¶

The Registration Procedure for this registry is Specification Required, where the Expert Review has to ensure the feasibility of entries with respect to the following expectations/rules.¶

Each row registers one Variation Type Choice for one Context (as registered in Section 5.4.1), and specifies the Variation Type (also as registered in Section 5.4.1) for which it is a choice.¶

All Variation Type Choices MUST be unique across all Variation Types, so that the Variation Type can always be deduced from the Variation Type Choice. This permits future encodings that do not necessarily have to use the Variation String representation (as registered in Section 5.4.4), and also makes it easier to recognize erroneous variation representations.¶

Because they are used in protocol encodings, Variation Type Choices MUST be as simple as possible. They MUST consist only of the characters a-z and 0-9.¶

The "Dflt" flag indicates that the Variation Type Choice is the default choice for its Variation Type. Default choices are not included in the Variation String encoding of Variations. When new Variation Types are added to a Context to introduce variations of a new aspect of BRSKI, the backward-compatible choice has to become the default choice for that new Variation Type.¶

The "Rsvd" flag indicates a choice that has not been sufficiently vetted/specified to allow its use in Variations (Section 5.4.4), but that is known to be a possible candidate and is reserved to track that possible extension through future specification work.¶

References in parentheses specify the necessary functionality for a Variation Type Choice, but do not specify the actual registration of the Variation Type Choice.¶

The initial content is as follows.¶

Designated Experts:

TBD.¶

Registration Procedure:

Specification required.¶

5.4.4. Variations

IANA is asked to create a sub-registry called "Variations" in the "BRSKI Discovery Parameters" registry.¶

The Registration Procedure for this registry is Specification Required, where the Expert Review has to ensure the feasibility of entries with respect to the following behavior/rules.¶

Each row registers one or more Variation String(s) that represent one Variation in one Context, and specifies the combination of Variation Type Values indicated by that Variation.¶

Variation Type Values MUST be listed in the order in which their Variation Types appear in Section 5.4.1, including the default Variation Type Values for the Variation Types known at the time of registration. Once a Variation String for a Context is registered, its listed Variation Type Values SHOULD NOT be modified (except to correct an erroneous registration).¶

The primary Variation String SHOULD be derived by concatenating the listed Variation Type Values, separated by "-", except for default values. This is called the standard Variation String construction rule. The empty string is represented as "".¶

Any Variation String that does not follow this construction rule SHOULD receive a note explaining why.¶

When new Variation Types are later introduced into the Contexts table (Section 5.4.1), they will not lead to a change in the Variation String(s); instead, it is understood that the Variation represents the default Variation Type Values for any such additional Variation Types.¶

This registry table exists to document which specification(s) use specific Variations, so that implementations do not have to consider supporting arbitrary possible (but not validated by specification) Variations.¶

The sub-registries specified above register the permissible Context and Variation Type Values.¶

The initial content is as follows.¶

Designated Experts:

TBD.¶

Registration Procedure:

Specification required.¶

Notes:

(1) For backward compatibility with [BRSKI], Section 4.3, the objective-value of the GRASP objective AN_join_registrar for this Variation MUST be the exact (uppercase) string "EST-TLS", and receivers MUST treat an AN_join_registrar objective-value of "EST-TLS" as this Variation. In all other cases, including the GRASP objective AN_Proxy ([BRSKI], Section 4.1.1), this Variation is signaled with the Variation String "".¶