Re: [tcpm] WG Last Call for ICMP Attacks

Joe Touch <touch@ISI.EDU> Wed, 09 September 2009 15:21 UTC

Return-Path: <touch@ISI.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DA7228C2C9 for <>; Wed, 9 Sep 2009 08:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WTKuDgLHjFi3 for <>; Wed, 9 Sep 2009 08:21:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 87DAF28C190 for <>; Wed, 9 Sep 2009 08:21:04 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id n89FL1GV001297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Sep 2009 08:21:03 -0700 (PDT)
Message-ID: <>
Date: Wed, 09 Sep 2009 08:21:01 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Carlos Pignataro <>
References: <> <B01905DA0C7CDC478F42870679DF0F1005B64E383D@qtdenexmbm24.AD.QINTRA.COM> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "Smith, Donald" <>, 'tcpm Extensions WG' <>, 'David Borman' <>, Fernando Gont <>
Subject: Re: [tcpm] WG Last Call for ICMP Attacks
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Sep 2009 15:21:05 -0000

Hash: SHA1

Carlos Pignataro wrote:
>> It's OK to qualify it with "this is unlikely", but IMO it needs to be
>> discussed with more than a single word in a single paragraph.
> I think that "this is unlikely" or "this is highly unlikely" would still
> be understating the probability (I am curious to see any experienced
> example of ICMP being delayed minutes). Redundancy architectures of
> routers typically cover the planned upgrade (or even unexpected reload)
> scenarios you presented.
> Perhaps a separate sentence in that paragraph before the "Thus, " with
> some variation of "rate-limiting can delay ICMPs, and some other highly
> unlikely theoretical scenarios can compound the delay"?

You can't rely on something that isn't required. The fact that current
implementations, in current operation, don't do this isn't relevant.

Consider the proposal to resend 'the last packets seen' after a link
outage, to 'tickle' TCP into waking up. That proposal was considered
inappropriate because the router would hold the packet too long to
satisfy requirements. However, if someone were to propose to hold ICMPs
and issue them later, that would be *compliant*.

Protocols aren't just about what happens to work today; they're about
what you can expect to work tomorrow too. Anything that examines the
contents of an ICMP needs to appreciate that those contents do NOT have
to obey timeliness requirements - notably of the protocol being conveyed
as payload. You need to explain what happens when your assumptions are
wrong not because they're often wrong today, but because you cannot know
whether they'll be wrong tomorrow.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -