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

From: IAB Executive Administrative Manager <[email-masked]>
Date: Wed, 25 Aug 2021 11:43:59 -0700

This is an announcement of an IETF-wide Call for Comment on 
draft-iab-use-it-or-lose-it-02.

The document is being considered for publication as an Informational RFC 
within the IAB stream, and is available for inspection at:
<https://datatracker.ietf.org/doc/draft-iab-use-it-or-lose-it/>

The Call for Comment will last until 2021-09-22. Please send comments to
[email-masked] and [email-masked].

Abstract:

   The ability to change protocols depends on exercising the extension
   and version negotiation mechanisms that support change.  This
   document explores how regular use of new protocol features can ensure
   that it remains possible to deploy changes to a protocol.  Examples
   are given where lack of use caused changes to be more difficult or
   costly.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Aug 2021 15:00:42 -0400

I find the ending of the introcution:

    It is possible
    that these conclusions are less applicable to protocol deployments
    that have less scale and diversity, or operate under different
    constraints.

to seriously understate the limitations of this work.  The most 
important different cases I can see are the extremely widely deployed 
protocols at the Internet and Routing layers.  These protocols share the 
problems that are identified.  But the proposed approaches to improving 
the situation are likely to be problematic at best.  I think a much 
stronger disclaimer is needed.

Yours,
Joel

On 8/25/2021 2:43 PM, IAB Executive Administrative Manager wrote:
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Aug 2021 11:17:57 +1200

I support Joel's point, but here are two more. 

(1) At least for the Internet layer, we have a major problem in deploying new extensions, especially IPv6 extension headers, but this problem goes back 25 years as far as new IPv4 options are concerned. I hoped that section 2.3 "Multi-Party Interactions and Middleboxes" would touch on this, but it doesn't.

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. In my world, it's much more significant than the concerns in this draft, and none of the suggested techniques help, as far as I can see.

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?

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

Regards
   Brian Carpenter

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 26 Aug 2021 09:43:11 +1000

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

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.

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.

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 25 Aug 2021 17:57:00 -0700

> (1) At least for the Internet layer, we have a major problem in deploying new extensions, especially IPv6 extension headers, but this problem goes back 25 years as far as new IPv4 options are conce…

In the IP case, I found that using the example of the 4 bit version 
number is a bit weak. "The version field in IP was rendered useless when 
encapsulated over Ethernet" -- AFAIK, that's not just Ethernet. And I 
don't think anyone seriously considered using the same encapsulation for 
v4 and v6, or using the version number for anything besides debugging...

The really big example at the IP level would be the IP options (IPv4) or 
the IPV6 extension headers. Neither of those really works as intended, 
pretty much because of the implementation issues that Joel mentions. 
There is a reason why QUIC runs on top of UDP, not on top of 
"payload-type = QUIC" -- and that's very much in line with the central 
point in the draft.

> 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 have some sympathy for the assumption in the draft that features are 
not deliberately blocked. For me, the big issue partial blockage, such 
as intermediaries allowing some configuration of an e2e protocol but not 
others. For e2e deployments, that translates into random failures for 
obscure reasons. Discussing that will require a fair bit of text, much 
more than the current section 4.3. I can see why this would be better 
addressed in a different draft -- like the wire-image draft. But yes, 
this draft could explicitly point to wire-image for that discussion.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Aug 2021 15:38:52 +1200

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

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

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

I agree. All I'm suggesting is to state it a bit more explicitly. The current sentence is only a <shrug>.
> 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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Aug 2021 06:24:37 +0200

I might point out that some features *are* intentionally blocked.  
Random pings and traceroutes into a network is generally considered 
unfriendly and have been used as a means to identify points of attack.  
There are also features that**are *unintentionally* blocked, simply 
because they are not understood.  One of the challenges we face is the 
design choices that permit or deny such blocking.  It's made all the 
more challenging because protocol designers may not fully understand the 
weaknesses in their designs.

This having been said, I would be concerned about going too far down 
that path in this draft, because it really is a work unto itself to explore.

Eliot

On 26.08.21 02:57, Christian Huitema wrote:
> as intermediaries allowing some configuration of an e2e protocol but 
> not others. For e2e deployments, that translates into random failures 
> for obscure reasons. Discussing that will require a fair bit of text, 
> much more than the current section 4.3. I can see why this would be 
> better addressed in a different draft -- like the wire-image draft. 
> But yes, this draft could explicitly point to wire-image for that 
> discussion.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 30 Aug 2021 10:50:42 +0200 (CEST)

>     Il 26/08/2021 06:24 Eliot Lear <[email-masked]> ha scritto:
> 
> 
> 
>     I might point out that some features are intentionally blocked.  Random pings and traceroutes into a network is generally considered unfriendly and have been used as a means to identify points of attack.  There are also features that are unintentionally blocked, simply because they are not understood.  One of the challenges we face is the design choices that permit or deny such blocking.  It's made all the more challenging because protocol designers may not fully understand the weaknesses in their designs.
> 
The "Limiting participation" section is also affected by this. The first paragraph sounds like advocating that we should have less diversity in Internet operations or protocol implementations, so that we can have the few operators agree among themselves on whatever is necessary to make new features work. (This was indeed the approach of the DNS flag day, which was only possible because there are many DNS operators but very few DNS implementers.) Then, the second paragraph provides examples which are rather related to preventing in-network blocking and meddling by middleboxes and network operators.

I think both approaches can help extensibility but create other problems - this should be discussed or at least mentioned.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy