This document provides an overview of IPv6 security that is specifically aimed at IPv4 engineers and operators. Rather than describing IPv6 in an isolated manner, it aims to re-use as much of the existing IPv4 knowledge and experience as possible. It highlights the security issues that affect both protocols in the same manner, as well as those that are new or different for the IPv6 protocol suite. Additionally, it discusses the security implications arising from the co-existence of the IPv6 and IPv4 protocols.
3c7ad3f60f63c849f9bff9b85784a99aThe subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue.
23b96b2e0c0f6f3f0381dc2d3096094cThis is a draft of IPv6 Extension Headers in the Real World. IPv6 Extension Headers allow for the extension of the IPv6 protocol, and provide support for some core functionality such as IPv6 fragmentation. However, IPv6 Extension Headers are deemed to present a challenge to IPv6 implementations and networks, and are known to be intentionally filtered in some existing IPv6 deployments. This summarizes the issues associated with IPv6 extension headers, and presents real-world data regarding the extent to which packets with IPv6 extension headers are filtered in the public Internet, and where in the network such filtering occurs. Additionally, it provides some guidance to operators in troubleshooting IPv6 blackholes resulting from the use of IPv6 extension headers. Finally, this document provides some advice to protocol designers, and discusses areas where further work might be needed.
d82bab036020d2be2c57fd94ad014d8cSI6 Networks' IPv6 toolkit is a security assessment and troubleshooting tool for the IPv6 protocols. It can send arbitrary IPv6-based packets.
e917241effbe7cf2e11871e27e158638These are presentation slides from the German IPv6 Kongress that was held in Frankfurt, Germany in 2013.
e6c73a6fcc93a33627218eef82b9e773These slides are from an IPv6 reconnaissance presentation given at CONFidence 2013.
9f1975c39e0739d27b1e88c21bdd05f0This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses.
ae070a249f63b43911cdd8f7fed8ededThese are the slides for the "Hacking IPv6 Networks" security training course as given at BRUCON 2012.
cc61c9d06b08dae10665135b93de0a44This toolkit houses various IPv6 tools that have been tested to compile and run on Debian GNU/Linux 6.0, FreeBSD 9.0, NetBSD 5.1, OpenBSD 5.0, Mac OS 10.8.0, and Ubuntu 11.10.
21fe4ecb93a9b4783be7b16d88b0ab81This toolkit houses various IPv6 tools that have been tested to compile and run on Debian GNU/Linux 6.0, FreeBSD 9.0, NetBSD 5.1, OpenBSD 5.0, Mac OS 10.8.0, and Ubuntu 11.10.
2c7f9cfc0a8845694439a2bbdb6b9446This toolkit houses various IPv6 tools that have been tested to compile and run on Debian GNU/Linux 6.0, FreeBSD 9.0, NetBSD 5.1, OpenBSD 5.0, Mac OS 10.8.0, and Ubuntu 11.10.
e8cef869daa70b46ba19bfbb59e2fe74IPv6 Extension Headers with Neighbor Discovery messages can be leveraged to circumvent simple local network protections, such as "Router Advertisement Guard". Since there is no legitimate use for IPv6 Extension Headers in Neighbor Discovery messages, and such use greatly complicates network monitoring and simple security mitigations such as RA-Guard, this document proposes that hosts silently ignore Neighbor Discovery messages that use IPv6 Extension Headers.
88e4cd8c43b31362b6703b610a89105dThis document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks.
d96217260b6f3769c1ac440b3d837b95The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear on the local network. This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. Additionally, it discusses possible mitigations for the aforementioned issue.
b19815ec6492b8610bedbb0b546da854This document document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.
4dcb63f7c1f9d761dc2eb52d93196625This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues.
a61bcc625432b24b81ea3a98b5bdb4b7The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by some implementations as "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that fragmentation-based attack vectors against traffic employing "atomic fragments" are completely eliminated.
fd38a93b8f7a41b1670e2e3f42b96c1fThis Internet Draft specifies the security implications of predictable fragment identification values in IPv6. It primarily focuses on countermeasures and mitigations.
111f5c7995657add921af66de1588127When an IPv6 node processing an IPv6 packet does not support an IPv6 option whose two-highest-order bits of the Option Type are '10', it is required to respond with an ICMPv6 Parameter Problem error message, even if the Destination Address of the packet was a multicast address. This feature provides an amplification vector, opening the door to an IPv6 version of the 'Smurf' Denial-of-Service (DoS) attack found in IPv4 networks. This document discusses the security implications of the aforementioned options, and formally updates RFC 2460 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector.
e5af6fb0c5d35e703ef6a119c7b6b71aNeighbor Discovery is one of the core protocols of the IPv6 suite, and provides in IPv6 similar functions to those provided in the IPv4 protocol suite by the Address Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP). Its increased flexibility implies a somewhat increased complexity, which has resulted in a number of bugs and vulnerabilities found in popular implementations. This document provides guidance in the implementation of Neighbor Discovery, and documents issues that have affected popular implementations, in the hopes that the same issues do not repeat in other implementations.
1be4575d298c79f1d76da36e8e0f4cd4Recent security research seems to indicate that a number of IPv6 Neighbor Discovery implementations fail to implement basic sanity checks on received packets and/or fail to properly manage protocol data structures, being subject of trivial Denial of Service (DoS) attacks. Additionally, some IPv6 protocol features allow a number of attacks, ranging from man-in-the-middle to Denial of Service (DoS). This document discusses how to conduct a security/robustness assessment of Neighbor Discovery implementations by means of the SI6 Networks' IPv6 toolkit - a free, portable, and fully-featured IPv6 security assessment and trouble-shooting toolkit. Additionally, it provides pointers to ongoing work in this area, such that the aforementioned issues can be mitigated where appropriate.
8a65ffde5b00eee9e520aab39bf62a9dNeighbor Discovery is one of the core protocols of the IPv6 suite, and provides in IPv6 similar functions to those provided in the IPv4 protocol suite by the Address Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP). Its increased flexibility implies a somewhat increased complexity, which has resulted in a number of bugs and vulnerabilities found in popular implementations. This document provides guidance in the implementation of Neighbor Discovery, and documents issues that have affected popular implementations, in the hopes that the same issues do not repeat in other implementations.
c685017402f1b7880a5c07ebc8aaa101IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore IPv6 address scanning attacks have long been considered unfeasible. This document analyzes how traditional address scanning techniques apply to IPv6 networks, and also explores a number of other techniques that can be employed for IPv6 network reconnaissance. Additionally, this document formally obsoletes RFC 5157.
7f78a70d248af1e14513342f955f8fa1This toolkit houses various IPv6 tools that have been tested to compile and run on Debian GNU/Linux 6.0, FreeBSD 9.0, NetBSD 5.1, OpenBSD 5.0, Mac OS 10.8.0, and Ubuntu 11.10.
a4557708150feac8fb1fae279a6414f1ipv6mon is a tool for monitoring IPv6 address usage on a local network. It is meant to be particularly useful in networks that employ IPv6 Stateless Address Auto-Configuration (as opposed to DHCPv6), where address assignment is decentralized and there is no central server that records which IPv6 addresses have been assigned to which nodes during which period of time. ipv6mon employs active probing to discover IPv6 addresses in use, and determine whether such addresses remain active.
98f71bbf9254a35a40f290ab4572d606
© 2020 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed