Re: [Edm] [arch-d] Call for Comment: <draft-iab-use-it-or-lose-it-02> (Long-term Viability of Protocol Extension Mechanisms)

[Brian E Carpenter <[e-mail]>]

On 26-Aug-21 11:43, Martin Thomson wrote:
> On Thu, Aug 26, 2021, at 09:17, Brian E Carpenter wrote:
>> Looking back in the draft, I see that it intentionally ducks the 
>> question: "This document largely assumes that extensions are not 
>> deliberately blocked." But what if they are? That's what firewalls do 
>> for a living and it's a major block on innovation. 
> 
> Yes, you are not the only one.
> 
> However, this is very much not in scope for this work.  Another document can attempt to convince people that their security goals might need to come second to allowing innovation.  (I realize that this might diminish its value for you, but that larger scope is a larger lift than I'm willing to undertake.)
> 
>> I'm not suggesting that this document can solve the problem, but can we 
>> have a more complete acknowledgement of it than the sentence quoted 
>> above?
> 
> I can see two angles on this.
> 
> 1. Where the firewall knows about a feature and specifically chooses to blocks it.
> 
> 2. Where the firewall doesn't know about a feature and blocks it because it doesn't understand it.
> 
> Can you agree that there is nothing we gain from trying to do anything about (1)?

Not much, because sadly Steve Bellovin's "Distributed Firewalls" paper from 1999 failed to revolutionise the industry. (The point being that configuring and applying such blocking *only* at the destination host allows consenting hosts to receive everything they want and drop everything they don't want.)

> 
> For (2), I very deliberately avoided making the distinction.  My experience with firewalls varies.  We had a bunch of really constructive discussions with Web Application Firewall people who very much don't want to block innovation, but who had done so inadvertently.  On the other hand, blocking the unknown is very much a stated goal of many SIP SBCs.

Indeed. Also solved 20+ years ago by Bellovin, but such is history.

> 
> As far as the pain we all feel as a result of the policies these firewalls apply, that's just part of our job.
> 
> At best, the only thing we might do is acknowledge that this distinction exists.  The conclusion would still be the same though.  We might disagree with the policy, or even the right to apply the policy, but as long as we can't prevent someone from applying the policy, it still results in hard constraints for which this document has no answers.

I agree. All I'm suggesting is to state it a bit more explicitly. The current sentence is only a <shrug>.
> 
>> (2) Again in 2.3 "Multi-Party Interactions and Middleboxes", should 
>> there be a discussion of a complex situation where N peers are 
>> communicating using protocol P, but each peer potentially supports a 
>> different subset of extensions? That gives you up to N^2 possible 
>> variants. It's not insoluble, but it needs a bit of care in protocol 
>> design (and is different than in a traditional client/server model).
> 
> That seems like it is not in scope here, but more of a question of how you might design a multi-party protocol for extension.

True, but the section's title made me expect more than I found in the text.

   Brian