Subject: draft-ietf-ipv6-deprecate-01-01-candidate-02

From: Joe Abley <[email-masked]>
Date: Mon, 25 Jun 2007 12:56:07 -0400

Hi all,

Apologies for the delay on this update; real life has been intruding  
with great regularity.

The change-log reads:

    01-candidate-02  Moved description of traffic amplification to
       Section 1, and inserted a corresponding cross-reference in
       Section 5.  Strengthened the language in Section 4.2 along the
       lines suggested by Thomas Narten.  Small typos corrected.   
Added a
       further sentence in Section 4.1 intended to act as further
       encouragement for operators to implement [RFC3704].

I still have my doubts about the practical usefulness of a standards  
document attempting to dictate operational behaviour using normative  
language, but since my doubts aren't widely shared I am happy to  
throw them to the side.

Unified diff follows; new candidate text is attached. If I've missed  
any other updates requested by people, please let me know and I  
promise a more rapid turn-around for subsequent candidates.

Alternatively, if people tell me to submit this as -01, I will do so  
with all due alacrity.

Thanks,

Joe

--- draft-ietf-ipv6-deprecate-rh0-01-01.unpg    2007-06-25  
12:52:59.000000000 -0400
+++ draft-ietf-ipv6-deprecate-rh0-01.unpg       2007-06-25  
12:51:22.000000000 -0400
@@ -11,7 +11,7 @@
               Deprecation of Type 0 Routing Headers in IPv6
-             draft-ietf-ipv6-deprecate-rh0-01-candidate-01
+             draft-ietf-ipv6-deprecate-rh0-01-candidate-02
Status of this Memo
@@ -45,10 +45,11 @@
Abstract
     The functionality provided by IPv6's Type 0 Routing Header can be
-   exploited in order to achieve packet amplification for the purposes
-   of generating denial-of-service traffic.  This document updates the
-   IPv6 specification to deprecate the use of IPv6 Type 0 Routing
-   Headers, in the light of the severity of this security concern.
+   exploited in order to achieve traffic amplification over a remote
+   path for the purposes of generating denial-of-service traffic.  This
+   document updates the IPv6 specification to deprecate the use of IPv6
+   Type 0 Routing Headers, in the light of the severity of this  
security
+   concern.
     This document updates RFC 2460 and RFC 4294.
@@ -80,11 +81,29 @@
     also defined.  Type 0 Routing Headers are referred to as "RH0" in
     this document.
-   The functionality provided by IPv6's Type 0 Routing Header can be
-   exploited in order to achieve packet amplification for the purposes
-   of generating denial-of-service traffic.  This document updates the
-   IPv6 specification to deprecate the use of IPv6 Type 0 Routing
-   Headers, in the light of the severity of this security concern.
+   A single RH0 may contain multiple waypoint addresses, and the same
+   address may be included more than once in the same RH0.  This allows
+   a packet to be constructed such that it will oscillate between two
+   RH0-processing hosts or routers many times.  This allows a stream of
+   packets from an attacker to be amplified along the path between two
+   remote routers, which could be used to cause congestion along
+   arbitrary remote paths and hence act as a denial-of-service
+   mechanism. 88-fold amplification has been demonstrated using this
+   technique [CanSecWest07].
+
+   This attack is particularly serious in that it affects the entire
+   path between the two exploited nodes, not only the nodes themselves
+   or their local networks.  Analogous functionality may be found in  
the
+   IPv4 source route option, but the opportunities for abuse are  
greater
+   with RH0 due to the ability to specify many more waypoints in each
+   packet.
+
+   The severity of the threat is considered to be sufficient to warrant
+   deprecation of RH0 entirely.  This has the unfortunate side-effect
+   that benign use cases for RH0 are eliminated along with the  
potential
+   security hazards; such applications may be facilitated in the future
+   by new routing header specifications which do not suffer from RH0's
+   problems.
     This document updates [RFC2460] and [RFC4294].
@@ -129,21 +148,27 @@
     described in [CanSecWest07] can be mitigated using ingress  
filtering,
     as recommended in [RFC2827] and [RFC3704].
+   A site security policy intended to protect against attacks using RH0
+   SHOULD include the implementation of ingress filtering at the site
+   border.
+
4.2.  Firewall Policy
+   Blocking all IPv6 packets which carry Routing Headers (rather than
+   specifically blocking type 0, and permitting other types) has very
+   serious implications for the future development of IPv6.  If even a
+   small percentage of deployed firewalls block other types of routing
+   headers by default, it will become impossible in practice to extend
+   IPv6 routing headers.  For example, Mobile IPv6 [RFC3775] relies  
upon
+   a type-2 RH; wide-scale, indescriminate blocking of Routing Headers
+   will make Mobile IPv6 undeployable.
+
     Firewall policy intended to protect against packets containing RH0
-   should be constructed such that routing headers of other types  
(which
-   may well have legitimate and benign applications) are handled on
-   their own merits.  For example, discarding all packets with any type
-   of routing header simply as a reaction to the problems with RH0 is
-   inappropriate, and may hamper future functionality designed using
-   non-type 0 routing headers.  For example, Mobile IPv6 uses the  
type 2
-   Routing Header [RFC3775].
-
-   Where filtering capabilities do not facilitate matching specific
-   types of Routing Headers, filtering based on the presence of any
-   Routing Headers on IPv6 routers, without explicitly checking the
-   Routing Header type, is strongly discouraged.
+   MUST NOT simply filter all traffic with a routing header; it must be
+   possible to disable forwarding of type 0 traffic without blocking
+   other types of routing headers.  In addition, the default
+   configuration MUST permit forwarding of traffic using a RH other  
than
+   0.
5.  Security Considerations
@@ -153,31 +178,8 @@
     examples of vulnerabilities which are facilitated by the  
availability
     of RH0 can be found in [CanSecWest07].  In particular, RH0  
provides a
     mechanism for traffic amplification, which might be used as a  
denial-
-   of-service attack.
-
-   A single RH0 may contain multiple waypoint addresses, and the same
-   address may be included more than once in the same RH0.  This allows
-   a packet to be constructed such that it will oscillate between two
-   RH0-processing hosts or routers many times.  This allows a stream of
-   packets from an attacker to be amplified along the path between two
-   remote routers, which could be used to cause congestion along
-   arbitrary remote paths and hence act as a denial-of-service
-   mechanism. 88-fold amplification has been demonstrated using this
-   technique [CanSecWest07].
-
-   This attack is particularly serious in that it affects the entire
-   path between the two exploited nodes, not only the nodes themselves
-   or their local networks.  Analogous functionality may be found in  
the
-   IPv4 source route option, but the opportunities for abuse are  
greater
-   with RH0 due to the ability to specify many more waypoints in each
-   packet.
-
-   The severity of the threat is considered to be sufficient to warrant
-   deprecation of RH0 entirely.  This has the unfortunate side-effect
-   that benign use cases for RH0 are eliminated along with the  
potential
-   security hazards; such applications may be facilitated in the future
-   by new routing header specifications which do not suffer from RH0's
-   problems.
+   of-service attack.  A description of this functionality can be found
+   in Section 1.
6.  IANA Considerations
@@ -282,6 +284,13 @@
     01-candidate-01  Incorporated contributions from working group:
        substantially reduced Section 5; clarified wording in Section 3.
+   01-candidate-02  Moved description of traffic amplification to
+      Section 1, and inserted a corresponding cross-reference in
+      Section 5.  Strengthened the language in Section 4.2 along the
+      lines suggested by Thomas Narten.  Small typos corrected.   
Added a
+      further sentence in Section 4.1 intended to act as further
+      encouragement for operators to implement [RFC3704].
+
Authors' Addresses
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2007 12:00:44 +0200

FWIW, my opinion is 'ship it'. It seems like time
to get a formal readout of (rough) WG consensus
on this.

     Brian

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 27 Jun 2007 13:13:31 +0100

I also think this is in good shape.

One addition that would be useful is to reference the v6ops security 
overview (draft-ietf-v6ops-security-overview-06.txt currently in AUTH48 
and about to be published as RFC 4942).
This also discusses security issues with RH0 (including the 
amplification attack) and routing headers in general.

Regards,
Elwyn