Re: [Model-t] Definition of an intermediary

[Joachim Fabini <[e-mail]>]

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




On 23/12/2021 07:53, Martin Thomson wrote:
> 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
>