Re: HTTP router point-of-view concerns

Roberto Peon <grmocg@gmail.com> Thu, 11 July 2013 20:35 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 A41B021F99F2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2013 13:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.543
X-Spam-Level:
X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.055, 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 Xkcrstux-7T1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2013 13:35:38 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCAF11E817B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 11 Jul 2013 13:35:38 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UxNaE-00087f-99 for ietf-http-wg-dist@listhub.w3.org; Thu, 11 Jul 2013 20:35:22 +0000
Resent-Date: Thu, 11 Jul 2013 20:35:22 +0000
Resent-Message-Id: <E1UxNaE-00087f-99@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 1UxNa5-00086v-Jf for ietf-http-wg@listhub.w3.org; Thu, 11 Jul 2013 20:35:13 +0000
Received: from mail-oa0-f54.google.com ([209.85.219.54]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UxNa4-0003fY-Nw for ietf-http-wg@w3.org; Thu, 11 Jul 2013 20:35:13 +0000
Received: by mail-oa0-f54.google.com with SMTP id o6so12078680oag.27 for <ietf-http-wg@w3.org>; Thu, 11 Jul 2013 13:34:46 -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=SVxWH8yjIOq+7FfIJ1JJQl+GtGgJTitOGtV5XJQ30Kk=; b=X0N3eH5aKvtLeo9POVeYjxNEl3/NRle6bz5TMaUUh00V/wC0j5upNtxZKulCq8ojZ6 HRTc3Um0Guksol1dbwMidVx6el2VeQsc6MMz18PQY/iP7YU//5BfNx3FFAFQD5rDg1EQ G8toqkq4N9Gyp8oTydV4BgfXmr/QCRaaWs50Jg/VnVn+ePnJcKu3UreSJMGU1rsqmmuH iSp/NVafYTQYXZnTl2mlDL+2GYw5AM6xg/6GmrKc5oKkiGWAqV8QkrRuPI8ZCNEGWemB BE5qnksgEo7H+ItRVrKyPaJOXdGBxAVVZZHmmoYitFUbCHYz1DzuLQINFSxLlY5vZAUY xR4Q==
MIME-Version: 1.0
X-Received: by 10.60.140.168 with SMTP id rh8mr33393395oeb.17.1373574886707; Thu, 11 Jul 2013 13:34:46 -0700 (PDT)
Received: by 10.76.91.229 with HTTP; Thu, 11 Jul 2013 13:34:46 -0700 (PDT)
In-Reply-To: <CABP7RbcgRr8mHVaQK8pbBP=XR3gjZDcAAfbYm4waz3CCydX+sg@mail.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> <CAP+FsNcOZnLa9GCr6XcZNFdq-mSXG6Q-_1Lb5u=a2YyXNCsVfQ@mail.gmail.com> <CABP7RbfGYsryOsEWW+UWJ+fdVejiRQSHH0DF_Kw4Pf=EJQX+rw@mail.gmail.com> <CAP+FsNcAJB85i=me4dqjzPcF_uV88LsLr+hBLrxZv_F8hdB4Dg@mail.gmail.com> <CABP7RbcgRr8mHVaQK8pbBP=XR3gjZDcAAfbYm4waz3CCydX+sg@mail.gmail.com>
Date: Thu, 11 Jul 2013 13:34:46 -0700
Message-ID: <CAP+FsNdt+wm_LsWXh_O3s2xFTTGahqdwb83xCNQ=A68bfvyF3A@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: 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="047d7b2e4c463227ae04e142531d"
Received-SPF: pass client-ip=209.85.219.54; envelope-from=grmocg@gmail.com; helo=mail-oa0-f54.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 1UxNa4-0003fY-Nw 161bfc8a17c3acb30f75cb7c169b897f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP router point-of-view concerns
Archived-At: <http://www.w3.org/mid/CAP+FsNdt+wm_LsWXh_O3s2xFTTGahqdwb83xCNQ=A68bfvyF3A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18710
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>

yup!
-=R


On Thu, Jul 11, 2013 at 1:29 PM, James M Snell <jasnell@gmail.com> wrote:

> Yes, and I'm saying that, the way the mechanism is currently defined,
> as soon as you set the size to zero, those "free" items are removed
> from the table and you no longer get them for "free"... so there is a
> certain amount of state that *is* allocated per connection (even if
> it's relatively minor).
>
> Ultimately, the question of whether header compression can be used as
> an attack vector will rest entirely on implementation and
> experimentation.
>
> On Thu, Jul 11, 2013 at 1:07 PM, Roberto Peon <grmocg@gmail.com> wrote:
> > I'm calling that the static table. Those are the elements you get for
> "free"
> > (as in the memory is allocated once in the process, as opposed to for
> every
> > connection).
> >
> > -=R
> >
> >
> > On Thu, Jul 11, 2013 at 1:02 PM, James M Snell <jasnell@gmail.com>
> wrote:
> >>
> >> On Thu, Jul 11, 2013 at 12:35 PM, Roberto Peon <grmocg@gmail.com>
> wrote:
> >> >[snip]
> >> >
> >> > The DoS vector you're talking about is not a DoS vector if the
> >> > intermediary
> >> > resets all streams before the change-of-state-size comes into effect.
> >> > When the state size is 0, one should be able to use some kinds of
> >> > 'indexed'
> >> > representations, so long as those representations refer only to items
> in
> >> > the
> >> > static tables. Why do you believe that this would use more or less
> CPU?
> >> > (It
> >> > should use less CPU and less memory...)
> >> > [snip]
> >>
> >> Well, as far as I can tell, according to the current header
> >> compression draft, there is no "static table". The header table is
> >> pre-populated, yes, but those items would fall out of the header table
> >> via eviction as the table fills. There is nothing in the current
> >> header compression draft that says those items are permanent.... Given
> >> that, and given that we've already established that reducing the
> >> header table size forces eviction, setting the size to zero would
> >> cause all of the pre-populated items to be evicted.
> >>
> >> - James
> >
> >
>