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

[Tom Herbert <[e-mail]>]

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."

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
> > >
> > >