Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 24 March 2020 16:43 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD363A0C8A for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 09:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sx7HoFIFZJZh for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 09:43:14 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE933A0CB2 for <tsvwg@ietf.org>; Tue, 24 Mar 2020 09:43:13 -0700 (PDT)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id CA44C1B0023F; Tue, 24 Mar 2020 16:43:07 +0000 (GMT)
To: Tom Herbert <tom@herbertland.com>, "Black, David" <David.Black@dell.com>
Cc: tsvwg <tsvwg@ietf.org>
References: <CALx6S349SE2Ho0V2bJPSE7dh3+2f5Wiw1AofMke0RY4FwF=ebw@mail.gmail.com> <679FAA73-401E-499D-87CB-10F973E05DD6@strayalpha.com> <MN2PR19MB40455E00DB52880A38EB494C83F00@MN2PR19MB4045.namprd19.prod.outlook.com> <4FA8060E-C661-42FB-BCA1-43F32E5FA1F5@strayalpha.com> <MN2PR19MB40458C69C9C91C70AD889D3A83F10@MN2PR19MB4045.namprd19.prod.outlook.com> <CALx6S35J8K0bAmPp72svv+BuOKc1ZdrK_odfcJsPujmQz-iyyA@mail.gmail.com> <MN2PR19MB4045877E00DB58216A58A45883F10@MN2PR19MB4045.namprd19.prod.outlook.com> <CALx6S36eY1mv-US5sajO62wXGqPr=So3RJCedOT9rZU74Q2ZdQ@mail.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <571ab190-858f-47f3-1ef4-883d3d1287b1@erg.abdn.ac.uk>
Date: Tue, 24 Mar 2020 16:43:07 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CALx6S36eY1mv-US5sajO62wXGqPr=So3RJCedOT9rZU74Q2ZdQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/7vjMnB1XsaAqgSrWLi03QCQK-_o>
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 16:43:18 -0000

On 24/03/2020 16:31, Tom Herbert wrote:
> On Tue, Mar 24, 2020 at 9:17 AM Black, David <David.Black@dell.com> wrote:
>> Dell Customer Communication - Confidential
>>
>> Tom,
>>
>> In 20/20 hindsight, I've clearly not fully understood your original comment.
>>
>> Could you propose specific text changes that would address it?
>>
> David,
>
> My original comment was that the following text in the draft is not
> relevant for the reasons I mentioned. The change I suggest would be to
> simply remove the paragraph:
>
> "o On the one hand, protocols do not necessarily have an incentive to
> expose the actual information that is used by the protocol itself and
> could therefore manipulate the exposed transport header information to
> gain an advantage from the network. The incentive to reflect actual
> transport header information has to be considered when proposing a
> method."

Why do you think this is not a view held by some people?

This is a point that has been included in the draft for some 
considerable time, and consideration of incentives to lie has been a 
recurrent theme in understanding deployment stories. The present text 
simply notes this point, and then says it should be "considered".  The 
story of why TOS was extremely difficult to deploy outside of controlled 
environments is a nice example of this.

This is part of a two-part construction. I see this point as balanced in 
the second part (which I assume you would agree with), and I chose this 
re-ordering so that the second point was mentioned last

Gorry

> Tom
>
>
>> Thanks, --David
>>
>>> -----Original Message-----
>>> From: Tom Herbert <tom@herbertland.com>
>>> Sent: Monday, March 23, 2020 11:22 PM
>>> To: Black, David
>>> Cc: Joseph Touch; tsvwg
>>> Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> On Mon, Mar 23, 2020 at 6:48 PM Black, David <David.Black@dell.com>
>>> wrote:
>>>>> That sounds like it’s leaning towards extortion - the kind we have now, in
>>> which
>>>>> “if you don’t let us see your ports and we don’t like them, we’ll block you”.
>>>> That sounds like a networking version of turning Spinal Tap’s amps up to 11 ...
>>>>
>>>>
>>>>
>>>>> I’d lean the other way - that the network really shouldn’t be doing anything
>>> based on information
>>>>> gleaned from transports - explicitly given or not - because it only serves to
>>> create mutual escalation of misinformation.
>>>> ... and that looks like other end of the spectrum.
>>>>
>>>>
>>>>
>>>> What I had in mind was something more balanced about benefits to exposing
>>> some information to the network that motivate endpoints and endpoint
>>> implementers to do so ... where motivate is not intended to imply extortion-like
>>> threats, and the benefits aren’t necessarily the network doing something
>>> immediate based on the exposed information (there are several examples in
>>> Section 2.3 of the draft).
>>>>
>>>>
>>>> To be concrete, here’s one possible text change, based on taking out the
>>> words that seems to be the focus of this discussion:
>>>>
>>>>
>>>> OLD
>>>>
>>>>     o  On the one hand, protocols do not necessarily have an incentive to
>>>>
>>>>        expose the actual information that is used by the protocol itself
>>>>
>>>>        and could therefore manipulate the exposed transport header
>>>>
>>>>        information to gain an advantage from the network.  The incentive
>>>>
>>>>        to reflect actual transport header information has to be
>>>>
>>>>        considered when proposing a method.
>>>>
>>>> NEW
>>>>
>>>>     o  On the one hand, protocols do not necessarily have an incentive to
>>>>
>>>>        expose information that is used by the protocol.  The incentive
>>>>
>>>>        to expose transport header information has to be considered when
>>>>
>>>>        proposing a method to do so.
>>>>
>>> David,
>>>
>>> That's changing the meaning of the text. The original text was making
>>> a point that if transport layer information is exposed there needs to
>>> be an incentive for the host to set the information honestly and
>>> correctly. This is true, not just for transport layer information but
>>> for everything the host tells the network. An obvious example is TOS
>>> in IPv4-- left to their own devices everyone would just request the
>>> highest level of service of traffic for all packets. So we need some
>>> tangible incentive for user to be honest and correct. For instance,
>>> TOS might have worked if the user were explicitly charged for the
>>> higher level of service, but that would imply a contract between the
>>> network and the host is established and a whole bunch of mechanisms
>>> that require far more than just anonymously volunteering some
>>> arbitrary amount of transport layer information.
>>>
>>> Tom
>>>
>>>>
>>>> Which leaves room to argue that there is no incentive, or there is insufficient
>>> incentive, or the risks outweigh the benefits, etc.
>>>>
>>>>
>>>> Thanks, --David
>>>>
>>>>
>>>>
>>>> From: Joseph Touch <touch@strayalpha.com>
>>>> Sent: Monday, March 23, 2020 7:08 PM
>>>> To: Black, David
>>>> Cc: Tom Herbert; tsvwg
>>>> Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
>>>>
>>>>
>>>>
>>>> [EXTERNAL EMAIL]
>>>>
>>>>
>>>>
>>>> On Mar 23, 2020, at 3:19 PM, Black, David <David.Black@dell.com> wrote:
>>>>
>>>>
>>>>
>>>> [writing as draft shepherd]
>>>>
>>>>
>>>>
>>>> Point taken – would it be reasonable to rework that paragraph to observe
>>> that there should be incentives for endpoints to expose transport information,
>>> e.g., otherwise implementers may simply not bother?
>>>>
>>>>
>>>> That sounds like it’s leaning towards extortion - the kind we have now, in
>>> which “if you don’t let us see your ports and we don’t like them, we’ll block
>>> you”.
>>>>
>>>>
>>>> I’d lean the other way - that the network really shouldn’t be doing anything
>>> based on information gleaned from transports - explicitly given or not -
>>> because it only serves to create mutual escalation of misinformation.
>>>>
>>>>
>>>> Joe
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks, --David
>>>>
>>>>
>>>>
>>>> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Joseph Touch
>>>> Sent: Monday, March 23, 2020 11:20 AM
>>>> To: Tom Herbert
>>>> Cc: tsvwg
>>>> Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
>>>>
>>>>
>>>>
>>>> [EXTERNAL EMAIL]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 23, 2020, at 7:58 AM, Tom Herbert <tom@herbertland.com> wrote:
>>>>
>>>>
>>>>
>>>> Fundamentally, transport layer is end-to-end information. There is no
>>>> contract between end hosts and the network that hosts have to be
>>>> honest or correct in setting information in the transport layer-- the
>>>> only contract is between the endpoints.
>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>>
>>>>
>>>> Another point worth mentioning:
>>>>
>>>>
>>>>
>>>> - if endpoints can lie or mislead about transport info to get their way, they
>>> can, will, and IMO *SHOULD*.
>>>>
>>>>
>>>> That goes for using port 53 for nearly anything anyone wants to. Transport
>>> info isn’t there to make things nice for network operators - that’s what the
>>> network layer is for.
>>>>
>>>>
>>>> Oh, yeah, I know - network operators don’t want “heavy” stuff in *their*
>>> headers because it slows them down when they don’t want it. Too bad, IMO. If
>>> they want the info, they need to deal with the pain.
>>>>
>>>>
>>>> Joe
>>>>
>>>>