Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices

Jen Linkova <furry13@gmail.com> Wed, 17 June 2015 12:41 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209231A9059 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 05:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.149
X-Spam-Level:
X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFoxtgCnYUIn for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 05:41:18 -0700 (PDT)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E081A9055 for <v6ops@ietf.org>; Wed, 17 Jun 2015 05:41:18 -0700 (PDT)
Received: by yhak3 with SMTP id k3so32529612yha.2 for <v6ops@ietf.org>; Wed, 17 Jun 2015 05:41:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8fpGFQSvBpwWqr4PUt6mB4+iJ8ABx17UokIj4jYBiyg=; b=QmwWYhTbMbZq9KboIb/AT4eS+mpl2vW798i3rjE4kk/w851w24W69Zwsc/f/HLjxn3 xkYbytB5BdCORAChy7h3tvXj/Ip8BKrY48TpHfXKX9EUPa2pN16FhPH+u6MDRa1CoJ8R upis49EZqtZ2jA7nIKCpG5W+xoaHUMt1GMP4WrEkLcRGcYZtnZplodQ/Qq6OpmfmAhKG qdW9a6BY/A+RUnzHvoUMTBv7ZKQf7/TvJFjvQs5F7Jpt7LNREyygiubh6pCGPPCVCtmI /o+MgkjDXARJO+ihzFT5UGKemTzzXOsyRZQq2iNr2KVDpaNt5TrRv/ov1Yj/8EeNlCRR Qvug==
X-Received: by 10.52.124.43 with SMTP id mf11mr4597156vdb.92.1434544877268; Wed, 17 Jun 2015 05:41:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.82.130 with HTTP; Wed, 17 Jun 2015 05:40:36 -0700 (PDT)
In-Reply-To: <558165C4.30904@foobar.org>
References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <20150517191841.GA26929@ernw.de> <C07DF957-9A2D-4962-ABAA-DE61F5C5D533@cisco.com> <CAFU7BAR0YeGe7NbYTqNSAcMukGjAz6akWaVcODWVJwpTJKQhWQ@mail.gmail.com> <558165C4.30904@foobar.org>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 17 Jun 2015 14:40:36 +0200
Message-ID: <CAFU7BAS1mNRDv6b4QN=A3O9TpLSreuAApXwKedGzp1vM6d73Kg@mail.gmail.com>
To: Nick Hilliard <nick@foobar.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ORzoR_EsvccoLx9pIkJ3hquOBs0>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2015 12:41:19 -0000

On Wed, Jun 17, 2015 at 2:19 PM, Nick Hilliard <nick@foobar.org> wrote:
> On 17/06/2015 11:01, Jen Linkova wrote:
>> I'd like to point out that the problem is not specific to IPv6 at all.
>> How deep is MPLS label stack? Where are TCP flags or port number in
>> the packet (so I can match 'tcp established' or 'tcp 443')? oops, we
>> don't know....it depends...so some linecards do not copy enough data,
>> some (newer ones) do.
>
> bear in mind that each entry in the mpls label stack will be 4 octets,
> which gives.  An EH could be orders of magnitude larger.

Sorry, I should have made my point clear. What 'm trying to say is that:
1) if the current approach of 'copy X bytes to on-chip memory' there
is always a chance to receive a valid packet which requires more than
X bytes to be copied for correct processing.Therefore I believe we
should discuss how to handle such situation in general instead of
trying to find a magic value of X (I'd suggest 42 then ;)) and limit
all headers length by that number.
2) while just a few years ago you might see linecards which could look
at...how many? 64 bytes? into packets, nowadays they are replaced with
linecards which are able to look much deeper. So while protocol
designers should be aware of such limitation, absolute numbers are
increasing and the situation is improving (btw my measurements do show
that packets with 8 / 16 bytes EHs have much lower drop rate than
packets with 512/1024 bytes EHs, which I dare attribute to the hw
limitations).
3) I assume that vendors are developing hardware and software to meet
customers needs (more or less ;)) - 5 years ago who would need to look
deeper than 5 labels? so some linecards were quite upset to see such
deep label stack and might crash; now I'm told that 'we can inspect 10
labels easily because there are use cases'. Why could not we expect
smth like that happening if/when a use case for EH arises?


-- 
SY, Jen Linkova aka Furry