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

On Thu, Jun 11, 2015 at 6:58 PM, Enno Rey <erey at ernw.de> 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 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.

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

https://tools.ietf.org/html/draft-wkumari-long-headers-03

Comments are appreciated...

-- 
SY, Jen Linkova aka Furry