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 PROTECTED]
Pekka Savola wrote:
On Mon, 19 Jan 2004, Fred Templin wrote:
[...]
Assuming we are on the same page,
Yep.
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.
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.
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)
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
the outgoing attached link.
But I disagree with this conclusion, as discussed above.
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.
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.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
