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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
