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

[Gorry Fairhurst <[e-mail]>]

See below.

> On 24 Mar 2020, at 17:51, Tom Herbert <[e-mail]> wrote:
> 
> 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.
> 
OK, thanks for taking the time to detail this. I will try a reply  - forgive me, if I repeat things I have said in other rounds of discussion, but I will do my best to answer... see below.

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

Agree this text is more general. I will look at that text and see if these two paras can be moved.

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

True - but actually, I suggest this is true of any generalised header. It is true of a GRE tunnel header and other encaps.

> 2) Hop-by-Hop options are explicit
> so that the end host or application control their content,

Perhaps ... I would really encourage support this, APIs, protocols and the authentication methods to protect integrity of info, etc. The reason I keep pushing back a little is because I don’t know of people saying they are actually using extensions to manage and operate their networks, am I missing something? 

 I would like to stick with a scope that the document describes things that have been done. I know that both you and I, and others, have int area drafts that we’d like to see use of extension headers. Am I missing something? I didn’t see people running networks explain how they are using this. I would be really happy to understand deployment experience....

... if anyone else on the list also has this experience of reading and using extensions headers, let me know - off list if you prefer.

> 3)
> Hop-by-Hop options are the only protocol conformant method to expose
> arbitrary information to the network.

Not sure “only” and “conformant” are so helpful words here.

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

Not because I specifically don’t want that to be the case, only because I didn’t hear people saying they had experience of using extensions for operations support, to traverse firewalls, run measurement tools, inform QoS/SLA policers/classifiers, whatever. We need to get networking people to support them in routers etc.

Gorry

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