Subject: [arch-d] Fwd: [IAB] I-D Action: draft-iab-path-signals-collaboration-00.txt

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 17 Mar 2022 14:27:55 +0100

Hi all,

Just a quick update to this list: We revised the draft last week based on the feedback we got. Thanks again everybody for the input!

The diff is quite big as we also did a bit of re-org and clean-up but I believe we addressed all comments and also hopefully managed to makes things more clear.

Additional feedback and reviews are as aways welcome!

Mirja

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: [IAB] I-D Action: draft-iab-path-signals-collaboration-00.txt
> Date: 7. March 2022 at 14:05:04 CET
> To: <[email-masked]>
> Cc: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Internet Architecture Board IETF of the IETF.
> 
>        Title           : Considerations on Application - Network Collaboration Using Path Signals
>        Authors         : Jari Arkko
>                          Ted Hardie
>                          Tommy Pauly
>                          Mirja Kühlewind
> 	Filename        : draft-iab-path-signals-collaboration-00.txt
> 	Pages           : 15
> 	Date            : 2022-03-07
> 
> Abstract:
>   This document discusses principles for designing mechanisms that use
>   or provide path signals, and calls for standards action in specific
>   valuable cases.  RFC 8558 describes path signals as messages to or
>   from on-path elements, and points out that visible information will
>   be used whether it is intended as a signal or not.  The principles in
>   this document are intended as guidance for the design of explicit
>   path signals, which are encouraged to be authenticated and include a
>   minimal set of parties and minimize information sharing.  These
>   principles can be achieved through mechanisms like encryption of
>   information and establishing trust relationships between entities on
>   a path.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-iab-path-signals-collaboration/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-iab-path-signals-collaboration-00
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Mar 2022 11:10:52 +1100

Hi IAB et al,

I think the draft gets to the core of the issue here:

> The goal of improving privacy and trust on the Internet does not necessarily need to remove the ability for network elements to perform beneficial functions. We should instead improve the way that these functions are achieved and design new protocols to support explicit collaboration where it is seen as beneficial. As such our goals should be:
> 
> 	• To ensure that information is distributed intentionally, not accidentally;
> 	• to understand the privacy and other implications of any distributed information;
> 	• to ensure that the information distribution is limited the intended parties; and
> 	• to gate the distribution of information on the participation of the relevant parties
> 
> These goals for exposure and distribution apply equally to senders, receivers, and path elements.
> 
> Going forward, new standards work in the IETF needs to focus on addressing this gap by providing better alternatives and mechanisms for building functions that require some collaboration between endpoints and path elements.

I can't help but wonder if it'd improve the discussion if this were framed in terms of access to information about the communication between two parties and a third party, regardless of whether that third party is "the network" or not -- because in many cases, the only way that the network is relevant appears to be as a potential control channel.

From that perspective, I think it's clearer that:

* Multi-party communication inherently has more potential privacy/security exposure, as compared to two-party communication
* Multi-party communication also places additional cognitive load on the end user, as they have to account for multiple relationships
* Those factors *can* be reduced by leveraging trust relationships, but they need to be created with great care; the issues involved are subtle
* The amount of information available to the third party matters -- volume and variety will increase its value
* Therefore, limiting the information available to third parties to the minimal amount needed to achieve the functions that they're trusted with is another technique worth pursuing
* All of this implies that enabling these functions needs to be done in a case-by-case manner, with particular attention to the specifics of each situation (a la spin bit)
* In turn, that implies that each function needs to be considered legitimate enough by the Internet community to warrant such a protocol design effort.

Hope this helps,

> On 18 Mar 2022, at 12:27 am, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

--
Mark Nottingham   https://www.mnot.net/

---

From: Melinda Shore <[email-masked]>
Date: Tue, 22 Mar 2022 16:20:22 -0800

On 3/22/22 4:10 PM, Mark Nottingham wrote:> I can't help but wonder if 
it'd improve the discussion if this were
> framed in terms of access to information about the communication
> between two parties and a third party, regardless of whether that
> third party is "the network" or not -- because in many cases, the
> only way that the network is relevant appears to be as a potential
> control channel.

I wonder if it's time to look back at the history of middlebox
communication in the IETF, both path-coupled and not.  For the
most part that work was motivated by the traversal problem, but
it may be more broadly applicable, and the reasons it has
repeatedly flopped may not be relevant here (although I suspect
that they are, at least in part).

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 23 Mar 2022 11:00:29 +0100 (CET)

> Il 23/03/2022 01:10 Mark Nottingham <[email-masked]> ha scritto:
> 

I do not disagree, but this last bullet implies the extremely hard discussion on who is "the Internet community" and who is entitled to speak for it. This is even more difficult given that there is ample disagreement between stakeholders on whether network access to connection information is desirable, acceptable or dangerous, and that some of these stakeholders have strong business or political interests in making that happen or not happen, so full consensus, perhaps even rough consensus, is likely to be impossible.

IMHO a reasonable stance for a technical SDO would be to develop the technical mechanism so that those who can and want to introduce this kind of information exchange can do so in the best possible way, and then stay entirely out of any deployment or policy discussion, unless stars somehow align and we discover that there is at least something that we all agree upon.

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Mar 2022 08:34:35 +1100

Hey Vittorio,

> On 23 Mar 2022, at 9:00 pm, Vittorio Bertola <[email-masked]> wrote:
> 

I don't think we disagree here; just because something is published by the IETF doesn't convey universal legitimacy -- although it's one signal, due to the quality of some of our output and the openness of our process. Adoption by many users and networks is another such signal.

> IMHO a reasonable stance for a technical SDO would be to develop the technical mechanism so that those who can and want to introduce this kind of information exchange can do so in the best possible…

I don't think it's reasonable to 'stay entirely out of any deployment or policy discussion' when designing a technical mechanism that directly impacts both. What's important is that we remember the role we're playing as engineers, which is where our legitimacy is sourced from -- technical expertise, combined with a history of delivering specifications that improve the Internet that people get so much utility from.

Cheers,