All RH0 hysteria needs to stop now. This entire thread and effort is a BS smokescreen. There is nothing new here. The effort to kill off RH0 is all about enforcing a specific business model to sustain the zombie's of the telco world after they bought up all the independent isp's and still can't make the intelligent-network king.
There is no 'amplification', so the abstract is just wrong. The best this can do is route a single stream around policy; and for some the ability to route around the brokenness of an ISP in anti-competitive mode is a value, not a drawback. The crap in the document about an anycast destination being an amplification shows how little understanding there is about the concept. Anycast == 'unicast to the nearest instance'. There is no amplification, so again I say the hysteria needs to stop. There is no reason to preclude nodes from processing RH0 packets. If you have to say something say that 'hosts must not forward' else they become routers. It is perfectly fine for a host to process an RH0 packet as long as the result is another address on the same host. There is no reason for a host to forward an RH0 packet. If a router processes an RH0 packet, policy must have allowed it to do so as the network manager is presumably in control of his routers. The business model where RH0 has value is for metro/geo aggregation where the source needs to select the subscriber's transit provider across the metro/geo fabric. This is a business model the telco minded world wants to preclude because it recognizes that the customer has control, not the provider in a monopolistic strangle-hold. /rant I am getting really tired of the recent efforts by the telco world trying to kill off value to the end user, just because they get no direct benefit or perceive a direct threat to their dying model. rant/ Tony > -----Original Message----- > From: Joe Abley [mailto:[EMAIL PROTECTED] > Sent: Monday, May 28, 2007 2:04 PM > To: IETF IPv6 Mailing List > Subject: draft-ietf-ipv6-deprecate-rh0-01-candidate-00 > > > 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 --------------------------------------------------------------------
