BRSKI discovery and variations

Specification

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.

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.

Service Names The role that a responder socket supports is indicated in each discovery mechanism through an appropriate signalling element. 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.

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 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. 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. 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.

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 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.

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.

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 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.

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 connections pledge to proxy or registrar and proxy to registrar connections using TCP. "cBRSKI" (constrained BRSKI) is the context covering connections pledge to proxy or registrar and proxy to registrar connections using UDP. "BRSKI-PLEDGE" is the context covering pledges using for connections from agents. It can equally cover in the future through variations the discovery of 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. This document does also not introduce variation contexts for discovery of other BRSKI roles, such as discovery of pledges by agents (as defined in ), 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.

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 .

Variation Contexts Registry Table The IANA "BRSKI Variations Contexts" registry table, see , 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.

Variation Type and Choices Registry Table The IANA "BRSKI Variations and Variation Strings" registry table, see , 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. 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, specifies the empty string "" as the objective-value in 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.

Variations and Variation String Registry Table The IANA "BRSKI Variations and Variation Strings" registry table, see , 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.

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 ) 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 . 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. 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 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" ).

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.

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. 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.

Service Announcements Responder selection as described in 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.

Responder Selection in Proxies Unless amended by the requirements listed below, proxies SHOULD follow all the descripton from . 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. 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. 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 , which is used for example by . 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.

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.

Join Proxies Support for Discovery and Variations

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 "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.

Registrar Operations Modes Proxies may use different approaches to connect to registrars. The following subsections discuss the primary relevant options.

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 per variation.

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. 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 . 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. 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 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 , which is used for example by . 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.

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. 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.

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 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.

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.

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. 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.

Discoverable BRSKI Pledges

BRSKI-PLEDGE context BRSKI-PLEDGE is the context for discovery of pledges by nodes such as registrar-agents. Pledges supporting 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 . DNS-SD WG Question TBD: Is there sufficient auto-configuration support in , 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 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, 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 . This does not affect operations for the service instance name.

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: A manufacturer has different product lines and re-uses serial-numbers across them. 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 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. calls this the X520SerialNumber. 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 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.

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

SN:" SN = Serial Number, PID = Product Identifier Manufacturer published DNS-SD Instance Schema (options): .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 ]]> "Pledge IDevID certificate information" shows the relevant parts of an IDevID. As defined in , 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). 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. 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.

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.

Variation signaling and encoding rules for different discovery mechanisms

DNS-SD

Signaling The following definitions apply to any instantiation of DNS-SD including DNS-SD via mDNS as defined in , but also via unicast DNS, for example by registering the necessary DNS-SD Resource Records (RR) via (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 and fall back to mDNS if fails to work, e.g.: it fails to discover SRP server and/or default domain.

Variation String Encoding Variation Strings from the IANA registry 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.

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 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 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 , 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.

Examples These example use OUI and IPv6 addresses reserved for documentation purposes. Do not re-use these addresses in actual deployments

In example , 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. 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.

In the second example , a server system in the NOC of customer with domain example.org is set up as the registrar for various BRSKI options. It uses 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. 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.

GRASP

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 is called the "security and transport substrate" to be used for GRASP. 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.

Encoding and Examples To announce protocol variations with , the supported Variation is indicated in the objective-value field of the GRASP objective, using the method of forming the Variation string term in , and listed in the Variation String column of the 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.

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.

In , 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 .

CORE-LF

Overview "Web Linking", 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", introduces a stand alone method to discover resources, such as service instances. CORE-LF was introduced primarily for use with 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). 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. 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.

Background 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 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 . The following picture, 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 , which also defines IPv6 and site-scoped address options.

; rt="brski.jp" Example: REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp RES: 2.05 Content ;rt=brski.jp ]]> introduces the operations of a CoAP based join proxy both as a connection based proxy as in (only using UDP connections for COAPs instead of TCP for TLS as in ), 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. The following picture, shows the encoding and an example of this discovery. 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 link format, and , Section 3.2, the authority attribute can not include a port number unless it also includes the IP address.

;rt=brski.jpy Example: REQ: GET /.well-known/core?rt=brski.jpy RES: 2.05 Content ;rt=brski.jpy ]]>

Specification This section specifies the use of CORE-LF for BRSKI variations. These specifications are backward compatible extensions to what was is specified in and , 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 and from (URI) for explanations and relies on the following template example, .

;\ rt=brski-service(;var="brski-variation-string(s)");\ pw="priority weight" ]]> 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 and 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 . 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 . 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 and . 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 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 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.

Examples

; # [1] rt=brski.rs;var="est-tls prm-jose cmp"; pw="1 2", ; # [2] rt=brski.jp;var="est-tls prm-jose cmp"; pw="1 2", ; # [3] rt=brski.rs;var=, pw="1 2", ; # [4] rt=brski.jp;var=, pw="1 2", ; # [5] rt=brski.rjpy;var=, pw="1 2" ]]> 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. Example [1] is the equivalent announcement for a BRSKI registrar service as shown for DNS-SD in 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.

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 . 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 .

; # [1] rt=brski.rs;var="est-tls prm-jose cmp"; pw="1 2", ; # [2] rt=brski.rs.requestvoucher, ; # [3] rt=brski.rs.voucher_status, ;rt=brski.rs.rv, # [4] ;rt=brski.rs.vs, # [5] ]]> [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 . 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 , 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 "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.