Subject: Re: ICMPv6 echo reply to multicast packet thread

From: Suresh Krishnan <[email-masked]>
Date: Tue, 9 Mar 2004 19:16:31 -0500 (EST)

Hi Jyrki,
	Find comments inline.

Regards
Suresh

On Mon, 8 Mar 2004, Jyrki Soini wrote:

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

I do not see anything wrong with this scenario. If I send an ICMP Echo 
Request to 100M nodes I MUST expect a Echo reply from 100M nodes. How 
about if I sent a DATA packet, which requires an ACK, to the group by 
mistake? 

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

Agree. I would really like to have this. But if I had to choose between 
probabilistic echo replies or none, I would pick none.

>
>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.
>
Setting the hop limit to 1 does not help . If half my multicast group is 
across a router and I DO NOT KNOW this it would become impossible 
to debug multicast. So remove the SHOULD and replace it with either a MUST 
or a MUST NOT.

"An Echo Reply MUST/MUST NOT be sent in response to an Echo Request 
message sent to an IPv6 multicast or anycast address"

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 10 Mar 2004 01:30:49 +0100

> about if I sent a DATA packet, which requires an ACK, to the group by 

I guess that Jyrki's thoughts where more along the lines of:
"What if I send a simple ICMPv6 Echo Request with *your* source address".

The only real solution for this of course is filtering, but I am
not going to see that happen knowing that quite a number, make
that most, IPv4 based ISP's don't filter their customers on source
addresses. Even RFC1918 addresses seem to be unfiltered at most ISP's.
Talking about source filtering here, which should be very easy as
you know yourself as an ISP which prefixes one assigned to that user
or simply to yourself as an ISP, a simple "source !myprefix drop"
entry in your peering/transit router fixes this all, better stick
as close to the client as possible et voila.

But then still other ISP's don't and you are still vulnerable.

> Agree. I would really like to have this. But if I had to 
> choose between probabilistic echo replies or none, I would pick none.

None would indeed be better as then you are not thinking "but maybe
they have configured it to not do it".

This is somewhat the same problem that occured when there where
a lot of icmp attacks over unicast and Cisco set a default ratelimit
on their routers, after some time even simple traceroutes would
not work anymore due to this.

The Mtrace method is the real answer to debugging multicast.

<SNIP long confidentiality clause>

Greets,
 Jeroen

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 9 Mar 2004 20:00:25 -0500 (EST)

Hi Jeroen,
  Find comments inline.

Regards
Suresh

>"What if I send a simple ICMPv6 Echo Request with *your* source address".

Aha. That makes more sense to me. But why should we point to just ICMPv6 
Echo request? Pretty much all data packets which need an ack can be used 
for this attack. It could be any protocol, not just ICMPv6. Anyway all the 
more reason for a MUST NOT. 

>as close to the client as possible et voila.

I agree. 

>they have configured it to not do it".

Exactly. I would rather live without the uncertainity.

>The Mtrace method is the real answer to debugging multicast.

Didn't know mtrace worked with v6 addresses. Is there an implementation 
out there for IPv6? Would be cool to have.

><SNIP long confidentiality clause>

Sorry. Can't help it. It is appended by the mail server ;-).

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Mar 2004 08:20:19 +0200 (EET)

On Wed, 10 Mar 2004, Jeroen Massar wrote:
> > I do not see anything wrong with this scenario. If I send an ICMP
> > Echo Request to 100M nodes I MUST expect a Echo reply from 100M
> > nodes. How about if I sent a DATA packet, which requires an ACK,
> > to the group by mistake?
> 

Note that when you send to a multicast address, your source address is 
checked to be RPF-wise correct, otherwise it's dropped in the 
multicast forwarding.  So, I don't think spoofing is that feasible a 
scenario in "multicast ping".

If we disallow ICMP Echo Request, what about other services (TCP/UDP) 
that may be listening at the receiver systems?  Those could be 
likewise affected -- TCP SYN/ACK, or a UDP response packet could have 
tremendous effect on the network as well.

Inevitably, we'll seem to be reaching to a conclusion that we cannot 
avoid this at the specification level -- but the solution lies at the 
concerned parties in the form of filtering.

Note that this problem does not (really) exist if SSM is used, and
this is easily prevented if draft-ietf-mboned-embeddedrp-02.txt is
used (which are the only two reasonable options), as you can put in
filters in your RP configuration, preventing anyone (except specific
sources) from sending packets to the members of the group.

-- 
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: "Stephen Sprunk" <[email-masked]>
Date: Wed, 10 Mar 2004 15:22:41 -0600 (CST)

> more reason for a MUST NOT.

Wait a minute...  Now we're talking about prohibiting ANY multicast app
from responding unicast to multicasted data?  That's a basic part of
functionality that is assumed in many apps!

Can someone explain why we're looking for a different solution to this
behavior for IPv6 when the IPv4 behavior is already set in stone?  For
apps which may not even be aware which version they're using, why should
IPv6 not respond in some or all cases when IPv4 always does?

>>as close to the client as possible et voila.

I don't see the relevance of this to multicast, since RPF inherently stops
all off-subnet spoofing.  What problem are we trying to solve?

S

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 10 Mar 2004 22:21:51 -0500 (EST)

Hi Stephen,
  Find comments inline.

Regards
Suresh

>IPv6 not respond in some or all cases when IPv4 always does?

The problem is not about apps responding unicast to multicast data. It is 
 specifically only about apps sending unicast ICMPv6 Echo replies in 
response to ICMPv6 echo requests sent to multicast addresses. Everything 
else (all data packet behavior) is not under discussion here.

The statement about IP4v4 always responding to multicast echo requests 
is not entirely true. The expected IPv4 host  behavior is described in RFC 
1122

3.2.2.6  Echo Request/Reply: RFC-792

            Every host MUST implement an ICMP Echo server function that
            receives Echo Requests and sends corresponding Echo Replies.
            A host SHOULD also implement an application-layer interface
            for sending an Echo Request and receiving an Echo Reply, for
            diagnostic purposes.

            An ICMP Echo Request destined to an IP broadcast or IP
            multicast address MAY be silently discarded.

So an IPV4 may or may not respond to an ICMP echo request message.
In IPv6 we have a chance to take away this uncertainity and replace it 
with either a host MUST respond or a host MUST NOT respond to ICMP echo 
requests sent to a multicast address. This takes out the guesswork about 
"is the host down or did the admin configure it to not respond to echo 
requests?".

>all off-subnet spoofing.  What problem are we trying to solve?

I did not write the above passage even though you attributed it to me ;-).

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Mar 2004 08:24:23 +0200

> scenario in "multicast ping".

Right. I think this protection is good enough that we can
generally rely on it, as long as the remaining case (on path
attacker) is understood and mentioned in the security
considerations.

> tremendous effect on the network as well.

Yes. A couple of comments:

- Some of those applications might not be answering if the destination
   address is a multicast address. So this may not apply to all
   applications. But it would apply to some.

- As discussed in the context of the ICMPv6 spec revision, there are
   similar multicast respond flooding issues even with base IPv6
   processing before you get to any "application" such as ping.
   Unrecognized destination option, for instance, would cause a
   flood of responses.

In general, we may not wish to limit the ability of applications
to respond to multicast, that may be needed in some cases. However,
applications that do respond to multicast probably want to say
something about the remaining case in their security considerations
section. Some applications may also use some form of source authentication
to ensure that only the legitimate sender's messages are processed.

This still leaves open what the behaviour for ICMPv6 Echo Request
should be. I would not bundle this issue with what the other
applications do, but my default answer would be to not respond
to multicast requests unless there is a specific reason to do
so. In this case there seems to be some discussion about multicast
debugging capabilities. I do not have experience of that myself.
Are multicast echo requests the primary multicast debugging
mechanism? If yes, we should allow responses to be sent. If not,
I agree with Suresh that it should be disallowed. Note that
multicast debugging through echo responses is naturally limited
to rather small multicast groups ;-) So I suspect people who
need multicast in a large scale are going to need another
debugging tool in any case.

--Jari

---

From: Stig Venaas <[email-masked]>
Date: Thu, 11 Mar 2004 11:13:00 +0100

On Thu, Mar 11, 2004 at 08:24:23AM +0200, Jari Arkko wrote:
[...]
> debugging tool in any case.

ICMP echo to link-local multicast addresses is very useful for
debugging. In particular the all-nodes group ff02::1. If one
were to restrict this, I would make an exception for link-local
scope at least.

Stig

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 11 Mar 2004 07:52:02 -0600 (CST)

> attacker) is understood and mentioned in the security

With the noted exception, do we have consensus that multicast ping is not
useful as a DoS attack vector?

> to ensure that only the legitimate sender's messages are processed.

I don't think anyone would object to individual protocols being hardened,
or at least studied, for multicast-specific security problems.

> debugging tool in any case.

IMHO, a multicast ping is the only tool that is simple enough and
ubiquitous enough for end users to attempt diagnostics before calling
their support folks -- one simple command tells you whether your problems
are at the network layer or application layer.  I say keep it.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 11 Mar 2004 08:06:00 -0600 (CST)

Suresh Krishnan said:
>>> Aha. That makes more sense to me. But why should we point to just
>>> ICMPv6 Echo request? Pretty much all data packets which need an
>>> ack can be used for this attack. It could be any protocol, not
>>> just ICMPv6. Anyway all the more reason for a MUST NOT.
>>

You pointed out that ICMP echo is not the only protocol this attack can
(supposedly) use; my argument is that turning off ICMP echo replies is
only useful if we prohibit all other apps from replying as well.  Given
the noted holes in other aspects of ICMP that still MUST respond in error
conditions, we're just shifting the problem around without making it any
more difficult for attackers.  If they can't flood someone with Echo
Replies, they'll just flood someone with Destination Unreachables (or some
other response) -- assuming, of course, they find a way around RPF.

> is not entirely true. The expected IPv4 host  behavior is described in RFC

RFC 1122 Sec 3.2.2.6 is ambiguous.  The only self-consistent reading I can
find is that hosts MUST respond if they receive an echo request, but the
_network_ may drop broadcast or multicast pings before delivering them.

>>I don't see the relevance of this to multicast, since RPF inherently
>>stops all off-subnet spoofing.  What problem are we trying to solve?
>

It's been quoted many times, but I figured it was worth responding to.

S

---

From: Jyrki Soini <[email-masked]>
Date: Thu, 11 Mar 2004 19:57:14 +0200

>other response) -- assuming, of course, they find a way around RPF.
The ICMPv6 specs is pretty careful on Error Messages in response to 
multicast packet.

2.4. Message Processing Rules
    (e) An ICMPv6 error message MUST NOT be sent as a result of
        receiving:
...
        (e.3) a packet destined to an IPv6 multicast address (there are
               two exceptions to this rule: (1) the Packet Too Big
               Message - Section 3.2 - to allow Path MTU discovery to
               work for IPv6 multicast, and (2) the Parameter Problem
               Message, Code 2 - Section 3.4 - reporting an unrecognized
               IPv6 option that has the Option Type highest-order two
               bits set to 10), or

         (e.4) a packet sent as a link-layer multicast, (the exception
               from e.3 applies to this case too), or

         (e.5) a packet sent as a link-layer broadcast, (the exception
               from e.3 applies to this case too), or

         (e.6) a packet whose source address does not uniquely identify
               a single node -- e.g., the IPv6 Unspecified Address, an
               IPv6 multicast address, or an address known by the ICMP
               message sender to be an IPv6 anycast address.

I find it contradicting to be this careful for error conditions while
to easier to generate non-error condition reply SHOULD be sent.

I agree that multicast ping is useful tool and would not like to totally get
rid of it. Still it is dangerous in case of large multicast groups.

How about the following wording:

     An Echo Reply MUST be sent in response to an Echo Request message
     sent to an IPv6 multicast address. By default hop-limit IPv6 header
     field MUST be set to value 1 [on non-router hosts?]. The hop-limit
     SHOULD be administratively configurable. Hop-limit limitation is 
used to
     prevent Echo Reply message storms on large multicast groups.

    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.

This makes it possible to use ping to multicast address and get always
response, if other nodes are on the same link. By default there would
be no echo reply storm for multi-link groups (except on each link the
number of multicast listeners on link causes two packets:
echo reply and time exceeded back from router).

For multilink case group can still be investigated by increasing some
nodes echo-reply hop-limit may be increased to bigger value.

If [on non-router hosts?] is added to the wording, routers would
send echo reply messages to multicast echo request packets.
Still the resulted echo reply storm will be decreased from the current
situation.
---
Jyrki Soini