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

From: [email-masked]
Date: Wed, 7 Jan 2004 11:50:51 -0600

Fred,

I don't quite understand why the Timer-based method need to
consider the source but Token-bucket based method or the
Bandwidth-based method don't (as the draft suggests).

Why not limit the rate of ICMPv6 error messages to a particular 
source by using even the token-bucket based method ?

Regards
Mukesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Fred Templin
Sent: Wednesday, January 07, 2004 6:00 AM
To: Savolainen Teemu (Nokia-TP/Tampere); [email-masked]
Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

Teemu,

ICMPv6 echo request/reply don't count, because they're not ICMPv6 errors.
If a well-behaved A is sending packets that cause B to generate ICMPv6 errors,
A will adapt its behavior and the ICMPv6 messages from B to A will naturally
subside. Can B be reasonably assured that A will be well behaved if B has
a security association with A? I certainly think so. Must B maintain state to
avoid the problem you are describing for any A with which it does not have
a security association? Perhaps.

Under the assumption of well-behaved nodes, Pekka's point about token
bucket being well-suited for bursty traffic was a good one; once the burst
of messages from A causing B to send errors subsides, other nodes such
as C will receive the ICMPv6 error messages they need from B so that they
can also naturally adapt their behavior.

Fred
[email-masked]

[email-masked] wrote:
Hi,

I have a question/clarification about the Token-bucket based method I couldn't clearly figure out from draft or mail discussions I found. 

If there is a situation like this:
- Node A is already sending loads of ICMPv6 to the Node B for any reason (Node B flooding A with echo requests for example).

- Node C sends something to Node A that causes ICMPv6 message to be sent to Node C

- Now wouldn't Node A very likely drop the single response for Node C because Node B has already caused A's Token-bucket to fill up and over? Wouldn't this be a bit unfair for Node C, particularily if the Node B is deliberately flooding A?

So should Token-bucket based method also look for source/destination address like Timer-based method says? Or is this fully implementation specific issue as the draft states that those three methods (f.1/f.2/f.3) are example! s anyway? 

Thanks,

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Margaret Wasserman
> Sent: 07 January, 2004 04:06
> To: Gupta Mukesh (Nokia-NET/MtView)
> Cc: [email-masked]
> Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
> 
> 
> 
> Hi Mukesh,
> 
> >One of the issues raised was about rate limiting methods
> >suggested by the draft. The draft suggests Timer-based,
> >Bandwidth-based and Token-bucket based methods for limiting
> >the rate of the ICMP messages.
> >
> >After going through the discussion about this in the archive
> >and thinking about this a little bit, I propose that we
> >remove the Timer-based and Bandwidth-based methods and just
> >keep the Token-bucket based method in the draft. (look at
> >the arguments a! t the end of this mail)
> >
> >I would like to hear from people who would like to keep the
> >Timer-based and Bandwidth-based methods with logical reasons.
> 
> I'm not sure if these are logical reasons, but... I am
> concerned about making a change that will invalidate any
> existing ICMPv6 implementations, unless that change is
> absolutely necessary (e.g. to block a serious security
> hole or to prevent a significant operational problem).
> 
> Would it work to state in the new draft that implementations
> SHOULD implement the Token-bucket method, but MAY implement
> the other methods?
> 
> I think that would appropriately encourage implementation of
> the Token-bucket method without invalidating existing
> implementations that use one of the others.
> 
> Thoughts?
> 
> Margaret
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

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

---

From: Fred Templin <[email-masked]>
Date: Wed, 07 Jan 2004 10:07:53 -0800

Mukesh,

>Bandwidth-based method don't (as the draft suggests).

The text says:

         (f.1) Timer-based - for example, limiting the rate of
               transmission of error messages to a given source, or to
               any source, to at most once every T milliseconds.

The key phrase is: "to a given source, or to any source", so it
doesn't seem that the timer-based method *needs* to consider the
source. BTW, I cut-and-pasted the above text out of RFC 1885
(published in December 1995 and obsoleted by RFC 2463) so we
are talking about very old history here.

>source by using even the token-bucket based method ?

I would be concerned about the overhead for caching per-source
information, especially in low-end routers. But, that's just an
off-the-cuff remark and not well thought out in terms of all
the implications.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Jan 2004 20:22:15 +0200 (EET)

(Tailed down the cc:)

> off-the-cuff remark and not well thought out in terms of all

I'm worried about the same thing -- and I don't think source-based
token-bucket is justified.  Sure, feel free to do so, but a regular
one should work just as well with sufficiently large burst allowance
(e.g., 50-100 packets).

If someone is DoS'ing you it may actually be a feature that you don't 
consider the source .. you can't overload the box by spoofing 
different source addresses :-)

W.r.t. the other thread, I don't have objections to giving an 
implementation hint on the parameters -- it's just that I don't think 
it's really needed.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings