Tunneling as a mechanism in stack design to accomodate corner conditions without complicating layers

[SmithSamuelM]

One of the things that is common practice with the IP protocol stack is to create IP tunnels. A tunnel essentially hides another protocol's packet inside an IP packet in order to leverage the broad support of the internet and internet routing. Often is easier and cheaper and faster to deploy a system with a pair of IP tunneling router over pre-existing IP infrastructure than to install the infrastructure that is specific to the protocol needed for the end-user application. I had a company that manufactured tunneling routers for IoT and I was chair of the WG for the ANSI/EIA 852 IP tunneling protocol.

In ISO OSI protocol stack designs tunneling can be very hard to accomplish because of the rigidity of the layering and the lack of a true spanning layer. But with a true spanning layer with any number of branching lightweight layers above, a tunneling design can usually find in the IP stack a good starting point that is easy to design towards.

The advantage of a tunnel is that if there is a type of service that is not well supported by the IP stack itself then one can leverage the IP infrastructure which is fairly universal for routing packets to distributed locations and then only have to install infrastructrure that supports the application specific protocol in the end locations. This reduces overall system costs while better enabling applications specific features. Global routing infrastructure is expensive and unless you are a well funded telecom company you are not going to lay miles of communications lines globally in order to connect two endpoints just because IP doesn't provide the exact service features you need at the end applications. Either you figure out that you can tunnel or its a no go.

So in trusted protocol design what is the analog of tunneling. Well tunneling is leveraging existing infrastructure in way that expands the application layer feature set without requiring the existing infra-structure to support that feature set.

One relevant infrastructure to trust protocols is cryptography. Different cryptographic algorithm clases require different libraries and other support infrastructure. Trying to design a trust protocol that supports today all the anticipated cryptographic algorthim classes can greatly complicate the design and slow adoption especially if many of the algorithm classes are only needed for corner cases. So a solution would be to tunnel information that leverages other cryptographic infrastructure inside Trust Protocol packets.

Things like onion routing can be viewed as a type of tunneling because the onion routers are all sitting at the application layer of the IP stack (they are not IP routers using ICMP) So we can provide both future flexiblity and immediate simplicity (usually they are a trade-off) by enabling tunneling with simple enough spanning layer.

[SmithSamuelM]

IP itself is tunneled through other protocols in the support of the IP layer. In this very strong sense protocol tunneling is the super power of IP. The weakness of the IP layer makes it easy to tunnel IP packets over other protocols and channels. The MAC address header used by Ethernet and WIFI protocols is used to wrap the IP packet as a MAC payload so that IP is tunneled over Ethernet or WiFI. The PPP protoco tunnelsl IP packets over a modem, which might be first tunneled via DSL and then the phone line. Or tunneled over a fiber link.

One can find support for IP tunnels over
USB
Bluetooth
NFC
FireWire
Thunderbolt

And various other more obscure protocols.

This ease of tunneling IP over other channels and protocols maximizes the support to the IP layer and thereby maximizes adoptability. A thicker layer would tend to make tunneling harder to implement and therefore reduce the support leading to less adoptablity.

What does this mean for a Trust spanning layer. We want the layer to be thin enough that tunneling over other protocols is easy so that the support and hence adoptability is maximized.

So when there is a platform or infrastructure out there that moves packets we can think of ways to tunnel TSP messages through that infrastructure.

Examples

Tunneling TSP mesage through a given DID method infrastructure
Tunneling a TSp message over HTTPS
Tunneling a TSP Message over email
Tunneling a TSP Message over some chat protocol
etc.

The adapter layers (think ARP for MAC ethernet/wifi that sits below IP) that sit below the TSP are crucial thin layers below TSP that enable more adoptability.

We we talk about different types of trust we can think of the analogy to IP where different types of trust may correspond to different infra-structure that we are tunneling the strong authentication trust of the TSP. We can form channels that are weaker for trust and still tunnel TSP so that the endpoint at the other end of the tunnel gets the strong trust over a trustless or weaker trust channel.

The same applies to other properties besides authenticity, like confidentiality (encryption) and privacy. Some channels through which we tunnel TSP messages might provide different degrees of confidentiality or privacy in addition to the the authenticity. But the correct placement for these channels is in the support of TSP because we are tunneling through them. A service that sits above the TSP is leveraging the properties of the TSP directly not being tunneled through.

[dhh1128]

+100

This is essentially the same thinking as DIDComm's narrative about transport independence. How we move bits is so varied that we can't afford to lock ourselves into one method. And we don't have to, if the concept that we're trying to move boils down to a self-contained bag of bits. As Sam says, the work to adapt to new movement patterns has already been done. Or it could be done easily, at a minimum.

It's when that bag of bits requires special headers to be set in transport 1 but not in transport 2, or when it only has certain security properties if it moves over transport 3, that we get into trouble.

[SmithSamuelM]

When I used to do lots of IoT development and testing I would have 10 or more IP interfaces on my computer. When I had an applications that wanted to use a given channel with a given channel’s properties the configuration of the IP interface took care of that for me and I simple sent the packet to the corresponding interface. The IP adapter to the channel was usually provided by a vendor who had a stake in supporting that traffic and they provided the channel configuration interface for me. So really low adoption barrier.

In contrast when I wanted to. tunnel something special over IP so that it had properties that no off-the-shelf channel already had then I had to write my own tunnel with all the configuration for it. So we want to give space for both approaches because both have advantages and free infrastructure is hard to argue with except when it doesn’t do exactly what you need, then you can decide if you want to pay the cost of adding layers above to provide the ncessary features of a channel created as a tunnel from above instead of leveraging existing support by tunneling through a channel created below.

[SmithSamuelM]

HTTP Web centric design often loses the layering because the body of an HTTP packet as document as key value store means I can just about put anything anywhere in that document and it still works at least on ReST based APIs. I can make all kinds of functional layer violations without it costing me much because well its just a key/value store. But I can’t tunnel this way. tunneling requires wrapping so at the very least if I am using key value mappings they have to be carefully nested and isolated not mixed up together at the top level of the document. Proper tunneling requires that payloads must be opaque to their encapsulating protocol. Then I can tunnel through a tunnel through a tunnel etc. I can also tunnel through a stream but I need framing headers that isolate properly so that payloads remain opaque no matter how they are transported.

Indeed when the nesting is rigidly followed then I can enforce it explicity by replacing a nested block (map) as payload with a hash of its serialization and then either attach the contents or transmit them out of band or via a caching store and forward mechanism. Which by itself provides an alternate channel with alternate channel properties for privacy, confidentiality, availability and durability that the in band protocol does not have to provide.

And this hash hoisting of contents to provide alternate channels for the hashed contents works for any nestable serialized data structure not merely key value stores like JSON

[SmithSamuelM]

What I have found is resistance from DID method infrastructure adherents to being leveraged for tunneling. Each DID Method as a platform wants to be the network and doesn't want to merely be a network to be tunneled through. But spanning layer interoperability in its support is largely tunnels through other infrastructure. The IP layer simply as an address made tunneling easy.

One reason KERI AIDs are namespace agnostic is so that they can be tunneled more easily because if you squint hard enough all protocol headers look like namespaces for their payloads. And if a protocol is being tunneled through another protocol with stacked headers, the stack of headers looks like a nested namespace.