Re: [tsvwg] (transport) RE: Advance notice on request to poll TSVWG for adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03

[Bill Gage <[e-mail]>]

In many wireless networks, the Wireless Node acts like a NAT or proxy so 
that the IP address seen by the server is associated with the Wireless 
Node, not (directly) with the client. Even if the client IP address is 
visible to the server, the Wireless Node must be on the (downlink) 
forwarding path so that it can intercept a packet destined for the 
client and redirect the packet to the access node that is serving the 
client.

Given this, I think you could incorporate the metadata into a 
destination options header. A number of surveys have indicated that IPv6 
packets with destination options are not dropped in-transit, unlike the 
problems experienced with HbH options.

Destination options are independent of the transport protocol and, so, 
would be applicable to UDP, TCP, RTP, QUIC, etc. Destination options can 
also be included in an authentication header integrity check value for 
protection.

It would be fairly easy for a server to announce support for providing 
metadata in the destination option of an initial packet and only provide 
subsequent metadata if the Wireless Node (or client) provided a 
reciprocal indication of support in the destination option of a response 
packet.


/bill


On 2023-10-31 1:52 p.m., Kaippallimalil John wrote:
> Hi Tom,
> 
>> Is there significance to referring to the "outer UDP packet" instead of just the
>> "UDP packet"? Are you assuming a UDP tunnel is always used?
> 
> 	[JK] Yes, UDP tunnel is always used. (see Figure 5 /section 6.3 in draft)
>>
>> Since this makes the information end-to-end, how does it interact with or
>> complement the data in a UDP transport layer protocol such as QUIC?
>> For example, would MED data in a UDP Option be useful with RTP/QUIC? I
>> would also point out that QUIC endeavours to encrypt the end-to-end
>> information, do you believe that MED data in a UDP Option would be similarly
>> encrypted (that would ensure that the network won't try to read or modify
>> the data)?
> 
> 	[JK] MED is still sent per packet.
> With QUIC or RTP, it would be a UDP in UDP tunnel, with the outer header UDP option carrying MED.
> The inner packet is sent end-to-end and encrypted (or not) end-to-end. MED in outer UDP is used for classifying in wireless network.
> 
> The information in MED does not contain user's data or content related data (like CSRC in RTP),
> so there should be no need to encrypt - the data is more like the M bit, Seq#, SSRC, .. of RTP in RFC 9335 (Completely Encrypted RTP) which are only authenticated.
> In the draft we specify that MED is sent only within a trusted limited domain and if it crosses an untrusted/transit network, everything must be encrypted.
> Typically security gateways are used at the boundaries (see section 6.2, and Figure 4) in such cases and the draft is (re)stating that.
> Authentication of MED may be needed to detect tampering on path if its usage extends beyond such limited domains.
> 
> BR,
> John
> 
> 
>> -----Original Message-----
>> From: Tom Herbert <[e-mail]>
>> Sent: Tuesday, October 31, 2023 10:54 AM
>> To: Kaippallimalil John <[e-mail]>
>> Cc: C. M. Heard <[e-mail]>; Sri Gundavelli
>> <[e-mail]>; Spencer Dawkins at IETF
>> <[e-mail]>; Sebastian Moeller <[e-mail]>;
>> Joe Touch <[e-mail]>; TSVWG <[e-mail]>
>> Subject: Re: (transport) RE: [tsvwg] Advance notice on request to poll
>> TSVWG for adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03
>>
>> On Tue, Oct 31, 2023 at 7:20 AM Kaippallimalil John
>> <[e-mail]> wrote:
>>>
>>> Hi,
>>>
>>> Thanks for this feedback. Much of it has been factored into the proposed
>> revision to use MED in outer packet UDP option for now.
>>>
>>> Further responses tagged with [JK]:
>>>
>>>> But the big elephant in the room is that
>>>> draft-ietf-tsvwg-udp-options exclusively defines TRANSPORT options
>>>> designed to be consumed by endpoints, not NETWORK options designed
>>>> to be inspected by routers or other middleboxes. If
>>>> draft-kaippallimalil-tsvwg-media-hdr-wireless-03
>>>> is to be adopted as a basis for future work, then in my opinion one
>>>> of the adoption questions should be whether the WG would be willing
>>>> to make this change of direction to draft-ietf-tsvwg-udp-options.
>>>>
>>>> The rather lengthy previous discussion pretty much left this last
>>>> point up in the air, but I came away with the conclusion that trying
>>>> to fix
>>>> IPv6 HbH options is probably the better alternative in the long run.
>>>
>>>          [JK] The authors discussed this and related notes from Alex with the
>> various trade-offs of each of the transports.
>>> For this draft, MED in outer UDP packet option from server (Provider-A) to
>> wireless node (Provider-B) is sufficient.
>>> The only potential drawback may be that the option at the end of the
>> packet may affect performance, or may not depending on the
>> implementation.
>>
>> Hi John,
>>
>> Is there significance to referring to the "outer UDP packet" instead of just the
>> "UDP packet"? Are you assuming a UDP tunnel is always used?
>>
>> Since this makes the information end-to-end, how does it interact with or
>> complement the data in a UDP transport layer protocol such as QUIC?
>> For example, would MED data in a UDP Option be useful with RTP/QUIC? I
>> would also point out that QUIC endeavours to encrypt the end-to-end
>> information, do you believe that MED data in a UDP Option would be similarly
>> encrypted (that would ensure that the network won't try to read or modify
>> the data)?
>>
>> Tom
>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: C. M. Heard <[e-mail]>
>>>> Sent: Saturday, October 28, 2023 12:53 PM
>>>> To: Kaippallimalil John <[e-mail]>; Sri
>>>> Gundavelli <[e-mail]>; Spencer Dawkins at IETF
>>>> <[e-mail]>
>>>> Cc: Tom Herbert <[e-mail]>; Sebastian Moeller
>>>> <[e-mail]>; Joe Touch <[e-mail]>; TSVWG
>>>> <[e-mail]>
>>>> Subject: Re: [tsvwg] Advance notice on request to poll TSVWG for
>>>> adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03
>>>>
>>>> On Sat, Oct 28, 2023 at 9:50 AM Tom Herbert wrote:
>>>>> On Sat, Oct 28, 2023 at 9:18 AM Sebastian Moeller wrote:
>>>>>> Unless the respective layer's data is encrypted, intermediate
>>>>>> nodes obviously can look into packets at every level they
>>>>>> desire, and since they do not need to ask for permission there
>>>>>> is really nothing stopping them... Given that fact, it seems
>>>>>> academic to claim there is a practical difference in usability of UDP
>> options and IPv6 HBH.
>>>>>
>>>>> I think there are material differences. UDP Options only work with
>>>>> UDP, UDP options are in protocol trailers which would be
>>>>> problematic to support in router hardware data path, and there's
>>>>> no distinction between transport layer options and network layer
>>>>> options (i.e. last thing we want is for some router to burn cycles
>>>>> parsing and skip over a bunch of transport layer options to find
>>>>> the network layer options they're interested in).
>>>>
>>>> I'd like to answer these points.
>>>>
>>>> 1. UDP Options only work with UDP.
>>>>
>>>> Correct.
>>>>
>>>> On the other hand, IPv6 HbH options work only with IPv6 and by all
>>>> accounts suffer from an egregious drop rate in today's open Internet.
>>>> There is some empirical evidence that the Internet is much more
>>>> tolerant of UDP options; however, the measurements didn't test what
>>>> happens when UDP Length == 8 (which would be required by the
>>>> potential fixes in 2 and 3 below).
>>>>
>>>> 2. UDP options are in protocol trailers which would be problematic
>>>> to support in a router's [or any middlebox's] hardware data path.
>>>>
>>>> Correct but potentially fixable: draft-ietf-tsvwg-udp-options
>>>> defines per- fragment options, which do not have that disadvantage.
>>>> Moreover, any host to network signalling in a packet that uses UDP
>>>> fragmentation would necessarily have to put such signals in the
>>>> per-fragment options area, not in the trailer (which cannot in
>>>> principle be located until the packet is reassembled). There is some
>>>> waste of space by using an atomic FRAG option, but that could in
>>>> principle be mitigated by introducing a third format that omits the
>> Identification, Frag.
>>>> Offset, and Reass DgOpt Start fields (this would be useful in any
>>>> situation where an endpoint wants to hide one or more UNSAFE
>> options).
>>>>
>>>> 3. There's no distinction between transport layer options and
>>>> network layer options.
>>>>
>>>> Again, correct but potentially fixable: add a proviso to the spec
>>>> that any option intended for the endpoint use  only SHOULD be in the
>> trailer.
>>>>
>>>> My intent here is not to advocate for the changes, but rather to
>>>> point out that they are likely to be NECESSARY to turn UDP options
>>>> into a suitable carrier for host-to-network signalling. I brought
>>>> these points up before, but I didn't see them addressed in
>>>> draft-kaippallimalil-tsvwg-media-hdr-wireless-
>>>> 03.
>>>>
>>>> But the big elephant in the room is that
>>>> draft-ietf-tsvwg-udp-options exclusively defines TRANSPORT options
>>>> designed to be consumed by endpoints, not NETWORK options designed
>>>> to be inspected by routers or other middleboxes. If
>>>> draft-kaippallimalil-tsvwg-media-hdr-wireless-03
>>>> is to be adopted as a basis for future work, then in my opinion one
>>>> of the adoption questions should be whether the WG would be willing
>>>> to make this change of direction to draft-ietf-tsvwg-udp-options.
>>>>
>>>> The rather lengthy previous discussion pretty much left this last
>>>> point up in the air, but I came away with the conclusion that trying
>>>> to fix
>>>> IPv6 HbH options is probably the better alternative in the long run.
>>>>
>>>> Mike Heard