Subject: [arch-d] IAB Adoption of draft-arkko-iab-path-signals-collaboration-01

From: IAB Executive Administrative Manager <[email-masked]>
Date: Wed, 10 Nov 2021 09:10:13 -0800

The IAB will discuss adoption of draft-arkko-iab-path-signals-collaboration-01 (Considerations on Application - Network Collaboration Using Path Signals) on the IAB stream at its meeting on 2021-11-17.

The draft can be found here: https://datatracker.ietf.org/doc/draft-arkko-iab-path-signals-collaboration/

The agenda for the meeting will be posted 48 hours ahead of the meeting here: https://www.iab.org/wiki/index.php/Agenda

Feedback about this draft can be sent in response to this mail on [email-masked], or to the IAB directly at [email-masked].

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 11 Nov 2021 23:44:35 +1100

I just read this document and have a few high-level comments.

The general topic area is good and a document along these lines would be a useful contribution.  To that end, I'm supportive of the IAB doing this work.  Read this as support for the IAB working on this.

It does need work though.

I find that the emphasis on endpoint-to-path signaling as opposed to path-to-endpoint signaling is a missed opportunity.  There's a lot to say about ECN or ICMP signals from the path that is going unaddressed here.  For example:

* How those signals might be validated
* How the sender of those signals might be authenticated
* How actions based on weakly authenticated signals might need to be limited

These considerations apply in both directions (path-to-endpoint and endpoint-to-path).

For example:

> For instance, an ICMP error that refers to a valid flow may be more trustworthy than any ICMP error claiming to come from an address.

This assumes a lot.  The point here is that an ICMP signal can often be authenticated as being generated by an on-path entity by virtue of it quoting parts of the IP packet that caused the signal to be generated.  Actions taken as a result are appropriate as long as they are limited to sending of future packets on that path as we assume that path elements are able to refuse to forward a packet.  We might not allow that ICMP signal to tear down connections if those connections might continue elsewhere (path migration as in QUIC), though we might allow that if there is no alternative way to continue (as in TCP without MPTCP).

This is, I think, one of the main components the draft should concentrate on.  That matches some of the other items in the draft: Minimization is good.  Establishing purpose and incentives are also good.  Limiting audience is also good.  More on this last point below, however.

I find the focus on consent to be problematic.  The doctrine of consent as it relates to the design of endpoint-path communication seems so far removed from the consciousness of end users that making that association is almost surreal.  My view is that reliance on consent in this setting is highly inappropriate.  Please reconsider your use of this in this document.

Finally, the document doesn't have to talk about this extensively, but the decision to involve path entities is one that needs to be taken carefully.  Deliberately adding more entities to the protocol complicates the design and can add dependencies.  Either endpoints or path elements probably want to avoid taking a dependency on the communication that is being developed, treating signals opportunistically.  In the absence of stronger authentication, you have to limit the extent to which signals can be acted upon anyway, but you also have to deal with the possibility that signals might be spoiled or absent.  QUIC spent a lot of time on this and this is absent in the document.

Editorial notes

I found the document a little difficult to read, but I will attribute that - mostly - to my ability to concentrate being diminished as a result of this week.  I think that the document introduction and abstract are a little more obtuse than is ideal.  I would request that the authors look at fixing the broken grammar.

Can I also request that the editors submit future revisions as XML so that HTML renderings can be used by those of us who prefer them.  Datatracker doesn't recognize Mirja as an author, likely due to her name containing a non-ASCII character.  An XML submission should fix that.

On Thu, Nov 11, 2021, at 04:10, IAB Executive Administrative Manager wrote:
> The IAB will discuss adoption of 
> draft-arkko-iab-path-signals-collaboration-01 (Considerations on 
> Application - Network Collaboration Using Path Signals) on the IAB 
> stream at its meeting on 2021-11-17.
>
> The draft can be found here: 
> https://datatracker.ietf.org/doc/draft-arkko-iab-path-signals-collaboration/
>
> The agenda for the meeting will be posted 48 hours ahead of the meeting 
> here: https://www.iab.org/wiki/index.php/Agenda
>
> Feedback about this draft can be sent in response to this mail on 
> [email-masked], or to the IAB directly at [email-masked].
>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 11 Nov 2021 13:59:20 +0100

Hi Martin,

Thanks for your feedback! See inline.

> On 11. Nov 2021, at 13:44, Martin Thomson <[email-masked]> wrote:
> 

Good!

> It does need work though.

Yes!

> This is, I think, one of the main components the draft should concentrate on.  That matches some of the other items in the draft: Minimization is good.  Establishing purpose and incentives are also…

Good point. I opened an issue: https://github.com/intarchboard/draft-path-signals-collaboration/issues/18

> I find the focus on consent to be problematic.  The doctrine of consent as it relates to the design of endpoint-path communication seems so far removed from the consciousness of end users that maki…

Hm, I guess this needs more discussion. I opened an issue as well: https://github.com/intarchboard/draft-path-signals-collaboration/issues/19

> Finally, the document doesn't have to talk about this extensively, but the decision to involve path entities is one that needs to be taken carefully.  Deliberately adding more entities to the proto…

This sounds nearly like a separate document to me. I know you also have a draft in this space. Maybe we should all discuss this a bit more?

I didn’t open an issue yet but feel free to do so.

> I found the document a little difficult to read, but I will attribute that - mostly - to my ability to concentrate being diminished as a result of this week.  I think that the document introduction…

It does need work. I also think the shorter the better. Specially the intro could probably be more concise.

> 
> Can I also request that the editors submit future revisions as XML so that HTML renderings can be used by those of us who prefer them.

Yes, not sure why this didn’t happen but I guess it’s because of the usual time pressure at the deadline.

>  Datatracker doesn't recognize Mirja as an author, likely due to her name containing a non-ASCII character.  An XML submission should fix that.

I also have a ticket for this.

Mirja

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 11 Nov 2021 07:12:09 -0600

I looked at the document, rather quickly, and wanted to followup on one
point that Martin made.

On Thu, Nov 11, 2021 at 6:45 AM Martin Thomson <[email-masked]> wrote:

> The general topic area is good and a document along these lines would be a
> useful contribution.  To that end, I'm supportive of the IAB doing this
> work.  Read this as support for the IAB working on this.
>
> I find that the emphasis on endpoint-to-path signaling as opposed to
> path-to-endpoint signaling is a missed opportunity.  There's a lot to say
> about ECN or ICMP signals from the path that is going unaddressed here.
> For example:
>
> > For instance, an ICMP error that refers to a valid flow may be more
> trustworthy than any ICMP error claiming to come from an address.
>
> This assumes a lot.  The point here is that an ICMP signal can often be
> authenticated as being generated by an on-path entity by virtue of it
> quoting parts of the IP packet that caused the signal to be generated.
> Actions taken as a result are appropriate as long as they are limited to
> sending of future packets on that path as we assume that path elements are
> able to refuse to forward a packet.  We might not allow that ICMP signal to
> tear down connections if those connections might continue elsewhere (path
> migration as in QUIC), though we might allow that if there is no
> alternative way to continue (as in TCP without MPTCP).
>
> This is, I think, one of the main components the draft should concentrate
> on.  That matches some of the other items in the draft: Minimization is
> good.  Establishing purpose and incentives are also good.  Limiting
> audience is also good.  More on this last point below, however.
>
> I find the focus on consent to be problematic.  The doctrine of consent as
> it relates to the design of endpoint-path communication seems so far
> removed from the consciousness of end users that making that association is
> almost surreal.  My view is that reliance on consent in this setting is
> highly inappropriate.  Please reconsider your use of this in this document.
>
> Finally, the document doesn't have to talk about this extensively, but the
> decision to involve path entities is one that needs to be taken carefully.
> Deliberately adding more entities to the protocol complicates the design
> and can add dependencies.  Either endpoints or path elements probably want
> to avoid taking a dependency on the communication that is being developed,
> treating signals opportunistically.  In the absence of stronger
> authentication, you have to limit the extent to which signals can be acted
> upon anyway, but you also have to deal with the possibility that signals
> might be spoiled or absent.  QUIC spent a lot of time on this and this is
> absent in the document.

In this text from the draft ...

   [RFC9049] discusses many past failure cases, a catalogue of past
   issues to avoid.  It also provides relevant guidelines for new work,
   from discussion of incentives to more specific observations, such as
   the need for outperforming end-to-end mechanisms (Section 4.4
<https://datatracker.ietf.org/doc/html/draft-arkko-iab-path-signals-collaboration-01#section-4.4>),
   considering the need for per-connection state (Section 4.6
<https://datatracker.ietf.org/doc/html/draft-arkko-iab-path-signals-collaboration-01#section-4.6>),
taking
   into account the latency involved in reacting to distant signals, and

      so on.

https://www.rfc-editor.org/rfc/rfc9049.html#name-endpoints-trusting-intermed
also talks about "Endpoints Trusting Intermediate Nodes", and we flat-out
punted that, on the current Internet. In
https://www.rfc-editor.org/rfc/rfc9049.html#name-applying-the-lessons-weve-l,
we said this was basically beyond our ability to engineer (as opposed to
researching), and suggested that

For "Endpoints Trusting Intermediate Nodes" and "Intermediate Nodes
Trusting Endpoints", these lessons point to the broader need to revisit the
Internet Threat Model.

So I'm super happy to see the IAB digging in this part of the Internet
landscape.

I don't think we've posted a pointer to this adoption call on the
PANRG mailing list. I'll do that now.

Best,

SPencer

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 12 Nov 2021 01:24:56 +1100

On Thu, Nov 11, 2021, at 23:59, Mirja Kuehlewind wrote:
> This sounds nearly like a separate document to me. I know you also have 
> a draft in this space. Maybe we should all discuss this a bit more?

I didn't mention that draft deliberately.  I think that the work is complementary.  Here, I think that all you want to do is acknowledge that you are constructing new protocols (or protocol overlays or something) with a challenging authentication setting and that should limit what the protocol can achieve.  That is a key design consideration, so I don't think you can put it out of scope.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 11 Nov 2021 07:24:28 -0800

> I didn't mention that draft deliberately.  I think that the work is complementary.  Here, I think that all you want to do is acknowledge that you are constructing new protocols (or protocol overlay…

As Martin said, we have to pay attention of authentication of path signals.

ECN is the best example that we have of signals from the path to 
endpoints, and it is actually deployed. But ECN can be misused by 
adversaries. For example, a man-on-the-side can observe packets in 
transit, and race copies of these packets with EC set. The attack will 
result in endpoints falsely believing that the path is congested, when 
in fact it is not.

Similar attacks can be mounted with ICMP packets, such as Packet Too Big 
or Port Unreachable.

Treating the path signals "carefully" might mitigate these issues. For 
example, if ECN says a path is congested but other signals like end to 
end delays say it is probably not, then endpoints would be well advised 
to ignore the signal.

-- Christian Huitema

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 11 Nov 2021 09:45:34 -0600

This won't surprise Christian, or most of the participants on this mailing
list, but

On Thu, Nov 11, 2021 at 9:24 AM Christian Huitema <[email-masked]>
wrote:

> adversaries. For example, a man-on-the-side can observe packets in transit,
> and race copies of these packets with EC set. The attack will result in
> endpoints falsely believing that the path is congested, when in fact it is
> not.
>

ECN was described in
https://www.rfc-editor.org/rfc/rfc9049.html#name-explicit-congestion-notific.
This section was added at the request of Martin Duke, and focused on three
OTHER problems, but ECN also has THIS problem. We didn't talk about this
problem much in the ECN section, because ...

> example, if ECN says a path is congested but other signals like end to end
> delays say it is probably not, then endpoints would be well advised to
> ignore the signal.
>

... we talked about the "endpoints trusting middlepoints" problem in
https://www.rfc-editor.org/rfc/rfc9049.html#name-icmp-source-quench.

So it's useful to remember that the problems Christian is naming are real
problems that have impeded the deployment and use of IETF protocols in the
past.

Best,

Spencer

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Nov 2021 17:06:09 +0100

Hi Martin,

> I find the focus on consent to be problematic.  The doctrine of consent as it relates to the design of endpoint-path communication seems so far removed from the consciousness of end users that maki…

I have some issues with consent as well, but I think we may differ as to 
what they are.  My two concerns about any consent model is that (a) it 
has to be meaningful and (b) it has to scale in such a way that the user 
isn't constantly pestered into granting it.  Both of those are hard 
problems.  Web sites here in Europe make a point of constantly nagging 
when consent isn't given.  I hate that.

So what does this mean?  Is there a question that can be asked that can 
establish consent (or lack thereof) in a means that can scale?  To me 
this ties to identity of the entities which themselves is hard to 
establish at scale (both in terms of number of entities and doing so 
without crippling the data path).

A few of us looked at this a while ago.  It's a hard problem; 
insurmountable?  I don't know.  But hard.

Eliot

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Nov 2021 20:32:12 +0200

Thanks for the comments, Martin!

I definitely agree that endpoint-to-path and path-to-endpoint both need to be discussed, and analysed. Good points about validation of signals from the path. Also, my impression that less has been written even in previous documentation and papers about from-path than about to-path. It seems worthwhile to explore this more.

I need to think more about your comments wrt consent, but initially they sound right.

Jari

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 12 Nov 2021 10:01:36 +0100 (CET)

> Il 11/11/2021 19:32 Jari Arkko <[email-masked]> ha scritto:
> 

I think that this is a broader issue that is coming up again and again in multiple pieces of work (e.g. yesterday at least two or three times in the chat during the DPRIVE-PEARG-DNSOP sequence).

There seem to be several people here that think that it is not realistic to rely upon end-users making good choices for their privacy, especially in complex environments and protocols, as it is hard to present the options in a meaningful way, and even if you did, the user would not have the technical competence to make an informed decision.

This is aligned with the approach taken by many of the leading global tech companies: they try to give you more privacy by making all the arrangements themselves, so that once you acquire their product you don't need to do anything else. Examples of this are Mozilla turning on DoH in the U.S. and picking the default resolver for all the users, or Apple and its new Private Relay, where Apple also runs one layer of proxies and picks a limited number of other operators that run the other layer.

However, this is in stark contrast with the basic principle of privacy laws almost everywhere in the world - definitely the GDPR, but also the many privacy laws from Brazil to China that seem to take the GDPR as a model. The principle there is that the user must have full control on each party that gets to process their data, and must be informed and consent separately to each of them, with very few exceptions. The law actually goes to a great length to prevent consent from expanding transitively: even if you buy a product from a company and accept their privacy conditions, that does not generally allow the company to involve other parties without informing you and getting your consent, nor to extend the processing to purposes other than delivering to you the specific product or service you bought. Anything else must be asked separately and consent must be optional.

I do not know how to reconcile these two views, nor if any general advice on the topic is actually possible, but perhaps this discussion on consent should be had once for all. Otherwise, the risk is that the IETF spends a lot of time working on designs that then raise lots of eyebrows as soon as they are noticed in Brussels.

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

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 12 Nov 2021 21:34:34 +0100

Inline

>    Encryption and other security mechanisms are on the rise on all
>    layers of the stack, protecting user data and making network
>    operations more secured.

>    Further, encryption is also a tool to
>    address ossification that has been observed over time.

Suggest:

| Further encryption is also a tool to address ossification which happens
| to user data, when unencrypted user data is used as signaling to the network,
| and this signaling can not evolve at the same speed as the user data
| needs to evolve.

Or something like that. Otherwise readers not so much on top of the
topic alredy may not get it.

>    Separation of
>    functions into layers and enforcement of layer boundaries based on
>    encryption supports selected exposure to those entities that are
>    addressed by a function on a certain layer.

Layers is a loaded and in this explanation IMHO unnecessary term.

| Separating user data into user-only data and data to be shared
| with third parties, applying encryption to both, and creating cryptographic
| cryptographic trust relationship only for the data to be shared with
| third parties such a certain entities along the path can overcome this
| challenge.

>    A clear separation
>    supports innovation and also enables new opportunities for
>    collaborative functions.  RFC 8558 describes path signals as messages
>    to or from on-path elements.  This document states principles for
>    designing mechanisms that use or provide path signals and calls for
>    actions on specific valuable cases.

I was specifically usig the term "third party", because we may want to
be ?maybe? more inclusive than thinking solely about on-path entities
as the ultimate collaboration partner. Think for example that in regulated
industries, some on-path device is only tapping into the data, forwarding it to
a third third party such as a regulatory entitiey which may in a data
center have totally different option to analyse the data. Of course,
the principle of explicitly separating out the data that is to be
shared with that third party is the same, but the whole mechanisms
how to put the stuff on the wire may be quite different for such use
cases. 

>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>    2.  Past Guidance . . . . . . . . . . . . . . . . . . . . . . . .   4
>    3.  Principles  . . . . . . . . . . . . . . . . . . . . . . . . .   5
>      3.1.  Intentional Distribution  . . . . . . . . . . . . . . . .   6
>      3.2.  Minimum Set of Entities . . . . . . . . . . . . . . . . .   7
>      3.3.  Consent of Parties  . . . . . . . . . . . . . . . . . . .   7
>      3.4.  Minimum Information . . . . . . . . . . . . . . . . . . .   8
>      3.5.  Carrying Information  . . . . . . . . . . . . . . . . . .   9
>      3.6.  Protecting Information and Authentication . . . . . . . .   9
>    4.  Further Work  . . . . . . . . . . . . . . . . . . . . . . . .  10
>    5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
>    6.  Informative References  . . . . . . . . . . . . . . . . . . .  11
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14
> 
> 1.  Introduction
> 
>    Encryption, besides its important role in security in general,
>    provides a tool to control information access and protects again
>    ossification by avoiding unintended dependencies and requiring active
>    maintenance.

Sounds again a bit too abstract to the average reader i think.

>    The increased deployment of encryption provides an
>    opportunity to reconsider parts of Internet architecture that have
>    rather used implicit derivation of input signals for on-path
>    functions than explicit signaling, as recommended by RFC 8558
>    [RFC8558].

It's lovely to always think of the Internet first, but IMHO, the Internet
is NOT the primary problem:

Yes, i wold love to see explicit signaling to help create better services
for example towards the Internet edge (access SP) for better network
srvices to Internet users (residential and commercial). But that is
building a business.

Where i think we have the real problem of end-to-end encryption is not
there, on the Internet / Internet edge. Yes, there has-been/is concern in service
providers that they can not well control "undesirable" traffic such as
p2p file sharing to overtake access bandwidth when it is incompatible
with CC of well behaving applications and monopolized congestion point bandwidth.
But that seems to be a waning concern with the evolution of CC/AQM
and file sharing So i would contend that for Internet Service, providers
can mostly live without DPI today and are not affected by the end-to-end
encryption.

I do not have good current market data, but i would contend and fear
that there is a much highe likelyhood, that in private networks, enterprises,
mission specific networks, IoT, industrial and similar networks,
dependency today against DPI functions is actually much larger. With
the ongoing increase of end-to-end encryption, these networks will
already resport for many of their application specific network policies
(QoS, performance measurements, accounting, access control, routing) to
rely purely on well-known ports, IP-addresses or DNS-DPI instead of traffic-DPI, and that
alltogeher will make those existing application traffic management
procedures harder and harder.

Those private networks have been the root cause for efforts in the IETF
for vendor to bring forward proposal such as SPUD and other forms
of path singnaling. So they do really reserve explicit mentioning
in the document, because this is IMHO where the most obvious ask from
customers and uptake in the industry of better mechanisms would be if
we do it well.

> 
>    RFC 8558 defines the term path signals as signals to or from on-path
>    elements.  Today path signals are often implicit, e.g. derived from
>    in-clear end-to-end information by e.g. examining transport
>    protocols.  For instance, on-path elements use various fields of the
>    TCP header [RFC0793] to derive information about end-to-end latency
>    as well as congestion.  These techniques have evolved because the
>    information was simply available and use of this information is

Btw: with you mentioning TCP: I really would like to see a strong statement,
that Internet CC related information elements (of likely transport layer)
have NO right to stay private to the user/application, because CC IS FUNDAMENTALLY
COLLABORATIVE along the path.

I think we shuold work towards the best solution that allows on-path
nodes to do the best job to handle congestion (aka: AQM mechanisms). And
that definitely includes making it scale with no/least-amount of per-flow
awareness. We have some of such AQM, but across the range of different
endpoint CC algorithms the whole framework is quite fragile and unfair.
All the different CC algorithm we are playin around with all have different
degrees of aggressiveness an get different amounts of bandwidth share under
congestin. There needs to be a strategy to improve on this instead of
just this ad-hoc relative performance measurements we're doing.

That IMHO is something like an ICNRG action item that should come from this.

> 
>    As such, applications and networks have evolved their interaction
>    without comprehensive design for how this interaction should happen
>    or which information would be desired for a certain function.  This
>    has lead to a situation where sometimes information is used that
>    maybe incomplete, incorrect, or only indirectly representative of the
>    information that was actually desired.  In addition, dependencies on
>    information and mechanisms that were designed for a different
>    function limits the evolvability of the protocols in question.

If you are are aare of or even thinking of specific examples, it always helps the
community reading this document to explicitly mention them, because as
i said already multiple times, we need to bring a larger part of the
community to understand the problems, and they will only do so from explicit
cases documented, not from abstractions. 

>    The unplanned interaction ends up having several negative effects:
> 
>    *  Ossifying protocols by introducing unintended parties that may not
>       be updating

The enterprise IT department certainly did intend and plan for application and
network to play nicely together. She just has little influence about what
she gets from network equipment and application vendors. So "unintended" is very specific from
the view of just the application developer. Maybe "unintended and/or uncoordinated".

>    *  Creating systemic incentives against deploying more secure or
>       private versions of protocols

What i a private version of a protocol ? Example please.
(never hear this term widely, so not sure people would agree on
 a definition, or even more so, why it would be a good thing).

>    *  Basing network behaviour on information that may be incomplete or
>       incorrect
> 
>    *  Creating a model where network entities expect to be able to use
>       rich information about sessions passing through

This is not a good statement. It sounds to me that it is always bad to have
such a rich information interaction. And that is not true. Example:
SP deploys video live distribution (unicast/multicast) contribution/distribution/access,
all the way from video servers to set top boxes in clients.

It is a perfectly valid and good rich information integration model for
network devices to analyze video performance, not only into RTP headers
for loss, jitter, latency, but also into video frame information to actually
derive user-experience quality metric impact of any network behavior along the
path.

Sure, in such an example we need to still discuss what/where we need
encryption, but assume this is NOT Internet, but inside a large video production entity,
such as a broadcaster. Why encryption and where and how ? Answer will be widely
different on scenario.

Back to the sentence of yours. Maybe best to qualify:

 ...passing through, even though this is not explicitly intended/support
 by the host-stack/application  mechanisms

(or similarily).

>    For instance, features such as DNS resolution or TLS setup have been
>    used beyond their original intent, such as in name-based filtering.
>    MAC addresses have been used for access control, captive portal
>    implementations that employ taking over cleartext HTTP sessions, and
>    so on.

The supposedly global DNS name space has been abused to direct
End-users content redirections to monopolized silos of content providers ? ;-))

>    Increased deployment of encryption can and will change this
>    situation.  For instance, QUIC replaces TCP for various application
>    and protects all end-to-end signals to only be accessible by the
>    endpoint, ensuring evolvability [RFC9000].  QUIC does expose
>    information dedicated for on-path elements to consume by design
>    explicit signal for specific use cases, such as the Spin bit for
>    latency measurements or connection ID that can be used by load
>    balancers [I-D.ietf-quic-manageability] but information is limited to
>    only those use cases.  Each new use cases requires additional action.

And AFAIK, there is no agility defined into the protocol to make it
easy for developers of applications to add such information elements
when they want to (i may be wrong). Aka: The agility to expose needs
to be the same as agility to hide.

>    Explicit signals that are specifically designed for the use of on-
>    path function leave all other information is appropriately protected.
>    This enables an architecturally clean approach and evolvability,
>    while allowing an information exchage that is important for improving
>    the quality of experience for users and efficient management of the
>    network infrastructure built for them.

See above. I fear the design fo QUIC is quite biased today for the side of hiding.

I think it would also be important to be transparent to the community
by talking about business incentives. The reason for introducing
end-to-end encryption was not only the good ones that you describe and
which are now carried by those who did it (agilicy, privacy), but it
started out foremost as a way to improve the OTTs mean to monetize their
applications without revenue sharing with the underlying connectivity
providers, effectively putting them in a position of replacing a lot
of such conectivity providers and in its wake eroding the very fundaments
of the Internet Architecture, replacing a highly resilient federated
infrastructure with a fragile set of vertical global OTT monopolies.

>    This draft discusses different approaches for explicit collaboration
>    and provides guidance on architectural principles to design new
>    mechanisms.  Section 2 discusses past guidance.  Section 3 discusses
>    principles that good design can follow.  This section also provides
>    some examples and explanation of situations that not following the
>    principles can lead to.  Section 4 points to topics that need more to
>    be looked at more carefully before any guidance can be given.
> 
> 2.  Past Guidance
> 
>    Incentives are a well understood problem in general but perhaps not
>    fully internalised for various designs attempting to establish
>    collaboration between applications and path elements.  The principle
>    is that both receiver and sender of information must acquire tangible
>    and immediate benefits from the communication, such as improved
>    performance.

If you say "The principle is", it makes it sound as if you agree with
this guidance to go forward. If that is not the case, write "The principle was".

I do not agree that this is a good principle, or at least not comprehensive
enough to warrant being written down by itself and make it sound like good.

See especially my above mentionng
of the collaborative nature of CC. If an application does not well-behave, then
better integration will make it easier for the network to help it be well behaved
and effectibely get WORSE experience - for the benefit of othres. This
aspect of course can extend whenever or whereever the policies for sharing
of resources in a particular network, Internet in a particular country and/or
private neworks do evolve beyong "Don't kill competing traffic".

For example when the police and fire departments Internet traffic in California
during wild fire are not switched off by Verizon, because they exceeded their
subscribed Internet volume but given by government policies priority over other
Internet traffic instead.

>    A related issue is understanding whether a business model or
>    ecosystem change is needed.  For instance, relative prioritization
>    between different flows of a user or an application does not require
>    agreements or payments.  But requesting prioritization over other
>    people's traffic may imply that you have to pay for that which may
>    not be easy even for a single provider let alone across many.

Or, see above (california fires), there may be regulations. Yes, please do not overlook
that wale in the room! Yes, it is not an elephant anymore. It has grown!
Because we where trying to ignore it, we are constantly ending up with
messy hacks by those regulators such IP/DNS acl whenever the word child
pornoraphy is mentioneed. By persons such as the head of the
european union.

>    But on to more technical aspects.
> 
>    The main guidance in [RFC8558] is to be aware that implicit signals
>    will be used whether intended or not.  Protocol designers should
>    consider either hiding these signals when the information should not
>    be visible, or using explicit signals when it should be.

"hiding these signals"
  -> "hiding the data/information that would allow to generate the implicit signal".

"be visible, or using explicit signals when it should be"
  -> "be visible, and/or converting it into explicit signals when it should be"

>    the need for outperforming end-to-end mechanisms (Section 4.4),
>    considering the need for per-connection state (Section 4.6), taking
>    There are also more general guidance documents, e.g., [RFC5218]
>    discusses protocol successes and failures, and provides general
>    advice on incremental deployability etc.  Internet Technology
>    Adoption and Transition (ITAT) workshop report [RFC7305] is also
>    recommended reading on this same general topic.  And [RFC6709]
>    discusses protocol extensibility, and provides general advice on the
>    importance of global interoperability and so on.

As background for the need and ways to keep protocols agile, and hence
require them to be encrypted to avoid such implicit signal ossification,
you may mention as ongoing work draft-thomson-use-it-or-lose-it. Maybe not
here, but elswhee (earlier ?) in the document.

> 3.  Principles
> 
>    This section attempts to provide some architecture-level principles
>    that would help future designers and recommend useful models to
>    apply.
> 
>    A large number of our protocol mechanisms today fall into one of two
>    categories: authenticated and private communication that is only
>    visible to the end-to-end nodes; and unauthenticated public
>    communication that is visible to all nodes on a path.  RFC 8558
>    explores the line between data that is protected and path signals.

>    There is a danger in taking a position that is too extreme towards
>    either exposing all information to the path, or hiding all
>    information from the path.

Not quite sure what purpose this paragraph takes. It sounds mostly like
exposing a thought process than a conclusion. Yes. lotsa politic.

>    Exposed information encourages pervasive monitoring, which is
>    described in RFC 7258 [RFC7258].  Exposed information may also be
>    used for commercial purposes, or form a basis for filtering that the
>    applications or users do not desire.

Let me open a side discussion which IMHO needs to go somewhere:

Today, i am not aware of ANY exposed information that is well integrity
protected. So for all intent and purpose, information exposed as it is
today also opens applications to WitM attacks (Women-in-the-Middle - sorry,
could not resist ;-). Of course, this can AND MUST be solved by
providing integrity protection for all information - whether it is
confidential or not. Alas of course, TLS1.3 does not even have such
"zero-encrypt" authentication option.

But back to topic:

What is the purpose of the paragraph ? Aka: Why only attempt to list
all the negatives ? The whole problem space is highly ambiguous, so
its better to be more inclusive about pro/cons.

Example:

Exposed informantion can be used for regulatory action. Whether or
not this is considered to be good or bad will even be split across
End-Users, but it is simply a legal requirement.

>    But a lack of all path signaling, on the other hand, may be harmful
>    to network management, debugging, or the ability for networks to

"network management, debugging"
  -> "network management: troubleshooting, traffic optimization, planning"
                         
>    provide the most efficient services.

Billing, Accounting, enforcing fairness (whatever the definition of
fairness is), regulations, differentiated, guaranteed services, ...
(i can go on forever ;-)

>    There are many cases where
>    elements on the network path can provide beneficial services, but
>    only if they can coordinate with the endpoints.

Btw: This is also a simplification coming from an "Internet" ==
"residential type End-User" view.

Imagine an enterprise network where end-users actually have little to say,
like in any company networks (western or eastern probably not even makin
much of a difference, but i really only know worker protection laws
for california, not china ;-).  The cooperation makes the policy
as to what end-users and their traffic are allowed to do. 

In Microsoft networks for example, everthing flows down from a domain
controller. Lets assume we do come up with solutions to separate out
explicit signaling trafic from end-to-end only traffic in
application/protocols. It would be very likely that the design
would then simply have the keying material for the explicit signaling
come down from the domain conroller to the endpoint, so the endpoint
and user will have no idea at all whom the keying material is shared
with, but the domain controller will decide that.

These solution are and will be built anyway for these type
of environments. They will just not be built in a way that
allows routers/switches to participate in it if we do not act.
So for example for any form of "Lawfull Intercept", this intercept
(key sharing etc) will happen by WitM operating at higher layers.

So when it comes to the core issues: desirable or undesirable
third-party integration will happen. If we get involved in this
in IETF/network protocols, we may help to accelerte it, for better or worth,
but we also have a seat on the table to create transparency,
user visibilily and maximum limitation for it. If we do not get involved,
it is out of our hands, and may be slower to evolve, but will
IMHO become a lot more intrusive over time and a lot more uncontrollable.

>    It also affects the
>    ability of service providers and others observe why problems occur
>    [RFC9075].
> 
>    This situation is sometimes cast as an adversarial tradeoff between
>    privacy and the ability for the network path to provide intended
>    functions.  However, this is perhaps an unnecessarily polarized
>    characterization as a zero-sum situation.  Not all information
>    passing implies loss of privacy.  For instance, performance
>    information or preferences do not require disclosing user or
>    application identity or what content is being accessed, network
>    congestion status information does not have reveal network topology
>    or the status of other users, and so on.

Ok. Another big aside about the complexity of this:

Application developers and Users have no idea what the network needs to do the
best job for the application. And/or the necessary evil such as regulation
or any equivalent for "advertisements" to pay for the user traffic. And
of course for Internet End-users we do want to keep up the fight to limit
any of this, but the first question is whether we are designing our
understanding of End-user beneefits only for ONE target deployment -
"Internet" (where i am not even sure there is only "one" "Internet").

To give a practical example:

It is extremely difficult/slow and error prone attempting to make applications
emit correct explicit signaling that is instructive as to what explicitly
the QoS in a network should do. DSCP, bandwidth, latency, weight share, priority
relative to other traffic. We do not even have good explicit signaling, but
assume we had, it would not be well adopted across many important application
spaces because application developers would not bother trying to figure this
all out and/or would do it wrong and cycles to fix stuff would be eternal.

I did one such proposal in draft-eckert-intarea-flow-metadata-framework-02.txt
it has a couple of those parameters, and i did work on their deployment
and integration into enterprise applications.

What is a lot easier is to actually expose parameters that let applications
not have to describe what they "want", but what their traffic "is". That
does incur a lot more loss of privacy, but it does allow a lot easier workflows
for networks to actually do the workflows it needs.

Simple practical example: We do have an explicit signaling that provides
an "Application ID". Big nono for "Internet", but for Enterprise, the
domain controller would as part of provisioning enterprise host parameters
enable for this explicit sinaling to be sent, ideally of course encrypted,
with keying material only be shared with authorized entities in the
enterprise. Does not even have to be the routers themselves because we
may not want _any_ IT network operator to see this. Could
be hashed information (AppID XOR hash(ports, secret)) collected by IPFIX that
can only be decoded by an IPFIX analyzers outside of the network.

>    This points to one way to resolve the adversity: the careful of
>    design of what information is passed.
> 
>    Another approach is to employ explicit trust and coordination between
>    endpoints and network devices.
>
>    VPNs are a good example of a case
>    where there is an explicit authentication and negotiation with a
>    network path element that's used to optimize behavior or gain access
>    to specific resources.

Counterpoint: A VN on a client is just a software-router into
a separate network. It has NOTHING to do with this problem of
actual "Endpoint/Application" integration with the network.

Alas, all the explicit signaling coming to mind do not have cryptographic
authentication and/or they're not used; IGMP, RSVP, PCP for example
We're really terrible ;-) (unless i am missing something, which would be great).

>    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.  Our goals should be:
> 
>    *  To ensure that information is distributed intentionally, not
>       accidentally;

Downgrade "distributed" to "sent" ? "distributed" sound like broadcasting,
even though example i gave would be desirable examples of as few-as-possible
recipient control is "easily" possible.

>    *  to understand the privacy and other implications of any
>       distributed information;
> 
>    *  to ensure that the information distribution targets the intended
>       parties; and
> 
>    *  to gate the distribution of information on the consent of the
>       relevant parties

These points do not separate betweeen:

   a) when and how is the ENCRYPTED explicit signaling sent ?
   b) WHO gets the keying material to decrypt it ?
   c) HOW is that authenticated receiver controlled to comply with constraints 
      to what it is permitted to do with the information ?

a) and b) are things we can easily work on. c) is the wale.

Please try to reformulate to make that distinction between 
receiving / extracting information and actually using it clearer.

Btw: This discussion has a time factor. In IP Multicast solutions, content is
encrypted, so you would argue normally that it doesn't matter if
someone unauthenticated can receive it (Satellite TV for example),
but content providers where and are afraid of long-term crypto attacks,
so they also wanted the IP MUlticast traffic forwardin to be
authenitcted so that unauthenticated receivers couldn't even
get the encrypted traffic and just wait for a few months to
get keys from someone else.  Granted. This was not a signaling
but user-data example, but same rules apply to explicit signaling:

If it has long-term value, then actual distribution of the
encrypted information is a lot more important to control than
for short-term valuable information, where one can primarily
count on the encryption for protection.

>    These goals for distribution apply equally to senders, receivers, and
>    path elements.
> 
>    We can establish some basic questions that any new network path
>    functions should consider:
> 
>    *  What is the minimum set of entities that need to be involved?
>
> 
>    *  What is the minimum information each entity in this set needs?
> 
>    *  Which entities must consent to the information exchange?

I think w really need to start writing down many scenarios of interest
to start hving a better discussion and to answer those questions.
Easy to show that different scenarios will render different answers.

>    If we look at many of the ways network path functions are achieved
>    today, we find that many if not most of them fall short the standard
>    set up by the questions above.  Too often, they send unnecessary
>    information or fail to limit the scope of distribution or providing
>    any negotiation or consent.

Wait! which solution does even try ? ;-))

Today AFAIK we only have the two extremes:
a) legacy unencrypted traffic, unauthenticated, all in the open
b) end-to-end encrypted with maybe those "forgotten/intentional
  tranparent bits" in transport protocol headers.
c)explicit on/off path signalig to the network (PCE, RSVP, IGMP, SDN-controller),
  where only a TLS connection to the controller would fit any
  reaonable model of security. And none of such proposed connections to
  SDN controller is anywhere standardized AFAIK.

Aka: would be good to have such a reminder that we're currently
not anywhere good, but only have either extremes (a,b) or crap (a),
or wishfull thinking (c with SDN controller).

Maybe not with as harsh words as mine ;-)

>    Going forward, new standards work in the IETF needs to focus on
>    addressing this gap by providing better alternatives and mechanisms
>    for providing path functions.
                   ^^^^^^^^^^^^^^^

That is limiting. Collecting App-ID or any other (performance) metric
in an enterprise (*) for example can service for payment to applications,
network planning etc.. I don't saw the text up to this point being
constrained to only path functions.

(*) Even access service providers are doin stats based on application
recognition to know whats streaming video, collaborative video etc.pp.
Of course, for them it is today often good enough just to look at the
biggies, and hence just look for IP-addresses mapping to zoom and webex
to figure out how much video conferencing there is and when it happens
(for network planning and performance optimiation). But when we are
going to see more and more evolution to use common network cache
infrastructures, even those distinctions will go away or require
"DNS-DPI".

>    Note that not all of these functions
>    can be achieved in a way that preserves a high level of user privacy
>    from the network; in such cases, it is incumbent upon us to not
>    ignore the use case, but instead to define the high bar for consent
>    and trust, and thus define a limited applicability for those
>    functions.

Three laws of Internet Robotics: ( ;-)
a) The End User HAS NO PRIVACY for the data elements necessary to achieve Internet Fairness
b) The End User HAS PRIVACY for any other data element as long as she only uses Best Effort (BE)
c) Any network ervice beyond BE must be architectured to maximize equal access
   to it by any application provider (and not only big ones).

Of course, c) is wishful thinking, but nothing wrong in doing that. Like World Peace.

> 3.1.  Intentional Distribution
> 
>    This guideline is best expressed in RFC 8558:
> 
>    "Fundamentally, this document recommends that implicit signals should
>    be avoided and that an implicit signal should be replaced with an
>    explicit signal only when the signal's originator intends that it be
>    used by the network elements on the path.  For many flows, this may
>    result in the signal being absent but allows it to be present when
>    needed."
> 
>    This guideline applies also in the other direction as well.  For
>    instance, a network element should not unintentionally leak
>    information that is visible to endpoints.  An explicit decision is
>    needed for a specific information to be provided, along with analysis
>    of the security and privacy implications of that information.
> 
> 3.2.  Minimum Set of Entities
> 
>    It is recommended that a design identify the minimum number of
>    entities needed to share a specific signal required for an identified
>    function.  In some cases this will be a very limited set, e.g. when
>    the application needs to provide a signal to a specific gateway
>    function.  In other cases, such as congestion control, a signal might
>    be shared with every router along the path, since each should be
>    aware of the congestion.
> 
>    While it is tempting to consider removing these limitations in the
>    context of closed, private networks, each interaction is still best
>    considered separately, rather than simply allowing all information
>    exchanges within the closed network.  Even in a closed network with
>    carefully managed components there may be compromised components, as
>    evidenced in the most extreme way by the Stuxnet worm that operated
>    in an airgapped network.  Most "closed" networks have at least some
>    needs and means to access the rest of the Internet, and should not be
>    modeled as if they had an impenetrable security barrier.

These are pretty good.

> 3.3.  Consent of Parties
> 
>    Consent and trust must determine the distribution of information.
>    The set of entities that need to consent is determined by the scope
>    and specificity of the information being shared.
> 
>    Three distinct types of consent are recommended for collaboration or
>    information sharing:
> 
>    *  A corollary of the intentional distribution is that the sender
>       needs to agree to sending the information.  Or that the requester
>       for an action needs to agree to make a request; it should not be
>       an implicit decision by the receiver that information was sent or
>       a request was made, just because a packet happened to be formed in
>       a particular way.

I think this should exclude information elements for congestion control/circuit-breaker
unless a different traffic class than BE is explicitly negotiated.

> 
>    *  At the same time, the recipient of information or the target of a
>       request should agree to wishing to receive the information.  It

to wishing -> on their wish ?

>       should not be burdened with extra processing if it does not have
>       willigness or a need to do so.  This happens naturally in most
>       protocol designs, but has been a problem for some cases where
>       "slow path" packet processing is required or implied, and the
>       recipient or router did not have willingness for this.

The example you give is interesting, because to me it proves that
the text of the point is not correct, although i am a bit at loss how
to exactly rewrite it:

I don't think you need to have "should agree (wishing) to receive the information".
It is perfectly fine to correctly define the mechanism so that uninterested
receivers can well IGNORE it.

Aka: the router-alert problem with slow-path is my example:
The problem was that implementations where punting ALL router
alerts to slow-path even though they did not do PGM. They could have
simply punted only based on combination of router-alert AND protocol
type. But the IETF RFCs failed to make a very strict MUST against
this requirement, because i guess back then we where fearfull/unknowing
about how to write about fast/slow-path. And we still have that
text writing problem today in HbH discussions i think.

Maybe amend:

Information that is sent without explicit approval by recipient must
be sent in a way that it can be ignored without any extra processing
for compliant implementations. - DSCP and flow labels are of
course example of this (for the most part).

>    *  Internet communications are not made for the applications, they
>       are ultimately made on behalf of users.  Information relating to
>       the users is something that both networks and applications should
>       be careful with, and not be shared without the user's consent.

It certainly would be a good thing, even if just for an appendix
to point out that "End users" who are "Employees" or "Live somewhere"
pretty much give up many rights and are assumed to implicitly consent 
with a lot of crap their employers or countries are doing,  so 
"User consent" may in many networks MEAN NOTHING, because it is
enforced if you want to earn money or live in a particular country.
(I do not consent to my countries law - yeah. Good luck !).

Yes. Call it part of being humble and not make our intentions
look like anything more than what they can actually mean, because
right now we are designing protocols based on an expectation of
what "End User Consent" would mean in a world free of corporations,
contries and only driven by what user consent a limited number of
big companies in the IETF think is desirable. Which has so far
been quite good. But also quite limited.

>       This is not always easy, as the interests of the user and (for
>       instance) application developer may not always coincide; some
>       applications may wish to collect more information about the user
>       than the user would like.

applications or deployments thereof (not all applications are in-house
of big content providers, many still have thousands of instances
where whoever deploys the instance is the one collecting the data).

>       As a result, typically an application's consent is not the same as
>       the user's consent.

And an application operator consent not the same as an application developer
consent.

> 3.4.  Minimum Information
> 
>    Parties should provide only the information that is needed for the
>    other party to perform the collaboration task that is desired by this
>    party, and not more.  This applies to information sent by an
>    application about itself, information sent about users, or
>    information sent by the network.
>
>    An architecture can follow the guideline from RFC 8558 in using
>    explicit signals, but still fail to differentiate properly between
>    information that should be kept private and information that should
>    be shared.

The text so far inclding RFC8558 does not discuss the problem of
passing information only to the desired recipients in the face of
encryption and breakage thereof. I mentioned this already upfront.

End-to-end encryption is intended to be strong enough to withstand
a period of time against attacks until the carried information has
lost value. This is even for data not always understood or done,
but its i think an understood principle by security experts.

When it comes to signaling to the network, this become more interesting
to understand because efficiency and fast processing of crypto make
it often very important to choose not very strong crypto, but crypto
that is just good enough to survice e.g.: much shorter term horizons
(and thats a difficult judgement call to make, and if we had better
 solutoins we would never want to make any such compromise anyhow,
 but see for example post-quantum).

>    In looking at what information can or cannot easily be passed, we can
>    look at both information from the network to the application, and
>    from the application to the network.
> 
>    For the application to the network direction, user-identifying
>    information can be problematic for privacy and tracking reasons.
>    Similarly, application identity can be problematic, if it might form
>    the basis for prioritization or discrimination that the that
>    application provider may not wish to happen.  It may also have
>    undesirable economic consequences, such as extra charges for the
>    consumer from a priority service where a regular service would have
>    worked.
> 
>    On the other hand, as noted above, information about general classes
>    of applications may be desirable to be given by application
> 
> 
> 
> Arkko, et al.             Expires 28 April 2022                 [Page 8]
> 
> Internet-Draft             Path Signals Collab              October 2021
> 
> 
>    providers, if it enables prioritization that would improve service,
>    e.g., differentiation between interactive and non-interactive
>    services.

8 Lines contra, 4 lines pro ;-) There are actually for each of
your negative examples equally use-cases where they turn into a positive.

One way to do this maybe better is to highlight all the desires we
think Internet End Users should have, starting with privacy, non-tracking/identification,
and then just saying that in other private networks and/or for other
regulated use cases any or all of these Intenet desires could be exactly the opposite
(instead of again enumerating them).

>    For the network to application direction there is similarly sensitive
>    information, such as the precise location of the user.

Interesting. Sound like the network shouldn't tell the user where the user is ?
Example ?

>    On the other
>    hand, various generic network conditions, predictive bandwidth and
>    latency capabilities, and so on might be attractive information that
>    applications can use to determine, for instance, optimal strategies
>    for changing codecs.

I would mention the most obvious one: Improving performance and fairness
of Internet traffic. Signaling from the network to support upseeding
for example. 

Changing codec is a bad example by itself. Write "codec parameters".

>    However, information given by the network about
>    load conditions and so on should not form a mechanism to provide a
>    side-channel into what other users are doing.

This seems to be contradictory to the collaborative congestion control model
of the Internet. Of course does my throughput give me an indication
about how many an/or what other users are doing to a very limited extend.

More fun example with multicast and video streamin: The longer it takes
for your content to start streaming the less people in yourneighborhood 
like/watch it.

Aka: need to add some limitation, that this rule is limited by the
desires and need of the Internet architecture and other IP networks
resource sharing technologies.

>    While information needs to be specific and provided on a per-need
>    basis, it is often beneficial to provide declarative information
>    that, for instance, expresses application needs than makes specific
>    requests for action.
> 
> 3.5.  Carrying Information
> 
>    There is a distinction between what information is passed and how it
>    is carried.  The actually sent information may be limited, while the
>    mechanisms for sending or requesting information can be capable of
>    sending much more.
> 
>    There is a tradeoff here between flexibility and ensuring the
>    minimality of information in the future.  The concern is that a fully
>    generic data sharing approach between different layers and parties
>    could potentially be misused, e.g., by making the availability of
>    some information a requirement for passing through a network.

And the counterpoint to this is that if there are no mechanism to answer
to regulatory requirements then they will come up with worse solutions
than the ones this framework could enable and we could control.

>    This is undesirable, and our recommendation is to employ very
>    targeted, minimal information carriage mechanisms.
...

> 4.  Further Work
> 
>    This is a developing field, and it is expected that our understanding
>    continues to grow.  The recent changes with regards to much higher
>    use of encryption at different protocol layers, the consolidation or
>    more and more traffic to the same destinations, and so on have also
>    greatly impacted the field.
> 
>    While there are some examples of modern, well-designed collaboration
>    mechanisms, clearly more work is needed.  Many complex cases would
>    require significant developments in order to become feasible.
> 
>    Some of the most difficult areas are listed below.  Research on these
>    topics would be welcome.
> 
>    *  Business arrangements.  Many designs - for instance those related
>       to quality-of-service - involve an expectation of paying for a
>       service.  This is possible and has been successful within
>       individual domains, e.g., users can pay for higher data rates or
>       data caps in their ISP networks.  However, it is a business-wise
>       much harder proposition for end-to-end connections across multiple
>       administrative domains [Claffy2015] [RFC9049].

And the counterpoint to this is all those inter-business arrangements
between big content providers and big service providers to give
more bandwidth to said content traffic than receivers of the traffic where
ever able to get a business arrangemenet with the service provider from.

Maybe this can be phrased as a different point about the economy of
scal problem: At the granularity of individual End-Users it is hard to
imagine whether any service differentiation can be made to work given 
the industries bad history with micro-payments. So we may ultimately
want to focus on 3 party mechanisms with network provider, application
provider and network/application user, to at least level the playing
field between larger and smaller application providers to some extend.

>    *  Secure communications with path elements.  This has been a
>       difficult topic, both from the mechanics and scalability point
>       view, but also because there is no easy way to find out which
>       parties to trust or what trust roots would be appropriate.  Some
>       application-network element interaction designs have focused on
>       information (such as ECN bits) that is distributed openly within a
>       path, but there are limited examples of designs with secure
>       information exchange with specific nodes.

I think we have just been lame on this point. And let concerns over
privacy stop pretty much all of the research/experimentation we should want to do
into the subject. The main issue is really that we do not have a good
history in IETF at all with proactively working on long-tem solutions.

Even anything we do on our "bleeding edge", like LISP and BIER is still based
on sufficiently well worked out designs by some proponents where we
then spend eternities of working out textual quirks. And thats all
IETF contributes. 

Would be great if we would be able to create tracks to do actual
research style experimentation. Aka: open ended as REsearch (in IRTF)
should be, but focussed on practical experimentation as experimental
IETF work has been.

>    *  Sharing information from networks to applications.  Some proposals
>       have been made in this space (see, e.g.,
>       [I-D.flinck-mobile-throughput-guidance]) but there are no
>       successful or deployed mechanisms today.

There is probably a lot more here. Would be nice to create a list.

Thanks a lot for the document.

Cheers
    Toerless

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Nov 2021 00:26:21 +0200

Toerless:

Thanks for these extensive comments. Much appreciated!

I need to read this with careful thought, but I think I do agree with many of your points (of course there may be a few that need discussion :-) )

Jari

---

From: Andrew Campling <[email-masked]>
Date: Mon, 15 Nov 2021 11:34:22 +0000

+1 to Vittorio's comments.

I share his concerns regarding the tendency to ignore or not even consult end-users, which seems totally at odds with RFC 8890.  In addition to the points that Vittorio makes, I observe that this tendency also seems to or reinforce existing or create new centralisation pressures, raising concerns about reduced resilience in the infrastructure of the Internet as well as obvious antitrust issues.  

As a way forward, I wonder whether a BoF focused on RFC 8890 at IETF 113 would be beneficial?  In addition, should we require new I-Ds and RFCs to add a section that deals with centralisation issues alongside the existing one on security?  

Andrew

-----Original Message-----
From: Vittorio Bertola <[email-masked]> 
Sent: 12 November 2021 09:02
To: Jari Arkko <[email-masked]>; Martin Thomson <[email-masked]>
Cc: [email-masked]
Subject: Re: [arch-d] IAB Adoption of draft-arkko-iab-path-signals-collaboration-01

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

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 15 Nov 2021 14:20:50 +0100

Inline

> I think that this is a broader issue that is coming up again and again in multiple pieces of work (e.g. yesterday at least two or three times in the chat during the DPRIVE-PEARG-DNSOP sequence).

I had that impression myself in the priv BOF.
I wonder if much of the content was not flying past all but crypto folks as

"yada yada yada privacy yada yada yaa anonymization yada yada yada."

Very hard for the larger community to vet all of this IMHO.

> There seem to be several people here that think that it is not realistic to rely upon end-users making good choices for their privacy, especially in complex environments and protocols, as it is har…

Can you come up with the least "privacy violating" instance of path
signaling that you would be concerned about and then explain if/how
the goals that led to this should be achieved differently without
privacy violation ?

E.g.: I want to do stream highest quality video, but thats not
possible with my regular Internet bitrate. So i signal that i
want more guaranteed bandwidth for this connection. Is, and if so
why this an issue for privacy ? Likewise low-latency when i am
doing gaming. Or my service provider promises me not to drop
any packet as part of a better service, but to ensure we can
distinguish wheter pckets where dropped in my home or in the SP
network, my applications now need to expose sequence numbers of
packets.

Aka: It is this "low level" transmission behavior that we're mostly
talking about. Bundled with mutual authentication/authorization.

Aka: practical example scenarios where/how this would be seen
as violating privacy would help to make the discussion practical.

I'll note that it IMHO always helps to compare with the physcial
world. When i drive into the fast-lane, i better bring my
payment gadget with me, and will be identified. 

> This is aligned with the approach taken by many of the leading global tech companies: they try to give you more privacy by making all the arrangements themselves, so that once you acquire their pro…

Any complex security problem can be solved with a suffficient
large number of trusted third parties.

(#1 cringeworthy sentence in cryptography i think. You may hate
 it and it may imply false assumptions, but its hard to deny ;-)

> However, this is in stark contrast with the basic principle of privacy laws almost everywhere in the world - definitely the GDPR, but also the many privacy laws from Brazil to China that seem to ta…

And the very same governments then turn around and immediately extract
all your data from those companies that have to put a lot of money into
running GDPR, for whatever reasons the governments see fit. Taxation,
Law enforcments, regulations, commerce statistics, you name it. Hence
the desire of those companies to develop encryption/privacy models,
where they simply don't have the information.

I just can't fathom examples of path-signaling to the network
to rise for my personal privacy anywher to the level of what
happens with my data in data-centers. Its really to me that
the path-signaling is about what i do on the street driving
compared to what i do someplace else after i arrive (data center).
Aka: Its an order of magnitudes easier problem to handle well.

> I do not know how to reconcile these two views, nor if any general advice on the topic is actually possible, but perhaps this discussion on consent should be had once for all. Otherwise, the risk i…

Well, at least if we are doing path signaling on-path with
data (think DSCP on steroids), then the encoding, transport and
crypto are so darn simple that every home-router could even
have a physical switch to turn it off. Try to do that for any
web-scale technology of concern. Even if i start turning
my path signaling into some magic API to an SDN controller,
will i alredy loose that transparency and simplicy and turn
myself into depending on a lot more trust of what happens
under covers i can't control anymore that easily.

Cheers
    Toerless

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 16 Nov 2021 19:28:37 +1100

I'm primarily addressing the reference to 8890 here, but am leaving a few other notes along the way...

> On 15 Nov 2021, at 10:34 pm, Andrew Campling <[email-masked]> wrote:
> 
> I share his concerns regarding the tendency to ignore or not even consult end-users, which seems totally at odds with RFC 8890.

That's a pretty long bow to draw. 8890 argues for broader consultation and consideration of user impact when we make standards -- it's not about surfacing choices to end users about how infrastructure works.

>  In addition to the points that Vittorio makes, I observe that this tendency also seems to or reinforce existing or create new centralisation pressures, raising concerns about reduced resilience in the infrastructure of the Internet as well as obvious antitrust issues.  

What are these 'obvious antitrust issues', in your estimation? 

> As a way forward, I wonder whether a BoF focused on RFC 8890 at IETF 113 would be beneficial?

It seems like you have something very different to the intent of 8890 in mind. If you want to suggest a BoF, please do, but don't hijack 8890, please.

> In addition, should we require new I-Ds and RFCs to add a section that deals with centralisation issues alongside the existing one on security?  

Normatively defining centralisation would be a better first step IMO.

> However, this is in stark contrast with the basic principle of privacy laws almost everywhere in the world - definitely the GDPR, but also the many privacy laws from Brazil to China that seem to ta…

You seem to be conflating _choice_ and _consent_. Arguably, accepting Mozilla or Apple's terms of use -- which presumably incorporate the same disclosures regarding whatever data they collect -- and the corresponding consent (note, e.g., that Private Relay needs to be turned on with a preference) and just as (if not much more) valid than an ISP's measures when 'collecting' data in the process of its DNS service. This has no bearing on whether they enable other services to be used, in the same way that the GDPR says nothing (and should not) about whether an ISP allows its users to access other DNS servers (for example). 

Cheers,

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

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 16 Nov 2021 17:29:25 +0100 (CET)

> Il 16/11/2021 09:28 Mark Nottingham <[email-masked]> ha scritto:
> 

I don't know if I understood your observation correctly. In any case, the point I was making is that, according to the GDPR, consenting to one purpose of treatment (e.g. you treating my personal data as a browser, to let me navigate the web) cannot be conflated with consenting to others (e.g. you redirecting my traffic through a third party acting as a proxy), unless you argue that the two things are technically impossible to separate and constitute one atomic service. This conceptually conflicts with the idea that I pick X as a browser and they also pick a number of other services and operators for me without asking (informing me is not enough, disclosure does not imply consent), even if they do it in my own interest to increase my privacy, and even if I would perhaps make worst choices on my own. Of course, this does not apply if they ask separately for each additional service, or if these services are separate opt-ins, like Apple Private Relay is at the moment.

(This is only about GDPR; then there is a separate discussion going on in Europe in terms of competition and antitrust law, e.g. whether the above could constitute "self-preferencing" or other market-distorting practices, which are going to be forbidden to dominant platforms even if deployed in GDPR-compliant ways.)

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Nov 2021 11:11:07 +1100

> I don't know if I understood your observation correctly. In any case, the point I was making is that, according to the GDPR, consenting to one purpose of treatment (e.g. you treating my personal da…

I think you're referring to purpose limitation as per Art 5(1)(b). Note that this is separate from consent -- there are other legal basis for data processing beyond consent (see Art 6(1)). 

Purpose limitation means that, for example, someone who has access to my personal data for the purpose of doing my taxes can't resell that data to a marketer, unless there's a legal basis for it (like consent). It doesn't mean that my accountant can't employ third-party services (for example, cloud storage) when doing my taxes -- so long as the purpose doesn't change and other requirements are met (see esp. Art 28). It also doesn't mean that my accountant can't consider optional parts of doing my taxes as covered by that legal basis (such as filling out the dreaded FATCA forms for the US), provided that the original purpose is suitably stated.

Arguing that the purpose of using a Web browser includes optional private protections is not unreasonable, especially given the state of DNS privacy in some places. In other words, 'redirecting traffic through a third party acting as a proxy' is not necessarily a separate purpose (particularly when that third party doesn't have access to any private data, such as the client's IP address, thereby removing its obligations under the GDPR). The GDPR says nothing about atomicity of services/implementation -- only *purposes*.

Beyond that, there's a strong argument that these systems are honouring the intent of Art 25(1) -- 'Data protection and design by default':

'[T]he controller shall [...] implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in oder to meet the requirements of this Regulation and protect the rights of data subjects.'

Spraying personal data at whoever happens to successfully offer a DNS resolver over DHCP doesn't seem to align very well with this.

Cheers,

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 17 Nov 2021 12:19:20 +0100 (CET)

> Il 17/11/2021 01:11 Mark Nottingham <[email-masked]> ha scritto:
> 

As you say, the legal matter is arguable and depends on whether DNS resolution or proxying can be considered an integral, non-optional part of the purpose (or service - since your purpose here is to provide the service your customer has asked for) of letting you navigate (and then, as I said, there are competition and telecom regulation laws too).

Now, the legal discussion is off topic, but the architectural discussion is not: should we consider DNS or traffic routing integral parts of an HTTP client, or should we try to preserve layer and application boundaries?

For example, it never happened that all the traffic generated by your device would have to go through your device maker's servers before proceeding to your intended destination. This started with cloud-based IoT stuff and Apple Private Relay is now bringing this to smartphones. Is this in line with the Internet's original architectural principles, or with those we want for the future?

This kind of corporate control is now the model for most contemporary Internet services, though the boundaries involved are often between different application-layer functions rather than between different layers. Think of app stores, merging together software indexing, software retrieval and installation, software security checks and payment gateways, without an option for you to pick different providers for each of these functions, and with conditions that are clearly only possible because of this bundling of functions in a dominant position (e.g. the 30% "Apple tax" on in-app payments). 

We are quickly losing some of the basic architectural principles of the Internet, like modularity, interoperability, multiple implementations. Doing it in the name of privacy does not make this more desirable.

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Wed, 17 Nov 2021 20:11:34 +0700

Dear architecture-discuss,
Toerless, Jari, & Tommy

Of signaling, of signing the internetwork system which is of the Internet
environment as one of the Internet(land)scape*1.

T. Berners-Lee said about the Internet and the Eorkd Wide Web as the
interoperability of languages, such a networking of languages --saying
software work with the supports of hardwares. Yet language is about sign*2.

M. Foucault's discourse-based archaeology finded that the 16th century
European "episteme" taught us about "networks of signs" as the space of
resemblance (referring to principles "convinientia", "aemulatio",
"analogie" and "sympathie"). Hermeneutics and semiology were superimposed
in the forms of similitude. Thus there were hermenutics of resemblance and
semiology of signature*3.

Yet there was "an architecture of signature" in relation with networked
city*4.

There may be matters of "networks evSolution", of the "Internet
evSolution"...*5

Regard,
Guntur Wiseno Putra

Notes:

1) "The internetwork environment consists of hosts connected to networks which
are in turn interconnected via gateways".

https://www.rfc-editor/rfc/rfc793.txt

Thus we have combinations:
- architectural ecology of the Internet(work)-based landscape
- architectural ecology of the land-based Internet(work)scape
- ecological architecture of  the Internet(work)-based landscape
- ecological architecture of the land-based Internet(work)scape

But, there are other kinds of environments besides those of the
Internet and of land.

At least there are the "Deep Ecology - a New Paradigm" (chapter 1 of
"The Web of Life by Fritjof Capra) and "Sustaining the Web of Life:
Science of Ecology, Systems Ecology, and Ecological Sustainability
(Part IV of "The Systems View of Life" by Fritjof Capra and Piere
Luigi Luisi.

https://www.pdfdrive.com/the-web-of-life-a-new-scientific-understanding-of-living-systems-e157334927.html

https://www.pdfdrive.com/the-systems-view-of-life-a-unifying-vision-e195169892.html

Yet Gilles Deleuze and Felix Guattari said about "milieu" built as a
model of deterritorialization by the Greeks for their earth of
philosophy: Territory and the Earth is a place where act of thinking
occurs. The Earth is in the constant movement of deterritorialization
--crustacheas walk in the bottom of waters and knights trace celestial
ways. The Earth and territory are two components with two zones of
vaguenes "deterritorialization" and reterritorialization". (Chapter 4.
"Geophilosophy" of "What is Philosophy"?)

2) "The Internet works because of interoperability between different
computers, despite different hardware, operating systems, local language
context, and software supplier. Users of the web sign on to the use of
these languages when they use the Internet". (TBL, "Stack of
Specifications")
https://w3.org/DesignIssues/Stack.html

3)(A machine-based copy for) Michel Foucault, "The Order of Things" ch.
"The Prose of the World"

4) Castells, M., "Networked City: Resaux, espace, societe) supposedly
concerning with network art. (Supposedly this is the address:)
https://www.espacestemps.net/articles/networked-city-reseaux-espace-societe/

5)
https://mailarchive.ietf.org/arch/msg/architecture-discuss/
q8Ons4idGc1iVJEE_7pGki69CVI/

https://mailarchive.ietf.org/arch/msg/architecture-discuss/
ER6_tSAKTsHYkspABZ-Gva9HJdI/

Pada Sabtu, 13 November 2021, Jari Arkko <[email-masked]> menulis:

> I need to read this with careful thought, but I think I do agree with many
> of your points (of course there may be a few that need discussion :-) )
>
> Jari
>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 17 Nov 2021 18:46:13 -0500

> I don't know if I understood your observation correctly. In any case, the point I was making is that, according to the GDPR, consenting to one purpose of treatment (e.g. you treating my personal da…

This intersting discussion seems to have very little to do with path
signaling. It also seems to have very little to do with IETF
standardization.