Subject: RE: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

From: [email-masked]
Date: Mon, 19 Jan 2004 03:18:16 -0600

Fred,

I mostly agree with Pekka here.

Specific comments inline:

> > I think we may have glossed over this in earlier discussion, 
> > but I believe
> > 'B' should be allowed as an expression of either messages OR bytes.
> > Size *does* matter in certain cases, and expressing 'B' 
> only in terms
> > of a number of messages is too limiting. I think this can 
> be fixed rather
> > simply by changing the phrase: "B error messages" to
> > "B error messages/bytes".

I agree with Pekka that this compllicates the text and the 
implementation. Moreover, N (the long-term average) can be
in number of packets per seconds or a fraction of the attached
link's bandwidth. Don't you think, the size of the packet
will be covered if N is specified as the fraction of the
bandwidth ?

> > Rate-limiting mechanisms which cannot cope with bursty traffic
> > (e.g., traceroute) are not recommended; thus a simple timer-
> > based implementation, allowing an error message every T
> > milliseconds (even with low values for T), is not reasonable.
> >  
> > I don't see the purpose in dis-recommending a particular scheme,
> > (i.e., the simple timer), since there are infinitely many other
> > possibilities that would be equally bad (or worse). Suggest
> > shortening this paragraph to a single sentence such as:
> 
> IMHO, it makes sense to dis-recommend an approach, because it's
> actually deployed out there, and thus it seems to be a good idea to
> specifically say that it is NOT a good idea.  I'm not aware of other, 
> "really broken" mechanisms which would have been deployed.  Moreover, 
> this was suggested in the previous RFC, so recommending against it 
> explicitly seems like a good idea.  

Agree. We even considered removing it. So dis-recomending is softer
than that.

> The text could use a bit sharpening up, to say that timer-based 
> discouragement is just and example, though, like:
> 
>        Rate-limiting mechanisms which cannot cope with bursty traffic
>         (e.g., traceroute) are not recommended; for example, a simple
>         timer-based implementation, allowing an error message every T
>         milliseconds (even with low values for T), is not reasonable.

Sounds better.

> > The rate-limiting parameters SHOULD be configurable.  In the
> > case of a token-bucket implementation, the best defaults depend
> > on where the implementation is expected to be deployed (e.g., a
> > high-end router vs. an embedded host).  For example, in a
> > small/mid -sized device, the possible defaults could be B=10,
> > N=10/s.
> >  
> > I may have missed this in earlier discussion, but the "SHOULD"
> > above used to be a "MUST" in the earlier text - is there any reason
> > we are now saying "SHOULD" instead of "MUST"?
> 
> I thought that was appropriate due to the reasons listed in the mail
> where I proposed the text.  I do not think it makes sense to require
> the values MUST be configurable on every kind of device -- take e.g. a
> mobile phone which implements an IPv6 stack.  MUST seems too strong
> here.  SHOULD seems more appropriate.  Changing the values is
> typically very useful especially in the cases where the implementation
> may be used in small devices and bigger routers as well.

Agree. If it is possible for the implementation to clearly choose 
appropriate default values based on the capacity of the links and 
the devices where the implementation is going to be used, there is 
no point in exposing this to the user.

Regards
Mukesh

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

---

From: Fred Templin <[email-masked]>
Date: Mon, 19 Jan 2004 08:25:13 -0800

> will be covered if N is specified as the fraction of the

I'll let the other stuff go for now, but the above is a very
important point and in need of a bit more discussion. The token
bucket text we are discussing essentially recommends that nodes
implement a virtual queue for outgoing ICMPv6 error messages
and perform active queue management on that queue based on the
parameters N and B.

RFC 2309 recommends active queue management for *routers*, but
the text we are talking about correctly goes the extra measure
of recommending active queue management at the source of the
ICMPv6 error messages itself, i.e., the "0th hop router".
RFC 2309, section 3(b) says:

    Note: the decision whether or not to drop an incoming packet
    can be made in "packet mode", ignoring packet sizes, or in
    "byte mode", taking into account the size of the incoming
    packet.  The performance implications of the choice between
    packet mode or byte mode is discussed further in [Floyd97].

So IMO (and based on the RFC 2309 text) an active queue
management recommendation that neglects "byte mode" and fails
to cite RFC 2309 as informative text would be omitting important
considerations that implementors should take into account. As
such, I suggest the following:

         A recommended method for implementing the rate-limiting
         function is a token bucket, limiting the average rate of
         transmission to N, where N can either be packets/second or a
         fraction of the attached link's bandwidth, but allowing up to
         B error messages/bytes to be transmitted in a burst, as long
         as the long-term average is not exceeded. Other methods that
         provide effective active queue management [RFC2309] for
         outgoing ICMPv6 error messages are also acceptable.

Fred L. Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Jan 2004 19:55:04 +0200 (EET)

On Mon, 19 Jan 2004, Fred Templin wrote:
> considerations that implementors should take into account. 

The background paper, Floyd97, states that the assumption is that
bandwidth is the scarce resource.  This may very well be the case for
the regular case of active queue management for packets that pass
through the router.  However, I do not think this is the case here --
the scarce resource should be assumed to be the pps of error messages
generated by the router, in which case the byte mode is inappropriate.

The threat model here is assumed to be that an attacker forces the
router to respond to packets with ICMP, overloading the CPU or other
resources of the router.

Again, the scarce resource could be the bandwidth in cases where the 
links are very low bandwidth, either close to the error-sending router 
or somewhere along the path -- but this is an issue which calls for 
strict AQM for all kinds of packets, and no special action should be 
needed for ICMPv6 error messages.

> As such, I suggest the following:
> 

I have to disagree here, on the grounds that it adds a bit complexity,
and may confuse the reader because the reference to active queue
management was written to talk about AQM of the forwarding path -- not
error generation path -- and as may be misleading or inappropriate.

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

---

From: Fred Templin <[email-masked]>
Date: Mon, 19 Jan 2004 11:19:26 -0800

>generated by the router, in which case the byte mode is inappropriate.

Pekka,

Let's be clear first on what node you are referring to by "the router". 
Let's
assume node A sends packets to node B that causes B to send ICMPv6 error
messages to node C (where, A and C may/may not be the same nodes and/or
the network path A->B may/may not have similar congestion/bandwidth/delay
characteristics to the path B->C). The "router" in this case is node B - 
correct?

Assuming we are on the same page, there are two worst-case threat
models to consider:

  Threat model 1:
  *************
  Node B (i.e., "the router") is congested in terms of CPU load, memory
  utilization, etc, while the network path from B->C is uncongested and
  uses only fast links.

  Threat model 2:
  *************
  The router is uncongested, but the network path from B->C is congested
  and/or has low-bandwidth links.

>router to respond to packets with ICMP, overloading the CPU or other

This is threat model 1. This threat model applies to the "leading edge"
of the router's algorithm for generating ICMPv6  errors, i.e., if the
router knows a priori that local resources are too congested, it will
selectively refrain from generating the error messages in the
first place (i.e., using the rate limiting parameters B and B).
But, if the constraining resources are available buffer space,
it could well be that bytes (rather than number of packets)
would be the more appropriate metric.

>needed for ICMPv6 error messages.

This is threat model 2. This threat model would apply to the "trailing
edge" of the router's algorithm for generating ICMPv6 errors, i.e.,
if the router's local resources are uncongested it will generate the
errors, forward them to the network for transmission, but will then
have no way of knowing whether a congested/bandwidth-constrained
link occurs on the path B->C (unless the congested link occurs on the
1st hop) and should therefore use AQM on ICMPv6 errors sent on
the outgoing attached link.

I agree that this issue calls for AQM for all kinds of packets, and
indeed this is well supported by the BCP documents. But, I disagree
that no special action should be needed for ICMPv6 error messages.
For example, suppose node X at the head of a slow link X->Y on the
path from B->C is using AQM and operating near the queue's high
water mark. If the traffic passing through X->Y is mostly due to well
behaved sessions, a high arrival rate of ICMPv6 error messages from
B at X will result in an equal likelihood of dropping the legitimate
traffic as dropping the ICMPv6 messages. Also, we have only the BCP
recommendations that network nodes implement AQM; we have no
guarantees that network nodes along all forwarding paths will comply.

Finally, I have looked at the RED queue management documents at:

  http://www.icir.org/floyd/red.htm

and so far I have not seen any conclusive evidence that shows either
packet mode vs. byte mode as the clearly superior model. As such,
I see it as beyond the scope of the document in question to promote
one of the models over the other.

Thanks - Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 Jan 2004 10:12:08 +0200 (EET)

[...]
> Assuming we are on the same page, 

Yep.

> there are two worst-case threat
> models to consider:

>   Threat model 1:

I disagree that we should be concerned about threat model 2 in this
specification.  The rate-limiting of ICMP error generation is seems
totally irrelevant when you consider the big pictuare of model 2:  
you can perform the same overloading with ICMP echo reply/request
messages, any traffic you want (e.g. UDP streams), etc. -- the point
is that if your network is congested (or low-bandwidth), you have to
deal with it in your network anyway -- no amount of changes to ICMP
rate-limiting is going to change that in any significant way.

> 1st hop) 

Yes, the router has no way of knowing about the congestion or 
bandwidth constrains anywhere along the path..

> and should therefore use AQM on ICMPv6 errors sent on

But I disagree with this conclusion, as discussed above.

> guarantees that network nodes along all forwarding paths will comply.

I have to disagree with this reasoning.  ICMPv6 is not special.  If we
had a community consensus that we must immediately adapt all the
protocols out there to cater for the case where there may be
congestion or low bandwidth links on the path, I'd probably agree 
that the behaviour needs to be changed.  But there is no such 
consensus, and inserting changes to ICMPv6 to accommodate this model 
is irrelevant and unnecessary in the big picture of bandwidth 
constraints and low bandwidth links.

---

From: Fred Templin <[email-masked]>
Date: Fri, 23 Jan 2004 10:36:26 -0800

Pekka,

Sorry for the delayed response, but I've been off pondering this one.
It seems to me that the question is more of a philisophical/operational
nature and not readily tackled from a theoretical perspective. The
point comes down to whom do you trust? Do you trust hosts to be
well behaved, or do you trust networks to provision mechanisms
to protect others against poorly-behaved hosts?

An analogy would be vehicles and highways. There are laws
about how drivers should operate their vehicles, but drivers break
them all the time. Highway authorities can set a maximum speed
limit of 65mph, but drivers routinely cruise at 80mph without
remorse. The Dept. of Motor Vehicles can state that vehicles
must meet certain performance criterion, but drivers frequently
modify their vehicles to make them perform more like race cars.
On the other hand, if the highway authority took away stop lights
from dangerous intersections, let potholes develop in roads, etc.
etc., drivers would be outraged and immediately begin using
other roads.

Anyway, this line of discussion is really outside of my area of
expertise.  It would be best to hear other opinions on this, but
I'm also respectful of the more  practical/operational aspects
that you bring to the discussion. Any suggestions on how to
proceed from here would be welcome.

Fred
[email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Mon, 26 Jan 2004 16:00:50 -0500

I agree with Pekka's assessment on the issues with changing the
text on rate-limiting.  Adding complicated scenarios is not in
the best interest of this document.  So, unless someone can show
evidence of a reason to do so, let's keep the text straightforward
and as simple as possible.

Regards,
Brian

---

From: Fred Templin <[email-masked]>
Date: Wed, 28 Jan 2004 12:09:41 -0800

Brian,

Based on the analysis in my last message, I also agree with Pekka.
But, I would still prefer to see the rate limiting text include the term
"messages/bytes" instead of just "messages". If it is too complicated
I'm just not seeing it; if it is problematic, that is a different story.
I'm interested to know others' thoughts on this, but also recognize
the need for closure.

Thanks - Fred
[email-masked]