Implications of Oversized IPv6 Header Chains

Bonica, Ron; Manral, Vishwas; Gont, Fernando

doi:10.17487/rfc7112

Cited by 5 publications

(9 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…With IPv6 connectivity come two forms of security issues. The first type are the set of completely new vulnerabilities that stem from IPv6 protocol changes and features (e.g., [27], [51]). Part of the problem for vendors and operators alike is that there are nontrivial technical hurdles to fully supporting IPv6, especially in policy devices, such as firewalls and IDSes.…”

Section: Introductionmentioning

confidence: 99%

Don’t Forget to Lock the Back Door! A Characterization of IPv6 Network Security Policy

Czyz¹,

Luckie²,

Allman³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

There is growing operational awareness of the challenges in securely operating IPv6 networks. Through a measurement study of 520,000 dual-stack servers and 25,000 dual-stack routers, we examine the extent to which security policy codified in IPv4 has also been deployed in IPv6. We find several high-value target applications with a comparatively open security policy in IPv6 including: (i) SSH, Telnet, SNMP, are more than twice as open on routers in IPv6 as they are in IPv4; (ii) nearly half of routers with BGP open were only open in IPv6; and (iii) in the server dataset, SNMP was twice as open in IPv6 as in IPv4. We conduct a detailed study of where port blocking policy is being applied and find that protocol openness discrepancies are consistent within network boundaries, suggesting a systemic failure in organizations to deploy consistent security policy. We successfully communicate our findings with twelve network operators and all twelve confirm that the relative openness was unintentional. Ten of the twelve immediately moved to deploy a congruent IPv6 security policy, reflecting real operational concern. Finally, we revisit the belief that the security impact of this comparative openness in IPv6 is mitigated by the infeasibility of IPv6 network-wide scanning-we find that, for both of our datasets, host addressing practices make discovering these high-value hosts feasible by scanning alone. To help operators accurately measure their own IPv6 security posture, we make our probing system publicly available. Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.

show abstract

Section: Introductionmentioning

confidence: 99%

Don’t Forget to Lock the Back Door! A Characterization of IPv6 Network Security Policy

Czyz¹,

Luckie²,

Allman³

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…Long header chains have implications [6] in scenarios where e.g. stateless firewalls need information up to the upper layer protocol: when the packet is fragmented, and due to the long header chain the first fragment does not contain all that needed information, the firewall can possibly not act on that packet appropriately.…”

Section: Misuses and Caveatsmentioning

confidence: 99%

Threats and surprises behind IPv6 extension headers

Hendriks

Velan

Schmidt

et al. 2017

2017 Network Traffic Measurement and Analysis Conference (TMA)

View full text Add to dashboard Cite

Abstract-The concept of Extension Headers, newly introduced with IPv6, is elusive and enables new types of threats in the Internet. Simply dropping all traffic containing any Extension Header -a current practice by operators-seemingly is an effective solution, but at the cost of possibly dropping legitimate traffic as well. To determine whether threats indeed occur, and evaluate the actual nature of the traffic, measurement solutions need to be adapted. By implementing these specific parsing capabilities in flow exporters and performing measurements on two different production networks, we show it is feasible to quantify the metrics directly related to these threats, and thus allow for monitoring and detection. Analysing the traffic that is hidden behind Extension Headers, we find mostly benign traffic that directly affects end-user QoE: simply dropping all traffic containing Extension Headers is thus a bad practice with more consequences than operators might be aware of.

show abstract

“…For the purposes of this document, the terms "IPv6 Extension Header", "First Fragment", "IPv6 Header Chain", and "Upper-Layer Header" are used as specified in [RFC7112] The first member of the IPv6 Header Chain is always an IPv6 header. For a subsequent header to qualify as a member of the IPv6 Header Chain, it must be referenced by the "Next Header" field of the previous member of the IPv6 Header Chain.…”

Section: Dhcpv6-shield Devicementioning

confidence: 99%

“…This means that, at least in theory, DHCPv6-Shield could result in false-positive blocking of some legitimate (non-DHCPv6-server) packets. However, as noted in [RFC7112], IPv6 packets that fail to include the entire IPv6 Header Chain are virtually impossible to police with stateless filters and firewalls; hence, they are unlikely to survive in real networks.…”

Section: Dhcpv6-shield Implementation Requirementsmentioning

confidence: 99%