Security Implications of IPv6 Options of Type 10xxxxxx
draft-gont-6man-ipv6-smurf-amplifier-03
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Last updated | 2013-09-21 (latest revision 2013-03-20) | ||
| Stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
pdf
htmlized
bibtex
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus Boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
https://www.ietf.org/archive/id/draft-gont-6man-ipv6-smurf-amplifier-03.txt
Abstract
When 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 and RFC 4443 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector.
Authors
Fernando Gont
(fgont@si6networks.com)
Will LIU
(liushucheng@huawei.com)
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)