Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00

From: "George V. Neville-Neil" <[email-masked]>
Date: Tue, 05 Jun 2007 18:25:09 +0900

Hi,

Where are we on this draft at the moment?

Best,
George

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Jun 2007 11:18:28 -0400

> Where are we on this draft at the moment?

I was taken out of commission last week by an IAB retreat, and am  
currently trying to catch up on all the things I am behind on.  
Apologies for the delay. I aim to have a revised candidate on the  
list in the next day or two.

Joe

---

From: [email-masked]
Date: Wed, 06 Jun 2007 12:39:29 +0900

At Tue, 5 Jun 2007 11:18:28 -0400,
> list in the next day or two.

Great, sorry to nag.

Best,
George

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Jun 2007 16:31:15 -0700

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-masked]]
> 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

---

From: Joe Abley <[email-masked]>
Date: Wed, 6 Jun 2007 22:33:32 -0400

Hi Tony,

On 6-Jun-2007, at 19:31, Tony Hain wrote:

> There is no 'amplification', so the abstract is just wrong.

The candidate -01 contains the following text:

    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.

That text attempts to summarise three techniques which, facilitated  
by the widespread availability of RH0 processing, facilitates  
amplification which could be used as part of a denial-of-service attack.

If you have objections to the text I quoted above, it would help me  
if you could spell them out. I find it far easier to grasp objections  
if they are grounded in specific text.

> The crap in the document about an anycast destination being

If you can find text that equates an anycast destination being "an  
amplification", please point it out so I can remove it.

> Anycast == 'unicast to the nearest instance'.

Indeed. I was one of the authors of BCP 126 and have some familiarity  
with the concept.

> perceive a direct threat to their dying model.

I'm confused by your references to telco bias, and I'd appreciate  
some clarification.

Regards,

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Jun 2007 09:40:46 -0700

>     technique [CanSecWest07].

The stream is not amplified, it is still a single stream, and it is only one
packet at a time that has to wait for reception before being reflected back.
The total traffic volume over a given path may be higher, but this is not a
multiplication of the number of streams. 

>     "capacitive effect" [CanSecWest07].

The discussion about 3rd party implies this is related to spoofing. In any
case there are 4 parties in this scenario; src/RH0-1/RH0-2/dst, unless it is
being reflected back to the source. The traffic is not accumulated, it is
reflected back over the same paths multiple times. The postulation is
irrelevant and without looking it up (just going on 'capacitive'), likely
related to latency creating the ability to 'store a large volume oFrom [email-masked] Thu Jun 07 12:46:11 2007
From: "Tony Hain" <[email-masked]>
To: "'Joe Abley'" <[email-masked]>
Date: Thu, 7 Jun 2007 09:40:46 -0700
Cc: 'IETF IPv6 Mailing List' <[email-masked]>
Subject: RE: draft-ietf-ipv6-deprecate-rh0-01-candidate-00
Reply-To: [email-masked]

>     technique [CanSecWest07].

The stream is not amplified, it is still a single stream, and it is only one
packet at a time that has to wait for reception before being reflected back.
The total traffic volume over a given path may be higher, but this is not a
multiplication of the number of streams. 

>     "capacitive effect" [CanSecWest07].

The discussion about 3rd party implies this is related to spoofing. In any
case there are 4 parties in this scenario; src/RH0-1/RH0-2/dst, unless it is
being reflected back to the source. The traffic is not accumulated, it is
reflected back over the same paths multiple times. The postulation is
irrelevant and without looking it up (just going on 'capacitive'), likely
related to latency creating the ability to 'store a large volume of data'.
That is just wrong, because the packet is not replicated or stored beyond a
single instance in flight. There is at most one instance in flight, in only
one direction at a time. The longer the latency, the lower the total number
of bit times in any given period that a single RH0 reflection can impact.
The total number of bit times for the stream will be the same independent of
latency, but they will be spread out over time as the delay goes up.

>     flight for longer, with corresponding increases in amplification

This is absolute BS. The type of path has absolutely nothing to do with the
'opportunity' to exercise the exploit, and the fact that the packet is in
flight longer actually lowers the volume of traffic over a unit of time. In
any case the total number of bits is the same no matter what the latency is,
so tunneling has absolutely no ability to 'increase' the amplification
potential. 

> amplification", please point it out so I can remove it.

5.4
   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.

The traffic will always go to one-and-only-one anycast node. It may not be
the same one that would have been selected without RH0, but it will not go
to multiple nodes. Also this is about routing around policy, which has the
conveniently overlooked benefit that if the local anycast instance fails but
the route still exists, the service is still available to those that use RH0
to find another. RH0 is a tool, it is not bad or evil, it is a tool that
allows stating a specific waypoint. Any tool can be exploited for unintended
uses, but that is not a reason to ban the tool.

> Indeed. I was one of the authors of BCP 126 and have some familiarity

Unfortunately the text in 5.4 does not reflect that. 

> I'm confused by your references to telco bias, and I'd appreciate

That was a rant, related to multiple days of off list FUD from obstinate ISP
types that want to remove any capability for IPv6 to allow the end users to
exercise any control. Since this document is about killing off a technology
that is required for a metro/geo business model, and it started life as
*-evil-*, it automatically gets bucketed in with the ISP myopia about end
users having any form of control. I have no problem limiting the number of
RH0 segments, but killing it off is a knee-jerk reaction to a well known
exploit. TCP-SYN can be exploited, but I donf data'.
That is just wrong, because the packet is not replicated or stored beyond a
single instance in flight. There is at most one instance in flight, in only
one direction at a time. The longer the latency, the lower the total number
of bit times in any given period that a single RH0 reflection can impact.
The total number of bit times for the stream will be the same independent of
latency, but they will be spread out over time as the delay goes up.

>     flight for longer, with corresponding increases in amplification

This is absolute BS. The type of path has absolutely nothing to do with the
'opportunity' to exercise the exploit, and the fact that the packet is in
flight longer actually lowers the volume of traffic over a unit of time. In
any case the total number of bits is the same no matter what the latency is,
so tunneling has absolutely no ability to 'increase' the amplification
potential. 

> amplification", please point it out so I can remove it.

5.4
   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.

The traffic will always go to one-and-only-one anycast node. It may not be
the same one that would have been selected without RH0, but it will not go
to multiple nodes. Also this is about routing around policy, which has the
conveniently overlooked benefit that if the local anycast instance fails but
the route still exists, the service is still available to those that use RH0
to find another. RH0 is a tool, it is not bad or evil, it is a tool that
allows stating a specific waypoint. Any tool can be exploited for unintended
uses, but that is not a reason to ban the tool.

> Indeed. I was one of the authors of BCP 126 and have some familiarity

Unfortunately the text in 5.4 does not reflect that. 

> I'm confused by your references to telco bias, and I'd appreciate

That was a rant, related to multiple days of off list FUD from obstinate ISP
types that want to remove any capability for IPv6 to allow the end users to
exercise any control. Since this document is about killing off a technology
that is required for a metro/geo business model, and it started life as
*-evil-*, it automatically gets bucketed in with the ISP myopia about end
users having any form of control. I have no problem limiting the number of
RH0 segments, but killing it off is a knee-jerk reaction to a well known
exploit. TCP-SYN can be exploited, but I don't see calls to deprecate TCP
... 

Section 7
This presentation resulted in widespread publicity for the risks associated
with RH0.

s/publicity/hysteria

Tony

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 07 Jun 2007 19:16:59 +0200 (CEST)

<counter-rant>

All this monomanic ISP-bashing needs to stop now, if IPv6 is ever
to take off in any manner.

The claim that RH0 is "just a tool" and that there is no "amplification"
is narrow-sighted at best, since I understood from what has been
discussed here that it can indeed cause excessive bandwith utilization
along a path, and is therefore a much too useful tool in a miscreant's
hand to let loose on the unsuspecting masses.

Also, please do note, one man's tool to "select which ISP to use" can
easily be viewed by the ISPs as a tool for theft of service, inducing
routers to carry packets between customers A and B where neither
customer has any direct or indirect customer/provider relationship
with the providers of the path which is being used.  Why would any
reasonable ISP tolerate such (potential) behaviour?

</counter-rant>

Best regards,

- Håvard

---

From: Geoff Huston <[email-masked]>
Date: Fri, 08 Jun 2007 11:23:49 +1000

> latency, but they will be spread out over time as the delay goes up.

you are right that no packet gets duplicated in this scenario and 
ultimately the number of packets in equals the number out. But the 
attack relies of the technique of stuffing packets in over an extended 
interval and then releasing them all towards the destination in a much 
shorter time interval.

My understanding of this form of "capacitance attack" was to send the 
first N packets with X number of address pairs in the routing header, 
the second set of N packets with Y address pairs in the routing header 
(where Y is less than X) and so on. If you get the numbers just right, 
then all the packets get released to the destination address at the same 
time - i.e. discharging all the traffic to the ultimate destination in 
the routing header address pair "capacitor" at the same time.

Yes, getting the timing right for this approach would appear to be a 
very tricky issue to solve!

regards,

   Geoff

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Jun 2007 18:56:19 -0700

> hand to let loose on the unsuspecting masses.

So fix it by restricting the number of waypoints. Killing it only prevents
valid uses.

> reasonable ISP tolerate such (potential) behaviour?

There is no requirement that an ISP accept a packet with RH0 from a
non-customer, so this claim of theft is just more FUD feeding the hysteria. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Jun 2007 18:59:59 -0700

> interval and then releasing them all towards the destination in a much

This makes no sense. The latency is the same for the entire packet chain, so
the delay between the first and last should be the same at the exit, modulo
normal queuing jitter.

> the routing header address pair "capacitor" at the same time.

Well one might try, but reality is that the last hop will just queue the
pile and they will arrive serially based on link speed if they are not
dropped. Also, unless X & Y are different paths for each time interval, the
preceding set of N will be tying up the link queues to preclude the
subsequent ones from moving.

> very tricky issue to solve!

I think it is more than timing. It would appear that one needs to choose an
appropriate set of X & Y alternative pairs to keep serialization delays from
getting in the way of the plan. It is much simpler to tell the army of
zombies to ddos a site than it is to figure out the right set of X & Y pairs
along with the right number of bounces for each set of N. The FUD over this
supposed threat is just feeding the hysteria. 

As I said earlier, it is reasonable to limit the number of waypoints in the
RH0 path. I don't know the right number, but to support the simple scenario
of selecting transit across a metro/geo fabric I could be convinced that 1
is right. Others may have different use cases with slightly more. In any
case, a small number of waypoints does not raise the threat of dos due to
bouncing significantly more than the threat of back-to-back packet dos.  

Tony

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Jun 2007 22:40:51 -0400

On 7-Jun-2007, at 12:40, Tony Hain wrote:

> The stream is not amplified, it is still a single stream,

That's a valid editorial point, thanks.

> and it is only one

No, that's not the case. Packets constructed with an RH0 extension  
header containing intermediate addresses A and B, N times (so, for  
example, if N=5 then RH0 contains ten addresses, A B A B A B A B A B)  
can be injected into the A-B cyclotron as rapidly as the path between  
the origin and A allows, without ever waiting for a response.

So long as the injection rate is higher than 1/(N*T) where T is the  
round-trip delay between A and B, the traffic impact between A and B  
will exceed that between the origin and A, N-fold.

> multiplication of the number of streams.

It's a multiplication of the amount of traffic being carried, though.  
The ability to cause 88Mbit/s of traffic in a remote network with  
only 1Mbit/s of effort is surely an amplification effect (and surely  
a concern).

> The discussion about 3rd party implies this is related to spoofing.

No, not at all. The victim address in this case is a destination  
address, not a source address.

My understanding of the CanSecWest authors' thinking with respect to  
this particular technique is that the number of (A, B) waypoints in  
the RH0 header would be varied such that for every one packet that  
entered the A-B cyclotron, you could achieve N packets leaving  
simultaneously, each having been round the A-B loop a different  
number of times.

Maximising the output of such a capacitor would require tuning the  
RH0 extension header construction according to the observed round- 
trip latency between A and B which seems non-trivial, but at the same  
time not impossible.

Note that I have not explored the details of this with the CanSecWest  
presenters, however; it's possible that they were thinking of  
something different (and equally plausible that there's a fault with  
my logic, above).

> 'opportunity' to exercise the exploit,

Right, but the round-trip path latency does (see above).

> The traffic will always go to one-and-only-one anycast node.

Not with widespread RH0 support; that's the point this section  
attempts to make. With RH0 support a single origin can send packets  
which will arrive at different anycast nodes, regardless of the  
natural (no-RH0) node that would normally receive the traffic.

> Unfortunately the text in 5.4 does not reflect that.

I have not yet understood your point (or you have not understood  
mine). I'm not convinced that we have a problem in 5.4, yet.

> exercise any control.

I am sympathetic to the problem; if I had a magic wand that would  
allow press coverage of technical issues to be (a) accurate and (b)  
fully understood by all who read it, I would wave it :-)

However, this seems orthogonal to the technical issue.

> Since this document is about killing off a technology
> users having any form of control.

There's a long history of "-is-evil-" being used in document names in  
the IETF, and it's common argot amongst operators when describing  
things that have unpleasant side-effects (see, for example, the  
recent, huge NANOG thread on NAT, where NAT was declared as being  
evil about every three messages).

You know this, of course. I feel your frustration, and I appreciate  
that one more reason not deploy IPv6 amongst operators of any share  
is not something that is going to make for a happy fun day for you.  
However, I don't think that blaming my earlier document name for non- 
deployment of IPv6 in this case is reasonable.

> I have no problem limiting the number of

The well-known exploit in this case was judged by this working group  
to have minimal demonstrated application in the real world, and non- 
trivial risks associated with its availability, hence the decision to  
deprecate.

If you think that judgement of consensus by the wg chairs was wrong,  
then that seems like something best taken up with them; this document  
is a reaction to that consensus, not a proponent of it.

> This presentation resulted in widespread publicity for the risks  

It seems like it would be unusual to see one without the other.

Joe

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 7 Jun 2007 19:53:19 -0700

Hi Joe,

> That's a valid editorial point, thanks.
The amount of traffic is amplified. I dont see a reason to say that
the amount of traffic is not amplified. The amount of processing is
amplified too.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 7 Jun 2007 20:00:04 -0700

Hi Tony,

> multiplication of the number of streams.
The packets are not replicated and as you said the amount of traffic
between the link is amplified.  It seems to be clearly stated in the
dictionary.

Amplify =  to make larger or greater (as in amount, importance, or
intensity) . http://www.m-w.com/dictionary/amplify

> So fix it by restricting the number of waypoints. Killing it only prevents
I have added a draft that puts in checks to reduce such traffic
amplification, for exactly the purpose you state.

Thanks,
Vishwas

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Jun 2007 23:09:12 -0400

On 7-Jun-2007, at 22:53, Vishwas Manral wrote:

> The amount of traffic is amplified.

Yes.

> I dont see a reason to say that
> the amount of traffic is not amplified.

Indeed, that would seem contradictory :-)

> The amount of processing is
> amplified too.

Yes.

Joe

---

From: Geoff Huston <[email-masked]>
Date: Fri, 08 Jun 2007 13:49:04 +1000

> the delay between the first and last should be the same at the exit, modulo

Here's an example:

The first N packets do       Src -> A -> B -> A -> B -> A -> B ->Dst

The second set of packets do Src -> A -> B -> A -> B ->Dst

The third set of packets do  Src -> A -> B ->Dst

Now if you get everything _just right_ in terms of timings (and that 
will be tricky) you can get all 3 sets of packets released to the 
destination in a burst that is up to 3 x the input packet rate in this 
example.

And, yes there are probably simpler DDOS attacks out there! I was simply 
trying to explain what the original work and Joe's draft referred to 
when they referred to "capacitance attacks".

regards,

   Geoff

---

From: Brian Haberman <[email-masked]>
Date: Fri, 08 Jun 2007 07:14:30 -0400

Hi Tony,

> So fix it by restricting the number of waypoints. Killing it only prevents

I am thinking that it is easier to fix by deprecating RH0 and then
defining a new routing header with stricter properties.  Similar to the
MIPv6 routing header.  That way, the safer RH option can be clearly
identified in the wild and won't be blocked/restricted/blocked by
filters meant to protect networks/nodes from the RH0 attacks.

Regards,
Brian

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 8 Jun 2007 08:21:22 -0700

> the origin and A allows, without ever waiting for a response.

And as soon as they are at A the packets have to wait for head of line
blocking to get to B. 

> only 1Mbit/s of effort is surely an amplification effect (and surely

So fix the spec so there is only one RH0 allowed. Killing it does not
prevent exploitation of the network. If exploitation is such a threat then
we need to kill off ICMP because it is a much more widely used attack vector
than routing headers.

> address, not a source address.

Due to serialization delay the victim will never be the destination. It
might be the upstream router queue from the destination, but the nice
mathematical theory about instantaneous convergence falls flat when reality
strikes in the form of bit serialization. 

> simultaneously, each having been round the A-B loop a different

Unless they vary the actual A & B with the destination behind a richly
connected fabric, the packets will never converge at exactly the same time.
Even if they did vary A & B, the packets can't exit simultaneously because
they have to queue up to get over that interface. 

> trip latency between A and B which seems non-trivial, but at the same

Converging packet streams onto an interface queue is much simpler using an
army of zombies in a ddos attack. Why would anyone waste time trying to game
a dynamic state where the tuning would have to be precise, and would easily
be disrupted by 3rd party traffic on the path? Unless someone can provide
the working code, this does not belong in any document because it is just
conjecture. 

> something different (and equally plausible that there's a fault with

You essentially described the same thing Geoff Huston did, so I suspect your
reading is not flawed. Their premise on the other hand is because the
reality of interface queuing and clocking invalidates the claimed result of
a simultaneous arrival. 

> natural (no-RH0) node that would normally receive the traffic.

The world should tremble in fear ... a single node can send individual
packets to more than one destination ?!?!?!?!   This section is still worded
wrong. Any single packet will always go to a single destination. Use of RH0
does not result in a single packet arriving at multiple anycast
destinations. 

The entire title of 5.4 is wrong, anycast is not defeated, the packet still
arrives at one-and-only-one of the anycast instances. Depending on where the
RH0 target is, that MAY be a different instance that would occur without the
routing header. 

Clearly the reason this text was put in was someone wants the entire world
to be forced into their policy model where nodes are not allowed to route
around a broken instance of an anycast service. Flash crowd containment
still happens, it just may be that a different instance of the service feels
the pain than what was expected. Load distribution is the goal for anycast,
even in the flash-crowd-containment scenario. Clearly somebody doesn't like
the idea that the end user should have the ability to select an instance if
the local one is broken, so again I say this entire effort is not about
fixing brokenness, it is about power and control over the lowly end user.

> mine). I'm not convinced that we have a problem in 5.4, yet.

The existing language effectively says that packets to an anycast dst which
have an RH0 header will arrive at multiple instances. I know you are trying
to say that 'the source node gets to select the anycast instance', but that
is not what this says, and if you said it the way I did it would not
generate the hysteria needed to get consensus. 

> However, this seems orthogonal to the technical issue.

The issue at hand is that RH0 should be limited to 1 or 2 to avoid the
bounce problem. Other than that this is all about control which is also a
non-technical issue, so exactly why are we doing this again?

> evil about every three messages).

I am aware of that, and those almost always start as non-technical 'I want
control' nonsense. As for the nanog thread on nat, the other 2 of 3 messages
were defending nat as the savior of the universe and absolutely necessary in
IPv6 networks. 

NANOG has stopped being a useful technical reference because it is all about
religion. 

> deployment of IPv6 in this case is reasonable.

Lack of deployment of IPv6 has nothing to do with IETF documentation. It is
all about the unwillingness of the 'guru cult' to risk their status by
trying to learn something different. The desperation is becoming more
apparent though as the reality of the end of IPv4 storms over the horizon. 

RH0 is not a threat if limited to 1 or 2. I can't come up with a reason for
more than one, but I am willing to believe there are use cases. 

> trivial risks associated with its availability, hence the decision to

That is because it's applicability is to an environment that can't get
formed until there is sufficient deployment of IPv6 to force the point that
alternative aggregation models to PA and swamp PI are required. Metro/geo in
addition to PA/PI will allow scaling capabilities to the masses, but making
those work requires at least a one hop RH0.

> is a reaction to that consensus, not a proponent of it.

Hopefully I will get some time in the next couple of weeks to draft an
alternative viewpoint related to fixing RH0. Claiming that consensus was
reached in the middle of press and mail list hysteria is a stretch. At the
same time there is precedent in the SL fiasco.

---

From: Joe Abley <[email-masked]>
Date: Fri, 8 Jun 2007 14:38:31 -0400

> filters meant to protect networks/nodes from the RH0 attacks.

This has the practical side-effect that it is well-aligned with  
operational practice (since several prominent implementations have  
been modified to treat RH0 has an unknown extension header, which is  
effectively the behaviour required by draft-ietf-ipv6-deprecate-rh0).

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 8 Jun 2007 14:48:10 -0400

> And as soon as they are at A the packets have to wait for head of line

Yes. I do not currently see how this prevents the amplification  
effect, however, except in corner cases where the round-trip latency  
between A and B is very low and the B-facing interface at A is of  
very low bandwidth.

>>>>     accumulating attack traffic in-flight between two well- 
>>>> connected
>>>> but

Seems to me that every denial-of-service attack against a single  
point victim experiences serialisation delay somewhere along the  
line, but that doesn't seem to mean that denial-of-service attacks  
don't deny service.

> the working code, this does not belong in any document because it  

There was code in the CanSecWest slides.

> does not result in a single packet arriving at multiple anycast

I agree, and it was not my intention to imply that they could. I will  
see whether I can make that more clear in the text (thanks).

> RH0 target is, that MAY be a different instance that would occur  

The point of the section is that a single client can arrange for  
packets with a single destination to be routed to different anycast  
nodes at will, not that the same packet could be made to arrive at  
multiple anycast nodes.

> generate the hysteria needed to get consensus.

I will change the text. I don't agree that the text as-written was  
designed to generate hysteria (and as I wrote it, I should know :-)  
but I agree that the text as it stands is woolly and could do with  
being made more clear.

Joe

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Sat, 09 Jun 2007 10:47:10 +0900

At Fri, 8 Jun 2007 14:38:31 -0400,
> effectively the behaviour required by draft-ietf-ipv6-deprecate-rh0).

Creating a new "safer" option has been suggested by others several
times already including on this mailing list.  So, let's do one thing
then the next.  If someone wants to suggest a safe version of this
they are welcome to.

Best,
George