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

"Fred Baker (fred)" <> Wed, 17 June 2015 16:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1C3DD1B2A78 for <>; Wed, 17 Jun 2015 09:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CSapbWN-G9wx for <>; Wed, 17 Jun 2015 09:46:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E0CB1AD368 for <>; Wed, 17 Jun 2015 09:46:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3761; q=dns/txt; s=iport; t=1434559565; x=1435769165; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4dH+H5BtQOdM2fDcoKce0UucWCNjIBl8KSzi0P0c3R0=; b=OIU8SQ1V92WjNnXrzaaKoSnX4Gcwowu+YQdHlO9eH92YHUJlB4S5/6n/ qQq1ViLjW0gJle0aSt9bSSIiC8Nv+dYPounkNPle0HpoC3uC0EwTKwPnG /cayFO/mMTdd9wKAiMCzOm8OCDkMB52kq582UxVBB+PaiPxCcAvRFRWBQ 4=;
X-Files: signature.asc : 487
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.13,633,1427760000"; d="asc'?scan'208"; a="4326536"
Received: from ([]) by with ESMTP; 17 Jun 2015 16:46:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t5HGk40B017100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jun 2015 16:46:04 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 17 Jun 2015 11:46:04 -0500
From: "Fred Baker (fred)" <>
To: Enno Rey <>
Thread-Topic: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices
Thread-Index: AQHQqR0Y1cqdHQMNH0ivLSqzykYy+g==
Date: Wed, 17 Jun 2015 16:46:03 +0000
Message-ID: <>
References: <> <> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_511FB745-3A79-4DB6-AABD-60B9ED6377C7"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [v6ops] [ipv6-wg] 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: Wed, 17 Jun 2015 16:46:07 -0000

> On Jun 17, 2015, at 1:14 AM, Enno Rey <> wrote:
> Fred, All,
> On Wed, Jun 17, 2015 at 07:41:33AM +0000, Fred Baker (fred) wrote:
>> I'm of course missing the preceding email. No problem with the cross-posting, but let's get the question on the table? Is this section 4.1's statement that "it is recommended that those headers appear in the following order"?
>> I have a hunch that an internet draft requiring headers to be in the listed order would be looked at with approbation. The issue, if any, would likely have regard to repeated Destination Option headers. However
>>   Each extension header should occur at most once, except for the
>>   Destination Options header which should occur at most twice (once
>>   before a Routing header and once before the upper-layer header).
>> seems to me fairly definitive.
> I'm not so sure about this. First probably a capital "SHOULD" would have been more appropriate.

RFC 2460 doesn't use the RFC 2119 conventions. Yes, it's hard to remember now, but RFC 2119 conventions weren't always the rule; they derived from similar usage in RFCs 1122/1123 and 1812. History lesson in the presence of adult beverages if that's interesting.

> Second - and this is our main point/observation - there's too much space of interpretation for actual implementation.
> To underline this I will just cite two somewhat random sections from the study we performed on evading security controls (IDPS systems) by means of extension headers, combined with fragmentation ( One of the devices (all of them latest code incl. some high-end gear) could be evaded by the following:

Cutting to the chase, on the surface it looks like most of the cases you specified conform to the sequence rule, with the exception of one that has three Destination Option Headers. What I *think* you're pointing out is (from your PDF) that this is part of a sequence of messages, one of which is fragmented, accepted by the intrusion detector, and not accepted by the ultimate host (perhaps a TCP checksum failed?), and as a result bypasses the signature that the intrusion detector is looking for. The issue wasn't that the sequence was incorrect, in most cases; it was that the intrusion detector made a different choice than the end host.

Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement).