Skip to main content

Using onion routing with CoAP

Document Type Active Internet-Draft (individual)
Authors Christian Amsüss , Marco Tiloca , Rikard Höglund
Last updated 2023-07-17 (Latest revision 2023-07-04)
RFC stream (None)
Intended RFC status (None)
Additional resources GitLab Repository
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
t2trg                                                          C. Amsüss
Intended status: Experimental                                  M. Tiloca
Expires: 5 January 2024                                       R. Höglund
                                                                 RISE AB
                                                             4 July 2023

                     Using onion routing with CoAP


   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.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Thing-to-Thing
   Research Group mailing list (, which is archived at

   Source for this draft and an issue tracker can be found at

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

   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 5 January 2024.

Amsüss, et al.           Expires 5 January 2024                 [Page 1]
Internet-Draft                 Onion CoAP                      July 2023

Copyright Notice

   Copyright (c) 2023 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 (
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Components overview . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Mechanisms  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Client proxy chain  . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Guidance for setting up proxy chains  . . . . . . . .   5
     3.2.  Server proxy chain  . . . . . . . . . . . . . . . . . . .   6
     3.3.  Proxy discovery . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Naming and name resolution  . . . . . . . . . . . . . . .   7
     3.5.  Establishing TLS connections between proxies  . . . . . .   7
     3.6.  Other tricks  . . . . . . . . . . . . . . . . . . . . . .   8
     3.7.  Overhead and optimizations  . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   [ See also abstract. ]

1.1.  Components overview

   This document introduces separate mechanisms that in combination
   enable setups similar to how Tor is used for anonymous web access.
   Some of the mechanisms need no new protocol components, but merely
   describe which existing steps are used to obtain the desired results.

Amsüss, et al.           Expires 5 January 2024                 [Page 2]
Internet-Draft                 Onion CoAP                      July 2023

   *  A client can use EDHOC to establish a unilaterally authenticated
      OSCORE context with proxies (see Section 3.1).

   *  A server can use EDHOC to establish a unilaterally authenticated
      OSCORE context to establish a reverse proxy address (see
      Section 3.2).

   *  A discovery mechanism for proxies (see Section 3.3).

   *  A naming and discovery mechanism for hidden services (see
      Section 3.4).

   Note that these mechanisms should be largely independent: A server
   that does not intend to hide its position can still advertise a
   cryptographic name at its real network coordinates, and thus be
   available both to clients that do hide their location (even if their
   proxies do not work as “exit nodes” in Tor terminology) and to
   clients on a local network.

   Figure 1 illustrates an example topology, and Figure 2 illustrates a
   cross-section of the OSCORE layers along one path.

                        P1                    P2
                        ^ \                  ^ |
                        |  \                /  |
   Client 1 -> P3       |   v      P4      /   |       P5  ---> Server 1
                   \    |    (published as     |      ^
                    \   |     server addr.)    |     /
                     v  |                      |    /
                       P6                      v   /

                            /  Client 2
                        P1          +------>  P2 -----+
                     /              |                 |
                    v               |                 v
                  P3               P4                  P5  ---> Server
                   \                 <--------+
                    \                         |
                     v                        |
                       P6 -------------------> P7
                                             (published as server addr.)

Amsüss, et al.           Expires 5 January 2024                 [Page 3]
Internet-Draft                 Onion CoAP                      July 2023

     Figure 1: Example topology of an onion style CoAP network showing
        two routes in separate graphs.  Note that the hop P4-->P2 is
     present in both chains, and can be pooled into one TLS connection

Client 1       P3    P6    P1    P4    P2    P7    P5       Server 1
                11--- 13--- 16---  ---6  ---4  ---2                              TLS connections
    18------------------------------------------------------                     End-to-end OSCORE
    17---------------------------  ------------------------7
    14---------------------              ------------------5
    12---------------                          ------------3
    10---------                                      ------1

   Figure 2: Cross section of the Client 1 --> Server 1 connection
   of [ TBD reference from label ].  Numbers indicate the sequence
    in which EDHOC is performed, and are placed on the side of the
     initiator.  Not depicted at step 8: Server 1 and/or P4 (TBD)
     publishes P4 as the public address of the hidden service; 9:
   client obtains the list of available proxies. 15: Client 1 looks
   up the introduction point of Server 1 through the proxy chain up
                        to P1 to discover P4.

2.  Conventions and Definitions

   The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
   “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.

3.  Mechanisms

3.1.  Client proxy chain

   A client can pick one or more proxies to hide its position in the

   Without OSCORE proxies, only one proxy hop can be chosen, because the
   CoAP requests contains at most two addresses: The address in the IP
   header, and the address in the Uri-Host option.  With the mechanisms
   introduced in [I-D.tiloca-core-oscore-capable-proxies], CoAP request
   can contain a Uri-Host option in each layer of OSCORE, effectively
   building a source routing chain.

Amsüss, et al.           Expires 5 January 2024                 [Page 4]
Internet-Draft                 Onion CoAP                      July 2023

   To build the chain, the client first chooses its first proxy hop, and
   runs EDHOC to establish an OSCORE context.  In this process, the
   proxy authenticates with its long-term credentials, whereas the
   client uses an ephemeral key (a plain CWT Cliams Set, [RFC8392]).
   The process can take as little as one round-trip per proxy; when
   message 3 of EDHOC is sent along with the OSCORE message (see
   [I-D.ietf-core-oscore-edhoc]) that contains the next hop’s message 1,

   Once one proxy context is established, EDHOC can be run through that
   proxy with the next proxy, until a chain of sufficient length has
   been established.  Care has to be taken to never use one of the later
   proxies with any chain other than the chain through which the
   connection was established, for otherwise the client can be
   deanonymized mor easily.

   When forwarding messages, every forward proxy strips off a layer of
   OSCORE from the request, and adds one to the response.

   Possible optimizations:

   *  Can EDHOC be run without transmitting two public keys (G_X and
      G_I) for the client?  (I.e., Can G_X be re-used as G_I without
      harm to EDHOC (likely not), and how would that be communicated?)

   *  For hops that are only ever used with a single next-hop, as is
      typical with all but the first proxy (see guidance below): Can
      default values for Proxy-Scheme and Uri-Host be communicated
      during EDHOC, values that would later be elided?  Otherwise, every
      request would contain explicit addresses of the full chain.  If
      taken to the extreme, this might be setting up a SCHC context that
      also compresses parts of the OSCORE option, where the client tells
      each proxy what the KID used with the next proxy is, and uses the
      same sender sequence number for the hops.  (This has own security
      considerations; might be necessary to apply offsets, at which
      point it gets overly complex).

      Effectively, setting a default value for Proxy-Scheme and Uri-Host
      makes that (originally forward) proxy a reverse proxy.

3.1.1.  Guidance for setting up proxy chains

   TBD: This section should contain guidance distilled from Tor
   operations.  In particular, it might recommend that a client pick one
   proxy hop as a long-term first hop, while building the remaining
   chain individually for each new origin server.

Amsüss, et al.           Expires 5 January 2024                 [Page 5]
Internet-Draft                 Onion CoAP                      July 2023

   Following common tor practice, it is expected that typical chain
   lengths are around 3 hops.  Note that the amount of processing on the
   peer side is independent of the length of the chain chosen by a host.
   If a client deems a one-hop setup sufficient and only has resources
   for maintaining one extra OSCORE context, it can still use a server
   that is hidden behind a 3 long proxy chain.

3.2.  Server proxy chain

   A server can pick one or more proxies to hide its position in the

   Unlike forward proxies, which are configured per request, this
   requires a dedicated mechanism.

   TBD: This document does not yet specify such a mechanism, but may
   draw upon the reverse proxy request of Section 2 of

   When forwarding messages, every reverse proxy adds a layer of OSCORE
   to the request, and removes one from the response.

3.3.  Proxy discovery

   A mechanism for discovering forward proxies is already described in
   [I-D.ietf-core-transport-indication]; discovery of reverse proxies
   suitable for servers will depend on the precise mechanism used.

   Both proxies’ discovery process may need to be augmented with
   metadata that indicates whether the proxy is willing to proxy to
   arbitrary locations on the Internet, or merely to hidden peers.  That
   distinction in forwrd proxies would be similar to how Tor
   distinguishes relay and exit nodes.  In reverse proxies, there is an
   analogous distinction that is not so much based on policy but rather
   on the structure of the authority component used by that reverse
   proxy: If the name is resolvable on regular CoAP stacks (i.e., DNS
   can resolve it to a global IP address), then regular CoAP clients can
   use the introduction address as an entry point.  It is still up to
   the hidden server’s policy to decide whether to allow access that is
   merely protected by the chain of hidden proxies, but not end-to-end.
   Note that the server will be unable to tell whether the client used
   just one layer of EDHOC and OSCORE to reach the introduction point,
   or has built its own client chain -- the former is merely a client
   proxy chain of zero length.

Amsüss, et al.           Expires 5 January 2024                 [Page 6]
Internet-Draft                 Onion CoAP                      July 2023

   Along with discovering the addresses of proxies, a well-maintained
   Tor-like network would provide authentication information for them.
   This would allow participants to trust that the proxy chain they are
   building is not all controlled by a single entity, but have been
   around independently for some time.

   TBD: Such a service is not specified yet.

3.4.  Naming and name resolution

   The mechanisms discussed in [I-D.amsuess-t2trg-rdlink] can be used by
   hidden services to come up with names for their services.  (That
   document will need to be updated to use mechanisms from
   [I-D.ietf-core-transport-indication]).  Unlike described there, they
   would not enter their network address into the distributed directory,
   but the address of their most remote reverse proxy (the introduction

   Along with the service’s public key (that is announced as part of the
   name), the published record may also include the public key of the
   introduction point, as that will allow the client to establish an
   extra layer with the introduction point.  TBD: The benefits of this
   layer are yet unclear, as is whether this needs to be a layer of
   OSCORE, or whether the mechanisms of [I-D.selander-lake-authz] could
   be used to roll that into the end-to-end establishment.  (Likely, an
   extra layer is needed, for even if that mechanism is used for some
   kind of encrypted origin indication, the later OSOCRE phase will need
   some origin indication at the introduction point to distinguish
   multiple hidden services behind the introduction point in such a way
   that an observer of the introduction’s ingress point can not tell
   which services are being used).

3.5.  Establishing TLS connections between proxies

   Proxy-to-proxy requests, which are the majority of transmitted
   request, are transmitted between unconstrained devices across the
   Internet.  As such, protecting those connections with an extra layer
   of TLS (as specified in [RFC8323]) is desirable, because

   *  it profits from TCP's flow control,

   *  it hides more request metadata (even though none of the metadata
      visible at this point should be linkable to the server or the
      client, with the exception of message length), and

Amsüss, et al.           Expires 5 January 2024                 [Page 7]
Internet-Draft                 Onion CoAP                      July 2023

   *  it allows requests to be mixed across MTU and thus to hide their
      length and number (provided there is sufficient traffic on the
      link to ensure that multiple messages are processed within one
      Nagle interval).

   [ TBD: Explore whether coercing traffic through specific pairs of
   nodes instead of random node pairings would make sense.  If it is
   dangerous, maybe servers might pair up on their own to ensure that it
   is hard to monitor their ingress and egress traffic for correlation.

   A challenge in establishing TLS connections on that link is that
   proxies are advertised with EDHOC credentials in the network’s
   discovery area.  The tools of [I-D.tschofenig-tls-cwt] may help
   bridging that gap.

3.6.  Other tricks

   TBD.  Current ideas:

   *  For increased privacy, it may make sense to spool requests and
      responses in proxies for "as long as practical".  Those setting up
      the proxy may indicate that in the security context.  While it
      increases the proxy's memory requirements a lot to keep several
      seconds of traffic around, it is not expected that these proxies
      will be operating at network capacity limits.

   *  Add chatter between proxies.  With the stark contrast between
      constrained device bandwidths and Internet bandwidths, this can be

   *  Access point assistance: While all of this is aimed at constrained
      devices as defined in [RFC7228], devices of Class 1 may not be
      capable of using the full proxy discovery service or setting up
      security contexts with all the hops in the chain.  Instead, they
      may only provide end-to-end encryption, and use a service provided
      by a local node (e.g. the border router in a 6LoWPAN network
      [RFC8138]) to set up the hops.  Such a setup can also be used to
      defer policy decisions to the network, which may decide to
      advertise its own address as an introduction point, or use a
      suitable length of reverse proxies.

   *  The introduction point would be the only suitable location to
      place a caching proxy when [I-D.amsuess-core-cachable-oscore] is
      used.  As the server is be aware that cacheable OSCORE is used, it
      can select a reverse proxy that was advertised with caching
      capabilities (with that metadatum still TBD).

Amsüss, et al.           Expires 5 January 2024                 [Page 8]
Internet-Draft                 Onion CoAP                      July 2023

3.7.  Overhead and optimizations

   TBD.  Main points:

   *  Establishing a default Uri-Host likely gives most savings.

   *  For intermediate hops, using a shorter AEAD tag might be an

4.  Security Considerations

   *  When using proxy chains, only contact a proxy through the one
      chain it is set up with, and only accept messages into a context
      if they were transported in the hop they are expected to be
      received from.

      It is of utmost importance to not have observably different
      behavior between messages with an unknown context and messages
      whose context is known but not expected at this point.  For
      example, if an attacker controls a server’s introduction point and
      intends to deanonymize clients, it may attempt to send responses
      directly to the suspected address of the client.

      In implementations, this can be mitigated by first looking up the
      list of contexts depending on the outer layer, and then looking up
      inside that list whether the security context is known and the
      message expected.

   *  What are the effects of sequence numbers on correlation?  Is it
      good or bad to use the same sequence number for all hops in a

5.  IANA Considerations


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

Amsüss, et al.           Expires 5 January 2024                 [Page 9]
Internet-Draft                 Onion CoAP                      July 2023

6.2.  Informative References

              Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in
              Progress, Internet-Draft, draft-amsuess-core-cachable-
              oscore-06, 11 January 2023,

              Amsüss, C., "CoRE Resource Directory Extensions", Work in
              Progress, Internet-Draft, draft-amsuess-core-resource-
              directory-extensions-08, 13 March 2023,

              Amsüss, C., "rdlink: Robust distributed links to
              constrained devices", Work in Progress, Internet-Draft,
              draft-amsuess-t2trg-rdlink-01, 23 September 2019,

              Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
              G. Selander, "Using EDHOC with CoAP and OSCORE", Work in
              Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-07,
              13 March 2023, <

              Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
              and J. Park, "Group Object Security for Constrained
              RESTful Environments (Group OSCORE)", Work in Progress,
              Internet-Draft, draft-ietf-core-oscore-groupcomm-18, 22
              June 2023, <

              Amsüss, C., "CoAP Protocol Indication", Work in Progress,
              Internet-Draft, draft-ietf-core-transport-indication-02,
              13 March 2023, <

Amsüss, et al.           Expires 5 January 2024                [Page 10]
Internet-Draft                 Onion CoAP                      July 2023

              Selander, G., Mattsson, J. P., and F. Palombini,
              "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
              Progress, Internet-Draft, draft-ietf-lake-edhoc-19, 3
              February 2023, <

              Selander, G., Mattsson, J. P., Vučinić, M., Richardson,
              M., and A. Schellenbaum, "Lightweight Authorization for
              EDHOC", Work in Progress, Internet-Draft, draft-selander-
              lake-authz-02, 21 April 2023,

              Tiloca, M. and R. Höglund, "OSCORE-capable Proxies", Work
              in Progress, Internet-Draft, draft-tiloca-core-oscore-
              capable-proxies-06, 5 April 2023,

              Tiloca, M. and R. Höglund, "OSCORE-capable Proxies", Work
              in Progress, Internet-Draft, draft-tiloca-core-oscore-
              capable-proxies-06, 5 April 2023,

              Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
              (CWTs) in Transport Layer Security (TLS) and Datagram
              Transport Layer Security (DTLS)", Work in Progress,
              Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <>.

Amsüss, et al.           Expires 5 January 2024                [Page 11]
Internet-Draft                 Onion CoAP                      July 2023

   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <>.

Appendix A.  Change log

   Since -00:

   *  Shaped into separate sections on the bits and pieces involved.

   *  Added illustrations.

   *  Moved all points from the previous notes in with the new text.

   Since [I-D.tiloca-core-oscore-capable-proxies-06]:

   *  The main body of the text was moved here and will be absent from
      the -07 version of that document.

   *  An abstract was added.



Authors' Addresses

   Christian Amsüss

   Marco Tiloca
   Isafjordsgatan 22
   SE-16440 Kista

Amsüss, et al.           Expires 5 January 2024                [Page 12]
Internet-Draft                 Onion CoAP                      July 2023

   Rikard Höglund
   Isafjordsgatan 22
   SE-16440 Kista

Amsüss, et al.           Expires 5 January 2024                [Page 13]