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

Jen Linkova <> Tue, 16 June 2015 19:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 777961ACDDC for <>; Tue, 16 Jun 2015 12:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.149
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uVTtZls-Ptcv for <>; Tue, 16 Jun 2015 12:03:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC6921ACD68 for <>; Tue, 16 Jun 2015 12:02:56 -0700 (PDT)
Received: by ykfr66 with SMTP id r66so21496985ykf.0 for <>; Tue, 16 Jun 2015 12:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=73E8n4K+zhwsUsCVxIPYH9nRMbRZgYVMD0upz5xRDds=; b=tvnr4ENnxLnFhGwgtxk9ZHulLutnXHIF0gzszRflR0O7k4kpp1wthvH/rxgLkbag9L E/r3GBBvWudgCwz5gHpmyuf6pvLBce7fCJEBGWPto+PhAJVL9ulX4W4MUneuaDquAoBH G7ptHDd9EgPNFa+d5pxd5reai/2WyGE7khUSrFkuQGeXnHK/YDJPO+9m1c+AaUyFFfqk XKY1KwDX6v+HlHcfr0VVr2VLYC86QldIC4kv7J5Ml1zei4vjjo+IbYI0UICL7sljqSvW OLyJ8Pq9M6KuSiiAlD26toSuYjTCslgCrESpQ8X0ZAml+YMb+jptme8s548v+GxKon9k LlDw==
X-Received: by with SMTP id f18mr1425495vdu.83.1434481376267; Tue, 16 Jun 2015 12:02:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 16 Jun 2015 12:02:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <> <>
From: Jen Linkova <>
Date: Tue, 16 Jun 2015 21:02:35 +0200
Message-ID: <>
To: Enno Rey <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, " IPv6" <>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Jun 2015 19:03:02 -0000

On Thu, Jun 11, 2015 at 6:58 PM, Enno Rey <> wrote:
> the problem here is the definition of "normal IP packet" as of RFC2460.

The problem here is what one might mean by "normal" (from Oxford dictionary):
1)  conforming to a standard;
2) usual, typical, or expected;

> To illustrate this I just quote from today's Cisco advisory (Cisco IOS XR Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets potentially crashing CRS-3 line cards:
> "The vulnerability is due to incorrect processing of an IPv6 packet carrying IPv6 extension headers that are valid but unlikely to be seen during normal operation. An attacker could exploit this vulnerability by sending such an IPv6 packet to an affected device that is configured to process IPv6 traffic. An exploit could allow the attacker to cause a reload of the line card, resulting in a DoS condition."
> two question come to mind here:
> - is a "valid but unlikely" extension header chain "normal"?

It is "normal" if you define "normal" as "conforming to a standard",
but it's not "normal" if you define "normal" as "usual/typical".

> - what ("combination of FW & IPS or whatever") would you put in front of a CRS?

Nothing. There is smth to put *on* CRS however - the image which
contains the fix...
I do not think we should blame a protocol for software bugs. I've seen
router crashes caused by ICMP and BGP packets. Shall we go ahead and
start discussing deprecation of the two above mentioned protocols? ;)
Especially taking into account than some people like filtering ICMP on
the edge of their networks? ;)

> my (sad) expectation is that we'll see much more of these (types of) issues in the future. given the current level of freedom that the RFC2460 leaves (see also discussion/picture in "properly parsing an IPv6 packet, let alone in wire speed" seems a pretty much unsolvable task to me.

(shameless plug) a group of enthusiasts have just submitted a new
version of document which discusses exactly this problem:

Comments are appreciated...

SY, Jen Linkova aka Furry