[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ICMPv6 echo reply to multicast packet thread

Hi Stephen,
  Find comments inline.


On Wed, 10 Mar 2004, Stephen Sprunk wrote:

>Suresh Krishnan said:
>> On Wed, 10 Mar 2004, Jeroen Massar wrote:
>>>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".
>> 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.
>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?

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

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

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


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
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6