On 24-May-2007, at 17:07, Joe Abley wrote:

> I've identified the following areas in which 00 might be modified,  
> based on traffic in this list and a small handful of private mail.  
> Please comment on the following, and point out any other  
> outstanding issues that I missed.

I have made some edits. Note that I am hoping to reach consensus on  
the changes to -00 which will produce -01 so that once -01 is  
submitted, it is ready for working group last call.

Attached is a proposed -01, and a unified diff from -00 follows.  
Please comment on the changes, and suggest others which are needed.


Joe

--- draft-ietf-ipv6-deprecate-rh0-00.unpg       2007-05-28  
16:56:44.000000000 -0400
+++ draft-ietf-ipv6-deprecate-rh0-01.unpg       2007-05-28  
16:56:59.000000000 -0400
@@ -3,15 +3,15 @@
Network Working Group                                           J. Abley
Internet-Draft                                                   Afilias
-Updates: 2460 (if approved)                                    P.  
Savola
-Intended status: Standards Track                               CSC/ 
FUNET
-Expires: November 29, 2007                               G. Neville- 
Neil
-                                                 Neville-Neil  
Consulting
+Updates: 2460, 4294                                            P.  
Savola
+(if approved)                                                  CSC/ 
FUNET
+Intended status: Standards Track                         G. Neville- 
Neil
+Expires: November 29, 2007                       Neville-Neil  
Consulting
                                                              May 28,  
2007
               Deprecation of Type 0 Routing Headers in IPv6
-                    draft-ietf-ipv6-deprecate-rh0-00
+             draft-ietf-ipv6-deprecate-rh0-01-candidate-00
Status of this Memo
@@ -45,13 +45,12 @@
Abstract
     The functionality provided by IPv6's Type 0 Routing Header can be
-   exploited in order to perform remote network discovery, to bypass
-   firewalls and 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 these security concerns.
+   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.
-   This document updates RFC 2460.
+   This document updates RFC 2460 and RFC 4294.
Table of Contents
@@ -65,6 +64,12 @@
       4.1.  Ingress Filtering
       4.2.  Packet Filtering
     5.  Security Considerations
+     5.1.  Network Discovery
+       5.1.1.  Testing Ingress Filtering
+       5.1.2.  Finding Attractors
+     5.2.  Bypassing Filtering Devices
+     5.3.  Denial of Service
+     5.4.  Defeating Anycast
     6.  IANA Considerations
     7.  Acknowlegements
     8.  References
@@ -83,11 +88,13 @@
     also defined.  Type 0 Routing Headers are referred to as "RH0" in
     this document.
-   Use of RH0 has been shown to have unpleasant security implications,
-   some of which are summarised in Section 5.  This document deprecates
-   the use of RH0.
+   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.
-   This document updates [RFC2460].
+   This document updates [RFC2460] and [RFC4294].
2.  Definitions
@@ -107,6 +114,9 @@
     IPv6 nodes MUST NOT originate IPv6 packets containing RH0.
+   IPv6 implementations are no longer required to implement RH0 in any
+   way.
+
3.2.  Processing
     IPv6 nodes MUST NOT process RH0 in packets addressed to them.  Such
@@ -137,17 +147,131 @@
     Where filtering capabilities do not facilitate matching specific
     types of Routing Headers, filtering based on the presence of any
-   Routing Headers on IPv6 routers, regardless of type, is strongly
-   discouraged.
+   Routing Headers on IPv6 routers, without explicitly checking the
+   Routing Header type, is strongly discouraged.
5.  Security Considerations
     The purpose of this document is to deprecate a feature of IPv6  
which
-   has been shown to have serious security implications.
+   has been shown to have undesirable security implications.
     Specific examples of vulnerabilities which are facilitated by the
-   availability of RH0 can be found in [CanSecWest07].
+   availability of RH0 can be found in [CanSecWest07], and are also
+   summarised below.
+
+5.1.  Network Discovery
+
+5.1.1.  Testing Ingress Filtering
+
+   A node N1 can probe a second node N2 in a remote autonomous  
system in
+   order to discover whether or not that autonomous system implements
+   ingress filtering ([RFC2827], [RFC3704]), so long as N2 supports RH0
+   processing, and N1 is able to identify one of N2's global-scope,
+   unicast IPv6 addresses.
+
+   N1 selects a global-scope source address A1 which is bound to a  
local
+   interface, and identifies a global-scope, unicast address A2  
which is
+   local to node N2.
+
+   N1 constructs an IPv6 datagram with IPv6 header source A1 and
+   destination address A2, and a RH0 containing the single waypoint
+   address A1.  N1 originates the datagram; if the datagram returns to
+   N1, then the autonomous system containing N2 does not implement
+   ingress filtering.
+
+5.1.2.  Finding Attractors
+
+   Some services are deployed on the Internet using anycast [RFC4786].
+   Individual anycast nodes normally receive traffic from sources  
within
+   a bounded topological region (a "catchment area").  Examples of
+   services deployed using IPv6 anycast include DNS authority
+   nameservers, 6to4 relay routers [RFC3068] and Teredo relays
+   [RFC4380].
+
+   It is usually difficult to determine the number and topological
+   locations of all anycast nodes providing a single service using a
+   single client probe, since only one node is typically visible to a
+   client at any time.  By including RH0 in packets addressed to an
+   anycast service address, however, a single client can cause a packet
+   to be sent via hosts or routers located in the catchment area of
+   remote anycast nodes.
+
+   Although the catchment areas of individual anycast nodes vary with
+   changing network topology and routing policy, opportunities to
+   discover the existence of other nodes without using RH0 are, in
+   general, limited.  RH0 provides a mechanism for automatic mapping of
+   anycast nodes and their catchment areas, information which might
+   subsequently be used to carry out attacks (see Section 5.4).
+
+5.2.  Bypassing Filtering Devices
+
+   Suppose a packet filter F is configured to protect two hosts S1 and
+   S2 which have different requirements for protection: S1 is intended
+   to serve some remote client C, but the filtering policies in F
+   restrict access to S2.  An example of such a scenario might be the
+   deployment of a public-facing web server (S1) and some other  
internal
+   device which provides an administrative interface over HTTP (S2).
+
+   If client C originates a datagram to S1 and includes a RH0 which
+   specifies an address of S2, then the packet might be passed by F
+   towards S1 and subsequently routed from S1 towards S2 without being
+   subject to the policies enforced by F. If S2 originates a packet in
+   reply towards C, it is feasible that the reply will be permitted by
+   F, and perhaps even that the reply will create state in F  
relating to
+   the communication between C and S2 which will allow subsequent
+   packets from C to be sent directly to S2 through F without the  
use of
+   RH0.
+
+5.3.  Denial of Service
+
+   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 technique can also be used as a more general traffic amplifier,
+   accumulating attack traffic in-flight between two well-connected but
+   mutually-distant waypoints and then finally delivering it towards a
+   third party once the RH0-directed oscillations for each packet are
+   complete. 7-fold amplification has been postulated using this
+   "capacitive effect" [CanSecWest07].
+
+   Various IPv6 transition mechanisms involve the transmission of IPv6
+   packets through tunnels built on IPv4 infrastructure (e.g.
+   [RFC2893], [RFC3056]).  Tunnels remain widely-used at the time of
+   writing for the transmission of IPv6 traffic over IPv4 networks.   
The
+   use of such tunnels can result in IPv6 paths which include a small
+   number of routers apparently connected by very high latency circuits
+   (tunnels).  Such paths provide opportunities to keep packets in-
+   flight for longer, with corresponding increases in amplification
+   potential.
+
+5.4.  Defeating Anycast
+
+   Packets originated by a single clients towards anycast destination
+   addresses will normally be routed towards a topologically local
+   anycast node for service.  This underpins one of the reasons to
+   deploy services using anycast: to sink traffic from flash crowds
+   locally, allowing damage from non-distributed sources to be  
localised
+   to the benefit of clients who are served by different anycast nodes.
+
+   By including RH0 with a waypoint address within the catchment  
area of
+   a remote anycast node, a single client can send traffic to multiple
+   anycast nodes providing the same service, avoiding the isolation of
+   such traffic to a single node which would otherwise result.
+
+   Section 5.1.2 describes the use of RH0 to facilitate the  
discovery of
+   anycast nodes deployed across the Internet, and to identify sets of
+   clients whose traffic is naturally attracted to particular anycast
+   nodes.  Together, these discovery and directed delivery techniques
+   allow all nodes of an anycast service to be targetted by a single
+   host.
6.  IANA Considerations
@@ -165,8 +289,10 @@
     [I-D.savola-ipv6-rh-hosts].  These efforts did not gain sufficient
     momentum to change the IPv6 specification, but resulted in the
     modification of the Mobile IPv6 specification to use the type 2
-   Routing Header instead of RH0 [RFC3775].  Routing Header issues were
-   later documented in [I-D.ietf-v6ops-security-overview].
+   Routing Header instead of RH0 [RFC3775].  Vishwas Manral identified
+   various risks associated with RH0 in 2006 including the  
amplification
+   attack; several of these vulnerabilities (together with other  
issues)
+   were later documented in [I-D.ietf-v6ops-security-overview].
     An eloquent and useful description of the operational security
     implications of RH0 was presented by Philippe Biondi and Arnaud
@@ -191,11 +317,14 @@
     [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", RFC 2460, December 1998.
+   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
+              April 2006.
+
8.2.  Informative References
     [CanSecWest07]
                BIONDI, P. and A. EBALARD, "IPv6 Routing Header  
Security",
-              April 2007.
+              CanSecWest Security Conference 2007, April 2007.
                http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
@@ -218,12 +347,28 @@
                Defeating Denial of Service Attacks which employ IP  
Source
                Address Spoofing", BCP 38, RFC 2827, May 2000.
+   [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+              IPv6 Hosts and Routers", RFC 2893, August 2000.
+
+   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+              via IPv4 Clouds", RFC 3056, February 2001.
+
+   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
+              RFC 3068, June 2001.
+
     [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for  
Multihomed
                Networks", BCP 84, RFC 3704, March 2004.
     [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility  
Support
                in IPv6", RFC 3775, June 2004.
+   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              Network Address Translations (NATs)", RFC 4380,
+              February 2006.
+
+   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
+              Services", BCP 126, RFC 4786, December 2006.
+
Appendix A.  Change History
@@ -239,6 +384,11 @@
     00 Renamed, draft-ietf-ipv6-deprecate-rh0, a candidate working  
group
        document.
+   01-candidate-00  Incorporated text summarising some of the unwelcome
+      uses of RH0; added some clariying text describing deprecation;
+      modified some ambiguous text in Section 4.2; added "Updates:
+      4294".
+
Authors' Addresses

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------