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

["Black, David" <[e-mail]>]

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?

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