Generally speaking, it seems appropriate to exclude implementation alternatives only if they are known to cause operational issues. One case of concern is that of a reflection attack in which an anonymous attacker (A) using a spoofed source address (C) sends a stream of malicious packets to a middle node (B) that would cause B to generate ICMPv6 errors. If B sends the ICMPv6 errors on a high-speed link (e.g., 1Gbps Ethernet), but the victim node C is at the far end of a long, thin link (e.g., 56Kbps modem, GPRS; 1xRTT wireless, etc) A can effectively deny service to C with a relatively low-bandwith stream of malicious packets.
Based on the reflection attack case, it seems unlikely to me that any of the rate limiting alternatives in section 2.4(f) can on their own provide sufficient assurance that nodes with low-bandwidth links will be protected from ICMPv6 error message DoS attacks (w/o defeating legitimate mechanisms that rely on ICMPv6 error messages, that is). Therefore, I see no value in seeking exclusion of any of the rate limiting alternatives at this point in time. Instead, the reflection attack case (and perhaps others) suggests that other measures are needed - in particular, it seems to me that authentication of source addresses in received IPv6 packets should be mandatory.
Fred [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
If we decide to keep the Timer-based method, another problem
is to decide the value of T (not more than one icmp to a given
source every T milliseconds). 1 ms might be overwhelming for
a 64 kpbs link and 100 ms will be over-restricting for 10 gbps link.
What about we keep the Timer-based method, discuss the advantages and disadvantages and suggest keeping the value
of T configurable per link so that the administrator can
decide the correct value of T based on the bandwidth of the
link.
Do we all agree to remove the Bandwidth-based method ??
Regards
Mukesh
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
