Subject: ICMPv6 echo reply to multicast packet thread

From: Jyrki Soini <[email-masked]>
Date: Mon, 08 Mar 2004 20:04:18 +0200

I sent a comment to ICMPv6 update draft during IETF meeting and received
 a few comments but not quite a discussion. Here is somewhat extreme
example of the DoS attack vulnerability I'm worried about:

Imagine, one day man is landing on Mars and real-time video is
multicasted on Internet. There are 100 million listeners on the
group. The multicast group is any-source group using embedded RP
address. The video quality is not perfect and one listener decides to
debug the problem. He sends a ICMPv6 Echo Request packets to the group
address without thinking beforehand.  As the group is any-source
group, the host is allowed to send packets.  Packet gets delivered to
the RP that sends it through the multicast tree.

Current ICMPv6 specification states at Chapter 4.2 Echo Reply Message:

"An Echo Reply SHOULD be sent in response to an Echo Request message
sent to an IPv6 multicast or anycast address."

The consequence is that the original Echo Request packet gets 100 000
000 unicast Echo Reply messages back.

Ping to multicast address has operational usage as debugging tool and
totally disabling reply to Echo Request message sent to an IPv6
multicast address would not be a good solution.

I see two alternatives to limit the Echo Reply to multicast packet
problem:
1. Limit Echo Reply packet to only be allowed on link-scope multicast
   echo requests.
2. Require that hop-limit is set to for instance value 1 for the
   Echo Reply packet.

I find the latter alternative is better as this way also global scope
multicast groups may be debugged still although the echo reply will be
discarded by the first router.

Message sent to anycast address should only cause one reply message
and that should not be problematic.

I propose changing chapter 4.2 Echo Reply Message paragraph:

   An Echo Reply SHOULD be sent in response to an Echo Request message
   sent to an IPv6 multicast or anycast address.  In this case, the
   source address of the reply MUST be a unicast address belonging to
   the interface on which the Echo Request message was received.

to:

   An Echo Reply SHOULD be sent in response to an Echo Request message
   sent to an IPv6 multicast address and the Hop-Limit IPv6 header
   field MUST be set to value 1.

   If Echo Reply message is sent in responce to an Echo Request
   message sent to an IPv6 multicast or anycast address, the source
   address of the reply MUST be a unicast address belonging to the
   interface on which the Echo Request message was received.

Perhaphs in practice the hop-limit could be somewhat bigger than 1 without
real problems?
---
Jyrki Soini

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

---

From: "Jeroen Massar" <[email-masked]>
Date: Mon, 8 Mar 2004 19:34:07 +0100

Jyrki Soini wrote:

> I sent a comment to ICMPv6 update draft during IETF meeting 
> and received a few comments but not quite a discussion. Here is somewhat extreme
> group.

I like this idea, especially the part where 100 million users
are using IPv6 ;)

<SNIP

> 2. Require that hop-limit is set to for instance value 1 for the

<SNIP>

> Perhaphs in practice the hop-limit could be somewhat bigger 
> than 1 without real problems?

I would suggest that the default hoplimit for these kind of
ICMP's gets set to 1 but that it is configurable in cases
where the ISP knows the size of their multicast network.
In an ideal solution it would be only the hops of a maximum
of 2 AS's.

In light of the above and debugging multicast wouldn't it be
a good idea to revive and implement mtrace, eg as in:
http://archive.dante.net/mbone/refs/draft-ietf-idmr-traceroute-ipm-07.txt

But then for IPv6?

Greets,
 Jeroen