Subject: Re: [tsvwg] I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Oct 2017 11:38:58 +1300

Switching to tsvwg. 6man is Bcc'ed. Previous discussions followed on from
https://mailarchive.ietf.org/arch/msg/ipv6/wb339ewBLP7Ijj2eCotCt-W_g8Y

On 20/10/2017 11:00, Tom Herbert wrote:
> On Thu, Oct 19, 2017 at 2:41 PM, Manfredi, Albert E <
> [email-masked]> wrote:
> 
>> -----Original Message-----
>> From: ipv6 [mailto:[email-masked]] On Behalf Of Toerless Eckert
>>
>>> Finally wrt. architectural cleanlyness: Per-flow service negotiation
>>> IMHO is clearly a transport layer function, there is no concept of
>>> 5-tuple flows at IP layer.
>>
>> I would agree I  principle, although IPv6 does have that flow label that
>> makes the 5-tuple less essential to identify an individual "flow," and it
>> sits at layer 3.
> 
> 
> Right.
> 
> 
>> The problem remains, though: security mechanisms, which render the layer 4
>> QoS knobs unworkable. Everything outside the "security enclaves" at either
>> end, and these security enclaves might just be inside the two end hosts
>> themselves, will have to be delivered best effort.
>>
>> Bert, I don't follow. One of the big wins using the 3-tuple is that it can
> still indicate a flow even if all the transport transport headers and
> payload are encrypted. So this should allow specifying QoS without
> revealing anything about the content except that the sender wants to group
> certain packets together as a flow and apply QoS on them.

Exactly. That's also why the flow label and traffic class are not covered
by IPSec authentication, in case some mechanism changes them en route.

   Brian