Re: HTTP router point-of-view concerns

Roberto Peon <grmocg@gmail.com> Thu, 11 July 2013 22:57 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 E7FC011E8139 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2013 15:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.544
X-Spam-Level:
X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.054, 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 BYqoofCIijFA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2013 15:57:49 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 63F8511E8136 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 11 Jul 2013 15:57:49 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UxPnb-0007QW-St for ietf-http-wg-dist@listhub.w3.org; Thu, 11 Jul 2013 22:57:19 +0000
Resent-Date: Thu, 11 Jul 2013 22:57:19 +0000
Resent-Message-Id: <E1UxPnb-0007QW-St@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 1UxPnT-0007PW-M6 for ietf-http-wg@listhub.w3.org; Thu, 11 Jul 2013 22:57:11 +0000
Received: from mail-ob0-f169.google.com ([209.85.214.169]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UxPnS-0006V2-HM for ietf-http-wg@w3.org; Thu, 11 Jul 2013 22:57:11 +0000
Received: by mail-ob0-f169.google.com with SMTP id up14so10761400obb.28 for <ietf-http-wg@w3.org>; Thu, 11 Jul 2013 15:56:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UKfaepfYBT0j294so41XyWoMZyYKSqnkHX2l1hkmAdU=; b=PD5lGMTdJaNBoZKz95ZICDUCcd6aYsM8svXSW99Tp6sn1exJtQ/tfo8u6GmMXS1e0z v288rYMHWMdhKSfCdc2+iI/JL6DnmDV2A46Y1ZPIZ/mODh7OXBJNJd38oM4D4kYzLurG oXto6OFRQnW2WqFs1qAYwmwiGo4zgf754hMjK+uCYSDvE0OWrDioqJ0HDQSP7yujxEG5 5krceoSeEUHd0PfDHtoq5ckAyh1z/eOrj1q4kHHj2QqbiYJmDYecVdHMTKT3obzCaL11 ODCer6t9/ucvSfVlEYM6HMzB1vxzB6X9hDZ16pMBG7khuFq4oFixwZEFV/ilS/pFBFmm PG+A==
MIME-Version: 1.0
X-Received: by 10.60.95.198 with SMTP id dm6mr33703263oeb.44.1373583404430; Thu, 11 Jul 2013 15:56:44 -0700 (PDT)
Received: by 10.76.91.229 with HTTP; Thu, 11 Jul 2013 15:56:44 -0700 (PDT)
In-Reply-To: <21347651-656B-4BA0-9261-830D09DAC883@gmail.com>
References: <CA+qvzFPUpcm6kUtJx+rTw8Dpp4Gtx4Bmr3XPDhjNsjchUfN9_w@mail.gmail.com> <51DE1E32.9010801@treenet.co.nz> <CAP+FsNdcYhA=V5Z+zbt70b5e7WmcmXgjG5M9L3vfXeXfTwmRnw@mail.gmail.com> <51DE327C.7010901@treenet.co.nz> <CABkgnnXeqD6wh0dcJ1Dz=4PLAJNkDeGcCuzMr9ATd_7xS7nbGQ@mail.gmail.com> <CABP7RbcUkLf3CTAB4jwicnsiKWLGVY6=hX0k=0256SR_gcVt9A@mail.gmail.com> <092D65A8-8CB7-419D-B6A4-77CAE40A0026@gmail.com> <CAP+FsNfpHY-Eai7T+vW01LRPweKmSfVhWO-Tj0ii4wWzX6fwUg@mail.gmail.com> <9AF548E8-D4CD-426B-9F6F-F390476821AA@gmail.com> <CAP+FsNev6zz2VHyj7KTBwHLMagP=n6EOiM_5UFvm13y25Bmx_Q@mail.gmail.com> <21347651-656B-4BA0-9261-830D09DAC883@gmail.com>
Date: Thu, 11 Jul 2013 15:56:44 -0700
Message-ID: <CAP+FsNcwaAUbsL4fhmm9bRxYT74BSgH_XmZKdhcW+ge_kW3PMg@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Sam Pullara <spullara@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="089e011606f4e3f9c404e1444efc"
Received-SPF: pass client-ip=209.85.214.169; envelope-from=grmocg@gmail.com; helo=mail-ob0-f169.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.646, 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 1UxPnS-0006V2-HM f69f31d41230b5ec04d5d5f55db5cc3b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP router point-of-view concerns
Archived-At: <http://www.w3.org/mid/CAP+FsNcwaAUbsL4fhmm9bRxYT74BSgH_XmZKdhcW+ge_kW3PMg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18713
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>

Thusfar, the feedback we're received from security experts indicates that
it is comparable to an attack without the compression (i.e. requires
exponential time w.r.t. the size of the plaintext, or comparable to forcing
the use of a brute-force attack).

-=R


On Thu, Jul 11, 2013 at 3:43 PM, Sam Pullara <spullara@gmail.com> wrote:

> The CRIME attack seems the biggest reason to switch something else.
> Brutal. I assume that we are positive that the proposed encoders don't have
> similar issues since they don't expose substrings of the cookies.
>
> Sam
>
> On Jul 11, 2013, at 12:56 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
> A fair bit of this quantitative analysis was published with the SPDY
> whitepapers.
>
> Yes, packets matter.
> Yes, RTT matters most.
> number of packets is highly correlated with bytes on the wire
>
> The encoders/compressors here were developed because:
> 1) any stream compressor is subject to the CRIME attack
> 2) gzip uses more memory/cpu than these more specific schemes
> 3) the encoders/compressors here were developed with an eye towards
> allowing intermediaries to have much more control over the size and cost of
> the compression stuff
>
> The upstream path is often very limited.
> If we want to have server push or similar be competitive with inlining, we
> need the cost of that metadata to be low.
> -=R
>
>
> On Thu, Jul 11, 2013 at 12:51 PM, Sam Pullara <spullara@gmail.com> wrote:
>
>> It would be great to have a quantitative analysis of the benefit we can
>> expect to get on various types of links and header sets so we could compare
>> various implementations. I'm unconvinced these solutions are much better
>> for real requests than gzip with an initial dictionary. Also, isn't bytes
>> on the wire the wrong metric? Aren't these slow links much more sensitive
>> to the number of packets / round trips?
>>
>> Sam
>>
>> On Jul 11, 2013, at 12:37 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>
>> If one doesn't care about number of bytes on the wire, or if one doesn't
>> care about user-perceived latency, then obviously compression is a waste.
>> If one does care, then, especially on slower links, header compression
>> does a great deal to reduce latency as the HTTP metadata eats up a
>> significant fraction of available bandwidth on those links.
>>
>> -=R
>>
>>
>> On Thu, Jul 11, 2013 at 10:21 AM, Sam Pullara <spullara@gmail.com> wrote:
>>
>>> How sure are we that the entire idea of header compression isn't a bad
>>> idea? I implemented something similar in the WebLogic T3 protocol
>>> (BubblingAbbrevTable, probably still in there) and it was mostly just a
>>> pain. If I were to go back I would just use gzip with some agreed upon seed
>>> dictionary. Thought I would bring this up since it seems like it is a very
>>> controversial feature to begin with.
>>>
>>> Sam
>>>
>>> On Jul 11, 2013, at 10:14 AM, James M Snell <jasnell@gmail.com> wrote:
>>>
>>> > Yes, the ability to set compression context size to 0 is very useful.
>>> > My fears around this area are:
>>> >
>>> > 1. In order to achieve maximum throughput, Intermediaries may opt to
>>> > *always* set compression context to 0, forcing the headers to always
>>> > be passed as Literals, killing the utility of having the header
>>> > compression mechanism there in the first place.
>>> >
>>> > 2. The assumption of a non-zero default compression context size when
>>> > the connection is established opens a race condition that a malicious
>>> > sender could exploit in a denial of service attack. Yes, the receiver
>>> > could opt to terminate the connection once it detects bad behavior,
>>> > but there is still a potential window of time there where the receiver
>>> > could be forced to do significant additional work.
>>> >
>>> >  (This is particularly bad given that header continuations are
>>> unbounded.)
>>> >
>>> > 3. Setting the compression context size to 0 does not stop the sender
>>> > from sending the Indexed Literal instructions anyway. The receiving
>>> > endpoint would still be required to process those instructions even if
>>> > the data is not actually being indexed, causing CPU cycles to be
>>> > consumed. For any individual block of headers it may not be a
>>> > significant load, but it's something that needs to be addressed.
>>> >
>>> >  (This can be fixed in the spec by stating that any attempt to Index
>>> > any individual (name,value) whose size is greater than the available
>>> > header table size results in a Compression Error. Making this change
>>> > would mean that when Compression Context size is 0, the only operation
>>> > that would not result in an error is Literal without Indexing. This
>>> > was discussed on the list but as far as I can tell it's not yet
>>> > captured in the spec).
>>> >
>>> > 4. The fact that header continuations can be unbounded is deeply
>>> > troubling, especially given that the endpoint is required to buffer
>>> > and process the complete header block (well.. that's only half true,
>>> > the encoding does allow for incremental processing of the HEADERS
>>> > frame payloads but the spec requires that the complete header block is
>>> > always processed). Sure, the recipient is free to terminate the
>>> > connection as soon as it detects bad behavior, but the sender could
>>> > end up forcing the recipient to do a significant amount of extra
>>> > processing with a never ending sequence of HEADERS frames. Smart
>>> > implementations will know how to deal with this, yes, but overall it
>>> > adds to the already growing list of "New Complex Things" that an
>>> > HTTP/2 implementer needs to know about.
>>> >
>>> >  (In the implementation I've done, I provide a configuration
>>> > parameter that allows a developer to cap the number of the
>>> > continuations and the total size of the header block)
>>> >
>>> > I know that we're in "implementation" phase right now and that
>>> > everyone is busy getting their code ready for testing in August, but
>>> > after updating my implementation to the latest version of the draft,
>>> > my concerns with regards to stateful header compression definitely
>>> > remain.
>>> >
>>> > On Thu, Jul 11, 2013 at 9:36 AM, Martin Thomson
>>> > <martin.thomson@gmail.com> wrote:
>>> >> On 10 July 2013 21:20, Amos Jeffries <squid3@treenet.co.nz> wrote:
>>> >>> It seems not to be negotiable from the recipients side.
>>> >>
>>> >> Compression context size = 0 is entirely negotiable from the recipient
>>> >> end, with a small wrinkle, that I know some folks are working on.
>>> >> Which is, a client can start using a default compression context size
>>> >> prior to learning that a server has no space (substitute intermediary
>>> >> as appropriate there).
>>> >>
>>> >
>>>
>>>
>>>
>>
>>
>
>