Hi, only roughly going through this thread but ...
On further consideration, I think the bandwidth-based method might actually
be dangerous in some situations. Suppose there were asymmetric paths
between nodes A and B; the path A-B consisting of all 1Gbps links and
the path B-A consisting of
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext
Margaret Wasserman
Sent: 07 January, 2004 04:06
To: Gupta Mukesh (Nokia-NET/MtView)
Cc: [EMAIL PROTECTED]
Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
Hi Mukesh,
One
Margaret Wasserman wrote:
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
On Wed, 7 Jan 2004, Brian Haberman wrote:
I think that would appropriately encourage implementation of
the Token-bucket method without invalidating existing
implementations that use one of the others.
I agree with the sentiment here. Changes to this document should
not affect backwards
] [mailto:[EMAIL PROTECTED] Behalf Of ext Margaret Wasserman Sent: 07 January, 2004 04:06 To: Gupta Mukesh (Nokia-NET/MtView) Cc: [EMAIL PROTECTED] Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting MethodsHi Mukesh, One of the issues raised was about rate limiting methods suggested
Pekka,
Mostly agree, except with the final paragraph where you say that
the parameters for token bucket, timer, etc. mechanisms don't
matter that much. ICMPv6 says that errors should include up to
the IPv6 min-MTU bytes of the packet that caused the error. That's
1280 bytes, but on some long,
Hi Margaret,
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).
?
Regards
Mukesh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Fred Templin
Sent: Wednesday, January 07, 2004 6:00 AM
To: Savolainen Teemu (Nokia-TP/Tampere); [EMAIL PROTECTED]
Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
Teemu
values in the
draft.
Regards
Mukesh
-Original Message-
From: ext Fred Templin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 07, 2004 6:13 AM
To: Pekka Savola; Brian Haberman
Cc: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView); [EMAIL PROTECTED]
Subject: Re: draft-ietf-ipngwg-icmp-v3
, January 07, 2004 6:00 AM
To: Savolainen Teemu (Nokia-TP/Tampere); [EMAIL PROTECTED]
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
(Tailed down the cc:)
On Wed, 7 Jan 2004, Fred Templin wrote:
Why not limit the rate of ICMPv6 error messages to a particular
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,
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
Mukesh,
As Pekka already pointed out, all the three methods are provided
as examples. The draft mandates the rate limiting by saying:
an IPv6 node MUST limit the rate of ICMPv6 error messages it sends
and then it provides examples by saying:
There are a variety of ways of implementing the
: ext Fred Templin
[mailto:[EMAIL PROTECTED]Sent: Wednesday, January 07, 2004 5:32
AMTo: Margaret Wasserman; Gupta Mukesh
(Nokia-NET/MtView)Cc: [EMAIL PROTECTED]Subject: Re:
draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
Margaret,
On further consideration, I think
PMTo: 'ext Fred Templin'Cc:
[EMAIL PROTECTED]Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate
Limiting Methods
Fred,
Rethinking about the following example of yours. Do we need to
consider
the
asymmetric paths between A and B ? I guess, the problem can be
seen
with even
: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
Fred,
Rethinking about the following example of yours. Do we need to consider
the asymmetric paths between A and B ? I guess, the problem can be seen
with even symmetric path. Let say the network is like
A --- 1gig --- C --- 56 kbps -- D
In your previous mail you wrote:
I would like to hear from people who would like to keep the
Timer-based and Bandwidth-based methods with logical reasons.
= Even if Token-based is the best method it can be a bit expensive
to implement (code size and memory requirements) on very small
On Tue, 6 Jan 2004, Francis Dupont wrote:
In your previous mail you wrote:
I would like to hear from people who would like to keep the
Timer-based and Bandwidth-based methods with logical reasons.
= Even if Token-based is the best method it can be a bit expensive
to implement
In your previous mail you wrote:
On Tue, 6 Jan 2004, Francis Dupont wrote:
In your previous mail you wrote:
I would like to hear from people who would like to keep the
Timer-based and Bandwidth-based methods with logical reasons.
= Even if Token-based is
Pekka,
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
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
-
From: ext Pekka Savola [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 06, 2004 9:44 AM
To: Fred Templin
Cc: Francis Dupont; Gupta Mukesh (Nokia-NET/MtView); [EMAIL PROTECTED]
Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
On Tue, 6 Jan 2004, Fred Templin wrote
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
Pekka,
Pekka Savola wrote:
On Tue, 6 Jan 2004, Fred Templin wrote:
Generally speaking, it seems appropriate to exclude implementation
alternatives only if they are known to cause operational issues.
[...]
Traceroute not working (without unnecessary delays) is a serious
operational
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
25 matches
Mail list logo
