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

[Toerless Eckert <[e-mail]>]

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"


>    [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),
>    considering the need for per-connection state (Section 4.6), taking
>    into account the latency involved in reacting to distant signals, and
>    so on.
> 
>    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