Re: Design: Ignored Unknown Frame Types and Intermediaries

Roberto Peon <grmocg@gmail.com> Mon, 13 May 2013 22:09 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 1620A21F869A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 15:09:30 -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 UdcHc-ePoECt for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 15:09:23 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id ADE3A21F8630 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 13 May 2013 15:09:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Uc0vR-0000ZJ-Us for ietf-http-wg-dist@listhub.w3.org; Mon, 13 May 2013 22:08:58 +0000
Resent-Date: Mon, 13 May 2013 22:08:57 +0000
Resent-Message-Id: <E1Uc0vR-0000ZJ-Us@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1Uc0vF-0000Ux-RV for ietf-http-wg@listhub.w3.org; Mon, 13 May 2013 22:08:45 +0000
Received: from mail-ob0-f176.google.com ([209.85.214.176]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1Uc0vE-000863-SU for ietf-http-wg@w3.org; Mon, 13 May 2013 22:08:45 +0000
Received: by mail-ob0-f176.google.com with SMTP id wc20so7043480obb.7 for <ietf-http-wg@w3.org>; Mon, 13 May 2013 15:08:18 -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=jbYeFk9fO05sLy4uDj6+WJW5SsAXj1z5AAIfFZSHMMw=; b=kcLKM1QNbG9gu+m++Xy2tLbqSUAYnZB+Q2Y7O0WEBaP7K8MdT9tP+h6wbs8x2dPbLU ylA/Me0DNZWhne/c7+pmPI6pff0LhEmmrY34P8hdUJiuDLwvGOF8z5uxNB6v5X6BPJAF yVck8h1ufaoF3ac5FxQAxvVJ7Sxulq/2SkdV5sFOtKy/8bML+IB4BcZvcvCE3HzyEH+A MLkZgNckhE71BVcvT7caGyWCaluAeMVroUCOla17PsUkLlao9wr7BDNYlf1CahkamG9D vDVftIabiLUYX3WH9QaKJQ900YCCJe49h3UifIgJEGSsqGQ3QhWWDLzHMQT8pksyWssy orXA==
MIME-Version: 1.0
X-Received: by 10.60.46.70 with SMTP id t6mr14622013oem.121.1368482898728; Mon, 13 May 2013 15:08:18 -0700 (PDT)
Received: by 10.76.130.139 with HTTP; Mon, 13 May 2013 15:08:18 -0700 (PDT)
In-Reply-To: <CABkgnnXJRHu_LsD+Fq9dTNi9Sqfmj0GQMBGO9QzZy6DCfxSJAQ@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> <CAP+FsNd3260xnQG8JU3UQkkSwaVhVgwkDPPcR02W_W0q12+HFw@mail.gmail.com> <CABkgnnXJRHu_LsD+Fq9dTNi9Sqfmj0GQMBGO9QzZy6DCfxSJAQ@mail.gmail.com>
Date: Mon, 13 May 2013 15:08:18 -0700
Message-ID: <CAP+FsNdoZNOV2JxHgVHorp94QC0+KGOrYpVdi5FoZ8jAEsGd5g@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, Yoav Nir <ynir@checkpoint.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=089e014949720f5d9304dca0c152
Received-SPF: pass client-ip=209.85.214.176; envelope-from=grmocg@gmail.com; helo=mail-ob0-f176.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.739, BAYES_00=-1.9, 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: maggie.w3.org 1Uc0vE-000863-SU 3a3ab0265978220f95b1fff8b0ecd282
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+FsNdoZNOV2JxHgVHorp94QC0+KGOrYpVdi5FoZ8jAEsGd5g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17982
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>

I believe that, if one does remove/ignore such frames the session may not
be as optimal as it might otherwise be, but the rule, by definition,
precludes the use of anything which would hinder interop if emitted, but
then ignored by the receiver.
The rule is that one MUST NOT send a frame if its removal would cause
session corruption/termination/problems.
So, can you provide an example? :)


I think the version string is the most robust way to ensure that an
intermediary does the right thing-- If an intermediary sees a version
string it doesn't recognize, it simply doesn't allow the negotiation of
that variant.
This is more simple because the lack of an explicit negotiation for this
will lead to either:
1) implementations which ignore the spec, since their mission is to provide
security and consistency
2) Clients, servers, and proxies all maintaining a heuristic and
table/history about when and why sessions were terminated when a not
standardized opcode was
 I don't want to have to have maintain a table of endpoints which have sent
me some error-code or terminated my session because I included an unknown
opcode type (that would be pretty complicated). This would have to be done
for both sides, for that matter.

I'd prefer to say that an intermediary MUST NOT touch things in the session
which it does not recognize if it doesn't know the version, but allowed the
version to be negotiated, and it MAY remove things it doesn't know from a
session when the version is one which is fully specified.

That allows the intermediary to simply not negotiate things it doesn't like
on a per-connection basis, instead of having to have this complex cache of
'this feature doesn't work when X,Y,Z'.

James has pointed out that a reverse proxy may still have some difficulties
with this, assuming it wishes to support an unknown extention, but, I think
that trade (no longer requiring clients and servers to have to worry about
this, while having the proxy continue to worry about it) is reasonable.

-=R



On Mon, May 13, 2013 at 2:13 PM, Martin Thomson <martin.thomson@gmail.com>wrote;wrote:

> On 13 May 2013 11:37, Roberto Peon <grmocg@gmail.com> wrote:
> > 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)?
>
> It's trivially possible to construct a scenario where this happens,
> but only if you don't write down a "MUST ignore" rule.  Once the rule
> is in place, then you are constraining future extensibility.  A "MUST
> ignore" rule is the easiest rule to get right, but there are other
> models you can use.
>
> > 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.
>
> The ignore/remove distinction is very important.  You can't
> selectively remove; it's all or nothing.  Either remove everything you
> don't know about or leave it all in.
>
> This consideration, along with James' hop-by-hop question does suggest
> a relatively simple way out:
>
> All unsupported/unknown frames that have a non-zero stream identifier
> MUST be ignored.  If a stream is forwarded by an intermediary, all
> unsupported/unknown frames MUST either be forwarded or removed; an
> intermediary MUST NOT selectively forward unsupported frame types.
> Unsupported/unknown frames with a zero stream identifier MUST be
> ignored and MUST NOT be forwarded.
>
> > 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.
>
> Yeah, we addressed that early on.  If you want to guarantee that the
> other guy is going to support something, either work out how to agree
> in-session (with those ignored frames) or negotiate a new protocol.
>