Subject: [Model-t] Definition of an intermediary

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Dec 2021 17:53:51 +1100

One of the pieces of feedback on the -tmi draft was related to how it defines intermediary.

I want to explore that a little more, because I think that this is important.

The definition I have now concentrates on entities whose participation in the protocol is primarily the receipt and forwarding of messages from others, rather than the origination or termination of messages.

This was always my intent, but it's hard to get this right.  The more you dig into this, the harder it gets.  

Firstly, there are functions that require that an intermediary terminate or originate communication in ways that are more sophisticated than mere forwarding.  And these are, often, the most useful and interesting functions.

Does a video conference bridge that drops video from someone to save bandwidth act as an endpoint when it throws that data away?  Is a DNS recursive resolver or CDN node that serves from cache doing more than intermediate?  Maybe those can be viewed as simple time-shifting, so they still fit the basic definition.  However, is my mail provider doing more than intermediate when it provides me with a search function over my inbox?

Second, the potential for an intermediary to modify messages is often key to the operation of a protocol.  When does that modification turn the intermediary into a full participant?  A SIP B2BUA is often cast as a full protocol participant, which is certainly true from the perspective of how the protocol is engineered, but in the abstract it is indistinguishable from an intermediary, even if it doesn't strictly adhere to the SIP definition of a proxy.

Third, the nature of some protocols is that they mix communication with intermediaries with end-to-end messages.  SIP, SMTP, and HTTP share lineage and so all suffer from this to varying degrees.  My sense is that this is largely OK and that we can rely on some interpretation of intent to clear things up, though we might need to recognize that we might end up disagreeing on the specifics.

Are there other wrinkles that I've failed to identify?

I've started iterating on a definition here: https://github.com/martinthomson/tmi/pull/5

---

From: Joachim Fabini <[email-masked]>
Date: Thu, 23 Dec 2021 09:59:13 +0100

Hi Martin,

your informal description imho summarizes the main aspects of an
intermediary that have been of relevance to the model-t discussion so far.

As a more formal attempt (is there a need for such) I'd term an
intermediate (in the context of model-t) a system I that:
1. Is located on the commmunication path between two endpoints E1 and
E2, I != E1 and I != E2. I.e., intermediate I can access (r and/or w)
data exchanged between E1 and E2 at one or more protocol layers.
2. Stores state of E1, E2, and/or of the communication between E1 and E2
at various protocol layers.
3. Optionally modifies the communication between E1 and E2, acting as a
proxy (on various protocol layers) on behalf of E1 and/or E2 in their
supposed end-to-end communication. I.e., E1 observes the aggregated
behavior of I and E2, potentially
3a. not being aware of the presence of I at all and
3b. not being able to tell apart the contributions/modifications of I and E2

Additional observations:
- Wrt 3: The observation is valid the other way round, too: E2 may
experience the aggregated behavior of E1 and I without being able to
tell apart who contributed what - this can range from 100% I and 0% E1
(like in the case of a B2BUA) to 0% I and 100% E1 (case in which I is a
passive listener).
- Wrt 3: The observation is valid at any protocol layer
- Wrt 1: one may consider subpaths, too (e.g., load balancing, MPTCP,
SCTP, ... - I may be located on a subpath that does not transfer all of
the information).
- Wrt. 1: there may be multiple endpoints involved - thinking of the
multicast case.
- Wrt 3: the definitions above are supposed to capture both,
modifications in the value domain (changes, drops, additions at various
protocol layers), as well as in the timing domain (buffering, delay). My
personal background is covert and subliminal communication, so the
timing should be part of the state, too.

Essential is (again, imho) the observation that an endpoint E1 (or even
an external observer on the path between I and E1) can not tell apart
the contributions of E2 and I (in terms of value or timing domain,
protocol headers and protocol payload) - nor can it assess the
session/endpoint state stored by I.

regards
Joachim

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 23 Dec 2021 15:57:55 +0100 (CET)

> Il 23/12/2021 07:53 Martin Thomson <[email-masked]> ha scritto:
> 

Well, to me the definition of "intermediary" is much simpler - anything sitting between the fingers of the sending human being and the eyes of the receiving human being (or of the single human being involved, in human-to-server communication) is an intermediary. This definition may not be very useful if you want to design communication protocols in isolation from what will be happening within the protocol endpoints, but IMHO is the only valid one if you want to correctly assess the impacts on security, privacy and other rights for the end-users.

(I'd actually like to document the above view in a draft sooner or later, as a contribution to the debate)

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 23 Dec 2021 17:20:27 +0100

On 2021-12-23, at 15:57, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> 
> between the fingers of the sending human being and the eyes of the receiving human being (or of the single human being involved, in human-to-server communication) is an intermediary. 

… which demonstrates that the term intermediary is always relative to a perspective.

There are other aspects — we often talk about an intermediary if it does non-standard (or non-standardized) processing, so it can get in the way of the endpoints trying to communicate.  More generally, anything that violates, or is in addition to, the commonly agreed basic architecture.

Very important for me is whether 0, 1, or 2 endpoints agreed to go through this intermediary (or even had the initiative to ask for or select the intermediary).

Grüße, Carsten

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 24 Dec 2021 10:46:00 +1100

Hi Joachim,

I wasn't looking for quite that level of formality, but it is helpful to frame it that way.  I think that your general structure and observations are mostly right.

> session/endpoint state stored by I.

This sounds good to me.  Apart from this "cannot tell apart" notion.  You had it more accurately above where you say "may".  What E2 (or En) sees via an intermediary might be authenticated in the protocol and therefore not subject to that sort of spoofing.

Of course, very few old protocols put in the work to make these functions clear.  Even the new ones aren't uniformly precise about it.  QUIC accepts signals from the path like ECN and ICMP and is able to authenticate them (partly), but isn't able to distinguish where they come from.

Your note about the timing is a particularly good one.  Timing of delivery is almost always under intermediary control.  See also replay.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 24 Dec 2021 10:56:52 +1100

On Fri, Dec 24, 2021, at 03:20, Carsten Bormann wrote:
> On 2021-12-23, at 15:57, Vittorio Bertola 
> <vittorio.bertola=[email-masked]> wrote:
>> 

This is the key observation, I think.  If we're to make contributions that are of use to protocol designers, then we need to think about perspectives other than the human one.  Once the effect on the true end-to-end system of communication between people has been duly considered, there might be work to do.  Engagement at an appropriate level allows us to provide concrete and actionable guidance.

> Very important for me is whether 0, 1, or 2 endpoints agreed to go 
> through this intermediary (or even had the initiative to ask for or 
> select the intermediary).

0, 1, or N :)

I generally agree here, though when you say "agreed", that gets interesting very quickly.  The notion of consent has some real limitations here.  Part of what I'm talking about in the draft is ensuring that these interjections by intermediaries are deliberate, that participants are identified, and the extent of their capabilities understood.  That is all in service of a more comprehensible and robust system.