Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

[Mirja Kuehlewind <[e-mail]>]

Hi Martin,

Thanks for your more elaborated review. I don’t think there was an intention in the document to say that „listed practices are privileged and therefore deserving of protection“ but I can see how you could read it this way. I think the intention was to rather not make a judgement if these practices are „good“ or „bad“ because the assumption was that it would be even harder to find consensus on that but I agree that the document could at least explicitly state that these practices are not endorsed and not all of them are seen as worth supporting in future or any way desirable.

However I still think it is important to document current practices and spell out implication that changes in the Transport Layer can have.  I also agree that the document got a bit redundant in the mean time and some of the „could“ and „might“ might actually go too far beyond the goal of documentation. 

The document was initially not intent to talk about potential solutions or future approaches to address desired implications that have been identified. However there was quite a bit of feedback that the document should go one step further. We could reconsider this approach but I actually think the document does a good job listing potential option to move forward. I hope this document can provide a common basis for understanding problems and therefore design work the ietf might do in future in this space. However the goal right now is really documentation and not making design decisions. 

Mirja


> Am 06.11.2019 um 05:10 schrieb Martin Thomson <[e-mail]>:
> 
> I just read this document.  tl;dr, I agree with David, but I'd like to provide rationale in long-form.
> 
> 
> The introductory material is largely quite good.  Though I found it to be a little long-winded and a bit repetitious, the thesis it sets up is an oft-repeated theme of recent discussion: encryption has these benefits, but increased deployment of encryption affects certain existing practices.  Add text on ossification.  In the abstract, that's all non-controversial.  The risk that this is a repetition of RFC8404 is tempered by the prospect that this document might include a more detailed analysis of transport-level mechanisms.
> 
> However, the remainder of the document says something different.  In reading Ekr's review here, I thought that might be through implication, but I found that it was far more direct.  There is an assumption throughout that the listed practices are privileged and therefore deserving of protection.  No attempt is made to acknowledge that some of these practices are can be harmful in various ways.  No recognition is given to the possibility that involving endpoints might offer alternative methods toward the same ends.  This is perhaps exemplified in the conclusion, which states:
> 
>> An increased pace of evolution therefore needs to be accompanied by methods that can be successfully deployed and used across operational networks.
> 
> And:
> 
>> Protocols that change their transport header format (wire image) or their behaviour (e.g., algorithms that are needed to classify and characterise the protocol), will require new network tooling to be developed to catch-up with each change.  
> 
> The use of "needs" and "will" in these statements is emblematic of the theme that carries throughout this conclusion and - to a lesser extent - the preceding sections: the document clearly states that these goals are important and stresses the importance of finding replacements.  For instance, I don't think it is appropriate for an on-path box to reset a flow that doesn't conform to some ideal (S3.2.4).  If I were to state the requirement for a network operator it would be that it be possible to identify and isolate sources of traffic that are consuming disproportionate amounts of resources.  That might avoid any implication that the network operator be able to measure goodput (S3.1.2), for instance.
> 
> End-to-middle and middle-to-end signaling is something this organization has repeatedly attempted to tackle.  It's a hard problem.  Success has been patchy.  Though we might debate relative success, successful signals are few in number.  This document contains a direct and specific plea.
> 
> It is possible that this problem could be addressed by adding water until this skew is sufficiently diluted.  Sadly, the homeopathic approach we took with RFC 8404 failed.  The IETF ended up publishing an RFC in the absence of consensus.  I don't see that tactic being any more effective in this case.  The catalogue of techniques here is somewhat interesting, even if it is now outdated as Bernard suggests.  A document with the right framing might work, but that would omit any conclusion other than the one that says that these techniques are approaching extinction.  Though that might be a shame in some ways - the loss of the ability to conduct research in some ways is a loss - those are the facts on the ground.
> 
> As this is a document that intends to represent consensus, I have to oppose publication on the grounds that it includes an ask I disagree with.  I assert that it would be better to concentrate on building those signals, even if it is one hard-earned bit at a time.  For instance, let's see how ECN and spin work out in QUIC.
> 
> 
>> On Wed, Nov 6, 2019, at 09:10, David Schinazi wrote:
>> I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This 
>> document discourages transport header encryption and publishing it 
>> could harm future protocol development.
>> 
>> David
>> 
>>> On Tue, Nov 5, 2019 at 1:04 PM Joe Touch <[e-mail]> wrote:
>>> 
>>> 
>>>> On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind <mirja.kuehlewind=[e-mail]> wrote:
>>>> 
>>>> What I’m hearing is that 2-3 people think this is not aligned but don’t actually say why exactly they think that
>>> 
>>> That’s not what we’re saying. We gave reasons. 
>>> 
>>> Joe 
>> _______________________________________________
>> saag mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/saag
>> 
>