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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 17 May 2015 19:50 UTC

Return-Path: <brian.e.carpenter@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 ED8CE1A1A68 for <v6ops@ietfa.amsl.com>; Sun, 17 May 2015 12:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham
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 3jfkIYAyt9xL for <v6ops@ietfa.amsl.com>; Sun, 17 May 2015 12:50:44 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 EE20D1A0334 for <v6ops@ietf.org>; Sun, 17 May 2015 12:50:43 -0700 (PDT)
Received: by pacwv17 with SMTP id wv17so119306646pac.2 for <v6ops@ietf.org>; Sun, 17 May 2015 12:50:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RL2Z6zrGHC+AiZXXlnwIykTCJMo4VBKtMkpca7ZqYO8=; b=ZywEWZnoXHuTWMrfmAwGI/WkU3ezK9f91rqyhEy99NWrVJtraOtXlWCsBz8pNkhPVz R2RTB/sNjwkYcSipDCnw1TfpqIrCs/Bqsdxvb6j+TYjbsrnam1vMAYNBa/l6pd6glkRA h7qIEA+gTYT5INveYCDWjZSGp0Nbh0Vv2R82pEQrl8sQE17QoRC4Go/68qHhhDs5Ptgd RwA5qve94jjZVgZoI+bpKoJ7CUqWdoruoBkMtYD4d7AqvXwqRipZi0F0VLdhpGAhc103 kpNQbi3LWjb2x5a9JbIKawcKVn0XvnHLiaCQxffNHBeBQo8oGdajHKB2i+/IRW5BYPyv k2uQ==
X-Received: by 10.67.1.98 with SMTP id bf2mr38498725pad.33.1431892243558; Sun, 17 May 2015 12:50:43 -0700 (PDT)
Received: from ?IPv6:2406:e007:5d8c:1:28cc:dc4c:9703:6781? ([2406:e007:5d8c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id qz3sm7858026pab.19.2015.05.17.12.50.40 for <v6ops@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 May 2015 12:50:42 -0700 (PDT)
Message-ID: <5558F0F4.7080707@gmail.com>
Date: Mon, 18 May 2015 07:50:12 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: v6ops@ietf.org
References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <20150517191841.GA26929@ernw.de>
In-Reply-To: <20150517191841.GA26929@ernw.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/Z5nMhV7OMKQA2CbWHEsYNGqrOTY>
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: Sun, 17 May 2015 19:50:46 -0000

On 18/05/2015 07:18, Enno Rey wrote:
> Hi Silvia,
> 
> On Sun, May 17, 2015 at 06:43:11PM +0000, Silvia Hagen wrote:
>> Hi
>>
>> I keep stumbling about that "recommendational wording" in RFC 2460 everytime I teach it.
>>
>> Couldn't we update RFC2460 and make this list a strict order?
> 
> good luck bringing this suggestion to IETF 6man... ;-)

Talking to hardware people, I have the impression that a more serious
problem is the lack of a single fixed TLV format for all extension headers.
The blending of extension headers and payload protocol numbers has also
turned out to be a mistake. The fact is that line speed parsing of the
headers needs a more complex hardware protocol engine than designers seem
ready to accept.

    Brian

> 
> 
> 
>>
>> I would want my firewall to notify me if the EHs in a packet do not follow the list.
> 
> actually when we tested a number of commercial firewalls in late 2013 (results here: https://www.ernw.de/download/TR14_IPv6SecSummit_AAtlasis-RISC-project_results.pdf) it turned out that pretty much all of them follow a (from our perspective "reasonable approach", that is dropping "unusal combinations or number of ext_hdrs" by default. (which, of course, violates RFC 2460. but apparently all major vendors follow a line of reasoning similar to ours).
> so, in short, firewalls "are not affected".
> 
> 
>> And limiting the number of possible EHs per packet might be a good idea.
> 
> yes, that _would actually be_ a good idea.
> 
> 
> I'm cross-posting this to v6ops as there's a related discussion going on right now. pls forgive this potential Usenet etiquette violation.
> 
> best
> 
> Enno
> 
> 
> 
> 
>>
>> Silvia
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: ipv6-wg [mailto:ipv6-wg-bounces@ripe.net] Im Auftrag von Benedikt Stockebrand
>> Gesendet: Sonntag, 17. Mai 2015 18:39
>> An: ipv6-wg@ripe.net
>> Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices
>>
>> Hi Enno and list,
>>
>> Enno Rey <erey@ernw.de> writes:
>>
>>> hope everybody had a great #RIPE70 meeting. We did!
>>> Many thanks to the organizers and chairs!
>>
>> and thanks to the actual speakers as well the speakers we had to turn down due to time constraints, too:-)
>>
>>> If the chairs consider this appropriate we will happily give a 
>>> presentation on this stuff in Bucharest or at another occasion.
>>
>> Sounds good to me!
>>
>>> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to 
>>> their number, order[...]
>>
>> Actually, as far as I'm concerned that's the real core of the problem.
>> Or more specifically, the first two lines of RFC 2460, section 4.1:
>>
>>    When more than one extension header is used in the same packet, it is
>>    recommended that those headers appear in the following order:
>>
>> followed on the next page by
>>
>>    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).
>>
>> Note in particular that these are not even RFC 2119 "SHOULD" or "RECOMMENDED" and such.
>>
>> The impact here is actually at least twofold: 
>>
>> - It is impossible to implement this as a simple pipeline architecture
>>   in hardware; at least for cases deviating from the "recommendations"
>>   above this effectively becomes either excessively complex to implement
>>   in hardware or an invitation to DoS when implemented in software on an
>>   otherwise hardware router.
>>
>> - As I understand it, at least some of the issues you have found are
>>   effectively based on violating the second paragraph quoted, making it
>>   impossible to come up with a lower bound on how long the header chain
>>   can actually get and therefore leading to the fragmentation related
>>   attacks and similar you have discovered.
>>
>> The original idea was that the extension headers are processed strictly in the order they occur, so one question to ask is if there is any valid reason to violate these "recommendations" for other than malicious purposes.
>>
>>
>> Cheers,
>>
>>     Benedikt
>>
>> -- 
>> Benedikt Stockebrand,                   Stepladder IT Training+Consulting
>> Dipl.-Inform.                           http://www.stepladder-it.com/
>>
>>           Business Grade IPv6 --- Consulting, Training, Projects
>>
>> BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
>>
>>
>