Re: [arch-d] Call for Comment: <draft-iab-path-signals-collaboration-01> (Considerations on Application - Network Collaboration Using Path Signals)

[Chris Box <[e-mail]>]

Hello IAB members and architectural thinkers,

A little while ago this came out:

> This is an announcement of an IETF-wide Call for Comment on
> draft-iab-path-signals-collaboration-01.
>
> The document is being considered for publication as an Informational RFC
> within the IAB stream, and is available for inspection at:
> <https://datatracker.ietf.org/doc/draft-iab-path-signals-collaboration/>
>

Having reviewed it, I support the aims and principles described in the
document, and consider them to be a good way forward. Without such work we
are heading towards a complete absence of path signals, and that would
create many problems of its own. The balance struck in the document seems
good, describing in general terms what should be shared, under which
conditions, and how information should be protected.

My overarching concern is only one of timing. It will take many years to
develop and deploy new information-sharing protocols that follow these
principles. In the meantime, hiding of cleartext path signals continues
apace. Network operators therefore face a few years of enforced blindness
before the new mechanisms are in place to permit sharing where the user
desires it. So it would be helpful to (a) advise careful consultation
before withdrawing each cleartext signal, and (b) work quickly on
developing the new protocols.

I also have some detailed feedback for your consideration, below.

*Section 1: Introduction*

The current document says "But a lack of all path signalling, on the other
hand, may be harmful to network management, debugging, or the ability for
networks to provide the most efficient services."

I’d like to suggest some more real-life examples in there, so it becomes
two sentences:
"But a lack of all path signalling, on the other hand, may be harmful to
network management, debugging, service provision, or security. It can also
harm the ability of networks to provide the most efficient services,
including traffic routing and content delivery optimisation.”

Regarding "Another extreme is to employ explicit trust and coordination
between all involved entities, endpoints as well as network devices.  VPNs
are a good example of a case where there is an explicit authentication and
negotiation with a network path element that is used to optimize behavior
or gain access to specific resources. Authentication and trust must be
considered in multiple directions: how endpoints trust and authenticate
signals from network devices, and how network devices trust and
authenticate signals from endpoints.", I have two points here.

   1. The second sentence is not an example of the first sentence. If I
   cross four autonomous systems in order to reach my VPN concentrator, then
   in the present world I am not telling those ASs "Hey, please let my packets
   through because of this good reason". I just try it and see if it works.
   Can we add an example that actually illustrates the first sentence?
   2. Terminology is currently confusing here. The phrases "network path
   element" and "network device" both seem to refer to the VPN concentrator,
   but it is also an endpoint of the VPN tunnel.


*Section 2: Principles*

These are listed in a counter-intuitive order for me. I would prefer an
order that aligns with the thought process someone would need to go through
in order to arrive at the right answer in an efficient way. I think you
have to first define the minimal information to be sent and who it needs to
be sent to, before considering how that should be achieved. I therefore
propose this is a better order:

Minimize Information
Limiting Impact of Information
Minimum Set of Entities
Intentional Distribution
Control of the Distribution of Information
Protecting Information and Authentication
Carrying Information


But people may be able to point out areas where some of these should be
swapped.

*Section 2.7: Carrying Information*

"This document recommends that signalling mechanisms that send information
are built to specifically support sending the necessary, minimal set of
information (see Section 2.4) and no more.  Such mechanisms also need have
an ability for establishing an agreement (see Section 2.2) and to establish
sufficient trust to pass the information (see Section 2.3)."

It's surprising to hear the IAB argue against extensibility, but I can see
that in such cases it's important to debate and agree the extent of the
information sharing risk. Having an extensible protocol can lead to an
open-ended information risk. So I tend to agree that that information needs
to be strictly defined.

*Section 2’s missing principle?*

The document implies there are cases where some flows should be
identifiable to an authorised network element. But it says nothing about
how the packets comprising the flow can be identified. The classic way to
identify a flow is by 5-tuple, but this is weakening and the use of MASQUE
destroys it entirely. I know the task of protocol design to support
specific use cases is left to the reader, but it might be beneficial to
articulate a generic principle that designers can draw on.

*Applying the stated principles*
In assessing this, I found it useful to consider how the principles might
be applied. So I’ve applied it to a zero-rating use case.

The case is that a user has purchased a network product that enables them
to use a set of video streaming services without paying for the data.
Example:
https://ee.co.uk/help/help-new/offers-and-services/passes/what-is-the-ee-video-data-pass.
They
would therefore like the network to know which packets are in scope of this
product, so that they are not overcharged for those packets.

The network would like to be sure that the packets claimed to be in scope
are genuinely in scope, and are not being fraudulently claimed. To keep
this use case simple, I have limited it to the naive approach where the
network assumes these claims are always valid. Adding fraud protection
would probably require an additional entity who is trusted by the other
two, but that's beyond the scope of what I'm trying to cover here.

I will now map the naive case to the principles.

Minimize Information

The information needs to be simply: is this packet in scope of network
product XYZ (e.g. EE video data pass)? The answer is a boolean yes or no.
Sending "this is packet is Netflix" would reveal unnecessary information.
Sending "this packet should be free" would reveal too little.

Limiting Impact of Information

The network would need to use this in deciding to which bucket this
packet's size should be counted.

Minimum Set of Entities

Entity 1: Client device, with knowledge of the app being used
Entity 2: Access network provider, who conveys the packets and charges the
end user

Intentional Distribution

Implied by the purchase of the product, but would benefit from a user
interface prompt to confirm this is still desired.

Control of the Distribution of Information

Sender needs to agree to send the information
Sender needs to authenticate to whom it is revealing this information
Receiver needs to agree to receive it
Receiver needs the same level of confidence in end user identity that it
already has in order to charge the end user.

Protecting Information and Authentication

The information should be delivered intact and not be revealed to any other
entities, which implies the communication channel should be authenticated,
integrity protected and confidential.

Carrying Information

Some mechanism needs to be defined that delivers the above, and no more.


Exploring the above has given me some confidence that the principles are
good, at least for this case.

Thanks to the IAB for working on this, as it points the way to how we
should deal with the loss of classic path signals.

Chris