Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

From: [email-masked]
Date: Tue, 6 Jan 2004 11:58:56 -0600

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

> -----Original Message-----
> From: ext Pekka Savola [mailto:[email-masked]]
> Sent: Tuesday, January 06, 2004 9:44 AM
> To: Fred Templin
> Cc: Francis Dupont; Gupta Mukesh (Nokia-NET/MtView); [email-masked]
> Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods 
> 
> 
> On Tue, 6 Jan 2004, Fred Templin wrote:
> > Asterisks already appear all the time using 'traceroute'. 
> That is why
> > three responses are solicited from each hop and the process proceeds
> > to the next hop even if only one response is received. 
> (Indeed, many of
> > the traceroutes I have seen will "knock three times" 
> repeatedly when a
> > non-responsive hop is encountered.)
> 
> Right.  But in my opinion, we want to optimize for the case that we 
> don't have to fall back to the timeouts unnecessarily.  Multiple 
> seconds' delay at each misbehaving hop is inappropriate.
>   
> > I agree that the traceroute example is a weak one, and not 
> sufficient
> > reason to exclude valid implementation alternatives.
> 
> We'll just have to disagree on this.  Internet traffic is
> characteristically rather bursty.  The rate-limitng functions have to
> be able to deal with that.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 

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

---

From: Fred Templin <[email-masked]>
Date: Tue, 06 Jan 2004 11:28:19 -0800

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Jan 2004 22:12:38 +0200 (EET)

On Tue, 6 Jan 2004, Fred Templin wrote:
> alternatives only if they are known to cause operational issues. 
[...]

Traceroute not working (without unnecessary delays) is a serious
operational issue, IMHO.

---

From: Fred Templin <[email-masked]>
Date: Tue, 06 Jan 2004 13:35:14 -0800

Pekka,

>Traceroute not working (without unnecessary delays) is a serious

I'm not quite as concerned about traceroute as you seem to be, but
I do agree that other mechanisms that rely on ICMPv6 might suffer
from a poor choice of rate limiting schemes. (Well, OK; traceroute
is a useful tool too.)

I'll give some consideration to the token-bucket thing; my main
concern is that min/max values for the rate-limiting parameters
'B' and 'N' are not currently specified. If reasonable values can
be determined, perhaps I will revise my opinion about exclusion
of the other schemes.

Fred
[email-masked]