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

Jen Linkova <furry13@gmail.com> Wed, 17 June 2015 10:02 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 B69391A888F for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 03:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.75
X-Spam-Level:
X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 wCcBpkcaB81L for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 03:01:54 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::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 6195C1A8880 for <v6ops@ietf.org>; Wed, 17 Jun 2015 03:01:54 -0700 (PDT)
Received: by yhan67 with SMTP id n67so29986578yha.3 for <v6ops@ietf.org>; Wed, 17 Jun 2015 03:01:53 -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:content-transfer-encoding; bh=jC2yxVJTPIaYBEybUdn1jtBMBK7kkAIpM1xxubEPjwg=; b=DtwIsgFpPurWzB8eLXRYNYxGKQ3HUdp9OPgQ+GyFiwi1aS2s72LAl9AN8pWAc9pt7S LYQIS+dej8Q8TL0hT1ubMgyn2PxJUqBbCtESZD80+9V8VITvJTM7zusNs26bRAplCnyr 75e+DK/rrf+HQTQyrcH+vD30eNsYfq0v3Jxp0PPRxaKFmrupgeHYuxLlxsXnHzjeXqTd k7n1+GXIsT5yBHUieoPJYuuJ4gcCDrAHFWEO4v+eeO9Ha6EWBVTQvHdBZ1m+I77t+XF9 z0zMiLDp5o9/bDWOq6lgkdcA5oeS3ktZmPW2Jnbx9H6hU8Tfzk7L+ozMUmGr+MxcxQ+/ y+Ag==
X-Received: by 10.52.227.200 with SMTP id sc8mr4193497vdc.35.1434535313639; Wed, 17 Jun 2015 03:01:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.82.130 with HTTP; Wed, 17 Jun 2015 03:01:33 -0700 (PDT)
In-Reply-To: <C07DF957-9A2D-4962-ABAA-DE61F5C5D533@cisco.com>
References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <20150517191841.GA26929@ernw.de> <C07DF957-9A2D-4962-ABAA-DE61F5C5D533@cisco.com>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 17 Jun 2015 12:01:33 +0200
Message-ID: <CAFU7BAR0YeGe7NbYTqNSAcMukGjAz6akWaVcODWVJwpTJKQhWQ@mail.gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/4mbn4HWUvteCB0n7ylMtPA5TK0g>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6-wg@ripe.net" <ipv6-wg@ripe.net>
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 10:02:01 -0000

On Wed, Jun 17, 2015 at 9:41 AM, Fred Baker (fred) <fred@cisco.com> wrote:
> Fernando would like to see a specification of how long the entire list of extension headers may be, in terms of "how large of a hardware buffer has to be implemented in a switch?" That has a couple of issues related to "why does one have to ask the question?" The hardware should definitely be large enough to read in the IPv6 header, the HBH Header, and the Routing Header. After that, the only host that SHOULD need to read it all in is the host itself, and the host can do its processing from RAM. There is one "gotcha" case, which is when someone uses an ACL (disallowing Fragmentation Headers, perhaps, or looking for the TCP port, meaning one has to ask whether a given packet is TCP and what its port number is). The firewall is going to have to chase down the chain of extension headers.

I agree. There is a definitely a big difference in requirements for
"traditional routers" and devices which are going to implement ACLs
(and other types of "multifields classifications" (as QoS based other
data than IP header). IMHO it's reasonable to assume that one might
need different hardware for "just routing" and enhanced QoS/ACL
services (it's a case nowadays anyway). For the latter case the device
has to either, as you said, chaise the whole chain down (which might
be as long as the whole packet) or have a way to deal with packets it
could not parse (applying a specific policy to such packets).

> How big is a HBH header? How big is a routing option such as the Segment Routing option? If that's a list of 27 services, each with a 16 byte IPv6 address...

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.
We do not know (could not know) exact numbers, the requirements are
changing, so does the hardware we deploy in out network. It's a kind
of race ;) and as long as there is a way to predict/configure the
behavior of the device when it could not fully parse the packet - I'm
fine with it..

>
>> On May 17, 2015, at 12:18 PM, Enno Rey <erey@ernw.de> 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... ;-)
>>
>>
>>
>>>
>>> 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/
>>>
>>>
>>
>> --
>> Enno Rey
>>
>> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>>
>> Handelsregister Mannheim: HRB 337135
>> Geschaeftsfuehrer: Enno Rey
>>
>> =======================================================
>> Blog: www.insinuator.net || Conference: www.troopers.de
>> Twitter: @Enno_Insinuator
>> =======================================================
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



-- 
SY, Jen Linkova aka Furry