Subject: moving towards draft-ietf-ipv6-deprecate-rh0-01

From: Joe Abley <[email-masked]>
Date: Thu, 24 May 2007 17:07:49 -0400

Hi all,

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 intend to circulate candidate text changes to this list before -01  
is submitted, in the interests of making -01 as close to finished as  
possible.

1. More description on what the potential problems with RH0 are.  
Whilst it appears there there is general agreement that a detailed  
treatment would best belong in a separate document, some stand-alone  
summaries in deprecate-rh0 would be useful.

Illjitsch sent some text, and I had previously worked on some  
summaries of the issues presented at CanSecWest. I propose to add  
some suitable summary text to the Security Considerations section.

2. More precise description of what deprecate means in the context of  
this document.

3. Tidying up the language in section 4.2 ("regardless of type") to  
make it less ambiguous.

4. Adding "Updates: 4294" (IPv6 Node Requirements).

What else did I miss?

Joe

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

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Fri, 25 May 2007 17:01:17 +0900

At Thu, 24 May 2007 17:07:49 -0400,
> 4. Adding "Updates: 4294" (IPv6 Node Requirements).
This seems like a good list.  I am hoping that 01 might be done soon
and moved on so that I can be comfortable updating the code.

Best,
George

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 25 May 2007 17:55:22 +0900

> some suitable summary text to the Security Considerations section.

I agree that we should briefly describe 'why this' (if this item
intends that).  Even if a normative spec is usually not so verbose
about rationale of specific behavior, I believe we must provide some
minimal level information on this for this document, especially
because this document attempts to deprecate existing specification;
implementors who are not involved in the whole discussion and just see
the resulting document won't be very much willing to modify their
implementations just by being told "do it".

Regarding the "rationale", I think the current draft actually
overstates the "problem".  Although the source routing may cause
various possible concerns, most of them would not result in such a
strong action as complete deprecation as far as I understand them;
we're primarily taking this action due to the tradeoff consideration
between the threat level of the amplification attack and possible
benefit of the routing header.

So, for example, the abstract of the 00 text seems to overstate the
issue:

   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.  [...]

I'd rephrase this so that we can concentrate on the exact problem:

   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.

I'd also update Sections 1 and 5 this way.  I'd also like to clarify
that this is particularly severe for RH0 in that it can contain much
more waypoints than the IPv4 source route option.

I believe it's beneficial to concentrate on the real point because it
would answer counter arguments like "why disable-by-default is not
deemed sufficient" or "why we deprecate it while keeping IPv4 source
route option", etc.

> 2. More precise description of what deprecate means in the context of  

Yes, this would be good.  I assume this also intends to clarify more
details about the processing behavior described in Section 3.2, e.g.

- what the receiving node should do if it receives a packet containing
  RH0 with the segment left field being 0
- whether or not ICMPv6 error is returned when a node receives a
  packet containing RH0

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Fri, 25 May 2007 13:52:12 -0700

Jinmei,

[with no hats on]

>    Headers, in the light of the severity of this security concern.

I agree that we should be clear about the problem and think your  
proposed text does that well.

> - whether or not ICMPv6 error is returned when a node receives a

I also agree that spelling this out in more detail as you suggest is  
a good idea.

Bob

---

From: Joe Abley <[email-masked]>
Date: Mon, 28 May 2007 17:03:47 -0400

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

> 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: Brian E Carpenter <[email-masked]>
Date: Tue, 29 May 2007 10:36:25 +0200

I'm fine with this version. Thanks.

    Brian

NEW: Preferred email for non-IBM matters: [email-masked]

On 2007-05-28 23:03, Joe Abley wrote:
> 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

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Tue, 29 May 2007 17:57:20 +0900

At Mon, 28 May 2007 17:03:47 -0400,
Joe Abley wrote:
> 
> [1  <text/plain; US-ASCII (7bit)>]
> 

I am fine with your 01 proposal.

Best,
George

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 30 May 2007 00:08:21 +0900

> submitted, it is ready for working group last call.

The 01-candidate doesn't completely address my previous comments.
Some of the comments may be controversial, but I believe at least some
others are supported by a majority of the wg (and should be
addressed before a WGLC).

- section 3.1

   IPv6 implementations are no longer required to implement RH0 in any
   way.

I don't understand why we bother to say this.  Isn't it enough to
state "IPv6 nodes MUST NOT originate IPv6 packets containing RH0."?

- section 3.2

This section doesn't address my previous comments: I believe we should
specify the behavior when a node receives RH0 with segment left being
0; we should also specify whether an ICMPv6 error should be returned.
I believe we should at least clarify these points before a WGLC.

I also pointed out the following sentence could be still ambiguous:

  IPv6 nodes MUST NOT process RH0 in packets addressed to them.

I suggest modifying this sentence to:

  IPv6 nodes MUST NOT process RH0 in packets whose destination address
  in the IPv6 header is an address assigned to them.

- section 4

I'm not sure if a protocol specification document is the appropriate
space for operational considerations especially when the
considerations contain some normative text (like "strongly
discouraged).  One possible compromise is to move the discussion to an
appendix.  This may sound excessive formalism, however, so I don't
insist on the adoption of this comment.

- section 5

IMO, this section contains too many details that are not directly
related to the deprecation action, make the document unfocused, and
could even make it misleading (even though I respect authors' effort
of writing up the summary).  I suggest we take more focused approach
as this version took for the abstract and introduction.  I
specifically propose the following revised text for a replacement of
the entire section (+ subsections):

=========================  from here  =========================

   The purpose of this document is to deprecate RH0.  It has been
   shown to have undesirable security implications as described in
   [CanSecWest07].  Among such implications the most significant is an
   amplified 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.  The same attack can be performed using
   the IPv4 source route option, but the attack is much severer for
   IPv6 because RH0 can contain a much more waypoints, which increase
   the amplification factor.  Ingress filtering [RFC2827] [RFC3704]
   can mitigate the attack, but it is not widely deployed yet and is
   not expected to be deployed soon.

   The severity of the threat thus warrants a strong countermeasure of
   deprecating the mechanism itself.

==========================  to here  ==========================

If we adopt this proposal I'd not have to care about other details of
this section, but here are a couple of specific comments to the text
itself in case my proposal is rejected:

- I think we should exclude the second paragraph of section 5.3 (about
  the 'capacitive effect').  The effectiveness of this attack is not
  so clear as the simple oscillation attack to me; the attacker would
  have to control the timing of the packets (by either or both of the
  transmission rate and the number of intermediate waypoints in RH0)
  so that all the packets flow between the "capacitor" exit and the
  target node at the same timing.  As far as I know this attack is not
  proved to be possible on real traffic unlike the simpler oscillation
  and that's why the draft states it has been "postulated" rather than
  "demonstrated".  Describing the possibility of the attack is
  interesting in a research paper, but IMO we should discuss things in
  a normative protocol specification based on threats that are proved
  to be possible.

- the following part of the third paragraph of section 5.3 is not
  really technically correct:

   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.

  Even though the cansecwest paper may indicate so, the circuit
  latency is actually irrelevant to the amplification factor (I
  discussed this with the authors and they admitted that).  The only
  relevant point in this context is that it may be possible to attack
  a longer path more effectively because the two consecutive waypoints
  may effectively contain multiple (IPv4) links and the IPv6 hoplimit
  is decreased only by one between them.

					JINMEI, Tatuya

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Wed, 30 May 2007 00:33:53 +0900 (JST)

>    not expected to be deployed soon.

	i disagree with "Ingress filtering can mitigate the attack" comment.
	while an attacker may not be able to spoof its source address if
	the attacker is in a network with ingress filtering, it is untrue that
	ingress filtering gives real protection against rthdr0 attacks.

	i'm writing it with an assumption that nodes would perform ingress
	filtering against packets with source-routing header properly - yup,
	they CANNOT perform ingress filtering due to the existence and the
	nature of the source-routing.  it is natural for source-routed packets
	to have its source address which seems strange for normal ingress
	filtering.  if nodes were to filter out source-routed packets based
	on ingress filtering, those implementations are mistaken!

	anyways, with the deprecation of rthdr0, "correctness" of ingress
	filtering does not give any damn.  but, if we are to implement and then
	write up a spec (yes, we have to implement before write any spec) for
	rthdr0 replacement (rthdr7, i presume:-), nodes that implement ingress
	filtering has to consider the above "correctness" stuff.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 May 2007 21:37:39 +0300 (EEST)

> state "IPv6 nodes MUST NOT originate IPv6 packets containing RH0."?

Only commenting on this as I feel rather strongly on this..

I don't think the wording you propose is good.  That begs the 
question, is a compliant IPv6 node required to prevent origination of 
RH0?  I.e., if a user, through a raw socket for example, were to send 
RH0, would the node be required to drop it?  What about if the IPv6 
API is used to try to originate such a RH0 packet?

I don't think this is what you're suggesting, and a "MUST NOT 
originate" seems to be on the borderline of the past Robert Elz's 
RFC3513 appeal of unclarity in the spec.

However, I agree that the current wording could probably be better.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 May 2007 21:44:09 +0300 (EEST)

> 	on ingress filtering, those implementations are mistaken!

If I understand you correctly, you're either 1) assuming that ingress 
filtering implementations would treat packets with a source 
routing/rtheader differently, e.g., to allow all such packets 
regardless of the source, or 2) arguing that the behaviour of an 
"source-routing friendly" ingress filter should be to allow source 
routing even with topologically incorrect source addresses.

I don't believe I've seen any implementation of uRPF or similar 
filtering method that would do 1).

While the merits of 2) could be argued, I believe this is not the 
right list to discuss how ingress filters could/should be more 
source-routing friendly.

In either case, I believe currently deployed ingress filters will 
practically block bouncing attacks with rh0 or ipv4 source routing.

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Wed, 30 May 2007 08:48:25 +0900 (JST)

> routing even with topologically incorrect source addresses.

	i guess i'm saying (2).

> practically block bouncing attacks with rh0 or ipv4 source routing.

	then, rthdr7 would need to rewrite source address on IPv6 header every
	intermediate hop, and use mobile-ip6 home address option for the real
	source address.  scary...
	i would not hold my breath for rthdr7.  ops guys, too bad...

itojun

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Wed, 30 May 2007 11:33:17 +0900

At Tue, 29 May 2007 21:37:39 +0300 (EEST),
Pekka Savola wrote:
> 
> [1  <text/plain; ISO-8859-1 (quoted-printable)>]

I would prefer to not split too many hairs.  I believe we want RH0
off, and if that is the case we should clearly state that:

  IPv6 nodes MUST NOT originate packets containing RH0 and SHOULD return
  a Parameter Problem ICMPv6 message with code of 2 Unrecognized IPv6
  Option Encountered when such packets are received.

That is in line with RFC 2463 in terms of error handling, gives users
of the network sufficient debugging information without there being a
new hole opened for attack, and leaves open the possibility that no
error is returned at all, likely though the use of a kernel tuning
variable (sysctl in FreeBSD).

Best,
George

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Wed, 30 May 2007 13:26:56 +0900 (JST)

> variable (sysctl in FreeBSD).

	we may need more precise wording on "such packets are *received*".  
	is it when ip6.ip6_dst is one of the node's address? (intermediate
	node on rthdr0 hop lists or final node)
	or could it be a router which has totally different address?
	see OpenBSD/Apple MacOS X sys/netinet6/ip6_input.c, they are really
	paranoid about this (took the latter approach).  they're good.

	and no, remove the sysctl, please.  bad guy can install freebsd to his
	old machine and place it to open IPv6 network to damage the whole
	planet.  "protected by root privilege" means nothing.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 31 May 2007 02:57:12 +0900

> However, I agree that the current wording could probably be better.

Please let me clarify my comment.  I didn't *propose* the "MUST NOT"
sentence; I simply cited it from the draft.  The following is a
verbatim and complete copy of Section 3.1 of the candidate draft:

=========================== from here ===========================

3.1.  Origination

============================ to here ============================

I understand the intent of the first sentence; but as you might point
out I agree this statement may be debatable (see below).

What I wanted to say in my previous message is that I don't understand
the intent of the second sentence while having the first sentence.

Hopefully this time I'm clearer.

In any event, to be possibly a bit more productive I guess I agree
with you.  I don't think specifying the originating side makes much
sense; attackers would still originate RH0 anyway (e.g., via a raw
socket, BPF, etc) in a hope of attacking non-updated packets whatever
the deprecation document states.  It sounds to me like "a node MUST
NOT send a packet containing a digital virus that can exploit the
receiving node".  Meanwhile, new implementations will naturally and
eventually stop including a code path that originates RH0 (e.g., by
deprecating the corresponding API knob) upon the deprecation of RH0
even if the document does not explicitly specify the originating side
behavior.  It just looks sufficient to me.

So, if I were to ask, I'd simply suggest removing section 3.1
altogether.  (But I don't necessarily oppose to specifying the
originating side; it just looks meaningless to me, but I agree it at
least doesn't do harm).

					JINMEI, Tatuya