Re: [tsvwg] signaling packet importance [was Re: New Version Notification for draft-herbert-fast]

[Sebastian Moeller <[e-mail]>]

Hi John,


> On Aug 13, 2023, at 22:22, Kaippallimalil John <[e-mail]> wrote:
> 
> Hi Sebastian,
> 
>> [SM] Could you clarify what exactly "drop MED" means here:
>> a) the packet is dropped (by whom)?
>> b) the MED option is ignored by the scheduling node, and excised
>> c) the MED option is ignored by the scheduling node, and left alone
>> d) the sender stops emitting MED options
> 
> My mail was not clear earlier, sorry about that.
> By "drop", the intent is to remove the UDP option (MED) at the entrance (router) if it is from an untrusted domain. This is to be sure that the data is from a trusted domain only.

	[SM] UDP options, even if used to communicate with the network, should IMHO always be end-to-end. So removing an option during transfer of a packet is problematic. If you must add a bit "acted upon" which is only set to one if a node evaluated the MED option...

> The scheduling node (wireless access point, gNB, etc) will act on the data/option that is presented to it, as it only arrives from a trusted domain.

	[SM] Okay, maybe add another bit "ignore this option"... but realistically this feels quite ad-hoc and not how I would design a protocol to talk to network nodes... I would like to see robust and reliable communication that does not rely on any path between sender and scheduling node to be fully compliant to some rules that require active intervention...

> 
>> How will the sender/scheduling node actually know that the option was visible outside the limited trust-domain? I guess the sending network needs to have clear egress policies about which "exits" can be taken
>> by MED adorned packets, but that means all exist nodes need to peek deep into the UDP headers...
> 
> The scheduling node (wireless access point, gNB) will use the data in MED with the assurance that it has transited only through domains which are trusted (or the whole flow encrypted if it transits an untrusted domain).

	[SM] It essentially needs to trust the full path not having done any shenanigans, is that really as robust and reliable as desirable for a method that aims at affecting QoS/priorities?


> Yes, the sending domains should have clear egress policy to forward only to a trusted domain, or encrypt across a untrusted network.
> And the receiving domain should verify that it is arriving from a trusted network likewise, or is encrypted.  (an example in 3GPP is the use of Security Gateways (SEG) across untrusted networks).

	[SM] I think I like the much less fickle approach where the MED option is always encrypted with a key only distributed to the relevant scheduling nodes.

> 
>> At that point I would argue that having the sender simply encrypt the option with a key the intended scheduler node(s) has/have makes a ton of sense (the scheduling node might even replace the encrypted
>> MED option with its decrypted representation of the MED option for the benefit of the end-node (which then does not also need the key, and can recognize whether the MED option was evaluated)).
>> 
>> Side-note: I am still puzzled at how a scheduler would look like that is supposed to act on such rich information essentially in real-time.... and how to secure such a scheduler against abuse.
> 
> Key provisioning and management is quite complex if we are considering N applications x M wireless networks x Large number of endpoints.

	[SM] So is keeping your trusted paths trust worthy... plus as I proposed, have the scheduling nodes replace the encrypted MED with a plain text one, so end nodes need no keys and immediately see what information was used by the scheduler...


> Note that the content of the packet is always encrypted, and the key management here is for the UDP option/metadata.

	[SM] I am pretty sure if MED takes off and offers tangible benefits for scheduling it will also be used for unencrypted media streams (to spare the scheduling node the work to deep dive into the packets and collect that information). However my interest is keeping the MED option end to end and signal the end points whether the MED option was evaluated/acted upon.


> If we are looking at the general internet,

	[SM] Which, respectfully we should for an IETF PS/Experimental draft, what 3GPP members do in their own private networks (assuming it is without side effects) would not really need IETF RFC status, no?


> I agree that what you suggest, or something like that, would be necessary to secure against abuse.
> In the draft, we have a smaller scope, i.e., that of a trusted limited domain consisting of application, wireless network.
> (Two examples there: (1) an Edge Site connected to a Mobile access network, (2) scenario in (1), but with an untrusted transport network in between over which the entire data is bulk encrypted using IPSec)


	[SM] To me this would make this an informational draft, "look IETFers here is what 3GPP members will do in their private networks". But if it is without side effects, it might not need an RFC at all.
	However, I assume that you want video transmission servers to actually gain the ability to emit MED options, so the whole thing then will not be so nicely compartmentalized, at that point I think looking outside of the initial private use-case gains more importance.

Regards
	Sebastian





> 
> BR,
> John
> 
> 
> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: Sunday, August 13, 2023 2:43 PM
> To: Kaippallimalil John <[e-mail]>
> Cc: [e-mail]; C. M. Heard <[e-mail]>; TSVWG <[e-mail]>; Sri Gundavelli <[e-mail]>
> Subject: Re: [tsvwg] signaling packet importance [was Re: New Version Notification for draft-herbert-fast]
> 
> Hi John,
> 
> 
>> On Aug 13, 2023, at 17:47, Kaippallimalil John <[e-mail]> wrote:
>> 
>>> My concern is that endorsing use of UDP options to signal in-network devices could cause the same reaction as IP HBH options - that they could be seen as unsafe to routers and could cause an over-reaction that causes >  deliberate blocking or stripping.
>>> 
>>> As the discussion noted, that’s not currently the case, or at least as best can be determined. I
>>> 
>>> It’d be useful to avoid creating new reasons that routers would want to interfere. I.e., the question isn’t whether IP options are an alternative - they clearly are the appropriate place for draft-kaippallimalil-tsvwg-media->  hdr-wireless and draft-reddy-tsvwg-explcit-signal - it’s whether using UDP options for those purposes could jeapordize them for everyone else.
>> 
>> The procedures in draft-kaippallimalil-tsvwg-media- hdr-wireless can in theory be realized by encoding it in IPv6 HBH options (IPv4 is another questions) but I share Mike's concern about the timeline.
>> (-- " Those might bear fruit someday, though the timeline is at best uncertain").
>> The authors (of tsvwg-media- hdr-wireless) are primarily looking to providing a viable solution for 3GPP in the short term (end of 2024 or so) even if it is an Experimental or Informational one.
>> 
>> And I acknowledge the issue that Joe has pointed to - of whether UDP options will be seen as unsafe, and a corresponding over-reaction.
>> Our attempt in draft-kaippallimalil-tsvwg-media- hdr-wireless to avoid this has been that:
>> -  the MED option is to be used only within a limited domain that spans an application network and wireless network with pre-established trust (RFC 8799)
>> -  if the MED option crosses an "untrusted network" (e.g. , a transport network in between), the entire flow should be encrypted such that MED is not visible.
>> -  if a MED option is visible outside the limited domain with trust (set of application, wireless networks), the draft recommends that MED be dropped.
> 
>        [SM] Could you clarify what exactly "drop MED" means here:
> a) the packet is dropped (by whom)?
> b) the MED option is ignored by the scheduling node, and excised
> c) the MED option is ignored by the scheduling node, and left alone
> d) the sender stops emitting MED options
> 
> How will the sender/scheduling node actually know that the option was visible outside the limited trust-domain? I guess the sending network needs to have clear egress policies about which "exits" can be taken by MED adorned packets, but that means all exist nodes need to peek deep into the UDP headers...
> 
> At that point I would argue that having the sender simply encrypt the option with a key the intended scheduler node(s) has/have makes a ton of sense (the scheduling node might even replace the encrypted MED option with its decrypted representation of the MED option for the benefit of the end-node (which then does not also need the key, and can recognize whether the MED option was evaluated)).
> 
> Side-note: I am still puzzled at how a scheduler would look like that is supposed to act on such rich information essentially in real-time.... and how to secure such a scheduler against abuse.
> 
> Regards
>        Sebastian
> 
> 
>> 
>> BR,
>> John
>> 
>> 
>> 
>> From: tsvwg <[e-mail]> On Behalf Of [e-mail]
>> Sent: Sunday, August 13, 2023 10:07 AM
>> To: C. M. Heard <[e-mail]>
>> Cc: TSVWG <[e-mail]>; Sri Gundavelli <[e-mail]>
>> Subject: Re: [tsvwg] signaling packet importance [was Re: New Version Notification for draft-herbert-fast]
>> 
>> My concern is that endorsing use of UDP options to signal in-network devices could cause the same reaction as IP HBH options - that they could be seen as unsafe to routers and could cause an over-reaction that causes deliberate blocking or stripping.
>> 
>> As the discussion noted, that’s not currently the case, or at least as best can be determined. I
>> 
>> It’d be useful to avoid creating new reasons that routers would want to interfere. I.e., the question isn’t whether IP options are an alternative - they clearly are the appropriate place for draft-kaippallimalil-tsvwg-media-hdr-wireless and draft-reddy-tsvwg-explcit-signal - it’s whether using UDP options for those purposes could jeapordize them for everyone else.
>> 
>> draft-daiya-tsvwg-udp-options-protocol-number is of a completely different nature; it aims to be part of the transport protocol in chaining the meaning of protocol layers, rather than encoding them all in the destination port of the first exchange. In that regard, it’s more like draft-touch-tcpm-sno (service number option), except that it would require similar ’next protocol’ identifiers at all protocol layers, which is (sadly) not the way current services and protocol stacks work.
>> 
>> Joe
>> 
>> 
>> —
>> Dr. Joe Touch, temporal epistemologist
>> http://www.strayalpha.com/
>> 
>> 
>> On Aug 12, 2023, at 6:14 PM, C. M. Heard <mailto:[e-mail]> wrote:
>> 
>> On Fri, Aug 11, 2023 at 7:47 PM Joe Touch wrote:
>> Just to be clear:
>> On Aug 11, 2023, at 2:42 PM, C. M. Heard <mailto:[e-mail]> wrote:
>> I've been pushing the idea to co-opt the per-fragment UDP options used for host-to-network signaling, and I'd like to make some comments about that.
>> 
>> This confuses transport options with network options.
>> 
>> Not confusion, but rather an explicit proposal to use the per-fragment options as network options instead of transport options. It is put forward to provide potentially workable solutions to the problems that draft-kaippallimalil-tsvwg-media-hdr-wireless and draft-reddy-tsvwg-explcit-signal are intended to solve.
>> 
>> Granted, an architecturally preferable way to accomplish these objectives would be to use IPv4 Options or IPv6 Hop-by-Hop Options. Indeed, I myself would prefer for IPv4/IPv6 Options to be used if the issues of high discard rates of packets with these options could be solved. There are efforts underway to mitigate the problems for IPv6 Hop-by-Hop Options. Those might bear fruit someday, though the timeline is at best uncertain. But as far as I know, the discard rates for IPv4 Options are equally dismal, and there are no efforts underway to fix that problem. Correction by parties with better knowledge of the facts than mine are invited.
>> 
>> My take is that the problems that draft-kaippallimalil-tsvwg-media-hdr-wireless and draft-reddy-tsvwg-explcit-signal (and possibly draft-daiya-tsvwg-udp-options-protocol-number as well) could, in principle, be solved by what I see as a modest change of direction to the UDP Options spec. Whether that would work out in practice is much less certain, for the reasons that Tom Herbert has pointed out. IMO it is a judgement call whether the chances are better to get IP Options (in any version) to work within our professional lifetimes. Given that, I don't think it would be right to turn draft-kaippallimalil-tsvwg-media-hdr-wireless and draft-reddy-tsvwg-explcit-signal away without a proper discussion.
>> 
>> Thanks,
>> 
>> Mike
>> 
>