]>

Austria christian@amsuess.com

TUD Dresden University of Technology

Helmholtzstr. 10 Dresden D-01069 Germany martine.lenders@tu-dresden.de

Internet CoRE CoRE, Web Linking, Proxy, URI, aliasing The Constrained Application Protocol (CoAP, ) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking to express alternative transports available to a device, and to optimize exchanges using these. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the core Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) provides transports mechanisms (UDP and DTLS since , TCP, TLS and WebSockets since ), with some additional being used in LwM2M and even more being explored (, ). These are mutually incompatible on the wire, but CoAP implementations commonly support several of them, and proxies can translate between them. CoAP currently lacks a way to indicate which transports are available for a given resource, and to indicate that a device is prepared to serve as a proxy; this document solves both by introducing the "has-proxy" terminology to Web Linking that expresses the former through the latter. The additional "has-unique-proxy" term is introduced to negate any per-request overhead that would otherwise be introduced in the course of this. CoAP also lacks a unified scheme to label a resource in a transport-independent way. This document does not attempt to introduce any new scheme here, or raise a scheme to be the canonical one. Instead, each host or application can pick a canonical address for its resources, and advertise other transports in addition.

Terminology Readers are expected to be familiar with the terms and concepts described in CoAP and link format (or, equivalently, web links as described in ).

Same-host proxy:

A CoAP server that accepts forward proxy requests (i.e., requests carrying the Proxy-Scheme option) exclusively for URIs that it is also the authoritative server for is defined as a "same-host proxy".

The distinction between a same-host and any other proxy is only relevant on a practical, server-implementation and illustrative level; this specification does not use the distinction in normative requirements, and clients need not make the distinction at all.

When talking of proxy requests, this document only talks of the Proxy-Scheme option. Given that all URIs this is usable with can be expressed in decomposed CoAP URIs, the need for using the Proxy-URI option should never arise. The Proxy-URI option is still equivalent to the decomposed options, and can be used if the server supports it.

Using URIs to identify transport endpoints The URI coap://[2001:db8::1] identifies a particular resource, possibly a "welcome" text. It is, colloquially, also used to identify the combination of a CoAP transport and the transport specific details. For precision, this document uses the term "the transport address indicated by (a URI)" to refer to the transport and its details (in the example, CoAP over UDP with an IPv6 address and the default port), but otherwise no big deal is made of it. The transport indicated by a URI is not only influenced by the URI scheme, but also by the authority component. The transports and resolution mechanisms currently specified make little use of this possibility, mainly because the most prominent resolution mechanism (SVCB records) has not been avaialble when was published and because it can not be expressed in IP literals. The provisions of this document enable this opportunistically for registered names () and for literals using the mechanism in . When the resolution mechanism used for a registered name authority component yields multiple addresses, all of those are possible ways to interact with the resource. The resolution mechanism or other underlying transport can give guidance on how to find the best usable one. With the currently specified transports and resolution mechanisms, the most prominent example of making use of that information is applying 's Happy Eyeballs mechanism to establish a TCP connection when a name resolves to both IPv4 and IPv6 addresses,

Paths in URIs that indicate transport addresses For the CoAP schemes (coap, coaps, coap+tcp, coaps+tcp, coap+ws, coaps+ws), URIs indicating a transport are always given with an empty path (which under their URI normalization rules is equivalent to a path containing a single slash). For the coap and coap+tcp schemes, URIs with different host names can indicate the same transport as long as the names resolve to the same addresses. For the others, the given host name informs the name set in TLS's Server Name Indication (SNI) and/or the host sent in the "Host" header of the underlying HTTP request. If an update to this document extends the list, for new schemes it might be allowed to have paths, queries or fragment identifiers present in the URI indicating the transport address. No guidance can be given here for these, as no realistic example is known. (Note that while the coap+ws scheme does use the well-known path /.well-known/coap internally, that is used purely on the HTTP side, and not part of the CoAP URI, not even for indicating the transport address). It is conceivable that a path such as the /.well-known/coap of CoAP-over-WebSockets would be indicated in an SVCB discovery's parameters similar to dohpath. This does not immediately help with the question of whether a URI indicating a transport can have a path, though. --CA

Existing use A similar concept is used in (expressed as pieces of its tp_info parameter), but not expressed with URIs yet. As that document migrates towards using CRIs (), it is expected that its transport addresses coincide with the URIs (CRIs, equivalently) indicating a transport. URIs indicating a transport are especially useful when talking about proxies; this use is aligned with the way they are expressed in the conventional environment variables http_proxy etc. . Furthermore, URIs processing is widespread in CoAP systems, and when that changes (e.g. through the introduction of ), URIs indicating a transport will still be efficient to encode. And last but not least, it lines up well with the colloquial identity mentioned above. (An alternative would be using a dedicated naming scheme, say, transport:coap:device.example.com:port, but that would needlessly introduce implementation complexity). Note that this mechanism can only used with proxies that use CoAP's native address indication mechanisms. Proxies that perform URI mapping (as described in Section 5 of , especially using URI templates) are not supported in this document. [ TBD: Do we want to extend this to HTTP proxies? Probably just not, and if so, only to those that can just take coap://... for a URI. ]

Goals This document introduces provisions for the seamless use of different transport mechanisms for CoAP. Combined, these provide:

1. Enablement: Inform clients of the availability of other transports of servers.
2. No Aliasing: Any URI aliasing must be opt-in by the server. Any defined mechanisms must allow applications to keep working on the canonical URIs given by the server.
3. Optimization: Do not incur per-request overhead from switching transports. This may depend on the server's willingness to create aliased URIs.
4. Proxy usability: All information provided must be usable by aware proxies to reduce the need for duplicate cache entries.
5. Proxy announcement: Allow third parties to announce that they provide alternative transports to a host.

For all these functions, security policies must be described that allow the client to use them as securely as the original transport. This document will not concern itself with changes in transport availability over time, neither in causing them ("Please take up your TCP interface, I'm going to send a firmware update") nor in advertising their availability in advance. Hosts whose transport's availability changes over time can utilize any suitable mechanism to keep client updated, such as placing a suitable Max-Age value on their resources or having them observable.

Indicating alternative transports While CoAP can set the authority component of the requested URI in all requests (by means of Uri-Host and Uri-Port), setting the scheme of a requested URI (by means of Proxy-Scheme) makes the request implicitly a proxy request. However, this needs to be of only little practical concern: Any device can serve as a proxy for itself (a "same-host proxy") by accepting requests that carry the Proxy-Scheme option. already mandates that a proxy recognize its own addresses. A minimal same-host proxy supports only those and respond with 5.05 (Proxying Not Supported). In many cases (precisely: on hosts that alias their resources across transports), this is equivalent to ignoring the Proxy-Scheme option in that request. A server can advertise a recommended proxy by serving a Web Link with the "has-proxy" relation to a URI indicating its transport address. In particular (and that is a typical case), it can indicate its own transport address on an alternative transport when implementing same-host proxy functionality. The semantics of a link from S to P with relations has-proxy ("S has-proxy P", <P>;rel=has-proxy;anchor="S") are that for any resource that has the same origin as S, the transport address indicated by P can be used to obtain that resource.

Example A constrained device at the address 2001:db8::1 that supports CoAP over TCP in addition to CoAP can self-describe like this:

Discovery and follow-up request through a has-proxy relation ;if="tag:example.com,sensor", ;rel=has-proxy;anchor="/" Req: to [2001:db8::1]:5683 on TCP Code: GET Proxy-Scheme: coap Uri-Path: /sensors/temp Observe: 0 Res: 2.05 Content Observe: 0 Payload: 39.1°C ]]>

Note that generating this discovery file needs to be dynamic based on its available addresses; only if queried using a link-local source address, the server may also respond with a link-local address in the authority component of the proxy URI. Unless the device makes resources discoverable at coap+tcp://[2001:db8::1]/.well-known/core or another discovery mechanism, clients may not assume that coap+tcp://[2001:db8::1]/sensors/temp is a valid resource (let alone is equivalent to the other resource on the same path). The server advertising itself like this may reject any request on CoAP-over-TCP unless it contains a Proxy-Scheme option. Clients that want to access the device using CoAP-over-TCP would send a request by connecting to 2001:db8::1 TCP port 5683 and sending a GET with the options Proxy-Scheme: coap, no Uri-Host or -Port options (utilizing their default values), and the Uri-Paths "sensors" and "temp".

Security context propagation Any security requirements posed by a server or client application on a CoAP request MUST be applied independently of the transport that is used to perform the request. If a transport can not be used to satisfy the requirements, it is ineligible for use with the request (from a client's point of view), and unauthorized (from a server's point of view). If the requirements contain transport layer security, the proxy needs to present the credentials required of the server to the client, and those of the client to the server; this is only practical when the proxy is a same-host proxy. Some applications have requirements exceeding the requirements of a secure connection, e.g., (explicitly or implicitly) requiring that name resolution happen through a secure process and packets are only routed into networks where it trusts that they will not be intercepted on the path to the server. Such applications need to extend their requirements to the source of the has-proxy statement; a sufficient (but maybe needlessly strict) requirement is to only follow has-proxy statements that are part of the same resource that advertises the link currently being followed. Section adds further considerations.

Choice of transports It is up to the client whether to use an advertised proxy transport, or (if multiple are provided) which to pick. Links to proxies may be annotated with additional metadata that may help guide such a choice; defining such metadata is out of scope for this document. Clients MAY switch between advertised transports as long as the document describing them is fresh; they may even do so per request. (For example, they may perform individual requests using CoAP-over-UDP, but choose CoAP-over-TCP for requests with large expected responses). When the describing document approaches expiry, the client can use the representation's ETag to efficiently renew its justification for using the alternative transport.

Selection of a canonical origin While a server is at liberty to provide the same resource independently on different transports (i.e. to create aliases), it may make sense for it to pick a single scheme and authority under which it announces its resources. Using only one address helps proxies keep their caches efficient, and makes it easier for clients to avoid exploring the same server twice from different angles. When there is a predominant scheme and authority through which an existing service is discovered, it makes sense to use these for the canonical addresses. Otherwise, it is suggested to use the coap or coaps scheme (given that these are the most basic and widespread ones), and the most stable usable name the host has.

Unreachable canonical origin addresses For devices that are not generally reachable at a stable address, it may make sense to use a scheme and authority as the canonical address that can not actually be dereferenced. The registered names available for that purpose depend on the locally defined host or service name registry. When the Domain Name System (DNS) is used, such names would not be associated with any A or AAAA records (but may still use, for example, TLSA records). Such URIs are only usable to clients that discover a suitable proxy along with the URI, and which can place sufficient trust in that proxy.

Advertisement through a Resource Directory In the Resource Directory specification , protocol negotiation was anticipated to use multiple base values. This approach was abandoned since then, as it would incur heavy URI aliasing. Instead, devices can submit their has-proxy links to the Resource Directory like all their other metadata. A client performing resource lookup can ask the RD to provide available (same-host-)proxies in a follow-up request by asking for ?anchor=<the-discovered-host>&rel=has-proxy. The RD may also volunteer that information during resource lookups even though the has-proxy link itself does not match the search criteria. [ It may be useful to define RD parameters for use with lookup here, which'd guide which available proxies to include. For example, asking ?if=tag:example.com,sensor&proxy-links=tcp could give as a result: <coap://[2001:db8::1]/s>;rt=tag:example.com,sensor,<coap+tcp://[2001:db8::1]/>;rel=has-proxy;anchor="coap://[2001:db8::1]/" This is similar to the extension suggested in . ]

Elision of Proxy-Scheme and Uri-Host A CoAP server may publish and accept multiple URIs for the same resource, for example when it accepts requests on different IP addresses that do not carry a Uri-Host option, or when it accepts requests both with and without the Uri-Host option carrying a registered name. Likewise, the server may serve the same resources on different transports. This makes for efficient requests (with no Proxy-Scheme or Uri-Host option), but in general is discouraged . To make efficient requests possible without creating URI aliases that propagate, the "has-unique-proxy" specialization of the has-proxy relation is defined. If a proxy is unique, it means that requests arriving at the proxy are treated the same no matter whether the scheme, authority and port of the link context are set in the Proxy-Scheme, Uri-Host and Uri-Port options, respectively, or whether all of them are absent. [ The following two paragraphs are both true but follow different approaches to explaining the observable and implementable behavior; it may later be decided to focus on one or the other in this document. ] While this creates URI aliasing in the requests as they are sent over the network, applications that discover a proxy this way should not "think" in terms of these URIs, but retain the originally discovered URIs (which, because Cool URIs Don't Change, should be long-term usable). They use the proxy for as long as they have fresh knowledge of the has-(unique-)proxy statement. In a way, advertising has-unique-proxy can be viewed as a description of the link target in terms of SCHC : In requests to that target, the link source's scheme and host are implicitly present. While applications retain knowledge of the originally requested URI (even if it is not expressed in full on the wire), the original URI is not accessible to caches both within the host and on the network (for the latter, see ). Thus, cached responses to the canonical and any aliased URI are mutually interchangeable as long as both the response and the proxy statement are fresh. A client MAY use a unique-proxy like a proxy and still send the Proxy-Scheme and Uri-Host option; such a client needs to recognize both relation types, as relations of the has-unique-proxy type are a specialization of has-proxy and typically don't carry the latter (redundant) annotation. [ To be evaluated -- on one hand, supporting it this way means that the server needs to identify all of its addresses and reject others. Then again, is a server that (like many now do) fully ignore any set Uri-Host correct at all? ] Example:

Follow-up request through a has-unique-proxy relation. Compared to the last example, 5 bytes of scheme indication are saved during the follow-up request. ;if="tag:example.com,collection", ;rel=has-unique-proxy;anchor="/" Req: to [2001:db8::1] via WebSockets over HTTPS Code: GET Uri-Path: /sensors/ Res: 2.05 Content Content-Format: application/link-format Payload: ;if="tag:example.com,sensor" ]]>

It is noteworthy that when the URI reference /sensors/temperature is resolved, the base URI is coap://device0815.example.com and not its coaps+ws counterpart -- as the request is still for that URI, which both the client and the server are aware of. However, this detail is of little practical importance: A simplistic client that uses coaps+ws://device0815.proxy.rd.example.com as a base URI will still arrive at an identical follow-up request with no ill effect, as long as it only uses the wrongly assembled URI for dereferencing resources, the security context is the same, the state is kept no longer than the has-unique-proxy statement is fresh, and it does not (for example) pass the URI on to other devices.

Impact on caches [ This section is written with the "there is implied URI aliasing" mindset; it should be possible to write it with the "compression" mindset as well (but there is no point in having both around in the document at this time). It is also slightly duplicating, but also more detailed than, the brief note on the topic in ] When a node that performs caching learns of a has-unique-proxy statement, it can utilize the information about the implied URI aliasing: As long as the has-unique-proxy statement is fresh and trusted, requests for either of the origins can be served from the cache of the other origin.

Using unique proxies securely The elision of the host name afforded by the unique-proxy relation is only possible if the required security mechanisms verify the scheme and host of the server. This is given for OSCORE based mechanisms, where "unprotected message fields (including Uri-Host [...]) MUST not lead to an OSCORE message becoming verified". With TLS based security mechanisms, name and scheme can not be completely elided in general. While the use of the SNI HostName field sets the default Uri-Host already, the scheme still needs to be sent in a Proxy-Scheme option to satisfy the requirement of . [ It may be possible to relax this requirement if the host publishes a trustworthy statement about serving the same content on all schemes; however, no urgent need for this optimization is currently known that warrants the extra scrutiny. ]

Self-description as a unique proxy The level of assurance a client needs from a server to elide the Uri-Host option in a request that was created from a URI with no IP address literal has been a controversial topic. [ Should we dig up old conversations, link to https://github.com/core-wg/wiki/wiki/CoAP-FAQ#q4, or just let the weight of a WG consensus-document-to-be do its work? ] The has-unique-proxy relation provides an easy way for a server to indicate that this is in fact allowed: A server can publish a statement such as </>;rel=has-unique-proxy in its /.well-known/core file. A client that receives and understands it can thus elide the Uri-Host option in requests to the server as per the definition of the relation.

Third party proxy services A server that is aware of a suitable cross proxy may use the has-proxy relation to advertise that proxy. If the transport used towards the proxy provides name indication (as CoAP over TLS or WebSockets does), or by using a large number of addresses or ports, it can even advertise a (more efficient) has-unique-proxy relation. This is particularly interesting when the advertisements are made available across transports, for example in a Resource Directory. How the server can discover and trust such a proxy is out of scope for this document, but generally involves the same kind of links. In particular, a server may obtain a link to a third party proxy from an administrator as part of its configuration. The proxy may advertise itself without the origin server's involvement; in that case, the client needs to take additional care (see ).

HTTP based discovery and CoAP-over-WS request to a CoAP resource through a has-unique-proxy relation ;if="tag:example.com,collection", ;rel=has-unique-proxy;anchor="coap://device0815.example.com/" Req: to device0815.proxy.rd.example.com on WebSocket Host (indicated during upgrade): device0815.proxy.rd.example.com Code: GET Uri-Path: /sensors/ Res: 2.05 Content Content-Format: application/link-format Payload: ;if="tag:example.com,sensor" ]]>

Generic proxy advertisements A third party proxy may advertise its availability to act as a proxy for arbitrary CoAP requests. This use is not directly related to the transport indication in other parts of this document, but sufficiently similar to warrant being described in the same document. The resource type "CPA-core.proxy" can be used to describe such a proxy.

A CoAP client discovers that its border router can also serve as a proxy, and uses that to access a resource on an HTTP server. ;rt=CPA-core.proxy Req: to [fe80::1] via CoAP Code: GET Proxy-Scheme: http Uri-Host: example.com Uri-Path: /motd Accept: text/plain Res: 2.05 Content Content-Format: text/plain Payload: On Monday, October 25th 2021, there is no special message of the day. ]]>

The considerations of apply here. A generic advertised proxy is always a forward proxy, and can not be advertised as a "unique" proxy as it would lack information about where to forward. A proxy may be limited in the URIs it can service, for technical reasons (e.g. when none of the URI's transports are supported by the server) or for policy reasons (only accessing servers inside an organizational structure). Future documents (or versions of this document) may add target attributes that allow specifying the capabilities of a proxy. [ An earlier version of this document contained a proxy-schemes attribute. This was discontinued because it could already not express whether a proxy could access IPv4 or IPv6 peers, and because the use of schemes is becoming less useful given the new recommendation of incorporating details from registered name resolution into the transport selection. ] The use of a generic proxy can be limited to a set of devices that have permission to use it. Clients can be allowed by their network address if they can be verified, or by using explicit client authentication using the methods of .

Client picked proxies This section is purely informative, and serves to illustrate that the mechanisms introduced in this document do not hinder the continued use of existing proxies. When a resource is accessed through an "actual" proxy (i.e., a host between the client and the server, which itself may have a same-host proxy in addition to that), the proxy's choice of the upstream server is originally (i.e., without the mechanisms of this document) either configured (as in a "chain" of proxies) or determined by the request URI (where a proxy picks CoAP over TCP and resolves the given name for a request aimed at a coap+tcp URI). A proxy that has learned, by active solicitation of the information or by consulting links in its cache, that the requested URI is available through a (possibly same-host) proxy, may use that information in choosing the upstream transport, to correct the URI associated with a cached response, and to use responses obtained through one transport to satisfy requests on another. For example, if a host at coap://h1.example.com has advertised </res>,<coap+tcp://h1.example.com>;rel=has-proxy;anchor="/", then a proxy that has an active CoAP-over-TCP connection to h1.example.com can forward an incoming request for coap://h1.example.com/res through that CoAP-over-TCP connection with a suitable Proxy-Scheme and Uri-Host on that connection. If the host had marked the proxy point as <coap+tcp://h1.example.com>;rel=has-unique-proxy instead, then the proxy could elide the Proxy-Scheme and Uri-Host options, and would (from the original CoAP caching rules) also be allowed to use any fresh cache representation of coap+tcp://h1.example.com/res to satisfy requests for coap://h1.example.com/res. A client that uses a forward proxy and learns of a different proxy advertised to access a particular resource will not change its behavior if its original proxy is part of its configuration. If the forward proxy was only used out of necessity (e.g., to access a resource whose indicated transport not supported by the client) it can be practical for the client to use the advertised proxy instead.

Transport indication from non-link sources: Service Binding Parameters Discovery mechanisms that exist in DNS , DHCP, Router Advertisements or other mechanisms can provide details already that would otherwise only be discovered later through proxy links. For when those details are provided in the shape of Service Binding Parameters, this section describes their interpretation in the context of CoAP transport indication. The subsections in this section are arranged to describe a consistent sequential full picture. The capabilities of this big picture are not exercised by any application known at the time of draft publication. It is instead backed by many small-scope use cases (such as bootstrapping issues of proxy-link based CoAP scheme unification, , and also applications outside CoAP such as ) and presents a unified solution framework.

Discovering transport indication details from name resolution When a host finds a CoAP transport from a URI and the URI's authority component does not contain a precise address literal, the resolution mechanisms which it may try generally depend on the CoAP transports and their variation which it supports. For example, if it supports CoAP-over-UDP and IPv6, it requests AAAA records through DNS and look them up in a host file. This document extends this and registers the _coap and _coaps attrleaf labels in using the pattern described as described in , and thus enables the use of SVCB records. This path is chosen over the creation of a new SVCB RR pair "COAP" / "COAPS" because it is considered unlikely that DNS implementations would update their code bases to apply SVCB behavior; this assumption will be revisited before registration. These can be used during the resolution of URIs using the "coap" or "coaps" schemes, respectively. No such labels are registered for other CoAP schemes that have been registered, as it is expected that applications that use them will prefer leaving the more detailed transport choice to the parameters. The "coaps" scheme comes with the expectation of using a secured transport. While discovered parameters can override this, components and applications MUST NOT select a transport and security mechanism combination with a reduced security level. [ There is no formal description of what the requirements following "coaps" really are. Would it make sense to only register "coap" here, unifying the scheme space even further, given that any applications needs to describe its security requirements anyway, and can just as well apply them to "coap"? ] Some SVCB parameters have defaults; for those new services, these are: * port: 5683 for _coap, 5684 for _coaps * ALPN: empty for _coap, "co" for _coaps * coaptransport: "udp" for _coap, empty for _coaps As SVCB records were not specified for the existing CoAP transports originally, generic CoAP clients are not required to use the SVCB lookup mechanism, but MAY attempt it opportunistically in order to obtain a usable transport (or to obtain it faster). Applications built on CoAP MAY require clients to perform this kind of discovery. Adding such a requirement is particularly useful if the application frequently advertises URIs with a scheme that defaults to a transport which its clients may not support, or when the application makes use of functionality afforded by such as apex domain redirection. (Had the SVCB specification predated the first new CoAP transports, that mechanism might have been used in the first place instead of additional schemes). The effects on a client of seeing SVCB parameters are similar to those of seeing a "has-proxy" link from the origin to the URI built using {#svcblit}. They differ in that SVCB parameters describe the server itself: Credentials expressed apply end to end (as opposed to credentials that describe the proxy in a "has-proxy" link), and the client could conclude that the implied proxy is a same-host proxy (if that had any impact on the client, which it does not).

Service Parameters Several parameters are relevant in the context of CoAP, independently of whether they are used with SVCB records or Service Binding Parameters transported outside of SVCB records, and independently of whether they apply to the _coap / _coaps service or another service that can be used on top of CoAP (such as _dns):

• port: The CoAP service using the transport described in this parameter is reachable on this port (described in ).
• alpn: The ALPN "coap" has been defined for CoAP-over-TLS , and "co" for CoAP-over-DTLS in . If an ALPN service parameter is found, this indicates that the ALPN(s) and thus the CoAP transport that can be used on this address / port. For example, "co" indicates that DTLS (and thus UDP) is used.
• coaptransport: This is a new parameter defined in this document, and similar to the ALPN parameter. If a coaptransport parameter is present, the indicated transport(s) can be used on this address / port. The names registered for existing transports are identical to the URI schemes that indicate their use in the absence of Service Binding Parameters. [ It is left for review by SVCB experts whether these are a separate parameter space or we should just take ALPNs for them, like eg. h2c does. ]
• edhoc-cred: This is a new parameter defined in this document, and describes that EDHOC can be used with the server, and which credentials can authenticate the server. The edhoc-cred parameter's value is a CBOR sequence of COSE Header maps as defined in . If the parameter is present, it indicates that EDHOC can be used on the transport, and that the server can be authenticated by any credential expressed in the sequence. This is similar to the TLSA records specified in . A COSE Header map can express many properties, not all of which are sufficient to authenticate a peer on any given security mechanism. Without excluding applications that may process other entries, a practical criterion for whether a header map is suitable for EDHOC is that the header map could also be used in EDHOC as ID_CRED_R if the credential is sent by value. For example, a header map with a kccs entry can be used to indicate a public key including a Key ID (kid), and that public key does not need to be sent during the EDHOC exchange. Alternatively, a header map with an x5t identifies the end entity certificate the server presents by a thumbprint (hash). It is up to the application to define requirements for the provenance of the edhoc-cred parameter, whether it needs to be provided through secure mechanism, or whether the server is strictly required to present that credential. This is unlike TLSA, which needs to be transported through DNSSEC, because a edhoc-cred parameter may be sent using other means than DNS (for example in DHCPv6 responses or Router Advertisements).
• edhoc-info: This is a new parameter defined in this document, describing how EDHOC can be used on the server. The value of the parameter is a CBOR map following the EDHOC_Information structure defined in and extended in . It is optional to provide and optional to process, but can help speed up the establishment of a security context.
• oauth-hints: This is a new parameter defined in this document, describing how ACE-OAuth can be used with this service. Its value is a CBOR map containing AS Request Creation Hints as described in . While an empty map can be useful (hinting that the client should use its configured ACE-OAuth setup), typical useful keys are 1 (AS, indicating the URI of the Authorization Server), 5 (audience, indicating the name under which the service is known to the Authorization Server), and 9 (scope, when discovering a particular service rather than just getting transport information for a host). That data is using the same shape the server might use when responding to an attempt at an unencrypted connection, and can not only speed up the discovery of the right AS, but can also protect that information (eg. when DNSSEC is used), and avoids the need for an unprotected first request. It is up to the application to define requirements for the use of such data. For example, it may require that the audience matches the requested host name, or may require that the scope matches the kind of service being discovered. When expressed in text format, e.g. in DNS zone files, the CBOR diagnostic notation can be used.

Examples of using name resolution discovery and parameters

Generic client discovering transport options A generic client is directed to obtain coap://dev1.example.com/log requests the name to be resolved using the system's resolution mechanisms, resulting in a DNS query for these records: _coap.dev1.example.com IN SVCB dev1.example.com IN AAAA The following records are returned: _coap.dev1.example.com IN SVCB 1 . coaptransport=tcp,udp _coap.dev1.example.com IN SVCB 1 . alpn=co,coap port=5684 _coap.dev1.example.com IN SVCB 1 . coaptransport=udp port=61616 dev1.example.com IN AAAA 2001:db8:1::1 Exceeding the single option it had with just the IP address, it may now also choose to establish a TCP connection on the default port, to use port 61616 for UDP (which results in more compact frames on a 6LoWPAN link), or to use either of the TLS based options.

Application mandating SVCB An application's policy is to mandate client support for SVCB records, and to require that a security mechanism must be used where credentials are backed either by DNSSEC or by the Web PKI. A server operator is running in a legacy network that only provides an IPv4 address behind NAT with a dynamic public address, but has PCP available. After running PCP to open a UDP port, it learns that 1.2.3.4:5678 will be available for some time. It therefore updates its DNS record like this: _coap.host.example.net 600 IN SVCB 1 publicudp.host.example.net \ port=5678 \ edhoc-cred={14:{... /KCCS with its public key/}} When a client starts using coap://host.example.net/interactive, it looks up that record and verifies it using DNSSEC. It then proceeds to send EDHOC requests over CoAP to 1.2.3.4 port 5678, setting the Uri-Host option to "host.example.net". The client could also have initiated an EDHOC session if no edhoc-cred parameter had been present, but then, it would have required that the server present some credential that could be verified through the Web PKI, for example an x5chain containing a Let's Encrypt certificate.

Producing request for a discovered service If a service's discovery process does not produce a URI but an address, host name and/or Service Binding Parameters, those can be converted to a CoAP URI, for which transport hints are already encoded in the parameters the URI is constructed from. An example of this is DNS server discovery . While it is up to the service to define the service's semantics, this section applies to any service whose use with CoAP is defined by a normative referencing this section:

• The client tries the available serivces with their ALPNs and CoAP transports according to its capabilities and the priorities and mandatory parameters as defined for Service Bindings.
• The service either defines a well-known path, or it defines a Service Binding Parameter that describes the service's path on the described endpoint, or it defines both (and the well-known path is the default in absence of the defined parameter). Th value is a CBOR sequence of text strings, which represent Uri-Path options in a CoAP request, or (equivalently) the path of a CRI reference . A parameter value that is not a well-formed CBOR sequence, or any item is not a text string, is considerd malformed. When expressed in text format, e.g. in DNS zone files, the CBOR diagnostic notation can be used. To access the service, a client sets the text string values of the used Service Binding as Uri-Path options in the request. If the resource is unavailable, the client may continue with options that have a larger SvcPriority value associated (if such a property exists in the discovery method). An example of such an option is docpath as defined in . (As that document precedes this one, it repeats the same rules explicitly rather than reusing these rules).
• A Service Binding is accompanied by a hostname: For example, this is the hostname of the Encrypted DNS Resolver or the Special-Use Domain Name in the case of lookups, or the authentication-domain-name in case of DHCP options or Router Advertisements. Unless its value is identical to the default value for Uri-Host (which is the case on transports with Server Name Indication (SNI)), the that name is added in the Uri-Host option.
• If the port Service Binding Parameter is set, the Uri-Port option is set to the port that set in the port prefix of the query (or the used CoAP transport's default port), unless that is its default value anyway.
• No Proxy-Scheme option is set.

By following the rules of or the equivalent rules for the respective CoAP transport, the service can be translated into a URI. This implies URI aliasing between the composed URIs of all transports if any of the transports use different schemes. The rules for setting Uri-Host and Uri-Port result in the authority component of the URI being equal to the Binding Authority defined in . Note that since different security policies may apply to service discovery and other application components that dereference URIs, any connections established while using the service and cache entries created by it need to be treated carefully, for example by using separate connection and cache pools.

Expressing Service Parameters as literals A method for expressing Service Parameters in URIs that do not use registered names is described in . Among other things, that mechanism allows encoding the full information obtained during service discovery in a URI instead of just the one choice taken. It is also required if different CoAP transports are using the same scheme (as is recommended in ) with IP address literals in URIs, for which unlike for resolved names no service parameters are available.

Guidance to upcoming transports When new transports are defined for CoAP, it is recommended to use the "coap" scheme (or "coaps" for TLS based transports). If the transport's identifiers are IP based and have identifiers typically resolved through DNS, authors of new transports are encouraged to specify Service Binding records () for CoAP, e.g., using an alpn or coaptransport parameter. and if IP literals are relevant to the transport, to follow up on . If the transport's native identifiers are compatible with the structure of the authority component of a URI, those identifiers can be used as an authority as-is. To help the host decide the resolution mechanism, it may be helpful to register a subdomain of .arpa as described in . The guidence for users is to never attempt to resolve such a name, and for the zone's implementation is to return NXDOMAIN unconditionally. For the purpose of specifying a transport protocol via Service Binding records, and to encourage future authors more, this document specifies the coaptransport Service Parameter Key (SvcParamKey) with the initial legal values "udp" and "tcp" which indicate either CoAP over UDP and CoAP over TCP as the transport. The present of transport security is indicated by the alpn SvcParamKey. If it the alpn SvcParamKey is not provided, but coaptransport is, the transport is unencrypted.Wondering if "udp" or "tcp" should be strings or numeric representations as value. The later would need an extra table or is there something we could reuse, e.g. from ? If the transport's native identifiers are incompatible with that structure (e.g. because they contain colons), the document may define some transformation. If a transport's native identifiers are only local, the zone .alt may be used instead. For example, CoAP over GATT removes the colons from Bluetooth Low Energy MAC addresses like 00:11:22:33:44:55 and combines them into authority compoennts such as 001122334455.ble.arpa. Slipmux might use the locally significant device name /dev/ttyUSB0 as coap://ttyUSB0.dev.alt/. URIs created from such names may not indicate the protocol uniquely: Additional transports specified later may also provide CoAP services for the same name. In the sense of , both transport would be identified by that URI. That is not an issue as long as the protocols underneath the CoAP transport provide a means of advertising the precise protocol used. For example, a hypothetical CoAP transport for BLE that is not GATT based can be selected for the same scheme and authority based on data in the BLE advertisement.

Security considerations

Security context propagation Clients need to strictly enforce the rules of . Failure to do so, in particular using a thusly announced proxy based on a certificate that attests the proxy's name, would allow attackers to circumvent the client's security expectation. When security is terminated at proxies (as is in DTLS and TLS), a third party proxy can usually not satisfy this requirement; these transports are limited to same-host proxies.

Traffic misdirection Accepting arbitrary proxies, even with security context propagation performed properly, would allow attackers to redirect traffic through systems under their control. Not only does that impact availability, it also allows an attacker to observe traffic patterns. This affects both OSCORE and (D)TLS, as neither protect the participants' network addresses. Other than the security context propagation rules, there are no hard and general rules about when an advertised proxy is a suitable candidate. Aspects for consideration are:

• When no direct connection is possible (e.g. because the resource to be accessed is served as coap+tcp and TCP is not implemented in the client, or because the resource's host is available on IPv6 while the client has no default IPv6 route), using a proxy is necessary if complete service disruption is to be avoided. While an adversary can cause such a situation (e.g. by manipulating routing or DNS entries), such an adversary is usually already in a position to observe traffic patterns.
• A proxy advertised by the device hosting the resource to be accessed is less risky to use than one advertised by a third party. The /.well-known/core resource is regarded as a source of authoritative information on the endpoint's CoAP related metadata, and can be queried early in the discovery process, or queried for verification (with filtering applied) after discovery through an RD. Other resources may be less trustworthy as they may be controlled by entities not trusted with the endpoint's traffic.

describes an extension to by which the client can verify that the proxy used by the client is recognized by the server. This is similar to querying /.well-known/core for any proxies advertised there, but happens earlier in the connection establishment, and leaves the decision whether the proxy is legitimate to the server. It only conveys information about the URI of the proxy. The mapping of any host name inside it to an IP address, or of an IP address to a routing decision, is left to the security mechanisms of the respective layers.

Protecting the proxy A widely published statement about a host's availability as a proxy can cause many clients to attempt to use it. This is mitigated in well-behaved clients by observing the rate limits of , and by ceasing attempts to reach a proxy for the Max-Age of received errors. Operators can further limit ill-effects by ensuring that their client systems do not needlessly use proxies advertised in an unsecured way, and by providing own proxies when their clients need them.

IANA considerations

Link Relation Types IANA is asked to add two entries into the Link Relation Type Registry last updated in : New Link Relation types

Relation Name	Description	Reference
has-proxy	The link target can be used as a proxy to reach URIs inside the origin of the link context.	RFCthis
has-unique-proxy	Like has-proxy, and using this proxy implies scheme and host of the target.	RFCthis

Resource Types IANA is asked to add an entry into the "Resource Type (rt=) Link Target Attribute Values" registry under the Constrained RESTful Environments (CoRE) Parameters: [ The RFC Editor is asked to replace any occurrence of CPA-core.proxy with the actually registered attribute value. ] Attribute Value: core.proxy Description: Forward proxying services Reference: [ this document ]

Service Parameter Key (SvcParamKey) IANA is NOT YET requested to add the following entries to the SVCB Service Parameters registry (). The definition of this parameter can be found in .

Number	Name	Meaning
10 (suggested)	coaptransport	CoAP transport protocol
to be assigned	edhoc-cred	EDHOC credentials identifying the server
to be assigned	edhoc-info	EDHOC profile information
to be assigned	oauth-hints	Describes how to obtain a token at an ACE Authorization Server

All entries have in common that their Reference is this this document, }

Underscored and Globally Scoped DNS Node Names IANA is NOT YET requested to add the following entries to the Underscored and Globally Scoped DNS Node Names registry (in the DNS Parameters group) established in and thus enables its use with SVCB records:

• SVCB, _coap, of this document
• SVCB, _coaps, of this document

The request for registration is deliberately not expressed at this point because it is yet to be revisited whether the creation of a "COAP" / "COAPS" RR pair similar to the "HTTPS" RR would be preferable.

References Normative References The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. Informative References W3C n.d. n.d. OMA SpecWorks n.d. Ericsson AB Ericsson AB Ericsson AB This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code size can be kept very low. The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. Universitaet Bremen TZI Lobaro UG Many research and maker platforms for Internet of Things experimentation offer a serial interface. This is often used for programming, diagnostic output, as well as a crude command interface ("AT interface"). Alternatively, it is often used with SLIP (RFC1055) to transfer IP packets only. The present report describes how to use a single serial interface for diagnostics, configuration commands and state readback, as well as packet transfer. Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) instead of in a sequence of characters. This simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –15 of this draft continues -14 by picking up // more comments, such as moving to a CRI scheme number registration // system based on unsigned numbers. This revision still contains // open issues and is intended to serve as a snapshot. This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. A collection of extensions to the Resource Directory [rfc9176] that can stand on their own, and have no clear future in specification yet. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/. Source for this draft and an issue tracker can be found at https://gitlab.com/chrysn/resource-directory-extensions. Acklio Institut MINES TELECOM; IMT Atlantique Universidad de Buenos Aires This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. RISE AB RISE AB Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints, as well as between an application endpoint and an intermediary or between two intermediaries. Thus, this document updates RFC 8613. The same approach can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication with intermediaries is used. This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. TUD Dresden University of Technology HAW Hamburg TUD Dresden University of Technology & Barkhausen Institut This document states problems when designing DNS SVCB records to discover endpoints that communicate over Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. As a consequence of learning about OSCORE, this discovery will allow a host to learn both CoAP servers and DNS over CoAP resolvers that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] for key exchange. Challenges arise because SVCB records are not meant to be used to exchange security contexts, which is required in OSCORE scenarios. RISE AB RISE AB The CoAP protocol was designed with direct connections and proxies in mind. This document defines mechanisms by which chains of proxies can be set up. In combination, they enable the operation of hidden services and client similar to how Tor (The Onion Router) enables it for TCP based protocols. TUD Dresden University of Technology HAW Hamburg TUD Dresden University of Technology & Barkhausen Institut This document specifies the usage of Service Parameters as used in SVCB ("Service Binding") DNS resource records for the discovery of transport-layer-secured CoAP services. Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] Ericsson Ericsson RISE RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth Client and Resource Server, and it binds an authentication credential of the Client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. RISE AB RISE AB The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. This document defines a number of means to coordinate the use and discovery of EDHOC application profiles. Also, it defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Finally, it defines a well-known EDHOC application profile. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. Universität Bremen TZI The Concise Binary Object Representation, CBOR (STD 94, RFC 8949), defines a "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. RFC 8610 extends this into what is known as Extended Diagnostic Notation (EDN). This document sets forth a further step of evolution of EDN, and it is intended to serve as a single reference target in specifications that use EDN. It specifies how to add application-oriented extensions to the diagnostic notation. It then defines two such extensions for text representations of epoch-based date/times and of IP addresses and prefixes (RFC 9164). A few further additions close some gaps in usability. It modifies one extension specified in Appendix G.4 of RFC 8610 to enable further increasing usability. To facilitate tool interoperation, this document specifies a formal ABNF definition for EDN as defined today, and it adds media types. This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document. TUD Dresden University of Technology Huawei Technologies HAW Hamburg TUD Dresden University of Technology & Barkhausen Institut This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known. The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers creating alternative namespaces. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. Thing to thing communication in Constrained RESTful Environments (CoRE) relies on URIs to link to servers. Next to hierarchical configuration and short-lived IP addresses, this document introduces a naming scheme for devices based on cryptographic identifiers. A special purpose domain is reserved for expressing those identifiers, and mechanisms for constrained devices to announce their names and to look them up are described. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK] As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] TUT Ericsson CoAP has been standardised as an application-level REST-based protocol. When multiple transport protocols exist for exchanging CoAP resource representations, this document introduces a way forward for CoAP endpoints as well as intermediaries to agree upon alternate transport and protocol configurations as well as URIs for CoAP messaging. Several mechanisms are proposed: Extending the CoRE Resource Directory with new parameter types, introducing a new CoAP Option with which clients can interact directly with servers without needing the Resource Directory, and finally a new CoRE Link Attribute allowing exposing alternate locations on a per-resource basis.

Change log Since draft-ietf-core-transport-indication-05:

• Semantics for where a has-proxy applies were changed from "wherever there is a hosts relation" to "across the same origin". The hosts relation has received complaints about its complexity, and there were no strong voices in either direction during or after IETF119 when the question has been asked; going for the easier version.
• Use of SVCB is added as a section. Underscore prefixes are registered for CoAP, enabling the use of SVCB DNS records for applications that opt in to it (rather than processing it as an alternative history). While the alternative history section was appreciated during IETF119, the authors found it highly impractical to provide SVCB ground work without having the actual registrations (it would have worked only because DNS discovery acts on a separate _dns prefix anyway), and chose the consistent approach of allowing SVCB lookups.
• Material from the DNS and DNR for CoAP documents was moved in (and overhauled in the process):
  • Constructing CoAP requests from Service Parameters that did not result from a host name lookup is described.
  • The coaptransport SVCB parameter is defined.
  • SVCB hints for ACE/OAuth are defined.
• Section on how a host can tell that Uri-Host is optional was moved from Open Questions into a section. This had been around for ages, and gathering some more experience with the matter, looks like the obvious approach.
• Editorial:
  • Style for unallocated registrations changed from TBD to CPA
  • References updated
  • Tooling updates
  • Minor fixes

Since draft-ietf-core-transport-indication-04:

• Not just the scheme, but also the authority value influences the transport selection.
  • Add guidance section for new transports.
  • Point out that registerd names already can fan out to different addresses.
• Rephrase and simplify security considerations, especially by limiting unique proxying for TLS.
• Add recommendation to new scheme authors to use "coap"/"coaps" and let the resolution process guide the selection.
  • Remove proxy-schemes attribute from core.proxy because of its greatly reduced value.
• Update "Related work" appendix to cover SVCB instead of SRV records
• Rename to "Transport Indication", using "protocol" only for other protocols, in established phrases, or when referring to CoAP as a general protocol.
• Add note linking CoAP-over-WS's .well-known/coap to dohpath
• Remove OSCORE vs. unique-proxy open point
• EDHOC EAD: Describe response option content
• Editorial updates

Since draft-ietf-core-transport-indication-03:

• Added appendices on alternative history and Literals beyond IP addresses. The remaining document was not brought in sync with those new parts.

Since draft-ietf-core-transport-indication-02:

• Added EAD appendix, adjusted security considerations to match.

Since draft-ietf-core-transport-indication-01:

• Simplify same-host proxy behavior by referring to existing RFC7252 mandate.
• proxy-links= lookup: Refer to prior art.

Since draft-ietf-core-transport-indication-00:

• Add section on canonical URIs that are not necessarily reachable.
• Clarify that the the "hosts" relation is followed transitively.
• Cross reference with compatible multicast-notifications concept.

Since draft-amsuess-core-transport-indication-03:

• No changes (merely changing the name after WG adoption)

Since -02 (mainly processing reviews from Marco and Klaus):

• Acknowledge that 'coap://hostname/' is not the proxy but a URI that (in a particular phrasing) is used to stand in for the proxy's address (while it regularly identifies a resurce on the server)
• Security: Referencing traffic misdirection already in the first security block.
• Security: Add (incomplete) considerations for unique-proxy case.
• Narrow down "unique" proxy semantics to those properties used by the client, allowing unique proxies to be co-hosted with forward proxies.
• "Client picked proxies" clarified to merely illustrate how this is compatible with them.
• Use of "hosts" relation sharpened.
• Precision on how this does and does not consider changing transports.
• "Related work" section demoted to appendix.
• Add note on DTLS session resumption.
• Variable renaming.
• Various editorial fixes.

Since -01:

• Removed suggestion for generally trusted proxies; now stating that with (D)TLS, "a third party proxy can usually not satisfy [the security context propagation requirement]".
• State more clearly that valid cache entries for resources aliased through has-unique-proxy can be used.
• Added considerations for Multipath TCP.
• Added concrete suggestion and example for advertisement of general proxies.
• Added concrete suggestion for RD lookup extension that provides proxies.
• Minor editorial and example changes.

Since -00:

• Added introduction
• Added examples
• Added SCHC analogy
• Expanded security considerations
• Added guidance on choice of transport, and canonical addresses
• Added subsection on interaction with a Resource Directory
• Added comparisons with related work, including rdlink and DNS-SD sketches
• Added IANA considerations
• Added section on open questions

Related work and applicability to related fields

On HTTP The mechanisms introduced here are similar to the Alt-Svc header of in that they do not create different application-visible addresses, but provide dispatch through lower transport implementations. In HTTP, different versions of the protocol (i.e., different transports) are distinguished using a protocol identifier equivalent to an ALPN. This works well because all relevant transports use transport layer security and thus can use ALPNs. In contrast, the currently specified CoAP transports predate ALPNs, and specified per-transport schemes, which enable the use of URIs that indicate transports. To accommodate the message size constraints typical of CoRE environments, and accounting for the differences between HTTP headers and CoAP options, information is delivered once at discovery time. Using the has-proxy and has-unique-proxy with HTTP URIs as the context is NOT RECOMMENDED; the HTTP provisions of the Alt-Svc header and ALPN are preferred.

Using DNS DNS Service Binding resource records (SVCB RRs) described in can carry many of the details otherwise negotiated using the proxy relations. In HTTP, they can be used in a way similar to Alt-Svc headers. SVCB records were not specified when CoAP was specified for TCP. If at any point SVCB records for CoAP are defined, name resolution produces a set of transport details that can be used immediately without the need for a has-proxy link. Explicit has-proxy links would still be relevant for third party advertised proxies.

Using names outside regular DNS Names that are resolved through different mechanisms than DNS, or names which are defined within the scope of DNS but have no universally valid answers to A/AAAA requests, can be advertised using the relation types defined here and CoAP discovery. In , a server using a cryptographic name as described in is discovered and used.

Obtaining a sensor value from a local device with a global name ;rel=has-unique-proxy; anchor="coap://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa" Req: to [2001:db8::1]:5683 on TCP Code: GET OSCORE: ... Uri-Path: /sensors/temp Observe: 0 Res: 2.05 Content OSCORE: ... Observe: 0 Payload: 39.1°C ]]>

Multipath TCP When CoAP-over-TCP is used over Multipath TCP and no Uri-Host option is sent, the implicit assumption is that there is aliasing between URIs containing any of the endpoints' addresses. As these are negotiated within MPTCP, this works independently of this document's mechanisms. As long as all the server's addresses are equally reachable, there is no need to advertise multiple addresses that can later be discovered through MPTCP anyway. When advertisements are long-lived and there is no single more stable address, several available addresses can be advertised (independently of whether MPTCP is involved or not). If a client uses an address that is merely a proxy address (and not a unique proxy address), but during MPTCP finds out that the network location being accessed is actually an MPTCP alternative address of the used one, the client MAY forego sending of the Proxy-Scheme and Uri-Path option. [ This follows from multiple addresses being valid for that TCP connection; at some point we may want to say something about what that means for the default value of the Uri-Host option -- maybe something like "has the default value of any of the associated addresses, but the server may only enable MPTCP if there is implicit aliasing between all of them" (similar to OSCORE's statement)? ] [ TBD: Do we need a section analog to this that deals with (D)TLS session resumption in absence of SNI? ]

Open Questions / further ideas

• Advertising under a stable name: If a host wants to advertise its host name rather than its IP address during multicast, how does it best do that? Options, when answering from 2001:db8::1 to a request to ff02::fd are: ,..., ;rel=has-unique-proxy;anchor="coap://myhostname" ]]> which is verbose but formally clear, and ,..., ;rel=has-unique-proxy;anchor="coap://myhostname" ]]> which is compatible with unaware clients, but its correctness with respect to canonical URIs needs to be argued by the client, in this sequence
  • understanding the has-unique-proxy line,
  • understanding that the request that went to 2001:db8::1 was really a Proxy-Scheme/Uri-Host-elided version of a request to coap://myhostname, and then
  • processing any relative reference with this new base in mind.
  (Not that it'd need to happen in software in that sequence, but that's the sequence needed to understand how the /foo here is really coap://myhostname/foo). If CoRAL is used during discovery, a base directive or reverse relation to has-unique-proxy would make this easier.

EDHOC EAD for verifying legitimate proxies This document sketches an extension to that informs the server of the public address the client is using, allowing it to detect undesired reverse proxies. [ This section is immature, and written up as a discussion starting point. Further research into prior art is still necessary. ] The External Authorization Data (EAD) item with name "Proxy CRI", label 24-CPA, is defined for use with messages 1, 2 and 3. A client can set this label in uncritical form, followed by a CRI () that is CBOR-encoded in a byte string as a CBOR sequence. The transport indicated by the URI is the proxy the client chose from information advertised about the server. If a server can not determine its set of legitimate proxies, it ignores the option (as does any EDHOC implementation that is unaware of it). If it recognizes the CRI as belonging to a legitimate proxy, it places the empty label in its non-critical form in the next message to confirm the proxy choice. Otherwise, it places the label in its critical form, either empty or containing a recommended CRI. The client may then decide to discontinue using the proxy, or to use more extensive padding options to sidestep the attack. Both the client and the server may alert their administrators of a possible traffic misdirection.

Literals beyond IP addresses [ This section is placed here preliminarily: After initial review in CoRE, this may be better moved into a separate document aiming for a wider IETF audience. ]

Motivation for new literal-ish names IP literals were part of URIs from the start . Initially, they were equivalent to host names in their expressiveness, save for their inherent difference that the former can be used without a shared resolver, and the latter can be switched to a different network address. This equivalence got lost gradually: Certificates for TLS (its precursor SSL has been available since 1995 ) have only practically been available to host names. The Host header introduced in HTTP 1.1 introduced name based virtual hosting in 1999. DANE , which provides TLS public keys augmenting the or outside of the public key infrastructure, is only available for host names resolved through DNSSEC. SVCB records introduced in 2023 allow starting newer HTTP transports without going through HTTP/1.1 first, enables load balancing, fail-over, and enable Encrypted Client Hello -- again, only for host names resolved through DNS. This document proposes an expression for the host component of a URI that fills that gap. Note that no attempt is yet made to register service.arpa in the .ARPA Zone Management; that name is used only for the purpose of discussion. The structure and even more the syntax used here is highly preliminary. They serves to illustrate that the desired properties can be obtained, and do not claim to be optimal. As one of many aspects, they are missing considerations for normalization and for internationalization.

Structure of service.arpa Names under service.arpa are structured into an optional custom prefix, an ordered list of key-value component pairs, and the common suffix service.arpa. The custom prefix can contain user defined components. The intended use is labelling, and to differentiate services provided by a single host. Any data is allowed within the structure of a URI (ABNF reg-name) and DNS name rules (63 bytes per segment). (While not ever carried by DNS, this upholds the constraints of DNS for names. That decision may be revised later, but is upheld while demonstrating that the desired properties can be obtained). Component pairs consist of a registered component type (no precise registry is proposed at this early point) followed by encoded data. The component type "--" is special in that it concatenates the values to its left and to its right, creating component values that may exceed 63 bytes in length. Initial component types are:

• "6": The value encodes an IPv6 address in format, with the colon character (":") replaced with a dash ("-"). It indicates an address of a host providing the service. If any address information is present, a client SHOULD use that information to access the service.
• "4": The value encodes an IPv4 address in dotted decimal format , with the dot character (".") replaced with a dash ("-"). It indicates an address of a host providing the service.
• "tlsa": The data of a DNS TLSA record encoded in base32 . Depending on the usage, this describes TLS credentials through which the service can be authenticated. If present, a client MUST establish a secure connection, and MUST fail the connection if the TLSA record's requirements are not met.
• "edhoc-cred", "edhoc-info", "oauth-info": SvcbParams in base32 encoding of their wire format.
• "coaptransport": SvcbParam in its text encoding.
• "s": Other Service Parameters that do not have an explicit component type. SvcbParams in base32 encoding of their wire format. TBD: There is likely a transformation of the parameters' presentation format that is compatible with the requirements of the authority component, but this will require some more work on the syntax. If present, a client SHOULD use these hints to establish a connection. TBD: Encoding only the SvcParams and not priorities and targets appears to be the right thing to do for the immediate record, but does not enable load balancing and failover. Further work is required to explore how those can be expressed, and how data pertaining to the target can be expressed, possibly in a nested structure.

Syntax of service.arpa Due to 's rules, all components are case insensitive and canonically lowercase. Note that while using the IPvFuture mechanism of would avoid compatibility issues around the 63 character limit and some of the character restrictions, it would not resolve the larger limitation of case insensitivity.

Processing service.arpa A client accessing a resource under a service.arpa name does not consult DNS, but obtains information equivalent to the results of a DNS query from parsing the name. DNS resolvers should refuse to resolve service.arpa names. (They would have all the information needed to produce sensible results, but operational aspects would need a lot of consideration; future versions of this document may revise this).

Examples TBD: For SvcParams, the examples are inconsistent with the base32 recommendation; they serve to explore the possible alternatives.

• http://s.alpn_h2c.6.2001-db8--1.service.arpa/ -- The server is reachable on 2001:db8::1 using HTTP/2
• https://mail.-.tlsa.amaqckrkfivcukrkfivcukrkfivcukrkfivcukrkfivcukrkfivcukrk.service.arpa/ -- No address information is provided, the client needs to resort to other discovery mechanisms. Any server is eligible to serve the resource if it can present a (possibly self-signed) certificate whose public key SHA256 matches the encoded value. The "mail.-." part is provided to the server as part of the Host header, and can be used for name based virtual hosting.
• coap://coaptransport.tcp.edhoc-cred.ueekcandaeasabbblaqlxq2jmbjg5jgtf2kazljkenaurxocc6i2ckx3zowjgyr.--.ai3ouj4a.6.2001-db8--1.service.arpa/ -- The server is reachable using CoAP over TCP with EDHOC security at 2001:db8::1, and the service is identifiable by the use of a KCCS credential describing an X25519 public key.
• coap://edhoc-cred.ueekcandaeasabbblaqlxq2jmbjg5jgtf2kazljkenaurxocc6i2ckx3zowjgyr.--.ai3ouj4a.service.arpa/ -- The same server without any discoverability hints; it is up to the client to discover a (possibly short-lived) connection opportunities to the server identified by that key.

Acknowledgements This document heavily builds on concepts explored by Bill Silverajan and Mert Ocak in , and together with Ines Robles and Klaus Hartke inside T2TRG. [ TBD: reviewers Marco Klaus ]