IPv6 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. Revision 2 of this document. This revision includes, among other things, a discussion of possible issues with SEND as a result of IPv6 fragmentation.
a8b7a492cc8ab102f8884547a7f042ea0e94a1cdbbad648050eb655bf675f524Cisco Security Advisory - A vulnerability in the IP version 6 (IPv6) processing code of Cisco IOS XR Software for Cisco CRS-3 Carrier Routing System could allow an unauthenticated, remote attacker to trigger an ASIC scan of the Network Processor Unit (NPU) and a reload of the line card processing an IPv6 packet. 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. Cisco has released free software updates that address this vulnerability. There is no workaround that mitigates this vulnerability.
e56b00b94f7935d03ca8b85ffb3a47abd5d4c85aedc4c8a4a169c488060e8544This 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.
4f100808cfb77d0cea54d4c5b190d179c17b9bd141d9d61bb6013c9766d28960This 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.
aea1ddd79e402a7e6cae6940341f56386d8efe61f639f9142e54a9dda4b93d71IPv6 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.
88c1519d37583c204027fbdd3ae3a25828b219b714e31c6f02daeaa96b3e1490This 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.
46631cfae65fdb6654ab9e329ade0ad4a20f0dd648446b6619a9a7a7b9676a5dThe 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.
9effe2e0fcf845f3f698a422ede8446c43df6f4d6472aafb96dd9a13c554fe6aThis 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.
f955987c95afee36773fb986f0bf5b02f89c6d9a9973c325dcbc1e926676ad9aThis 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.
903ddcb4eca069a1e4d2bb9516b478eda66b60596e5457b418a1891a5c85d510The 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.
feac00abce76ecd39bf1bb5b6c8804af13f2781cf51012a6d77c2a65a15888dfThis Internet Draft specifies the security implications of predictable fragment identification values in IPv6. It primarily focuses on countermeasures and mitigations.
38ea3e1b37df89d887edc1122b9c494c6779e2d1a05a220fd84e7a860c114607When 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.
fb4961bf8357488cad14ec9267d3578def97ef7eb554541ecd35f6f1114d3f2cNeighbor 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.
00f877672b0a83b4dcaf16a1fcdecc660203df4d41d883646ee612d312f28996Neighbor 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.
776720fc1a25b2e907c4a468e1b19348a3ea339fb5630e617a7932a7e2ea9b23IPv6 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.
048514499a17396a23d97600ebed59b44a15828ff936fd26e985822b271d5d5fThis 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.
2ca68992f1e854362ce2fe5d00357f8634430a612c312dba8e00ad5d586e35f4This document specifies a mechanism that can be implemented in layer-2 devices to mitigate attack vectors based on Neighbor Discovery messages. It is meant to complement other mechanisms implemented in layer-2 devices such as Router Advertisement Guard (RA-Guard) and DHCPv6-Shield, with the goal of achieving a comprehensive IPv6 First Hop Security solution. This document is motivated by the desire to achieve feature parity with IPv4 with respect to First Hop Security mechanisms.
b0bd48d4dfcf7fc338169df812038a282998457c61b3f8cfb9294a669b43f80aThis 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.
2167f8ff55bb0233568e045e7042373efab0919dd45517725399c88fa634ea33This 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.
b620fd364138e64c6e10717389b326fd4176c5005ea71cbad80cb84096381fe9IPv6 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 host scanning attacks against IPv6 networks, and therefore IPv6 host scanning attacks have long been considered unfeasible. This document analyzes the IPv6 address configuration policies implemented in most popular IPv6 stacks, and identifies a number of patterns in the resulting addresses lead to a tremendous reduction in the host address search space, thus dismantling the myth that IPv6 host scanning attacks are unfeasible.
3e402c5d8f47be6b853bd514ed35744c8ab3f764907fb96603770a5396359be0This 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. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users.
2be85628520d1d07881dc0a60f77204594c41e42519ec05b5b14ddb2b2f10d7fThis Internet Draft specifies the security implications of predictable fragment identification values in IPv6. It primarily focuses on countermeasures and mitigations.
797c390e09afddabe88fd2b44a2368bbbcd4539539cf70a92b9a03e8ffc6de92This IETF Internet Draft discusses security and interoperability implications of oversized IPv6 header chains.
8ec27e6f6b09e69798fd08859eb67352a7f027ed6076d6512288a35a48b32023This Internet Draft focuses on providing advice to RA-Guard implementations, rather than on the evasion techniques that have been found effective against most popular implementations of RA-Guard.
b94a267d451834a19ba9db5489c12513c4c414f2e2934e7d487b0a5d8d337180This Internet Draft specifies the security implications of predictable fragment identification values in IPv6. It primarily focuses on countermeasures and mitigations.
460fd180c573767e12e1ffa15a9dc5ae08637e6d06e765a8c0e9f2d0c204a17cThis 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. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the same manageability benefits can be achieved without sacrificing the privacy of users.
542e6aa994a33734dc569e8c3b291d6929f88f48ab8d12f2e29320b1c816fadd
© 2024 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