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

Ca By <cb.list6@gmail.com> Tue, 16 June 2015 13:08 UTC

Return-Path: <cb.list6@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 043AF1B342B for <v6ops@ietfa.amsl.com>; Tue, 16 Jun 2015 06:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.749
X-Spam-Level:
X-Spam-Status: No, score=-3.749 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, HTML_MESSAGE=0.001, 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 d1ld7hembzXD for <v6ops@ietfa.amsl.com>; Tue, 16 Jun 2015 06:08:20 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 E42141B3456 for <v6ops@ietf.org>; Tue, 16 Jun 2015 06:08:18 -0700 (PDT)
Received: by wicnd19 with SMTP id nd19so52620246wic.1 for <v6ops@ietf.org>; Tue, 16 Jun 2015 06:08: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:date:message-id:subject:from:to :cc:content-type; bh=6ERfw1CFvrCccnHCk/r1StxcMnMqxOW3GDGk2aqqFnI=; b=QPBJZWLqZEsldAIB46COfqJqPpH2cM+Gc4FB1zikooZPl/NqokyTcm5bWoP0gP2OGY zEiVeaiJRuKW+58NKVGIAh0qeBJUqpR1eCfSRl69Q9ejzRlEBQjs5WegRvx5143jDTuW RwFGn859cfLKZ15uRBdQD/S3VQJipfy99WAsfOzNPHVR6J5gTuGCmilErz9vBIuDQBYT pNIiJ+twbvWhvCBo0HwL0IUdf+HiFL64OT5mEoK1NUqQ4nDQH464jyqec/GsxLY7SNGV 4DB5Kw5TlMWEhD8JuUZ+uMcN3NfYvVPientMAokv4Y1pVXa1FYYOj9HmtGJ6x+y3D3pH Dosg==
MIME-Version: 1.0
X-Received: by 10.180.100.74 with SMTP id ew10mr44256260wib.12.1434460097520; Tue, 16 Jun 2015 06:08:17 -0700 (PDT)
Received: by 10.194.79.65 with HTTP; Tue, 16 Jun 2015 06:08:17 -0700 (PDT)
In-Reply-To: <283392813.4420641.1434431518036.JavaMail.yahoo@mail.yahoo.com>
References: <CAD6AjGTufBsW9pR37J-HJ7FV5o_UJTwrmPMRuuuP57ja3p19dQ@mail.gmail.com> <283392813.4420641.1434431518036.JavaMail.yahoo@mail.yahoo.com>
Date: Tue, 16 Jun 2015 06:08:17 -0700
Message-ID: <CAD6AjGQM_JSOKLaSS=ZwwYosOYSaU9AU687MCFfv5YWHRRRJcg@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Content-Type: multipart/alternative; boundary="14dae9cc9c5a8ea8060518a244a0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/mQR04A9KwF88nuYRPJE5PX_jQnI>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] 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: Tue, 16 Jun 2015 13:08:26 -0000

On Monday, June 15, 2015, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:

>
>   ------------------------------
>  *From:* Ca By <cb.list6@gmail.com
> <javascript:_e(%7B%7D,'cvml','cb.list6@gmail.com');>>
> *To:* Eric Vyncke (evyncke) <evyncke@cisco.com
> <javascript:_e(%7B%7D,'cvml','evyncke@cisco.com');>>
> *Cc:* "v6ops@ietf.org <javascript:_e(%7B%7D,'cvml','v6ops@ietf.org');>" <
> v6ops@ietf.org <javascript:_e(%7B%7D,'cvml','v6ops@ietf.org');>>; "
> ipv6-wg@ripe.net <javascript:_e(%7B%7D,'cvml','ipv6-wg@ripe.net');>" <
> ipv6-wg@ripe.net <javascript:_e(%7B%7D,'cvml','ipv6-wg@ripe.net');>>
> *Sent:* Tuesday, 16 June 2015, 8:32
> *Subject:* Re: [v6ops] Extension Headers / Impact on Security Devices
>
>
>
> On Monday, June 15, 2015, Eric Vyncke (evyncke) <evyncke@cisco.com
> <javascript:_e(%7B%7D,'cvml','evyncke@cisco.com');>> wrote:
>
> Enno,
>
> As you probably know, Cisco handles PSIRT issues with care, so, I have no
> clue on this specific advisory. My own (educated) guess is that the packet
> causing a LC reload is fully RFC 2460 compliant but unusual, so, probably
> (a guess again) a combination of extension headers triggering a bug.
>
> In this specific case, I would not blame IPv6 or RFC 2460 but rather my
> own company (even if the affected versions were quite old as new IOS-XR
> versions appear to be immune to this bug). And I appreciate the humor in
> your rhetorical question about which FW could protect a CRS... Air gap
> probably :-)
>
> More generally, regarding the 'parsing of the header' and performance, my
> understanding (and I am NOT a HW engineer) is that there are multiple ways
> to parse the header chain:
> - purely software in low-end devices, should have a marginal performance
> impact
> - specific ASIC in middle-end devices (read high end enterprise), probably
> some limitations and heavy performance impact (but again within one
> organization, so, easier to fix the root cause)
> - a lot of specialized network processors in high-end devices (SP gears),
> which is a similar case as the 'low-end device', performance impact but
> marginal as parsing the chain of headers is not that hard after all _when_
> coded correctly
>
> As the extension headers are specific to IPv6, this is an area when we
> will all learn (and have learned already) a lot of things...
>
> I respectfully disagree with your last sentence. Of course, destination
> AS/host SHOULD only accept useful, known and legit ext headers; but, why
> would an ISP filter on ext headers if they do not harm their own infra or
> a customer infra? Do you envision an Internet where only TCP/443 and
> UDP/43 would be accepted?
>
> Last point, the Internet will have to use IPv6 for 10 or 20 years at
> least. If the IETF/ISP block all new _options_ in _existing_ extension
> headers, then we will be stuck in 1997 for network innovation. While I do
> not like taking security risks, I even fear more the lack of innovation.
>
>
>
> I keep hearing this and it is very bizarre to hear
>
> With regards to 1997, believing that there will be innovation in the
> narrow waist of hour glass (network layer), that is very 1997. The network
> layer is stable and boring.... Hence it being narrow.  Innovation is
> welcome everywhere except network in the e2e model
>
> / Absence of evidence is not evidence of absence.
>
> / Consider what the network and host situation was in 1997 (wired network
> access, desktops outselling laptops, dialup Internet for residential,
> corporates in total probably being the largest spenders on Internet access)
> to today and the near future (wireless networks, smartphones/tablets being
> the dominant Internet access device in some markets - and they're
> multi-homed, M2M/IoT considered to be place where the greatest expansion of
> Internet connected devices is going to occur in the near future.)
>
> / IPv6 has had relatively little adoption, and it is only starting to
> increase quite rapidly in the last few years and that is mainly because of
> mobile networks. There hasn't and still doesn't seem to be much thinking
> about how IPv6's differences from IPv4's can be taken advantage of yet - an
> "IPv4 first" or an "IPv4 == IPv6" mindset seems to be still very common (I
> think the network virtualisation space is where this is might be most
> prominent - I think most of the technologies they're inventing require fork
> lift network upgrades, so the costs of deploying IPv6 at the same time
> become a lot less significant. So if there is a "cheap" opportunity to
> deploy IPv6, and IPv6 is going to be the long term network layer 3, why not
> optimise for it now? That was the thinking behind my "Enhancing Virtual
> Network Encapsulation with IPv6" draft)
>
> / We don't want to disable innovation opportunities that IPv6 may provide
> before people have arrived at an "IPv6 first" or "IPv4 != IPv6" mindset.
>
>
>
I have heard those stories, i don't find them compelling.

CB

>
>
> Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-)
>
> -éric
>
> On 11/06/15 11:58, "Enno Rey" <erey@ernw.de> wrote:
> >
> >the problem here is the definition of "normal IP packet" as of RFC2460.
> >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"?
> >- what ("combination of FW & IPS or whatever") would you put in front of
> >a CRS?
> >
> >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
> >http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/)
> >"properly parsing an IPv6 packet, let alone in wire speed" seems a pretty
> >much unsolvable task to me.
> >
> >That said I still fail to see any useful extension header besides AH&ESP
> >(not even FH) to be transported in the Internet.
> >
> >best
> >
> >Enno
> >
> >
> >
> >
> >
> >
> >
> > If your firewall cannot implement this policy, then
> >> it is time to change or to use a combination of FW & IPS or whatever.
> >>
> >> - network person: as I will live with IPv6 for the rest of my life,
> >>then I
> >> want a way to extend it and I need any packet to travel to my source to
> >>my
> >> destination. Any IPv6 packet should be able to traverse the
> >> Internet/private network as long as its layer-3 header is valid
> >> (filtering/dropping can be done exceptionally for good operational
> >> reason). Did we remember the IPv4 teardrop attack? It is blocked by
> >> default by most routers for years ;-)
> >>
> >> Bugs will plague us for ever... And make our life more complex than the
> >> above description of course ;-)
> >>
> >> -??ric
> >>
> >> On 17/05/15 20:43, "Silvia Hagen" <silvia.hagen@sunny.ch> 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?
> >> >
> >> >I would want my firewall to notify me if the EHs in a packet do not
> >> >follow the list.
> >> >And limiting the number of possible EHs per packet might be a good
> >>idea.
> >> >
> >> >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
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <javascript:_e(%7B%7D,'cvml','v6ops@ietf.org');>
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>