Security Implications of IPv6 Options of Type 10xxxxxx
draft-gont-6man-ipv6-smurf-amplifier-02

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2013-01-24
Stream (None)
Intended RFC status (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
IPv6 maintenance Working Group (6man)                            F. Gont
Internet-Draft                                    SI6 Networks / UTN-FRH
Updates: 2460, 4443 (if approved)                                 W. Liu
Intended status: Standards Track                     Huawei Technologies
Expires: July 28, 2013                                  January 24, 2013

         Security Implications of IPv6 Options of Type 10xxxxxx
                draft-gont-6man-ipv6-smurf-amplifier-02

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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 28, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Gont & Liu                Expires July 28, 2013                 [Page 1]
Internet-Draft        IPv6 options of Type 10xxxxxx         January 2013

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Updating RFC 2460 and RFC 4443 . . . . . . . . . . . . . . . .  5
   3.  Operational mitigations  . . . . . . . . . . . . . . . . . . .  6
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

Gont & Liu                Expires July 28, 2013                 [Page 2]
Internet-Draft        IPv6 options of Type 10xxxxxx         January 2013

1.  Introduction

   IPv6 has eliminated most of the amplification vectors that were
   available in IPv4 to perform 'Smurf'-like Denial of Service (DoS)
   attacks [CERT1998].  However, an amplification vector has been left
   in the core IPv6 and ICMPv6 specifications ([RFC2460] and [RFC4443])
   that would allow for an IPv6 version of the 'Smurf' Denial-of-Service
   (DoS) attacks [CERT1998] [RFC6274] found in IPv4 networks.  The
   aforementioned vector is based on the use of unsupported IPv6
   options, used in combination with multicast destinations.

   [RFC2460] specifies, in Section 4.2, that when a node processing an
   IPv6 packet does not support an IPv6 option whose two-highest-order
   bits of the Option Type are '10', it should respond with an ICMPv6
   Parameter Problem error message, even if the Destination Address of
   the packet was a multicast address.  [RFC4443] specifies, in Section
   2.4 (page 6), that packets destined to an IPv6 multicast address
   should not elicit ICMPv6 error messages, with the exception of ICMPv6
   Packet Too Big messages (such that Path-MTU Discovery works for IPv6
Show full document text