[Model-t] Review of draft-thomson-tmi

[Jari Arkko <[e-mail]>]

Hi,

I wanted to review this draft in preparation for tomorrow’s call. (Hopefully we will also have others doing the same on this and other drafts!)

Summary

This document (https://datatracker.ietf.org/doc/html/draft-thomson-tmi-02 <https://datatracker.ietf.org/doc/html/draft-thomson-tmi-02>) discusses the roles of endpoints vs. intermediaries, using a pretty broad definition of intermediaries, which could be anything from a cache to a DNS service to even just a router. The document argues that the intermediaries are a necessary and useful part of the Internet. Indeed, if there were no functions whatsoever in the network, there’d be no network at all. But there are tensions when the interests of the endpoints are not aligned with the interests of the intermediaries, and when for instance an intermediary does more than the endpoints wish it to do. The document proposes three principles around ensuring proper use of intermediaries, on avoiding intermediation, limiting who can be an intermediary, and limiting what the intermediaries are allowed to do.

Relevance

The document addresses a topic where there is often some tension between different interests and systems, as evidenced by various discussions on network functions interacting with end-to-end encryption, the role of various helper functions and how much information one wants to give them (DNS, various relays), or the discussions on application - network path signalling and information exchanges.

It is perhaps not the only* topic of interest to model-t type discussions, but it is interesting and relevant. 

*) Specifically, I think model-t should also think about the you-may-not-entirely-trust-your-endpoint issue, because that is a new and increasingly pressing issue. Of course that is not the only thing to focus on either.

Contribution

The overall question of tensions between endpoints and other parts of the system has of course been a long-standing topic. This document does not go beyond that particular topic, but focuses on a particular class endpoint vs. others, namely on how to interact with services that are not part of the endpoints but which are still beneficial for some purpose (forwarding, name resolution, etc.) It proposes a useful framework of three principles to guide future designs.

Detailed comments

Principles — in general, these seem spot on, and adequately described.

Definition of an intermediary (Section 2) — I think this is a simple definition, but I found the DNS example confusing. The draft talks about how DNS in general is not an intermediary, because it doesn’t actually intermediate communication. But yet the definition actually said “facilitate communications” which could include things like name resolution? Yet the draft says that recursive resolvers are intermediaries. Maybe I’m missing something, or perhaps some sharpening of the definitions is needed. Intuitively, my ISP’s or Google recursive resolver sits process-wise between me and my communications to a destination; and I’d like to limit what info I give them. So it feels like an intermediary, as the draft does say as well. But what’s the distinction then to, say, a root server, or the authoritative DNS server for the domain?

Intermediation is essential (Section 3) — good! Good examples.

Intermediation is useful (Section 4) — also good. Perhaps this section could also talk about the different ends of the scale. As the section says, individuals do not have scaling benefits than e.g. an ISP or CDN operator has, which has benefits for attack defence. But on the other end of the scale, resilience suffers if we attempt to aggregate everything to a single intermediary service. Aggreagion is useful to a point.

Intermediary enables scaling of control (Section 5) — agreed. Of course there’s similar arguments about endpoints, such as your favourite service or software. But that is perhaps a topic for some other work in the model-t space.

Incentive misalignment (Section 6) — yes.

Forced and unwanted (Section 7) — Agreed. But here it might be useful to discuss also a bit more about the types of forcing that are possible. There seems to be two eras, one where due to lack of encryption various kinds of “I’m on the path” devices were able to become intermediaries. What’s left when we move to the all-encrypted world? Would you consider intermediary services chosen by an app as forced? What about software limitations on your device that force you to the kind of intermediation that you’d rather not have (e.g., sending cleartext email through a server) but have no choice to avoid? Also, perhaps as a general point it might be useful to discuss more examples from the application level intermediaries in the document. I think you’d have plenty of messaging and email examples to use, Martin.

Contention (Section 8) — I wonder if there was a more clear conclusion from the SRv6 example — I do agree that some network tricks really are about tunnelling, in some cases using a particular way to encode the tunnel bits. But is tunnelling in general intermediation? Or harmful? Or only if it modifies (even temporarily) the packet? 

Services over intermediation (Section 9.1) — this leads me to back to the definition. Is an intermediary only an intermediary if the all communications flow through it? What if some information flows to it, but not all? Is it an intermediary if it can make a decision about something, like whether I can connect to example.com <http://example.com/>? Perhaps a different way to phrase the Section 9.1 principle is to focus on the information and modularity, not whether we call a thing service or intermediary. If I have a need for a function, I’d like that function to learn the minimal amount of information from what else I’m doing. I ask someone to perform that function, I get an answer, and then I go on my business to continue whatever else I may need to do. Not that I handle everything via that something which both sees my traffic while performing whatever small function I needed.

Your discussion of avoiding the intermediaries to become participants is spot on. This is also a benefit of the service model (or the limited-data-limited-function model): when I contact a service to perform a simple task, the rest of my communication partners don’t have to know about that and don’t have to prepare for N-way negotiation or error cases.

Deliberate selection (Section 9.2) — nice extension of the 8558 principle!

Limit capabilities (Section 9.3) — Good. There seems to be also some relationship to the Section 9.1 principle in terms of limiting the function/service to the minimal, modular function.

Conclusion

Thanks for interesting and useful work! I think this should somehow proceed towards an IAB RFC, although perhaps some further discussions/changes might be useful.

Jari