draft-ietf-anima-brski-discovery-02.txt

ANIMA                                                     T. Eckert, Ed.
Internet-Draft                                                 Futurewei
Intended status: Standards Track                                 E. Dijk
Expires: 9 January 2025                                IoTconsultancy.nl
                                                             8 July 2024


                     Discovery for BRSKI variations
                  draft-ietf-anima-brski-discovery-02

Abstract

   This document specifies how BRSKI entities, such as registrars,
   proxies, pledges or others that are acting as responders, can be
   discovered and selected by BRSKI entities acting as initiators.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 January 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.





Eckert & Dijk            Expires 9 January 2025                 [Page 1]

Internet-Draft               BRSKI-discovery                   July 2024


Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Abstracted BRSKI discovery and selection  . . . . . . . .   6
     3.2.  Variation Contexts  . . . . . . . . . . . . . . . . . . .   6
     3.3.  Variation Types and Choices . . . . . . . . . . . . . . .   7
     3.4.  Variations  . . . . . . . . . . . . . . . . . . . . . . .   8
     3.5.  BRSKI Variations Discovery Registry . . . . . . . . . . .   8
       3.5.1.  BRSKI Variation Contexts table  . . . . . . . . . . .   8
       3.5.2.  BRSKI Variation Type Choices table  . . . . . . . . .   9
       3.5.3.  BRSKI Discoverable Variations table . . . . . . . . .  10
       3.5.4.  Extending or modifying the registry . . . . . . . . .  11
     3.6.  BRSKI Join Proxies support for Variations . . . . . . . .  11
       3.6.1.  Permissible Variations  . . . . . . . . . . . . . . .  12
       3.6.2.  Join Proxy support for Variations . . . . . . . . . .  12
       3.6.3.  Co-location of Proxy and Registrar  . . . . . . . . .  13
     3.7.  BRSKI Pledges support for Variations  . . . . . . . . . .  14
       3.7.1.  BRSKI-PLEDGE context  . . . . . . . . . . . . . . . .  14
     3.8.  Variation signaling and encoding rules for different
           discovery mechanisms  . . . . . . . . . . . . . . . . . .  18
       3.8.1.  DNS-SD  . . . . . . . . . . . . . . . . . . . . . . .  18
       3.8.2.  GRASP . . . . . . . . . . . . . . . . . . . . . . . .  21
       3.8.3.  CORE-LF . . . . . . . . . . . . . . . . . . . . . . .  24
   4.  Updates to existing RFCs  . . . . . . . . . . . . . . . . . .  31
     4.1.  RFC8995 . . . . . . . . . . . . . . . . . . . . . . . . .  31
   5.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  31
     5.1.  BRSKI Variations Discovery Registry (section) . . . . . .  31
     5.2.  Service Names Registry  . . . . . . . . . . . . . . . . .  34
     5.3.  BRSKI Well-Known URIs fixes (opportunistic) . . . . . . .  35
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  35
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  36
   8.  Draft considerations  . . . . . . . . . . . . . . . . . . . .  36
     8.1.  Open Issues . . . . . . . . . . . . . . . . . . . . . . .  36
     8.2.  Change log  . . . . . . . . . . . . . . . . . . . . . . .  36
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  36
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  39
   Appendix A.  Discovery for constrained BRSKI  . . . . . . . . . .  40
     A.1.  Current constrained text for GRASP  . . . . . . . . . . .  40
       A.1.1.  Issues and proposed change  . . . . . . . . . . . . .  42
   Appendix B.  Possible future variations . . . . . . . . . . . . .  42
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  43
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  44






Eckert & Dijk            Expires 9 January 2025                 [Page 2]

Internet-Draft               BRSKI-discovery                   July 2024


1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document relies on the terminology defined in Section 1.  The
   following terms are described partly in addition.

   Context:  See Variation Context.

   Initiator:  A host that is using an IP transport protocol to initiate
      a connection or transaction to another host called the responder.

   Initiator socket:  A socket consisting of an initiators IP or IPv6
      address, protocol and protocol port number from which it initiates
      connections or transactions to a responder (typically UDP or TCP).

   Objective Name:  See Service Name.

   Resource Type:  See Service Name.

   Responder:  A host that is using an IP transport protocol to respond
      to transaction or connection requests from an Initiator.

   Responder socket:  A socket consisting of a responders IP or IPv6
      address, protocol and protocol port number on which it responds to
      requests of the protocol (typically UDP or TCP).

   Role:  In the context of this document, a type of entity in a
      variation of BRSKI that can act as a responder and whose supported
      variations can be discovered.  BRSKI roles relevant in this
      document include Join Registrar, Join Proxy and Pledge.  The IANA
      registry defined by this document allows to specify variations for
      any roles.  See also Variation Context.

   Socket:  The combination of am IP or IPv6 address, an IP protocol
      that utilizes a port number (such as TCP or UDP) and a port number
      of that protocol.

   Service Name:  The name for (a subset of) the functionality/API
      provided by a discoverable responder socket.  This term is
      inherited from Section 1 but unless otherwise specified also used
      in this document to apply to any other discovery functionality/
      API.  The terminology used by other mechanisms typically differs.
      For example, when Section 1 is used to discover a responder socket



Eckert & Dijk            Expires 9 January 2025                 [Page 3]

Internet-Draft               BRSKI-discovery                   July 2024


      for BRSKI, the Objective Name carries the equivalent to the
      service name.  In Section 1, the Resource Type (rt=) carries the
      equivalent of the service name.

   Type:  See Variation Type.

   Variation:  A combination one one variation choice each for every
      variation type applicable to the variation context of one
      discoverable BRSKI communications.  For example, in the context of
      BRSKI, a variation is one choice for "mode", one choice for
      "enroll" and once choice for "vformat".

   Variation Context:  A set of Services for whom the same set of
      variations applies

   Variation Type:  The name for one aspect of a protocol for which two
      or more choices exist (or may exist in the future), and where the
      choice can technically be combined orthogonal to other variation
      types.  This document defined the BRSKI variation types "mode",
      "enroll" and "vformat".

   Variation Type Choice:  The name for different values that a
      particular variation type may have.  For example, this document
      does defines the choices "rrm" and "prm" for the BRSKI variation
      "mode".

   ACP:  "An Autonomic Control Plane", [RFC8994].

   BRSKI:  "Bootstrapping Remote Secure Key Infrastructure", [RFC8995].

   BRSKI-AE:  "Alternative Enrollment Protocols in Section 1",
      [I-D.ietf-anima-brski-ae].

   BRSKI-PRM:  "Section 1 with Pledge in Responder Mode",
      [I-D.ietf-anima-brski-prm].

   cBRSKI:  "Constrained Bootstrapping Remote Secure Key Infrastructure
      (Section 1)", [I-D.ietf-anima-constrained-voucher].

   COAP:  "The Constrained Application Protocol (CoAP)", [RFC7252].

   CORE-LF:  "Constrained RESTful Environments (CoRE) Link Format",
      [RFC6690].

   cPROXY:  "Constrained Join Proxy for Bootstrapping Protocols",
      [I-D.ietf-anima-constrained-join-proxy].

   DNS-SD:  "DNS-Based Service Discovery", [RFC6763].



Eckert & Dijk            Expires 9 January 2025                 [Page 4]

Internet-Draft               BRSKI-discovery                   July 2024


   EST:  "Enrollment over Secure Transport", [RFC7030].

   GRASP:  "GeneRic Autonomic Signaling Protocol", [RFC8990].

   GRASP-DNSSD:  "DNS-SD Compatible Service Discovery in GeneRic
      Autonomic Signaling Protocol (GRASP)",
      [I-D.eckert-anima-grasp-dnssd].

   JWS-VOUCHER:  "JWS signed Voucher Artifacts for Bootstrapping
      Protocols", [I-D.ietf-anima-jws-voucher].

   lwCMP:  "Lightweight Certificate Management Protocol (CMP) Profile",
      [I-D.ietf-lamps-lightweight-cmp-profile].

   mDNS:  "multicast DNS", [RFC6762].

   SCEP:  "Simple Certificate Enrolment Protocol", [RFC8894].

2.  Overview

   The mechanisms described in this document are intended to help solve
   the following challenges.

   Signaling BRSKI variation for responder selection.

   When an initiator such as a proxy or pledge uses a mechanism such as
   Section 1 to discover an instance of a role it intends to connect to,
   such as a registrar, it may discover more than one such instance.  In
   the presence of variations of the BRSKI mechanisms that impact
   interoperability, performance or security, not all discovered
   instances may support exactly what the initiator needs to achieve
   interoperability and/or best performance, security or other metrics.
   In this case, the service announcement mechanism needs to carry the
   necessary additional information beside the name that indicates the
   service to aid the initiator in selecting an instance that it can
   inter operate and achieve best performance with.

   Easier use of additional discovery mechanisms.

   In the presence of different discovery mechanisms, such as Section 1,
   Section 1, Section 1 or others, the details of how to apply each of
   these mechanisms are usually specified individually for each
   mechanism, easily resulting in inconsistencies.  Deriving as much as
   possible the details of discovery from a common specification and
   registries can reduce such inconsistencies and easy introduction of
   additional discovery mechanisms.





Eckert & Dijk            Expires 9 January 2025                 [Page 5]

Internet-Draft               BRSKI-discovery                   July 2024


   Generalization of principles related to discovery and operation of
   proxies.

   Because of the unified approach to discovery of BRSKI Variations
   described in this document, it also allows to use Section 1 for
   document for Section 1 and Section 1, which may be of interest in
   networks such as Thread, which use Section 1.

3.  Specification

3.1.  Abstracted BRSKI discovery and selection

   In the abstract model of discovery used by this document and intended
   to apply to all described discovery mechanisms, an entity operating
   as an initiator of a transport connection for a particular BRSKI
   protocol role, such as a pledge, discovers one or more responder
   sockets (IP/IPv6-address, responder-port, IP-protocol) of entities
   acting as responders for the peer BRSKI role, such as registrar.  The
   initiator uses some discovery mechanism such as Section 1, Section 1
   or Section 1.  In the the initiator looks for a particular
   combination of a Service Name and an IP-protocol, and in return
   learns about responder sockets from one or more responders that use
   this IP-protocol and serve the requested Service Name type service
   across it.  It also learns the BRSKI variation(s) supported on the
   socket.

   Service Name is the name of the protocol element used in Section 1,
   unless explicitly specified, it is used as a placeholder for the
   equivalent protocol elements in other discovery mechanisms.  In
   Section 1, it is called objective-name, in Section 1 it is called
   Resource Type.

   Upon discovery of the available sockets, the initiator selects one,
   whose supported variation(s) best match the expectations of the
   initiator, including performance, security or other preferences.
   Selection may also include attempting to establish a connection to
   the responder socket, and upon connection failure to attempt
   connecting to the next best responder socket.  This is for example
   necessary when discovery information may not be updated in real-time,
   and the best responder has gone offline.

3.2.  Variation Contexts

   A Variation Context is a set of (Discover Mechanism, Service Names,
   IP-protocols) across which this document and the registry of
   variations defines a common set of variations.  The initial registry
   defined in this document defines two variation contexts.




Eckert & Dijk            Expires 9 January 2025                 [Page 6]

Internet-Draft               BRSKI-discovery                   July 2024


   BRSKI context:  context for discovery of BRSKI registrar and proxy
      variations by proxies, pledges or agents (as defined in Section 1)
      via the Service Names defined for Section 1 and Section 1 via TCP
      and hence (by default) TLS (version 1.2 or higher according to
      Section 1).

   cBRSKI context (constrained BRSKI):  context for discovery of BRSKI
      registrar and proxy variations by proxies, pledges via the Service
      Names defined for Section 1, Section 1 and Section 1 via UDP, and
      hence (by default) secure COAP.

   Note that the Service Names for cBRSKI include the same Section 1
   Service Names as for the BRSKI context, hence enabling the use of
   Section 1 with cBRSKI.

   This document does not define variations for different end-to-end
   encryption mechanisms, so only the "(by default)" options exist at
   the time of writing this document.  However, the mechanisms described
   here can also be used to introduce backward incompatible new secure
   transport options.  For example when responders start to support only
   TLS 1.3 or higher in the presence of TLS 1.2 only initiators, then
   new variations can be added, such that those initiators will not
   select those responders.

   This document does not introduce variation contexts for discovery of
   other BRSKI roles, such as discovery of pledges by agents (as defined
   in Section 1), or discovery of MASA by registrars.  However, the
   registry introduced by this document is defined such that it can be
   extended by such additional contexts through future documents.

3.3.  Variation Types and Choices

   A Variation Type is a variation in one aspect of the BRSKI connection
   between initiator and responder that ideally orthogonal from
   variations in other aspects of the BRSKI connection.

   A Variation Type Choice is one alternative (aka: value) for its
   Variation Type.

   This document, and the initial registry documenting the variation
   types introduces three variation types as follows:

   mode:  A variation in the basic sequence of URI endpoints








Eckert & Dijk            Expires 9 January 2025                 [Page 7]

Internet-Draft               BRSKI-discovery                   July 2024


      communicated.  This document introduces the choices of "rrm" to
      indicate the endpoints and sequence as defined in Section 1 and
      "prm" to indicate the endpoints and sequence as defined in
      Section 1.  Note that registrars also act as responders in "prm".
      "rrm" was chosen because the more logical "pim" (pledge initiator
      mode) term was feared to cause confusion with other technologies
      that use that term.

   vformat (voucher format):  A variation in the encoding format of the
      voucher communicated between registrar and pledge.  This document
      introduces the choices "cms" as defined in Section 1, "cose" as
      defined in Section 1 and "jose" as defined in Section 1.

   enroll:  A variation in the URI endpoints used for enrollment of the
      pledge with keying material (trust anchors and certificate
      (chain)).  This document introduces the following :choices

      *  "est" as introduced by Section 1 to indicate the Section 1
         protocol, which is default

      *  "cmp" to indicate the CMP protocol according to the Lightweight
         CMP profile (Section 1).  The respective adaptations to BRSKI
         have been introduced by Section 1.

      *  "scep" to indicate Section 1.  This is only a reservation,
         because no specification for the use of Section 1 with BRSKI
         exists.

3.4.  Variations

   A Variation is the combination of one Choice each for every Variation
   Type applicable to the Variation Context.  In other words, a
   variation is a possible instance of BRSKI if supported by initiator
   and responder.  In Section 1, the default variation is "registrar
   responder mode" (rrm) and use of the "cms voucher format" (cms).

3.5.  BRSKI Variations Discovery Registry

   The IANA "BRSKI Variations Registry" as specified by this document,
   see Section 5.1 specifies the defined parameters for discovery of
   BRSKI variations.

3.5.1.  BRSKI Variation Contexts table

   This table, Table 1, defines the BRSKI Variations Contexts.






Eckert & Dijk            Expires 9 January 2025                 [Page 8]

Internet-Draft               BRSKI-discovery                   July 2024


   The "Applicable Variation Types" lists the Variation Types from whose
   choices a Variation for this context is formed.  The "Service
   Name(s)" column lists the discovery mechanisms and their Service
   Name(s) that constitute the context.

3.5.2.  BRSKI Variation Type Choices table

   This table, Table 2, defines the Variations Type Choices.

   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.  Variation Types MUST the listed in the order in which
   the Variation Types are listed in the Applicable Variation Types
   column of the BRSKI Variation Contexts table.

   The "Variation Type Choice" column defines a Variation Type Choice
   term within the Context(s) of the line.  To allow the most flexible
   encodings of variations, all Variation Types and Variation Type
   Choices MUST be unique strings (across all Variation Types).  This
   allows to encode Variation Type Choices in a discovery mechanism
   without indicating their Variation Type.  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 documents which describe the
   Variation Type Choice.  Relevant specification includes those that
   only specify the semantics without referring to the aspects of
   discovery and/or those that specify only the Discovery aspects.
   Current RFCs for BRSKI variations preceding this RFC typically only
   specify the semantics, and this document adds the discovery aspects.

   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 to be assumed to be
   supported in discovery if discovery is performed without indication
   of any or an empty signaling element to carry the Variation or
   Variation Choices.  For example, Section 1 specifies the empty string
   "" as the objective-value in Section 1 discovery.  Because "rrm",
   "est" and "cms" are default in the BRSKI context, this Discovery
   signaling indicates the support for those Variation Type Choices.





Eckert & Dijk            Expires 9 January 2025                 [Page 9]

Internet-Draft               BRSKI-discovery                   July 2024


   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 known to be of potential
   interest.  "Rsvd" Variation Type Choices MUST NOT be considered for
   the Discoverable Variations table.  They are documented primarily to
   reserve the Variation Type Choice term.

   The Note(s) section expands the Variation Type Choice terms and
   provides additional beneficial specification references beyond the
   "Reference" column.

3.5.3.  BRSKI Discoverable Variations table

   This table Table 3 enumerates the Discoverable Variations and
   categorizes them.

   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 "Spec / Applicability" lists the document(s) that specify the
   variation, if the 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 column will indicate "-" if by expert
   opinion it is assumed that this variation should work, or "NA", if by
   expert opinion, this variation could not work.  The "Explanations"
   column includes references to the relevant documents and as necessary
   additional explanation.

   The "Variation" column lists the Variation Type Choices that form the
   Variation.  The Variation Type Choices MUST be listed in the order in
   which the Variation Types are listed in the Applicable Variation
   Types column of the BRSKI Variation Contexts table.

   The "Variation String" column has the string term used to indicate
   the variation when using the simple encoding of BRSKI Variation
   Discovery for GRASP as described in Section 1.  It is formed by
   concatenating the Choices term from the Variation column with the "-"
   character, excluding those Choices terms (and "-" concatenator) which
   are Default for the Context.  If this procedure ends up with the
   empty string, then this is indicated as "" in the column.



Eckert & Dijk            Expires 9 January 2025                [Page 10]

Internet-Draft               BRSKI-discovery                   July 2024


   The "Explanations" column explains the "Spec / Applicability" status
   of the Variation.

3.5.4.  Extending or modifying the registry

   Unless otherwise specified below, extension or changes to the
   registry require standards action.

   Additional Variation Type Choices and Variation Context discovery
   mechanism Service Names including additional discovery mechanisms
   require (only) specification and expert review if they refer to non
   standard action protocols and/or protocol variation aspects.  For
   example, a specification how to use Section 1 with BRSKI would fall
   under this clause as it is an informational RFC.

   Non standards action Variation Type Choices can not be Default(Dflt).
   They can only be Dflt* for non standards action (sub)Contexts.

   Reservation of additional Variation Type Choices requires (only)
   expert review.

   Additional Contexts MUST be added at the end of the BRSKI Variation
   Contexts table.

   Additional Variation Types MUST be added at the end of the Applicable
   Variation Types column of the BRSKI Variation Contexts table and at
   the end of existing lines for the Context in the BRSKI Variation Type
   Choices.  Additional Variation Types MUST be introduced with a
   Default (Dflt) Variation Type Choice.  These rules ensures that the
   rule to create the Variation String for GRASP (and as desired by
   other discovery mechanism), and it also enables to add new Variation
   Type and Choices without changing pre-existing Variation Strings: Any
   Variations String implicitly include the Default Choice for any
   future Variation Types.

   When a new Variation Type is added, their Default Choice SHOULD be
   added to the Variation Column of existing applicable lines in the
   BRSKI Discoverable Variations table.  Variations that include new
   non-Default Variation Type Choices SHOULD be added at the end of the
   existing lines for the Context.

3.6.  BRSKI Join Proxies support for Variations









Eckert & Dijk            Expires 9 January 2025                [Page 11]

Internet-Draft               BRSKI-discovery                   July 2024


3.6.1.  Permissible Variations

   Variations according to the terminology of this document are those
   that do not require changes to BRSKI join proxy operations, but that
   can transparently pass across existing join proxies without changes
   to them - as long as they support the rules outlined in this
   document.

   Different choices for e.g.: pledge to registrar encryption
   mechanisms, voucher format (vformat), use of different URI endpoints
   or enrollment protocol endpoints (mode) are all transparent to join
   proxies, and hence join proxies can not only support existing, well-
   defined Choices of these Variation Types, but without changes to the
   proxies also future ones - and only those are permitted to become
   Variation Type Choices.

   Changes to the BRSKI mechanism that do require additional changes to
   join proxies are not considered Variations according to this document
   and MUST NOT use the same discovery protocol signaling elements as
   those defined for variations by this document.  Instead, they SHOULD
   use different combinations of Service Name and Protocol (e.g.: TCP
   vs. UDP).

   For example, the stateless join proxy mode defined by Section 1 is
   such a mechanism that requires explicit join proxy support.
   Therefore, registrars sockets that support circuit proxy mode use the
   GRASP objective "AN_join_registrar", and registrar sockets that
   support stateless join proxy mode use the GRASP objective
   "AN_join_registrar_rjp".  This enables join proxies to select the
   registrar and socket according to what the join proxy supports and
   prefers.  By not using the same signaling element(s) for variations,
   join proxies can support discovery of all variations independent of
   their support for stateless join proxy operations.

3.6.2.  Join Proxy support for Variations

   Join proxies supporting the mechanisms of this document MUST signal
   for each socket they announce to initiators via a discovery mechanism
   the Variation(s) supported on the socket.  These Variation(s) MUST
   all be supported by the registrar that the join proxy then uses for
   the connection from the initiator (e.g.: pledge).  Pledges SHOULD
   announce sockets to initiators so that all Variations that are
   supported by registrars that the join proxy can interoperate with are
   also available to the initiators connecting to the join proxy.

   To meet these requirements, join proxies can employ different
   implementation option.  In the most simple one, a join proxy
   allocates a separate responder socket for every Variation for which



Eckert & Dijk            Expires 9 January 2025                [Page 12]

Internet-Draft               BRSKI-discovery                   July 2024


   it discovers one or more registrars supporting this Variation.  It
   then announces that socket with only that one Variation in the
   discovery mechanism, even if the Registrar(s) are all announcing
   their socket with multiple Variations.  When the join proxy operates
   in circuit mode, it can then select one of the registrars supporting
   the variation for every new initiator connection based on policies as
   specified by BRSKI specifications and/or discovery parameters, such
   as priority and weight when Section 1 is used, and redundant
   registrars include those parameters.

   TBD: insert example of received Registrar announcement and created
   proxy announcement ??

   Join proxies MAY reduce the number of sockets announced to initiators
   by using a single socket for all Variations for which they have the
   same set of registrar sockets supporting those Variations.  This
   primarily helps to reduce the size of the discovery messages to
   initiators and can save socket resources on the join proxy.

   Join proxies MAY create multiple sockets in support of other
   discovery options, even for the same Variation(s).  For example, if
   Section 1 is used by two registrars, both announcing the same
   priority but different weights, then the join proxy may create a
   separate socket for each of these registrars - and their variations,
   so that the join proxy can equally announce the same priority and
   weight for both sockets to initiators.  This allows to maintain the
   desired weights of use of registrars, even when the join proxy
   operates in stateless mode, in which it can not select a separate
   registrar for every client initiating a connection.

3.6.3.  Co-location of Proxy and Registrar

   In networks using Section 1 and Section 1, registrars must have a co-
   located proxy, because pledges can only use single-hop discovery
   (DULL-GRASP) and will only discover proxies, but not registrar.  Such
   a co-located proxy does not constitute additional processing/code on
   a registrar supporting circuit mode, it simply implies that the
   registrars BRSKI services(s) are announced with a proxy Service Name,
   to support pledges, and the registrar service name, to support join
   proxies.

   To ease consistency of deployment models in the face of different
   discovery mechanisms, Variations and non-Variation enhancements to
   BRSKI, it is RECOMMENDED that all future options to BRSKI do always
   have a Service Name for proxies and a separate Service Name in
   support of pledge or other initiators.  Pledges and other initiators
   SHOULD always only look for the proxy Service Name, and only Proxies
   should look for a registrar Service Name.  Registrars therefore



Eckert & Dijk            Expires 9 January 2025                [Page 13]

Internet-Draft               BRSKI-discovery                   July 2024


   SHOULD always include the proxy functionality according to the prior
   paragraph.  This only involves additional code on the registrar
   beyond the service announcement in case the Registrar would otherwise
   not implement circuit mode.

3.7.  BRSKI Pledges support for Variations

3.7.1.  BRSKI-PLEDGE context

   BRSKI-PLEDGE is the context for discovery of pledges by nodes such as
   registrar-agents.  Pledges supporting Section 1 MUST support it.  It
   may also be used by other variations of BRSKI when supported by
   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 SHOULD support DNS-SD via [I-D.ietf-dnssd-srp].

   TBD: Is there sufficient auto-configuration support in
   [I-D.ietf-dnssd-srp], that pledges without any configuration can use
   it, and if so, do we need to raise specific additional requirements
   to enable this in pledges ?

   These DNS-SD requirements are defaults.  Specifications for specific
   deployment contexts such as specific type of radio network solutions
   may need to specify their own requirements overriding or amending
   these requirements.

   Pledges MUST support to be discoverable via their service instance
   name.  They MAY be discoverable via DNS-SD browsing, so that
   registrar-agents can find even unexpected pledges through DNS-SD
   browsing.

   Support for browsing is required to discover over the network pledges
   supporting only Section 1, but not Section 1 if they have no known
   serial-number information from which their service instance name can
   be constructed, so it is a crucial feature for robust enrollment.
   See Section 6 for more details about discovery and BRSKI-PLEDGE.

   When pledges are discoverable vis DNS-SD browsing, they MUST expect
   that a large number of pledges exist in the network at the same time,
   such as in the order of 100 or more, and schedule their responses
   according to the procedures in Section 1 and Section 1 to avoid
   simultaneous reply from all pledges.

   TBD: What is the best section in mDNS/DNS-SD to point to for this
   timed reply to scale ?




Eckert & Dijk            Expires 9 January 2025                [Page 14]

Internet-Draft               BRSKI-discovery                   July 2024


   Browsing via DNS-SD for a pledge is circumvented by the pledge not
   announcing its PTR RR for "brski-registrar".  Technically, the
   remaining RR may not constitute full DNS-SD service, but they do
   provide the required discovery for the known service instance name of
   the pledge.

   counter measures such as limiting the number and rate of PRM connects
   that they accept, ideally on a per-initiator basis (assuming that
   DDoS attacks are more harder to mount than single attacker DoS
   attacks).

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

   *  Available to the pledges BRSKI 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 lead to
   possible duplicate replies from two or more pledges having the same
   serial number, such as in the following cases:

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

   2.  Two different manufacturer re-use the same serial-numbers.

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

   Nevertheless, this approach to resolving conflicts is not desirable:

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





Eckert & Dijk            Expires 9 January 2025                [Page 15]

Internet-Draft               BRSKI-discovery                   July 2024


   *  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 determine which the correct pledge is.
      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 (because they come from the same manufacturer).
      Even if some other IDevID field was used to distinguish their
      device model, the registrar-agent would not be able to determine
      that difference without additional vendor specific programming.

   In result:

   *  Vendors MUST document a scheme how their pledges form a service
      instance name from information available to the customer of the
      pledge.

   *  These service instance names MUST be unique across all IDevID of
      the manufacturer that share the same CA.

   The following mechanisms are recommended:

   *  Pledges SHOULD encode manufacturer unique product instance
      information in their subject name serialNumber.  [RFC5280] calls
      this the X520SerialNumber.

   *  Pledges SHOULD make this serialNumber information consistent with
      easily accessible product instance information when in physical
      possession of the pledge, such as product type code and serial
      number on bar-code/QR-code to enable Section 1 discovery without
      additional backend sales integration.  Note that discovery alone
      does not allow for enrollment!

   *  Pledges SHOULD construct their service instance name by
      concatenating their X520SerialNumber with a domain name prefix
      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.













Eckert & Dijk            Expires 9 January 2025                [Page 16]

Internet-Draft               BRSKI-discovery                   July 2024


Service Instance Name:
  "PID:Model-0815 SN:WLDPC2117A99.example.com"

Manufacturer published Service Instance Name schema:
 PID:\<PID>\\ SN:\<SN>.example.com

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

DNS-SD RR for the pledge:
  ; PTR RR to support browsing / discovery of service instance name
  _brski-pledge._tcp.local  IN PTR
    PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local

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

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

             Figure 1: Example service instance name data

   In Figure 1, the manufacturer "example" identifies device instances
   through a product identifier <PID> and a serial number <SN>.  Both
   are printed on labels on the product/packaging and/or communicated
   during purchase of the product.

   The service instance name of pledges from this manufacturer are using
   the string "PID:<PID> SN:<SN>.example.com". "example.com" is assumed
   to be a domain owned by this manufacturer. <PID> and <SN> are
   replaced by the actual strings.

   The IDevID encodes the service instance name without the domain
   ending (".example.com") in the X520SerialNumber field.  Other fields
   of the IDevID are not used.

   The resulting DNS-SD RRs that the pledge announces are shown in the
   example. " " and "." characters are escaped as recommended by
   Section 1.





Eckert & Dijk            Expires 9 January 2025                [Page 17]

Internet-Draft               BRSKI-discovery                   July 2024


   In this example, the same string as constructed for the service
   instance name is also used as the target host name.  This is of
   course not necessary, but unless the pledge already obtains a host
   name through other DNS means, re-using the same name allows to avoid
   coming up with a second method to construct a unique name.

3.8.  Variation signaling and encoding rules for different discovery
      mechanisms

3.8.1.  DNS-SD

3.8.1.1.  Signaling

   The following definitions apply to any instantiation of DNS-SD
   including DNS-SD via mDNS as defined in Section 1, but also via
   unicast DNS, for example by registering the necessary DNS-SD Resource
   Records (RR) via [I-D.ietf-dnssd-srp] (SRP).

   The requirements in this document do not guarantee interoperability
   when using DNS-SD, instead, they 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.

   TBD: We could say that mDNS MUST be supported, unless the network
   context defines an interoperable mode to support DNS-SD without mDNS
   ???

3.8.1.2.  Encoding

   Variation Type Choices defined in the IANA registry Table 3 are
   encoded as Section 1 Keys with a value of 1 in the DNS-SD service
   instances TXT RR.  This is possible because all Variation Type
   Choices are required to be unique across all Variation Types.  It
   also allows to shorten the encoding from "key=1" to just "key" for
   every Variation Type Choice, so that the TXT-DATA encoding can be
   more compact.

   If the TXT Record does not contain a Variation Type Choice for a
   particular applicable Variation Type, then this indicates support for
   the Default Choice of this Variation Type in the context of the DNS-
   SD Service Name.  For example, if the TXT Record is "jose", then this
   indicates support for "rrm" and "est", if the Service Name is brski-



Eckert & Dijk            Expires 9 January 2025                [Page 18]

Internet-Draft               BRSKI-discovery                   July 2024


   registrar or brski-proxy and the protocol is TCP (BRSKI Context), but
   also when the protocol is UDP (cBRSKI context), because "rrm" and
   "est" are defaults in both contexts.

   If multiple Variation Type Choices for the same Variation Type are
   indicated, then this implies that either of these Variation Type
   Choices is supported in conjunction with any of the other Variation
   Type Choices in the same TXT Record.  For example, if the TXT Record
   is "prm" "rrm" "cms" "jose", then this implies support for rrm-cms-
   est, rrm-jose-est, prm-cms-est and prm-jose-est.  This example also
   shows that if the default Variation Type Choice, such as "rrm" and
   another Choice of the same Variation Type ("prm") are to be indicated
   as supported, then both need to be included in the TXT Record.

   In Section 1, a responder does not only indicate a Service Name, but
   also its Service Instance Name, which needs to be unique across the
   domain to support initiators selecting a responder.  This
   specification makes no recommendation for choosing the Instance
   portion of that name.  Usually it is the same, or derived from some
   form of pre-existing system name.

   Registrars SHOULD support support their configuration without
   specifying a name to use in the Service Instance Name to minimize the
   amount of configuration required.  Registrars SHOULD support the
   configuration of such a name.

   If the responder needs to indicate different sockets for different
   (set of) Variations, for example, when operating as a proxy,
   according to Section 3.6.2, 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.  In this case, it is
   RECOMMENDED that the Instance Name includes the Variation it
   supports, such as in the format specified in Section 3.5.3 and used
   in the Variation String column of the Table 3 table.
















Eckert & Dijk            Expires 9 January 2025                [Page 19]

Internet-Draft               BRSKI-discovery                   July 2024


                  _brski-registrar._tcp.local
                  IN PTR  0200:0000:7400._brski-registrar._tcp.local
   0200:0000:7400._brski-registrar._tcp.local
                   IN SRV  1 2 4555 0200:0000:7400.local
   0200:0000:7400._brski-registrar._tcp.local IN TXT  "rrm" "prm"
   0200:0000:7400.local
                   IN AAAA  fda3:79a6:f6ee:0000::0200:0000:6400:0001

                  _brski-registrar._udp.local
                   IN PTR  0200:0000:7400._brski-registrar._udp.local
   0200:0000:7400._brski-registrar._udp.local
                   IN SRV  1 2 5684 0200:0000:7400.local
   0200:0000:7400._brski-registrar._udp.local IN TXT  ""

          Figure 2: DNS-SD for a simple BRSKI and cBRSKI registrar

   In the above example Figure 3, a registrar supports BRSKI with "rrm"
   and "prm" modes across the same TCP socket, port 4555.  It uses "cms"
   voucher format and "est" enrollment, which are not included in the
   TXT strings because both are default for _brski-registrar._tcp.  The
   registrar also offers cBRSKI with "rrm" mode, "cose" voucher and
   "est" enrollment on UDP port 5684, the COAP over DTLS default port.
   The TXT RR for this has only an empty string because "rrm", "cose"
   and "est" are default for cBRSKI.

   As the instance name, the registrar uses in this example the MAC
   address "0200:0000:7400", which is MAC address of the interface on
   which the registrar has the IPv6 address
   "fda3:79a6:f6ee:0000::0200:0000:6400:0001".  The registrar should
   know that this MAC address is globally unique (assigned by IEEE).
   Else it should instead use its IPv6 address as the Instance Name.
   For example, if the registrar is just a software application not
   knowing the specifics of the hardware it is running on, the MAC
   address MUST NOT be used.  If only mDNS is used (as in this example),
   then the IPv6 link-local address would also suffice as the Instance
   Name.

   In this example, a single Instance Name suffices, because BRSKI and
   cBRSKI are two separate service contexts: they are distinguished by
   different protocols: TCP vs. UDP.











Eckert & Dijk            Expires 9 January 2025                [Page 20]

Internet-Draft               BRSKI-discovery                   July 2024


  0123456789012345678901234567890123456789012345678901234567890123456789
                     _brski-registrar._tcp.local
                 IN PTR  0200:0000:7400-rrm._brski-registrar._tcp.local
  0200:0000:7400-rrm._brski-registrar._tcp.local
                 IN SRV  1 2 4555 0200:0000:7400-rrm.local
  0200:0000:7400-rrm._brski-registrar._tcp.local IN TXT ""
  0200:0000:7400-rrm.local
                 IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:0001

                     _brski-registrar._tcp.local
                 IN PTR 0200:0000:7400-prm._brski-registrar._tcp.local
  0200:0000:7400-prm._brski-registrar._tcp.local
                 IN SRV 1 2 4555 0200:0000:7400-prm.local
  0200:0000:7400-prm._brski-registrar._tcp.local
                 IN TXT "prm" "cmp"
  0200:0000:7400-prm.local
                 IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:0001

      Figure 3: DNS-SD for a BRSKI registrar supporting RRM and PRM

   In the second example Figure 3, a registrar needs to use two
   different Instance Names, because both share the same service
   context: BRSKI - TCP with service name brski-registrar.  In this
   example, the registrar offers "rrm" mode with "cms" voucher and "est"
   enrollment.  It also offers "prm" mode with "cms" voucher, but (only)
   with "cmp" enrollment protocol.  Because the registrar does not offer
   "rrm" with "cmp", or "prm" with "est", it is not possible to coalesce
   all variations under one Instance Name, so instead, two Instance
   Names have to be created, and with them the necessary (duplicate) RR.

   Note that the "-rrm" and "-prm" in the Instance Names are only
   explanatory and could be any mutually unique strings - as is true for
   the whole Instance Name.

   Note too, that because both Instances share the same port number 4555
   (and hence TCP socket), they both have to be provided by the same
   BRSKI application.  If two separate applications where to be started
   on the dame host, one for "rrm", the other for "prm", then they would
   have separate sockets and hence port numbers.

3.8.2.  GRASP










Eckert & Dijk            Expires 9 January 2025                [Page 21]

Internet-Draft               BRSKI-discovery                   July 2024


3.8.2.1.  Signaling

   This document does not specify a mandatory to implement set of
   signaling options to guarantee interoperability of discovery between
   initiator and responders when using GRASP.  Like for the other
   discovery mechanisms, these requirements will have to come from other
   specifications that outline what in Section 1 is called the "security
   and transport substrate" to be used for GRASP.

   [RFC8994] specifies one such "security and transport substrate",
   which is zero-touch deployable.  It is mandatory to support for
   initiators and responders implementing the so-called "Autonomic
   Network Infrastructure" (ANI).  DULL GRASP is used for link-local
   discovery of proxies, and the ACP is used to automatically and
   securely build the connectivity for multi-hop discovery of registrars
   by proxies.

3.8.2.2.  Encoding

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

   [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
       [["AN_Proxy", 4, 1, "",
        [O_IPv6_LOCATOR,
        h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
        ["AN_Proxy", 4, 1, "prm",
        [O_IPv6_LOCATOR,
        h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
        ["AN_Proxy", 4, 1, "",
        [O_IPv6_LOCATOR,
        h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]
   ]

    Figure 4: GRASP example for a BRSKI registrar supporting RRM and PRM



Eckert & Dijk            Expires 9 January 2025                [Page 22]

Internet-Draft               BRSKI-discovery                   July 2024


   Figure 4 is an example for a GRASP service announcement for
   "AN_Proxy" in support of BRSKI with both "rrm" and "prm" supported on
   the same socket (TCP port number) and for cBRSKI with COAP over DTLS.

   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.

   Because this GRASP encoding does not support service instance name,
   examples such as

   [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
       [["AN_Proxy", 4, 1, "",
        [O_IPv6_LOCATOR,
        h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
        ["AN_Proxy", 4, 1, "",
        [O_IPv6_LOCATOR,
        h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]
   ]

   [M_FLOOD, 42310815, h'fe800000000000000000000000000001', 180000,
       [["AN_Proxy", 4, 1, "prm",
        [O_IPv6_LOCATOR,
        h'fe800000000000000000000000000001', IPPROTO_TCP, 44000]]
   ]

            Figure 5: GRASP example with two different processes

   In Figure 5, A separate application process supports "prm" and hence
   uses a separate socket, with example TCP port 44000.  In this case,
   there is no need nor significant benefit to merge all service
   instance announcements into a single GRASP message.  Instead, the
   BRSKI-"rrm"/cBRSKI process would be able to generate and send its
   own, first, message shown in the example, and the second process
   would send its own, second message in the example.

   For a more extensive, DNS-SD compatible encoding of the objective-
   value that also support Service Instance Names, see
   [I-D.eckert-anima-grasp-dnssd].






Eckert & Dijk            Expires 9 January 2025                [Page 23]

Internet-Draft               BRSKI-discovery                   July 2024


3.8.3.  CORE-LF

   "Web Linking", [RFC5988] defines a format, originally for use with
   HTTP headers, to link an HTTP document against other URIs.  Web
   linking is not a standalone method for discovery of services for use
   with HTTP.

   Based on Web Linking, "Constrained RESTful Environments (CoRE) Link
   Format", Section 1 introduces a stand alone method to discover
   services instances, which are called resources in CORE-LF; primarily
   for use with Section 1 but equally for use with, for use with HTTP or
   any other suitable web transfer protocols.

   In CORE-LF, an initiator may use (link-local) IPv6 multicast UDP
   packet to the COAP port (5683) to discover a a possible responder for
   a specifically 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 equally query the
   parameters of the desired resource via unicast to the default COAP
   UDP or TCP port (5683).

   A service such as BRSKI registrar, join proxy or pledge can be
   considered to be a resource, but it can equally be broken down into a
   set of component resources resources, in which case the group can be
   requested.  As mentioned above, CORE-LF can equally be used to
   request and discover resources not using COAP, but any other suitable
   protocol.

   [RFC9176] defines a "Resource Directory" mechanism for CORE-LF which
   is abbreviated CORE-RD.  Initiators can learn the IPv6 address
   protocol (TCP or UDP) and port numberaof 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.

3.8.3.1.  Signaling







Eckert & Dijk            Expires 9 January 2025                [Page 24]

Internet-Draft               BRSKI-discovery                   July 2024


3.8.3.1.1.  Existing definitions

   Section 1 specifies the use of CORE-LF as a reference methods for
   pledges to discover registrars - in the absence of any proxies, to
   allow deployments of scenarios where no proxies are needed - and
   hence also where Section 1. is not needed.  Because BRSKI is designed
   so that pledges can be agnostic of whether they connect to a
   registrar directly or via a proxy, the resource/service that the
   pledge needs to discover is nevertheless called "(brski) join proxy
   (for pleges)", and encoded in CORE-LF as the value "brski.jp" for the
   resource type attribute ("rt=resource-type") according to Section 1.

   The following picture, Figure 6 shows the encoding and an example of
   this discovery. "ff02::fd" is the link-local scope address for "All
   Coap Nodes" in IPv6, as introduced in [RFC7390], which also defines
   IPv6 and site-scoped address options.

Template:

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

RES: 2.05 Content
   <coaps://[Responder_IP_unicast_address]:join-port>; rt="brski.jp"

Example:

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

RES: 2.05 Content
   <coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp

      Figure 6: CORE-LF discovery of registrar/proxy by pledges

   Section 1 introduces the operations of a CoAP based join proxy both
   as a connection based proxy as in Section 1 (only using UDP
   connections for COAPs instead of TCP for TLS as in Section 1), but
   also as a new, stateless join proxy - to eliminate the need for
   potentially highly constrained join proxy nodes to keep connection
   state and avoid the complexity of protecting that state against
   attacks.  The new resource type "brski.rjp" is defined to support
   stateless join proxies to discover registrars and their UDP port
   number that support the stateless, so-called JPY protocol.

   The following picture, Figure 7 shows the encoding and an example of
   this discovery.  Section 1 introduces the new scheme "coaps+jpy" for
   the packet header used by the stateless JPY" protocol.  The request
   in the template is assumed to be based on unicast, relying on another
   method to discover the IP address of the registrar first.  It could



Eckert & Dijk            Expires 9 January 2025                [Page 25]

Internet-Draft               BRSKI-discovery                   July 2024


   equally use COAP site-scoped IP multicast, but in general, the
   assumeption is that registrar will not necessarily be link-local
   connected to proxies (this may be different in specific deployments).
   Even though the registrar IP address is hence known, the reply still
   needs to include this address again because in the [RFC6690] link
   format, and [RFC3986], Section 3.2, the authority attribute can not
   include a port number unless it also includes the IP address.

Template:

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

RES: 2.05 Content
     <coaps+jpy://[Responder_IP_unicast_address]:join-port>;rt=brski.jpy

Example:

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

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

   Figure 7: CORE-LF discovery of registrars that support stateless
                       JPY protocll by proxies

3.8.3.1.2.  New variation discovery

   This document expands the above summarized existing CORE-LF
   definitions from Section 1 and Section 1 as follows.

   Discovery of stateful sockets on a registrar uses the resource type
   "brski.rs" (for "registrar (for) join proxies stateful)" - instead of
   "brski.rjpy" for the previosly defined stateless connection mode.

   The following picture Figure 8 show template and example of this
   discovery option.  In Example 1, the registrar is running on a
   separate port 7634 from the COREs UDP port, so this response needs to
   also include the IP address of the responding registrar (as explained
   above).  In Example 2, the registar functions are provided via the
   default (potentially shared) COAPS port, so this is not necessary.
   In both cases, the response include a shorter URL part "/b/s" which
   allows that the service can be used via that shorter prefix than the
   default "/.well-known/brksi", hence shortening the required COAPS
   packet sizes.







Eckert & Dijk            Expires 9 January 2025                [Page 26]

Internet-Draft               BRSKI-discovery                   July 2024


Template:

REQ: GET /.well-known/core?rt=brski.r(*|s|spy)

RES: 2.05 Content
     <scheme://[Responder_IP_unicast_address]:join-port>;rt=brski.(rjpy|rs)

Example 1:

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

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

Example 2:

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

RES: 2.05 Content
     </b/s>;rt=brski.rjpy

   Figure 8: CORE-LF discovery of registrars that support stateless
                       JPY protocll by proxies

   TBD: Question: can we really reply without coaps given how we always
   want coaps - aka: the query itself may not have been coaps ?? This is
   question for constrained proxy/voucher - can we rightfully (according
   to IETF specs) make the expection that even though the resource
   discovery is done insecure, that it is understood that the actual
   resource consumption has to use coaps ????  - question for COAP
   experts.

   Explanations:

   The discovery and distinction between a stateless and stateful
   registrar socket is orthogonal to the concept of a variation of BRSKI
   as defined in this document.  Therefore, the distinction between a
   stateless and stateless socket on a registrar is provided solely via
   the CORE-LF resource-type, "brski.rjpy" (stateless) and "brski.rs"
   (stateful).  In other words, the "rt" attribute in CORE-LF serves as
   the abstract "Service Name" in this document.  If discover of
   stateless join proxies was required with other discovery mechanisms
   such as GRASP or DNS-SD, then new "Service Name" equivalents in those
   discovery mechanisms would need to be defined.  For the purpose of
   this document, it is assumed that stateless proxy operations is well
   enough supported with CORE-LF.





Eckert & Dijk            Expires 9 January 2025                [Page 27]

Internet-Draft               BRSKI-discovery                   July 2024


   To indicate variations other than the default combination implied by
   Section 1 and Section 1, this document specifies the new "bv" (brski
   variation) attribute for CORE-LF records, which is specified relative
   only to "rt=brski.r*" resource targets.

   The value to the "bv=" attribute is a flattened string of the non-
   default Variation Type Choices as specified for GRASP, so that CORE-
   LF does not introduce another registry table to maintain.  The only
   difference is that the absence of the "bv=" attribute is equivalent
   to the actual defaults established by Section 1 and Section 1, namely
   "rrm" (registrar response-mode) with "cose" (CBOR with COSE signed
   voucher) and "est" - enrollment via the 'fitting' variation of EST,
   in the case of using COAPS it is [RFC9148], e.g.: EST over COAPS.
   Including or excluding "bv=" (empty value) is hence equivalent to
   "bs=cose", aka: the default variation over COAPS.

   When a variation implies use of HTTPS (or in the future any other
   transport other than COAPS), then the schema, and hence IP-address
   needs to be included in the CORE-LF response.  Likewise, even if the
   protocol schema is coaps, then the IP address needs to be included if
   the resource is not served on the standard COAPS UDP port.

   [ Q: How does the schema indicate UDP versus TCP for COAPS ??? ]

   The following Figure 9 shows the schema and an example for various
   BRSKI registar variations, discovered via CORE-LF.

   "rt=brski.rs" with schema "coaps" and without any "bv" attribute
   indicate the default combination of "rrm", "cose" and "est" (EST via
   COAPS), as introduced by [I-D.ietf-anima-constrained-voucher], aka:
   stateful cBRSKI.

   "rt=brski.rjpy" with schema "coaps+jpy" and without any "bv"
   attribute indicate the default combination of "rrm", "cose" and "est"
   (EST via COAPS), as introduced by
   [I-D.ietf-anima-constrained-join-proxy], aka: stateless proxy cBRSKI,
   using the JPY header.

   In both cases, there is no "bv=" attribute, so that the absence of
   the "bv" attribute indicates backward compatibility with existing
   definitions from [I-D.ietf-anima-constrained-voucher] and
   [I-D.ietf-anima-constrained-join-proxy].

   "rt=brski.rs" with schema "https" and with "bv=" indicates Section 1
   with its default variation of "rrm", "cms" and "est".  As there is no
   mechanism to support the JPY header via TCP (for https), there is no
   schema "https+jpy" option.




Eckert & Dijk            Expires 9 January 2025                [Page 28]

Internet-Draft               BRSKI-discovery                   July 2024


   "rt=brski.rs" with schema "https" and with "bv=cmp" indicates the
   variation "rrm", "cms" and "cmp" as introduced by Section 1, and
   "rt=brski.rs" with schema "https" and with "bv=prm-jose" indicates
   the variation "prm", "jose" and "cmp" as introduced by Section 1.

   Note that the variation type value of "est" does mean different
   protocol specifications depending on the transport.  Over "https" it
   means Section 1, whereas over COAPS it means [RFC9148].

   Template:

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

   RES: 2.05 Content
        <scheme://[Responder_IP_unicast_address]:join-port>;\
          rt=brski.r*(;brv=brski-variation-string)

   Example:

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

   RES: 2.05 Content
        <coaps://[2001:db8:0:abcd::52]:7634/b>;rt=brski.rs,
        <coaps+jpy://[2001:db8:0:abcd::52]:7633/b>;rt=brski.rjpy,
        <https://[2001:db8:0:abcd::52]:7634/b>;rt=brski.rs;bv=,
        <https://[2001:db8:0:abcd::52]:7634/b>;rt=brski.rs;bv=cmp,
        <https://[2001:db8:0:abcd::52]:7634/b>;rt=brski.rs;bv=prm-jose,

          Figure 9: CORE-LF discovery of registrars by a proxy for
                         different BRSKI variations

   The following Figure 10 shows variations that have not explicitly
   been defined in existing specifications, so it is more or less unless
   whether they will work withough additional specification of details
   to allow interoperability.  Specifically, it is unclear whether
   "endpoint" protocols defined for "http" transport will equall work
   over "coaps" transport without additional specification.

   For this reason, such variations are not explicitly assumed to be
   supportable, but included as candidarte, subject to additional
   specification, and/or expert review.

RES: 2.05 Content
     <coapsy://[2001:db8:0:abcd::52]:7633/b>;rt=brski.rsy;bv=cose-cmp,
     <coaps+jpy://[2001:db8:0:abcd::52]:7633/b>;rt=brski.rjpy;bv=cose-cmp,
     <https://[2001:db8:0:abcd::52]:7634/b2>;rt=brski.rjps;bv=jose-cmp,
     <https://[2001:db8:0:abcd::52]:7634/b3>;rt=brski.rjps;bv=cose-cmp




Eckert & Dijk            Expires 9 January 2025                [Page 29]

Internet-Draft               BRSKI-discovery                   July 2024


          Figure 10: Potential ? future registrar variations

   [ Q: Can we actually use the * discovery to only discover the two
   variations of registrar transport variations "rj*" - when we are a
   registrar ??? we do not want to discover the resource that proxies or
   registrars provide to pledges!!! ]

   When pledges need to discover (and select) proxies (or registrars)
   supporting a specific combination of variations, the encoding of
   attributes is the same as shown in Figure 8 except that now,
   "rt=brski.jp" needs to be discovered.

   It is a responsibility of the proxy to discover registrars and map
   their discovered "bv=" variations for rt=brski.rjp" and/or
   "brski.rjps" to the same "bv=" variations to their announced
   "rt=brski.jp" resources: For provies, there is simply a 1:1 mapping
   of the "bv" attribute and the connection scheme for the resources
   discovered from registrars, except for the subset of variations that
   can rely on COAPS transport, for those both the "rt=brski.rjp" and
   "rt=brski.rjps" are options how to proxy the resource for the pleges.

   Note that the port numbers announced by the proxy resources will of
   course likely be different than those announced by the registarars.

   Template:

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

   RES: 2.05 Content
        <scheme://[Responder_IP_unicast_address]:join-port>;\
            rt=brski.jp(;brv=brski-variation-string)

   Example:

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

   RES: 2.05 Content
        <coaps://[2001:db8:0:abcd::52]:7734/b>;rt=brski.jp,
        <https://[2001:db8:0:abcd::52]:7734/b>;rt=brski.jp;bv=,
        <https://[2001:db8:0:abcd::52]:7734/b2>;rt=brski.jp;bv=jose-cmp,
        <https://[2001:db8:0:abcd::52]:7734/b3>;rt=brski.jp;bv=cose-cmp

      Figure 11: CORE-LF discovery of registrars or proxies by pledges
                        for various BRSKI variations







Eckert & Dijk            Expires 9 January 2025                [Page 30]

Internet-Draft               BRSKI-discovery                   July 2024


4.  Updates to existing RFCs

4.1.  RFC8995

   TBD.

5.  IANA considerations

5.1.  BRSKI Variations Discovery Registry (section)

   This document requests a new section named "BRSKI Variations
   Discovery Parameters" in the "Bootstrapping Remote Secure Key
   Infrastructures (BRSKI) Parameters" registry
   (https://www.iana.org/assignments/brski-parameters/brski-
   parameters.xhtml).  Its initial content is as follows.

   [ RFC editor.  Please remove the following sentence.  Note to IANA:
   This section contains three tables according to the specifications of
   this document.  Each of these tables should include the table title
   so that they can be more easily distinguished.  If it is not possible
   to introduce more than one table per section, then we will modify the
   request accordingly for three sections, but given how the three
   tables are tightly linked, that would be unfortunate. ]

   Registration Procedure(s): Standards action or expert review based on
   registration.  See ThisRFC.

   Experts: TBD.

   Reference: ThisRFC.

   Notes:

   Dflt flag:  Indicates a Variation Type Choice that is assumed to be
      used if the service discover/selection mechanism does not indicate
      any variation.

   Rsvd Flag:  Indicates a Variation Type Choice that is reserved for
      use with the mechanism described in the Note(s) column, but for
      which no specification yet exists.

   Spec / Applicability:  A "-" indicates that the variation is
      considered to be feasible through existing specifications, but not
      explicitly mentioned in them.  An "NA" indicates that the
      combination is assumed to be not working with the currently
      available specifications.





Eckert & Dijk            Expires 9 January 2025                [Page 31]

Internet-Draft               BRSKI-discovery                   July 2024


   +==============+============+===========+===========================+
   | Context      | Applicable | Discovery | Service Name(s)           |
   |              | Variation  | Mechanism |                           |
   |              | Types      |           |                           |
   +==============+============+===========+===========================+
   | BRSKI        | mode       | GRASP     | "AN_join_registrar" /     |
   |              | vformat    |           | "AN_Proxy"                |
   |              | enroll     |           | with IPPROTO_TCP          |
   +--------------+------------+-----------+---------------------------+
   |              |            | DNS-SD    | "brski-registrar" /       |
   |              |            |           | "brski-proxy"             |
   |              |            |           | with TCP                  |
   +--------------+------------+-----------+---------------------------+
   | cBRSKI       | mode       | GRASP     | "AN_join_registrar" /     |
   |              | vformat    |           | "AN_join_registrar_rjp"   |
   |              | enroll     |           | /                         |
   |              |            |           | "AN_Proxy"                |
   |              |            |           | with IPPROTO_UDP          |
   +--------------+------------+-----------+---------------------------+
   |              |            | DNS-SD    | "brski-registrar" /       |
   |              |            |           | "brski-proxy"             |
   |              |            |           | with UDP                  |
   +--------------+------------+-----------+---------------------------+
   |              |            | CORE-LF   | rt=brski.*                |
   +--------------+------------+-----------+---------------------------+
   | BRSKI-PLEDGE | mode       | DNS-SD    | "brski-pledge" with TCP   |
   |              | vformat    |           |                           |
   |              | enroll     |           |                           |
   +--------------+------------+-----------+---------------------------+

                     Table 1: BRSKI Variation Contexts

   +=======+=========+=========+=========+=====+========================================+
   |Context|Variation|Variation|Reference|Flags|Note(s)                                 |
   |       |Type     |Type     |         |     |                                        |
   |       |         |Choice   |         |     |                                        |
   +=======+=========+=========+=========+=====+========================================+
   |BRSKI, |mode     |rrm      |[RFC8995]|Dflt |Registrar Responder Mode                |
   |cBRSKI |         |         |ThisRFC  |     |the mode specified in [RFC8995]         |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |       |         |prm      |ThisRFC  |     |Pledge Responder Mode                   |
   |       |         |         |         |     |[I-D.ietf-anima-brski-prm]              |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |BRSKI  |vformat  |cms      |[RFC8368]|Dflt |CMS-signed JSON Voucher                 |
   |       |         |         |ThisRFC  |     |                                        |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |       |         |cose     |ThisRFC  |     |CBOR with COSE signature                |
   +-------+---------+---------+---------+-----+----------------------------------------+



Eckert & Dijk            Expires 9 January 2025                [Page 32]

Internet-Draft               BRSKI-discovery                   July 2024


   |cBRSKI |         |cose     |ThisRFC  |Dflt |CBOR with COSE signature                |
   |       |         |         |         |     |[I-D.ietf-anima-constrained-voucher]    |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |       |         |cms      |[RFC8368]|     |CMS-signed JSON Voucher                 |
   |       |         |         |ThisRFC  |     |                                        |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |BRSKI, |         |jose     |ThisRFC  |Dflt*|JOSE-signed JSON, Default when prm is   |
   |cBRSKI |         |         |         |     |used                                    |
   |       |         |         |         |     |[I-D.ietf-anima-jws-voucher],           |
   |       |         |         |         |     |[I-D.ietf-anima-brski-ae]               |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |BRSKI- |mode     |prm      |ThisRFC  |Dflt |Pledge responder Mode                   |
   |PLEDGE |         |         |         |     |[I-D.ietf-anima-brski-prm]              |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |       |vformat  |jose     |ThisRFC  |Dflt |JOSE-signed JSON, Default when prm is   |
   |       |         |         |         |     |used                                    |
   |       |         |         |         |     |[I-D.ietf-anima-jws-voucher],           |
   |       |         |         |         |     |[I-D.ietf-anima-brski-ae]               |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |       |         |cms      |ThisRFC  |Rsvd |CMS-signed JSON Voucher, not specified. |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |       |         |cose     |ThisRFC  |Rsvd |CBOR with COSE signature, not specified.|
   +-------+---------+---------+---------+-----+----------------------------------------+
   |BRSKI, |enroll   |est      |[RFC8995]|Dflt |Enroll via EST                          |
   |cBRSKI,|         |         |[RFC7030]|     |as specified in [RFC8995], extension for|
   |BRSKI- |         |         |         |     |Section 1 when used in context BRSKI-   |
   |PLEDGE |         |         |         |     |PLEDGE<br}[RFC9148] when used over COAP |
   +-------+---------+---------+---------+-----+----------------------------------------+
   |       |         |cmp      |ThisRFC  |     |Lightweight CMP Profile                 |
   |       |         |         |         |     |{I-D.ietf-anima-brski-ae}},             |
   |       |         |         |         |     |[I-D.ietf-lamps-lightweight-cmp-profile]|
   +-------+---------+---------+---------+-----+----------------------------------------+
   |       |         |scep     |ThisRFC  |Rsvd |[RFC8894]                               |
   +-------+---------+---------+---------+-----+----------------------------------------+

                   Table 2: BRSKI Variation Type Choices

   Note 1:  The Variation String "EST-TLS" is equivalent to the
      Variation String "" and is required and only permitted for the
      AN_join_registrar objective value in GRASP for backward
      compatibility with RFC8995, where it is used for this variation.
      Note that AN_proxy uses "".









Eckert & Dijk            Expires 9 January 2025                [Page 33]

Internet-Draft               BRSKI-discovery                   July 2024


   +=======+==========================+=========+==========+============+
   |Context|Reference                 |Variation|Variations|Explanations|
   |       |                          |String   |          |/ Notes     |
   +=======+==========================+=========+==========+============+
   |BRSKI  |[RFC8995]                 |"" /     |rrm cms   |Note 1      |
   |       |                          |"EST-TLS"|est       |            |
   +-------+--------------------------+---------+----------+------------+
   |       |[I-D.ietf-anima-brski-ae] |cmp      |rrm cms   |            |
   |       |                          |         |cmp       |            |
   +-------+--------------------------+---------+----------+------------+
   |       |[I-D.ietf-anima-brski-prm]|prm-jose |prm jose  |            |
   |       |                          |         |est       |            |
   +-------+--------------------------+---------+----------+------------+
   +-------+--------------------------+---------+----------+------------+
   |cBRSKI |<<I-D.ietf-anima-         |"" /     |rrm cose  |            |
   |       |constrained-voucher}}     |"rrm-    |est       |            |
   |       |                          |cose"    |          |            |
   +-------+--------------------------+---------+----------+------------+

                                  Table 3

5.2.  Service Names Registry

   IANA is asked to modify and amend the "Service Name and Transport
   Protocol Port Number Registry" registry
   (https://www.iana.org/assignments/service-names-port-numbers/service-
   names-port-numbers.txt) as follows:

   brski-proxy and brski-registrar are to be added as Service Names for
   the "udp" protocol using ThisRFC as the reference.

   The registrations for brski-proxy and brski-registrar for the "tcp"
   protocol are to be updated to also include ThisRFC as their
   reference.

   The Defined TXT keys column for brski-proxy and brski-registrar for
   both "tcp" and "udp" protocols are to state the following text:

   See ThisRFC and the "BRSKI Variation Type Choices" table in the
   "Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters"
   registry.

   TBD: This request likely does not include all the necessary
   formatting.







Eckert & Dijk            Expires 9 January 2025                [Page 34]

Internet-Draft               BRSKI-discovery                   July 2024


5.3.  BRSKI Well-Known URIs fixes (opportunistic)

   The following change requests to "https://www.iana.org/assignments/
   brski-parameters/brski-parameters.xhtml#brski-well-known-uris" are
   cosmetic in nature and are included in this document solely because
   support for Endpoint URIs is implied by the mechanisms specified in
   this document and the existing registry has these cosmetic issues.

   1.  IANA is asked to change the name of the first column of the table
       from "URI" to "URI Suffix".  This is in alignment with other
       table columns with the same syntax/semantic, such as
       "https://www.iana.org/assignments/well-known-uris/well-known-
       uris.xhtml".

   2.  IANA is asked to change the Reference from [RFC8995] to
       [RFC8995], Section 8.3.1.

   3.  IANA is asked to include the following "Note" text: The following
       table contains the assigned BRSKI protocol Endpoint URI suffixes
       under "/.well-known/brski"." - This note is added to introduce
       the term "Endpoint" into the registry table as that is the term
       commonly used (instead of URI) in several of the memos for which
       this discovery document was written.  It is meant to help readers
       map the registry to the terminology used in those documents.

6.  Security Considerations

   In Section 1, pledges are easier subject to DoS attacks than in
   Section 1, because attackers can be initiators and delay or prohibit
   enrollment of a pledge by opening so many connections to the pledge
   that a valid registrar-agents connection to the pledge may not be
   possible.  Discovery of the pledge via DNS-SD increases the ability
   of attackers to discover pledges against which such DoS attacks can
   be attempted.

   Especially when supporting DNS-SD browsing across unicast DNS,
   Pledges MUST implement DoS prevention measures, such as limiting the
   number and rate of accepted TCP connections on a per-initiator basis.
   If feasible for the implementation, simultaneous connections SHOULD
   be possible, so that an ongoing attacker connection will not delay a
   valid registrar-agent connection.  When accepting connections, a
   strategy such as LRU MAY be used to ensure that an attacker will not
   be able to monopolize connections.

   Browsing via DNS-SD, especially via unicast DNS which makes
   information available network-wide does also introduce a perpass
   attack, gathering intelligence against what type and serial number of
   devices are installed in the network.  Whether or not this is seen as



Eckert & Dijk            Expires 9 January 2025                [Page 35]

Internet-Draft               BRSKI-discovery                   July 2024


   a relevant risk is highly installation dependent.  Networks SHOULD
   implement filtering measures at mDNS and/or DNS RR/services level to
   prohibit such data collection if there is a risk, and this is seen as
   an undesirable attack vector.

7.  Acknowledgments

   TBD.

8.  Draft considerations

8.1.  Open Issues

   Questions to the DNS-SD community.

   TBD

8.2.  Change log

   [RFC Editor: please remove this section.]

   WG draft 02:

   Fix up tables to be correctly rendered by html output.

   WG draft 01:

   Core-LF improvements / interim work.

   WG draft 00:

   Added section for CORE-LF.  Still missing to update existing text
   with the CORE-LF definitions.

   Individual version 01:

   Various enhancements

   Individual version 00:

   Initial version.

9.  References

9.1.  Normative References






Eckert & Dijk            Expires 9 January 2025                [Page 36]

Internet-Draft               BRSKI-discovery                   July 2024


   [I-D.ietf-anima-brski-ae]
              von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE:
              Alternative Enrollment Protocols in BRSKI", Work in
              Progress, Internet-Draft, draft-ietf-anima-brski-ae-12, 5
              July 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-anima-brski-ae-12>.

   [I-D.ietf-anima-brski-prm]
              Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
              with Pledge in Responder Mode (BRSKI-PRM)", Work in
              Progress, Internet-Draft, draft-ietf-anima-brski-prm-13, 5
              July 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-anima-brski-prm-13>.

   [I-D.ietf-anima-constrained-join-proxy]
              Richardson, M., Van der Stok, P., and P. Kampanakis, "Join
              Proxy for Bootstrapping of Constrained Network Elements",
              Work in Progress, Internet-Draft, draft-ietf-anima-
              constrained-join-proxy-15, 6 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
              constrained-join-proxy-15>.

   [I-D.ietf-anima-constrained-voucher]
              Richardson, M., Van der Stok, P., Kampanakis, P., and E.
              Dijk, "Constrained Bootstrapping Remote Secure Key
              Infrastructure (cBRSKI)", Work in Progress, Internet-
              Draft, draft-ietf-anima-constrained-voucher-24, 3 March
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              anima-constrained-voucher-24>.

   [I-D.ietf-anima-jws-voucher]
              Werner, T. and M. Richardson, "JWS signed Voucher
              Artifacts for Bootstrapping Protocols", Work in Progress,
              Internet-Draft, draft-ietf-anima-jws-voucher-10, 18 June
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              anima-jws-voucher-10>.

   [I-D.ietf-dnssd-srp]
              Lemon, T. and S. Cheshire, "Service Registration Protocol
              for DNS-Based Service Discovery", Work in Progress,
              Internet-Draft, draft-ietf-dnssd-srp-25, 4 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-
              srp-25>.

   [I-D.ietf-lamps-lightweight-cmp-profile]
              Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
              Certificate Management Protocol (CMP) Profile", Work in
              Progress, Internet-Draft, draft-ietf-lamps-lightweight-



Eckert & Dijk            Expires 9 January 2025                [Page 37]

Internet-Draft               BRSKI-discovery                   July 2024


              cmp-profile-21, 17 February 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              lightweight-cmp-profile-21>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/rfc/rfc5280>.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://www.rfc-editor.org/rfc/rfc6690>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/rfc/rfc6762>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/rfc/rfc6763>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/rfc/rfc7030>.

   [RFC7390]  Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
              the Constrained Application Protocol (CoAP)", RFC 7390,
              DOI 10.17487/RFC7390, October 2014,
              <https://www.rfc-editor.org/rfc/rfc7390>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.






Eckert & Dijk            Expires 9 January 2025                [Page 38]

Internet-Draft               BRSKI-discovery                   July 2024


   [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
              Control Plane for Stable Connectivity of Network
              Operations, Administration, and Maintenance (OAM)",
              RFC 8368, DOI 10.17487/RFC8368, May 2018,
              <https://www.rfc-editor.org/rfc/rfc8368>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/rfc/rfc8990>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/rfc/rfc8994>.

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

   [RFC9148]  van der Stok, P., Kampanakis, P., Richardson, M., and S.
              Raza, "EST-coaps: Enrollment over Secure Transport with
              the Secure Constrained Application Protocol", RFC 9148,
              DOI 10.17487/RFC9148, April 2022,
              <https://www.rfc-editor.org/rfc/rfc9148>.

   [RFC9176]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
              P. van der Stok, "Constrained RESTful Environments (CoRE)
              Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
              2022, <https://www.rfc-editor.org/rfc/rfc9176>.

9.2.  Informative References

   [I-D.eckert-anima-grasp-dnssd]
              Eckert, T. T., Boucadair, M., Jacquenet, C., and M. H.
              Behringer, "DNS-SD Compatible Service Discovery in GeneRic
              Autonomic Signaling Protocol (GRASP)", Work in Progress,
              Internet-Draft, draft-eckert-anima-grasp-dnssd-06, 5
              January 2024, <https://datatracker.ietf.org/doc/html/
              draft-eckert-anima-grasp-dnssd-06>.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
              DOI 10.17487/RFC5988, October 2010,
              <https://www.rfc-editor.org/rfc/rfc5988>.






Eckert & Dijk            Expires 9 January 2025                [Page 39]

Internet-Draft               BRSKI-discovery                   July 2024


   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7252>.

   [RFC8894]  Gutmann, P., "Simple Certificate Enrolment Protocol",
              RFC 8894, DOI 10.17487/RFC8894, September 2020,
              <https://www.rfc-editor.org/rfc/rfc8894>.

Appendix A.  Discovery for constrained BRSKI

   This appendix section is intended to describe the current issues with
   Section 1 and Section 1 as of 08/2023, which make both drafts
   incompatible with this document.  It will be removed if/when those
   issues will be fixed.

A.1.  Current constrained text for GRASP

   The following is the current encodings from Section 1.

   *  The transport-proto is IPPROTO_UDP

   *  the objective is AN_join_registrar, identical to Section 1.

   *  the objective name is "BRSKI_RJP".

   Here is an example M_FLOOD announcing the Registrar on example port
   5685, which is a port number chosen by the Registrar.

   [M_FLOOD, 51804231, h'fda379a6f6ee00000200000064000001', 180000,
   [["AN_join_registrar", 4, 255, "BRSKI_RJP"],
   [O_IPv6_LOCATOR,
   h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5685]]]

     Figure 12: cBRSKI Fig 5: Example of Registrar announcement message

   Most Registrars will announce both a JPY-stateless and stateful
   ports, and may also announce an HTTPS/TLS service:













Eckert & Dijk            Expires 9 January 2025                [Page 40]

Internet-Draft               BRSKI-discovery                   July 2024


   [M_FLOOD, 51840231, h'fda379a6f6ee00000200000064000001', 180000,
   [["AN_join_registrar", 4, 255, ""],
    [O_IPv6_LOCATOR,
     h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443],
    ["AN_join_registrar", 4, 255, "BRSKI_JP"],
    [O_IPv6_LOCATOR,
     h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5684],
    ["AN_join_registrar", 4, 255, "BRSKI_RJP"],
    [O_IPv6_LOCATOR,
     h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5685]]]

                                 Figure 13

   The following is the current text from Section 1.

   *  The transport-proto is IPPROTO_UDP

   *  the objective is AN_join_registrar, identical to Section 1.

   *  the objective name is "BRSKI_RJP".

   Here is an example M_FLOOD announcing the Registrar on example port
   5685, which is a port number chosen by the Registrar.

      [M_FLOOD, 51804231, h'fda379a6f6ee00000200000064000001', 180000,
      [["AN_join_registrar", 4, 255, "BRSKI_RJP"],
       [O_IPv6_LOCATOR,
        h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5685]]]

            Figure 14: Example of Registrar announcement message

   Most Registrars will announce both a JPY-stateless and stateful
   ports, and may also announce an HTTPS/TLS service:

      [M_FLOOD, 51840231, h'fda379a6f6ee00000200000064000001', 180000,
      [["AN_join_registrar", 4, 255, ""],
       [O_IPv6_LOCATOR,
        h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443],
       ["AN_join_registrar", 4, 255, "BRSKI_JP"],
       [O_IPv6_LOCATOR,
        h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5684],
       ["AN_join_registrar", 4, 255, "BRSKI_RJP"],
       [O_IPv6_LOCATOR,
        h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5685]]]

          Figure 15: Example of Registrar announcing two services





Eckert & Dijk            Expires 9 January 2025                [Page 41]

Internet-Draft               BRSKI-discovery                   July 2024


A.1.1.  Issues and proposed change

   One goal of this document is to define variations such that proxies
   can deal with existing and future variations.  This only works for
   variations for which proxies would need to perform specific
   processing other than passing on data between pledge and registrar.

   Changes in protocol that require specific new behavior of proxies
   must therefore not be variations signaled via the objective-value
   field of GRASP objectives.

   In result, this document recommends the following changes to the
   encoding for Section 1 and Section 1.

   [M_FLOOD, 51840231, h'fda379a6f6ee00000200000064000001', 180000,
   [["AN_join_registrar", 4, 255, ""],
    [O_IPv6_LOCATOR,
     h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443],
    ["AN_join_registrar", 4, 255, ""],
    [O_IPv6_LOCATOR,
     h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5684],
    ["AN_join_registrar_rjp", 4, 255, ""],
    [O_IPv6_LOCATOR,
     h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5685]]]

          Figure 16: Proposed Encoding of registrar announcements

   In summary:

   *  Circuit proxy operation is indicted with objective-name
      "AN_join_registrar" and IPPROTO_UDP.  The default for
      AN_join_registrar/UDP is the use of COAPs and CBOR encoded
      voucher.  For this default, the objective-value is "".

   *  Stateless JPY proxy operations is indicated with objective-name
      "AN_join_registrar_rjp" and IPPROTO_UDP.  The default for
      AN_join_registrar/UDP is the use of COAPs and CBOR encoded
      voucher.  For this default, the objective-value is "".

Appendix B.  Possible future variations

   The following table Table 4 shows possible future entries for
   "Variation String" if there is an interest for such a variation.
   Thesew would be subject to expert review and could hence require
   appropriate additional specification so that interoperability based
   on that variation string can be guaranteed.





Eckert & Dijk            Expires 9 January 2025                [Page 42]

Internet-Draft               BRSKI-discovery                   July 2024


   +=======+=========+=========+==========+========================================+
   |Context|Reference|Variation|Variations|Explanations / Notes                    |
   |       |         |String   |          |                                        |
   +=======+=========+=========+==========+========================================+
   |BRSKI  |-        |jose     |rrm jose  |possible variation of [RFC8995] with    |
   |       |         |         |est       |voucher according to                    |
   |       |         |         |          |[I-D.ietf-anima-jws-voucher]            |
   +-------+---------+---------+----------+----------------------------------------+
   |       |-        |jose-cmp |rrm jose  |possible variation of [RFC8995] with    |
   |       |         |         |cmp       |voucher according to                    |
   |       |         |         |          |[I-D.ietf-anima-jws-voucher] and        |
   |       |         |         |          |enrollment according to                 |
   |       |         |         |          |[I-D.ietf-lamps-lightweight-cmp-profile]|
   +-------+---------+---------+----------+----------------------------------------+
   |       |-        |cose     |rrm cose  |possible variation of [RFC8995] with    |
   |       |         |         |est       |voucher according to                    |
   |       |         |         |          |[I-D.ietf-anima-constrained-voucher]    |
   +-------+---------+---------+----------+----------------------------------------+
   |       |-        |cose-cmp |rrm cose  |possible variation of [RFC8995] with    |
   |       |         |         |cmp       |voucher according to                    |
   |       |         |         |          |[I-D.ietf-anima-constrained-voucher] and|
   |       |         |         |          |enrollment according to                 |
   |       |         |         |          |[I-D.ietf-lamps-lightweight-cmp-profile]|
   +-------+---------+---------+----------+----------------------------------------+
   |       |-        |prm-cmp  |prm jose  |possible variation of                   |
   |       |         |         |cmp       |[I-D.ietf-anima-brski-prm] and          |
   |       |         |         |          |[I-D.ietf-anima-brski-ae]               |
   +-------+---------+---------+----------+----------------------------------------+
   |       |-        |prm-cose |prm cose  |possible variation of                   |
   |       |         |         |est       |[I-D.ietf-anima-brski-prm] and          |
   |       |         |         |          |[I-D.ietf-anima-constrained-voucher]    |
   +-------+---------+---------+----------+----------------------------------------+
   |       |-        |prm-cose-|prm cose  |possible variation of                   |
   |       |         |cmp      |cmp       |[I-D.ietf-anima-brski-prm],             |
   |       |         |         |          |[I-D.ietf-anima-constrained-voucher] and|
   |       |         |         |          |[I-D.ietf-anima-brski-ae]               |
   +-------+---------+---------+----------+----------------------------------------+

                                  Table 4

Contributors

   Thomas Werner
   Siemens AG
   Germany
   Email: thomas-werner@siemens.com
   URI:   https://www.siemens.com/




Eckert & Dijk            Expires 9 January 2025                [Page 43]

Internet-Draft               BRSKI-discovery                   July 2024


   Steffen Fries
   Siemens AG
   Germany
   Email: steffen.fries@siemens.com
   URI:   https://www.siemens.com/


   Hendrik Brockhaus
   Siemens AG
   Germany
   Email: hendrik.brockhaus@siemens.com
   URI:   https://www.siemens.com/


   Michael Richardson
   Canada
   Phone: +41 44 878 9200
   Email: mcr+ietf@sandelman.org


   David von Oheimb
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   Email: david.von.oheimb@siemens.com
   URI:   https://www.siemens.com/


Authors' Addresses

   Toerless Eckert (editor)
   Futurewei USA
   United States of America
   Email: tte@cs.fau.de


   Esko Dijk
   IoTconsultancy.nl
   Email: esko.dijk@iotconsultancy.nl











Eckert & Dijk            Expires 9 January 2025                [Page 44]