Hi Stephen,
Find comments inline.
Regards
Suresh
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
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?".
>
>>>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 ;-).
>
>S
>
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 PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
