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

[Tom Herbert <[e-mail]>]

On Tue, Mar 24, 2020 at 9:43 AM Gorry Fairhurst <[e-mail]> wrote:
>
>
> On 24/03/2020 16:31, Tom Herbert wrote:
> > On Tue, Mar 24, 2020 at 9:17 AM Black, David <[e-mail]> 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?
>
Gorry,

I'm only giving my opinion.

> 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

It was not previously mentioned in the context of extension headers.
This is a general consideration for any unauthenticated plaintext data
in a packet that an intermediate node chooses to consume. As Joe said,
in the absence of any requirement or contract, it's the prerogative of
the host to manipulate packet contents as it sees fit to gain an
advantage (where sometimes the "advantage" is just that packets get
delivered and not dropped).

> 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

I provided text with three tangible benefits of exposing transport
layer information in Hop-by-Hop options, namely: 1) Hop-by-Hop options
work with any transport protocol, 2) Hop-by-Hop options are explicit
so that the end host or application control their content, 3)
Hop-by-Hop options are the only protocol conformant method to expose
arbitrary information to the network. I don't see that the latest
draft includes these, especially points #1 and #3. Why did you choose
to omit these in the latest draft?

Tom

>
> Gorry
>
> > Tom
> >
> >
> >> Thanks, --David
> >>
> >>> -----Original Message-----
> >>> From: Tom Herbert <[e-mail]>
> >>> 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 <[e-mail]>
> >>> 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 <[e-mail]>
> >>>> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> >>>>
> >>>>