Message Routing: in layer 2 or in layer 3?

[Willem-de-kok]

I don't know whether the TSP TF is the right place to discuss this @talltree?

Yesterday it was mentioned that, currently, message routing is situated in layer 2 of the ToIP four-layer model.
However, some mentioned that it could maybe also belong to layer 3.

I find it important to know where message routing in the ToIP four-layer model. And, consequently, whether or not the TSP should have message routing in it.

What will it mean for 'real-world' users of the ToIP-stack when message routing is part of layer 3 instead of layer 2? Will messaging then be an optional trust task? [In the Tech Arch (https://trustoverip.github.io/TechArch/) secure messaging is placed in layer 3 as an exemplary trust task.]

Desired responses would be one or more of the below:

• whether or not this is the right place to discuss this (+optionally where else to discuss this)
• confirmation/denial of the current status(/history) of message routing in the ToIP four-layer model.
• arguments why it should be placed in layer 2 or 3, together with consequences for 'real-world' users.

Much appreciated,
Willem

[wenjing]

Message routing is an Intermediary System function in the Tech Arch and not an Endpoint function. It is therefore not in ANY layer of the Endpoint stack - where the Trust Spanning Protocol itself is.

Someone COULD implement it in another host (who implements Intermediary System functions) using a Layer 3 feature/component but that is incidental, not a mandate. That would be one type of message router out of many other possibilities. One way to imagine this type of routers is double envelopers. If one chooses to implement this type of routers, then the routers would be a third-party Endpoints themselves.

Since Intermediary Systems are not in trust dependencies, someone COULD also implement them in any way they like (with or without any so-called ToIP layers). The Trust Spanning Protocol does not dictate how. One example is doing so transparently in a decentralized storage like in DWN.

So in short,

• whether or not this is the right place to discuss this (+optionally where else to discuss this)
  Yes

• confirmation/denial of the current status(/history) of message routing in the ToIP four-layer model.
  The example you cited is one of many - there is no hard exclusive mandate from TSP itself. The ToIP four-layer model requirements are for Endpoints, not Intermediary Systems.

• arguments why it should be placed in layer 2 or 3, together with consequences for 'real-world' users.
  Again, the layers do not apply (in the sense of hard requirement).
  I mentioned two examples - both are from 'real-world' users (or as real as I know and can cite). There are probably other examples.

[jospencer-460]

An interesting discussion. Thanks @Willem-de-kok and @wenjing - my views...

Bullet 1

If I remember @SmithSamuelM 's presentation correctly, there are different types of "routing" that can be done at layers 1 and 3 (if not 2).
Layer 1 - Endpoint routing can be provided by a specific service that identifies whether internal routing is possible or not. If internal routing is possible within the current endpoint solution, it may trigger internal logic to make the outward message look like it has been received from an external source (and then the TSP just hands this back to the appropriate trust task). This scenario may be used for complicated endpoint solutions (or for testing purposes etc.)
Layer 3 - A "gateway" or "router" is more likely to be a specific endpoint or an intermediary system. I make the distinction in that a gateway understands the business logic of the external service (e.g. payment scheme) and the protocol that this needs to support (a specific endpoint solution in our terminology), a router is just that, an intermediary system interested in getting the messages to the correct trust endpoint

As we're all trying to minimise the functionality within layer 2 to the authentic and secure messaging protocol, I'd suggest that routing isn't in layer 2. How you route and access the TSP counterparty endpoint are functions outside of Layer 2.

Bullet 2

Each endpoint solution (application, task, process) has the view of it's counterparty endpoint and the (initial) routing necessary to access / interact with it. It may not know the complete path to the counterparty endpoint, but it knows enough about it to package (send) and interpret (receive) messages to and from the counterparty endpoint.

Bullet 3

My response to Bullet 1 is based on different real-world examples in the payments space.

[dhh1128]

Message routing is an Intermediary System function in the Tech Arch and not an Endpoint function. It is therefore not in ANY layer of the Endpoint stack - where the Trust Spanning Protocol itself is.

I largely agree with @wenjing , but I feel compelled to nuance a little, because I think there's a danger of talking past one another due to imperfect alignment about what we mean by "routing."

If, by "routing", we simply mean the process of moving arbitrary bits from point A to point B (the function of the IP protocol, of Bluetooth, or of other transport mechanisms), then Wenjing's statement is definitely correct.

If, by "routing", we mean a process that is aware of how layers of protection surround a TSP message, and that maps those layers to the DIDs (or VIDs) of participants in an overall scheme to achieve/preserve security guarantees, for various parts of the overall journey from A to B, then I think it's a bit more complicated. Wenjing's statement is still true that "routing" isn't in the stack of an Endpoint, but from there I begin to diverge from him.

If TSP is able to make guarantees about the confidentiality of metadata only because, between Alice and Bob, there exist intermediaries that pseudonimize an opaque herd behind them (that is, the leg of the A->Intermediary=>Intermediary->B route between their two intermediaries uses identifiers other than the private ones by which Alice and Bob identify themselves to one another), then we cannot claim TSP offers confidentiality of metadata without noting that this feature depends on a certain routing strategy. It is not a dumb strategy for bit delivery; it is a smart strategy for wrapped TSP message delivery. Further, the stacks in the endpoints would need to be aware of this strategy, if they intend to use it and they want to reason about any benefits it provides, because it changes their use of identifiers and encryption algorithms in TSP's most primitive data structures (Jo's point to Wenjing's bullet 2). Further, it is not at all clear that Alice and Bob should have a conversation without testing their alignment about whether this behavior will be used. This would make such "confidential routing?" behavior a poor analog to the raw, IP-style "dumb bit transfer routing" that springs to mind for many who are veterans of network protocol design.

Now, please note that the previous paragraph has several conditionals in it. I'm not asserting that these conditionals are necessarily true; I'm asserting that they're undecided. In my mind, we haven't clarified whether confidential routing is an appropriate feature of any part of the stack, for any actors, let alone whether it's something that TSP wants to reference as an optional benefit. As Wenjing said, DWN might provide a kind of "routing" that has different properties from the one I've described. However, on the basis of that lack of clarity, I still feel that the strong statement by Wenjing that "the ToIP four-layer model requirements are for Endpoints, not Intermediary Systems" may be an oversimplification. Theory is one thing, practice another. Requirements bleed over, much as we'd like them not to.

Setting aside that nuance, and supposing that we do want confidential routing or something like it (such as a DWN variant), somewhere, I still agree with Wenjing that the feature I'm talking about isn't best implemented in layer 2. In my proposal, I put it at layer 3. This is where DIDComm has always had it (DIDComm's solution isn't DIDComm proper, but rather an optional protocol implemented atop DIDComm), and I think it's also where Sam would put it. The layer 1 routing that Sam mentioned is clearly a thing, too, but it belongs to the other half of my dichotomy (dumb bit transfer).

So, bottom line:

• right place to discuss? Sure.
• confirmation/denial of the current status(/history) of message routing in the ToIP four-layer model: I agree with Sam that there's layer 1 routing and layer 3 routing, but no layer 2 routing. I think this means I'm also agreeing with @jospencer-460 and Wenjing.
• arguments why it should be placed in layer 2 or 3, together with consequences for 'real-world' users: If we put it in layer 2, layer 2 gets fat. Layer 2 can make more guarantees, but becomes harder to implement. Either DIDComm's confidential routing, or Sam's ESSR mechanism, or DWNs, becomes the way to do this, and the other strategies are marginalized. If we put it in layer 3, all 3 strategies become trust tasks, and can compete in the marketplace of ideas. I am not cheerful about interop with this choice, if all 3 strategies are common; I think it looks possible on paper but in practice it turns out to be abysmal. But that's a whole nuther discussion.

[Willem-de-kok]

Thank you for the above replies.

If, by "routing", we mean a process that is aware of how layers of protection surround a TSP message, and that maps those layers to the DIDs (or VIDs) of participants in an overall scheme to achieve/preserve security guarantees, for various parts of the overall journey from A to B, then I think it's a bit more complicated.

This is what I meant. There are important (metadata) security/confidentiality/privacy aspects to routing that add to/degrade the amount of trust that the ToIP-stack provides. Therefore, I would also diverge a bit from Wenjing's idea that routing does not belong to the ToIP-model.

arguments why it should be placed in layer 2 or 3, together with consequences for 'real-world' users: If we put it in layer 2, layer 2 gets fat. Layer 2 can make more guarantees, but becomes harder to implement. Either DIDComm's confidential routing, or Sam's ESSR mechanism, or DWNs, becomes the way to do this, and the other strategies are marginalized. If we put it in layer 3, all 3 strategies become trust tasks, and can compete in the marketplace of ideas. I am not cheerful about interop with this choice, if all 3 strategies are common; I think it looks possible on paper but in practice it turns out to be abysmal. But that's a whole nuther discussion.

As I think that confidential routing should be an important aspect of the ToIP stack, I would love to have a discussion on this. I think here is an important choice to make in the consolidation phase. Do we want a fatter layer 2 with more guarantees with regards to confidential routing, but which might get harder to implement and has the potential of being less adoptable? Or do we want confidential routing to be a possible trust task, making layer 2 slimmer, and opening up the market place of routing ideas and a whole area of possible interop-conflicts? @talltree is this a topic worth discussing during one of the workshops?

Personally, I haven't yet got a well-founded opinion on where it should belong in the ToIP-stack. However, I have the feeling that since we shift from a client-server dominated transport paradigm to a more transport agnostic paradigm, the role of routing will change. Here are things that are not clear to me.
What are the most important confidential routing aspects that (might) change?
And, what security/privacy aspects arise from having mediators (in order to increase availability)?
How much metadata do mediators see about your communications behavior?