On Tue, 12 Feb 2002, Thomas Narten wrote: > following questions/comments: > > > Rate limiting: > > > > The limit parameters (e.g., T or F in the above examples) MUST > > be configurable for the node, with a conservative default value > > (e.g., T = 0.5 second, NOT 0 seconds, or F = 2 percent, NOT 100 > > percent). > > T= 0.5 seems fairly high. Why not .1 or .01 (on today's links). > > It might also be useful to point out that having too much rate > limiting (in routers) causes problems for traceroute, since this has > been experienced in practice. Indeed, if routers rate limit to one > message every .5 seconds, today's traceroute would seem to become > unusable in practice. Indeed, even at .1 seconds, traceroute won't > hardly work anymore. I.e., the first probe will get trigger an ICMP > error, the second one (some 20-30 ms later) will not, due to rate > limiting, etc. > > Would it be better to move away completely from fixed time intervals > and just say as a percentage of the link traffic? at least in the case > of routers? > > So, question for the WG: Is the current text on this topic adequate, > or should it be revised?
Well, I brought up the issue with traceroute when I noticed some major router vendors implemented timer-based mechanisms, and proposed the token-bucket mechanism (which is used quite often). Personally, I'm a bit unsatisfied how the examples are portrayed; IMO, timer-based should definitely go away, be put in last, huge disclaimers printed or whatever. Bandwidth-based does not really scale: same implementation could be used over 64kbit/s or 10Gbit/s links. What's the percentage there? Assuming sending ICMP errors require processor cycles, the latter might still use up too much CPU even with 0.01% ;-) Also personally, token bucket is IMO the only sensible way to handle this. > security considerations could perhaps use some updating. It seems largely > unchanged relative to RFC 2463. Has nothing really changed in our > thinking here since 2463 came out? ICMP, among others, can be used for many kinds of reflection attacks -- that is, like: src = <victim> dst = <router X> informational ICMP packet then router responds by sending (non-ratelimited) packets to <victim>, originated from <router X>. You kill two birds with one stone: flood the victim by using any node anywhere, and in the process, kill the CPU on the reflector node. :-) Mixing this with MIPv6 Home Address Option, the results would be even more disastrous. Not that there is all that much to be done about this.. :-( (this is partially discussed in draft-savola-ipv6-rh-ha-security-01.txt) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
