Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]

From: Tim Enos <[email-masked]>
Date: Tue, 08 May 2007 14:00:42 -0500 (CDT)

Hi Bob/all,

I advocate for option #1. IMO, the paper found by following the link below makes a good case against the use of IPv6 Routing Header Type 0: 

http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf.

The following I-D (perhaps among others) also succinctly delineates the potential security problems with its use:

draft-savola-ipv6-rh-ha-security-03.txt.

Whether it's the potential to reach a hidden host via a visible one, the ability to use reflection to launch a DoS attack, or other security issues as noted both on this list and the above referenced papers (and others), deprecation of Routing Header Type 0 (aka option #1) is best.

The implicit curriculum of #2 and #3 really seems to be that RH0 processing can be enabled. Also, to me it seems that #4 just gives us slightly less of a bad thing. Even workarounds such as ingress filtering with properly configured ACLs could also technically be used by an attacker.

I would also prefer that RH0 be silently dropped but could live with an ICMPv6 error message being sent back to the sending host (error messages are rate-limited). Not processing but forwarding RH0 does not seem to make sense.

Best Regards,

Timothy Enos
Rom 8:28

>From: Bob Hinden <[email-masked]>
>Date: 2007/04/25 Wed PM 07:39:40 CDT
>To: IETF IPv6 Mailing List <[email-masked]>
>Subject: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header issues]

>[trimming this to just the IPv6 w.g.]
>
>We think the question for the IPv6 working group on this topic is  
>does the working group want to do anything to address the issues  
>raised about the Type 0 routing header.  Possible actions include:
>
>  1) Deprecate all usage of RH0
>  2) Recommend that RH0 support be off by default in hosts and routers
>  3) Recommend that RH0 support be off by default in hosts
>  4) Limit it's usage to one RH0 per IPv6 packet and limit the number  
>of addresses in one RH0.
>
>These examples are not all mutually exclusive.
>
>Please respond to the list with your preference and justifications.
>
>Thanks,
>Bob Hinden / Brian Haberman
>IPv6 W.G. Chairs
>
>p.s. We will send a note to the other lists that the IPv6 w.g. will  
>be discussing this issue.
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 13 May 2007 18:10:50 +0200

On 8-mei-2007, at 21:00, Tim Enos wrote:

> I would also prefer that RH0 be silently dropped but could live  
> with an ICMPv6 error message being sent back to the sending host

Why is everyone so in love with silently dropping?

This only makes troubleshooting harder.

See RFC 2460 and imagine that type 0 is not recognized:

    If, while processing a received packet, a node encounters a Routing
    header with an unrecognized Routing Type value, the required  
behavior
    of the node depends on the value of the Segments Left field, as
    follows:

       If Segments Left is zero, the node must ignore the Routing header
       and proceed to process the next header in the packet, whose type
       is identified by the Next Header field in the Routing header.

       If Segments Left is non-zero, the node must discard the packet  
and
       send an ICMP Parameter Problem, Code 0, message to the packet's
       Source Address, pointing to the unrecognized Routing Type.

Additionally, it would be helpful if we could separate the issues on  
the table. There are many of them, and not all solutions apply to all  
of them:

- source routing can be used for amplification
- IPv6 source routing is enabled by default on most implementations
- IPv6 source routing can't be disabled on some implementations
- BSD will _forward_ IPv6 source routed packets even when IPv6  
forwarding is disabled
- apparently, there is no check whether the same addresses appear  
multiple time in many implementations