Re: Design: Ignored Unknown Frame Types and Intermediaries

Roberto Peon <grmocg@gmail.com> Mon, 13 May 2013 18:39 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1D321F85E8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 11:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pYuPxeSSBHs for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 11:39:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 99B2721F869C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 13 May 2013 11:39:37 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ubxdc-0004Wo-0r for ietf-http-wg-dist@listhub.w3.org; Mon, 13 May 2013 18:38:20 +0000
Resent-Date: Mon, 13 May 2013 18:38:20 +0000
Resent-Message-Id: <E1Ubxdc-0004Wo-0r@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UbxdQ-0004RG-Ps for ietf-http-wg@listhub.w3.org; Mon, 13 May 2013 18:38:08 +0000
Received: from mail-oa0-f51.google.com ([209.85.219.51]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UbxdP-0002xw-EI for ietf-http-wg@w3.org; Mon, 13 May 2013 18:38:08 +0000
Received: by mail-oa0-f51.google.com with SMTP id f4so7886490oah.24 for <ietf-http-wg@w3.org>; Mon, 13 May 2013 11:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sICFryqx+HgAdfgsyUZP+r9qVTxzCzDWGjstjkBLGVY=; b=acJwqrSz11bbY8NEMhRmPeon7aDncqZScYItS8GmwPfjCrEAF+JDkHCnlMVm4TVCjJ KpGzTdq2K8WXKyRVFUH7FotDLvloUSx53xZaBAIcWZCpojmd0gPCe+cpBH86fkaeJlXx SsYYuvgIQ1Kni556vx5yoiO4bf9z7XO4m1R9XoHRvsjY7FBIJdN3FrJOsTZDtjTpTrOJ 1btQrlOXo6mvAQUjRjQOU5dDKtBUSJI75cCNp2UqjGi0x6vG855QtIqj/E27dE7d9REU 7amgKJ82abqkiBSKqTErCgYLbENYqkLpMCIXtcXYudQ5H2/n6SHhQ5gZiW9YAO2NeKnp jwdQ==
MIME-Version: 1.0
X-Received: by 10.60.46.70 with SMTP id t6mr13917132oem.121.1368470261591; Mon, 13 May 2013 11:37:41 -0700 (PDT)
Received: by 10.76.130.139 with HTTP; Mon, 13 May 2013 11:37:41 -0700 (PDT)
In-Reply-To: <CABP7Rbf+H=WarqFaV0UM5On-3FkYAspkC4OBzh1HE6EpQow94w@mail.gmail.com>
References: <CABP7Rbfko48A0yAceDeHfQKR7S6aW7AAAqCZroaZzTScTooOvw@mail.gmail.com> <09C78900-966B-46B0-AB97-1394FD05849A@checkpoint.com> <CAP+FsNe2L2aZbDhM4OiWmh7b7f0HkrVfGwa6aKkD2ohNNKJHxg@mail.gmail.com> <2124BAB0-8FF1-4D6D-BBD8-F042B1EA5F7B@checkpoint.com> <CABP7Rbf+H=WarqFaV0UM5On-3FkYAspkC4OBzh1HE6EpQow94w@mail.gmail.com>
Date: Mon, 13 May 2013 11:37:41 -0700
Message-ID: <CAP+FsNd3260xnQG8JU3UQkkSwaVhVgwkDPPcR02W_W0q12+HFw@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Yoav Nir <ynir@checkpoint.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e01494972d3f72b04dc9dcfe1"
Received-SPF: pass client-ip=209.85.219.51; envelope-from=grmocg@gmail.com; helo=mail-oa0-f51.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.689, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UbxdP-0002xw-EI 6e48bd58ce090755362d519bafea7bc8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design: Ignored Unknown Frame Types and Intermediaries
Archived-At: <http://www.w3.org/mid/CAP+FsNd3260xnQG8JU3UQkkSwaVhVgwkDPPcR02W_W0q12+HFw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17970
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

James:
Can you construct a case where, if you follow the rule spelled out in my
earlier email, you fail to achieve interop (because I can't)?

The rule is, essentially:
If a party to the communication ignores (or removes) something it don't
understand, that must not screw up the session.

That implies that, when you add anything that must be interpreted, it then
must be declared in the version string (i.e. new version) and thus agreed
upon by both parties up front, and if you don't negotiate that other
version, you don't get to add frames whose removal would screw up the
session.

Yoav:
I agree that intermediaries must be able to remove things they'd don't
understand, and saying so in the spec is reasonable, since it'll happen
anyway.

-=R


On Sun, May 12, 2013 at 9:29 PM, James M Snell <jasnell@gmail.com> wrote:

> On Sun, May 12, 2013 at 9:11 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> > That's fine for interoperability. And I believe that middleware such as
> > caching proxies or reverse proxies will simply ignore unrecognized frames
> > and pass them on.
> >
>
> Belief does not ensure interoperability.
>
> > Firewalls will either remove the unknown frames or reset the entire
> > connection, and they'll do so regardless of what the spec says. I think
> that
> > we should have text that says that middleware MAY remove frames not
> > specified in the base draft. The reason is that otherwise the only
> choice is
> > to reset the entire connection, which makes extending the protocol almost
> > impossible - you'll get into the unhappy place TLS is with "retry at
> TLS1.0
> > without extensions, and if that doesn't work go to SSL3", except it's
> worse
> > for HTTP because the unknown frame could happen at any point during the
> > connection.
> >
>
> Some frames might need to be removed, some might be ok to leave it.
> Some might not matter to the middleware at all. It's better to be
> explicit and allow for both cases.
>
> For instance, we can say that frame types in the range 0x00-7F are
> hop-by-hop and never forwarded on, but frame types in the range
> 0x80-0xFF are end-to-end and MUST be forwarded on, even if they are
> completely ignored by the middleware. That would not only ensure
> interoperability but would make use of the new extension points
> possible.
>
> - James
>
> > Yoav
> >
> > On May 12, 2013, at 9:15 PM, Roberto Peon <grmocg@gmail.com> wrote:
> >
> > I believe that the simplest thing is that, when you don't understand it,
> you
> > ignore it.
> >
> > If that frame was required at some semantic level, then you should have
> > rev'd the version number or changed the version string in some other way
> at
> > the start of communication. That is easy and robust.
> >
> > This does imply that changing any state which the baseline protocol of
> that
> > version depends upon is a no-no, but doesn't preclude changing state
> which
> > the baseline protocol of that version *doesn't* know about.
> >
> > Making that a MUST, i.e. something like:
> > And endpoint may use frames with opcodes other than those defined in this
> > specification, however it MUST NOT do so if ignoring such a frame would
> > cause an unexpected stream or session error, either directly or
> indirectly.
> > -=R
> >
> >
> > On Sat, May 11, 2013 at 9:58 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> >>
> >>
> >> On May 11, 2013, at 6:27 PM, James M Snell <jasnell@gmail.com> wrote:
> >>
> >> > In the current draft, endpoints are required to "ignore" unknown and
> >> > unsupported frame types. What's not yet clear, however, is whether
> >> > such frames are required to be forwarded on by intermediaries that do
> >> > not support them.
> >> >
> >> > In other words, A talks to C via reverse proxy B. A sends a stream
> >> > that includes EXTENSION_FRAME_TYPE that is unknown to B. Is B...
> >> >
> >> > A) Required to drop the frame silently without forwarding it on to C
> >> > B) Required to always forward the frame on to C
> >> > C) Neither, B can do whatever it wants
> >> >
> >> > There is an obvious impact here on the future deployment of new
> >> > extension frame types. If the answer is A or C, we'll have to wait on
> >> > infrastructure support to use new frame types, which would be
> >> > unfortunate.
> >> >
> >> > - James
> >>
> >> I think (C) is the only answer. Consider two types of proxies: an SSL
> >> accelerator and a firewall. The SSL accelerator doesn't want to break
> >> anything, so it will forward everything (B), while a firewall doesn't
> let
> >> things pass which it doesn't understand (A). I think this will be the
> >> behavior for these two kinds of proxy regardless of what we specify.
> >>
> >> Since the UA can never know in advance what the server will support,
> there
> >> has to be some "extension support discovery" anyways. Perhaps if we had
> that
> >> in the SETTINGS frame, the proxy could filter out.  For example, add a
> >> SETTINGS_SUPPORTED_EXTENSION, which will hold an extension supported by
> the
> >> sender. You will need multiple settings values for multiple extensions.
> The
> >> server would send the same list as the client, filtered down to the
> list of
> >> extensions that it supports. A proxy could trim the list further to
> remove
> >> things it's going to drop.
> >>
> >> Yoav
> >
> >
> >
> >
> > Email secured by Check Point
> >
> >
>