Subject: Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt

From: "Ebalard, Arnaud" <[email-masked]>
Date: Thu, 10 May 2007 16:55:31 +0200

Le 10 mai 07 à 15:50, Brian Haberman a écrit :

> What happens if the packet is encrypted?

If you mean ESP-encrypted, ESP is "viewed as an end-to-end payload and
thus should appear after hop-by-hop, routing, and fragmentation  
extension
headers". -- quoted from RFC 2406. Note that it is just a "should".

So, for ESP-protected traffic, this should be similar to any other  
upper layer protocol. And, if the Routing Header is protected (and  
the endpoint of the IPsec connection accepts that order), it will  
still be dropped in the context of the draft (i.e. by the node the  
packet is addressed to).

a+

-- Arnaud Ebalard
EADS Innovation Works - IT Sec Research Engineer
PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026

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

---

From: "Ebalard, Arnaud" <[email-masked]>
Date: Thu, 10 May 2007 17:21:27 +0200

Oy,

Le 10 mai 07 à 16:49, Pekka Savola a écrit :

> On Thu, 10 May 2007, Jeroen Massar wrote:
>> As such, when you are a transit provider, and you have on the  
>> edges of
>> your network some vulnerable hosts, those hosts can be used to apply
>> this attack to your network.
>>
>> The documentation should thus specify that, where possible, RH0  
>> should
>> be filtered at customer borders.
>
> Well, IMHO that's a bit unnecessary.
>
> If you see packet ping-pong on the Internet, it's an indication that
> ingress and egress filters haven't been adequately set up.  Adding
> those will stop your network's bandwidth being wasted.
>
> Maybe this RH0 vulnerability will turn out for the good after all if
> it means better BCP38/84 deployment :-)

I agree. To sum up :

- ingress filtering will prevent the use of clients unpatched/non  
compliant clients nodes for bouncing RH0 traffic towards the  
internet. This will limit potential attacks to internal networks in  
the worst case scenario (if nothing is done by site administrators).  
This is efficiently implemented as this is done on the leaves. This  
does not impacts clients for regular traffic (including MIPv6).

- on core routers, if RH0 are not processed as a result of  
deprecation/deactivation, this prevents their use for bouncing RH0  
traffic: this also makes the Hop Limit an effective mean for limiting  
things too as the average distance between 2 possible waypoints (non  
compliant / unpatched) will be far higher than at the moment.

In worst case scenario, an attacker could use 2 leaves in the network  
(i.e. in a single ISP network) and locally wastes some bandwidth.  
Basically, this will motivate the network operator to implement  
ingress filtering ;-)

As deprecation also guarantees attackers won't be able to target  
service on compliant hosts, only unpatched/unfiltered ones will  
undergo attacks (in worst case scenario).

Cheers,

a+

-- Arnaud Ebalard

---

From: "Ebalard, Arnaud" <[email-masked]>
Date: Fri, 11 May 2007 11:03:30 +0200

Le 11 mai 07 à 04:24, JINMEI Tatuya / 神明達哉 a écrit :

> Are you suggesting the following part should apply regardless of the
> type of routing header?
>
>   In particular, the value of the Segments Left field
>   MUST not be considered.
>
> If so, I don't think the current rh0 draft could be interpreted that
> way (aside from whether we'd agree it in the first place).

Nope. I just said it was in contradiction (meaning it updated the
specification) with the following part of section 4.4 of RFC 2460:

       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.

as updated system will have to protect themselves from the remaining
source routed packets bounced by unpatched waypoints that still forward
RH0. RH0 will be a specific RH type for which stacks will not look at
the Segments Left field to select the behavior (meaning will not end
processing the UL if Segments Left is 0).

By the way, for the proposal of replying with an ICMPv6 message for RH0
packets whose destination address in the main IPv6 header is one of the
node, I think it's fair to do it independently of Segments Left field,
i.e. as soon as the type is 0 (better said than let implicit).

a+

-- Arnaud Ebalard

---

From: "Ebalard, Arnaud" <[email-masked]>
Date: Fri, 11 May 2007 11:06:09 +0200

Le 11 mai 07 à 07:52, David Malone a écrit :

> On Fri, May 11, 2007 at 11:16:49AM +0900, JINMEI Tatuya / ?$B?@L@C#:H
> wrote:
>> I believe we should rather return an ICMPv6 error.  Even if we decide
>> to deprecate type0 RH, there will be many non-updated systems for a
>> certain period of time.  Since there is at least one know popular  
>> (but
>> non-attacking) usage of RH0, i.e., probing 'return path' by
>> traceroute, we'll still see non-attacking packets containing RH0.  It
>> would be better to notice such innocent but not just well-informed
>> users explicitly, rather than simply dropping the packet.
>
> I buy this argument in favour of returning an error. I guess that
> means we should select an error type which is usefully displayed
> by (some/most/all?) versions of traceroute6?

If you go for that, then an ICMP Parameter Problem, Code 0, message
pointing to the unrecognized routing type seems reasonable.

a+

-- Arnaud Ebalard

---

From: Tim Enos <[email-masked]>
Date: Fri, 11 May 2007 16:19:18 -0500 (CDT)

Hi all,

>Oy,
>
>Le 10 mai 07 Ã  16:49, Pekka Savola a Ã©crit :
>

FWIW I think that loose RPF on the core routers could help mitigate attacks (on internal networks at least).
  
>does not impacts clients for regular traffic (including MIPv6).

Agreed that ingress filtering ala BCP 38 at the edge is strongly advised (at least a SHOULD). As cited by the authors (end of section 4), the number of asymmetric routes would seem to preclude the additional use of strict RPF. OTOH, loose RPF in the core seems to make sense.

>PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026

Best Regards,

Tim Enos
Rom 8:28