Re: [tcpm] WG Last Call for ICMP Attacks

"Anantha Ramaiah (ananth)" <> Wed, 09 September 2009 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43BAC28C44E for <>; Wed, 9 Sep 2009 08:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.224
X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xtPdImwNTGVF for <>; Wed, 9 Sep 2009 08:56:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DB04228C29C for <>; Wed, 9 Sep 2009 08:56:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,359,1249257600"; d="scan'208";a="188459834"
Received: from ([]) by with ESMTP; 09 Sep 2009 15:57:10 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id n89FvAiC032126; Wed, 9 Sep 2009 08:57:10 -0700
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id n89FvAgk029043; Wed, 9 Sep 2009 15:57:10 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 08:57:10 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 09 Sep 2009 08:57:09 -0700
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] WG Last Call for ICMP Attacks
Thread-Index: AcoxYTxr8TsqCXHrQnqry7pveb+GcQAAWSnw
References: <> <B01905DA0C7CDC478F42870679DF0F1005B64E383D@qtdenexmbm24.AD.QINTRA.COM> <> <> <><> <><> <><> <> <>
From: "Anantha Ramaiah (ananth)" <>
To: Joe Touch <touch@ISI.EDU>, "Carlos Pignataro (cpignata)" <>
X-OriginalArrivalTime: 09 Sep 2009 15:57:10.0619 (UTC) FILETIME=[30A782B0:01CA3166]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4539; t=1252511830; x=1253375830; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20WG=20Last=20Call=20for=20ICMP= 20Attacks |Sender:=20; bh=dqCoJ8dFtaFlVXmEY3b+U8isSVrGlz31lw4P5oViayQ=; b=sCUSJQaHcy0krG6sdxPoqi2unfebYe0G12faE9CWS/2Oqwgmfpth0K2A8Z PVZks7/c6lBDV8MzbXoKtLQimRBhG+AVwmEDy7D+YNiG45qye/K913xO+iyt NB9ZmDvx0YtqhhUZ0tj9Lbj4NMQMxtQNeFIJojQke4kuNWzEXFn5o=;
Authentication-Results: sj-dkim-1;; dkim=pass ( sig from verified; );
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:56:39 -0000

Jumping in to this thread since I had mentioned it many times earlier
that delayed ICMP's causing issues for seq # check is impractical today.
On the client side validation we can have the following scenarios :-

#1 - ICMP comes in and doesn't match the current segments (or in some
implementations packets) sitting in the retransmission queue, thus the
ICMP is silently dropped. No harm.
#2 - ICMP arrives and it matches the sequence #, this is the usual case.
No harm if false positives are handled correctly.

The cause for concern is the case where the ICMP packet gets delayed for
a long time and the sequence number has wrapped around and the seq # no.
exactly falls in the window of packets sitting in the retransmit queue.
This cam happen only when the data is sent at a very fast rate and such
cases extra checks are necessary. OTOH, if the ICMP packet seq#  falls
outiside (> SNDNXT) in such cases this is for something not yet sent,
discard it. No harm

IMO, this is not an issue at all, these false positives can be handled
with appropriate checks in the code.

Joe has brought this up multiple # of times and I don't really see this
as an issue. The merits of this seq# check far outweigh the de-merits,
if any. If you have extendeded ICMP support then we could check more to
get even more robustness. (example if timestmaps are available one could
make use of it) We have been using the seq# check in our boxes for quite
some time (Fernando's draft mentions many other popular OS'es using this
method) So, far they have been no issues in the field. 

My proposal would be to add some text to what Joe is concerned about,
highlight the fact that it is mostly theoritical and hence should not be
a concern. If needed some quantification can be done, but I really don't
see the point. 

Just my few bits...


> -----Original Message-----
> From: [] On 
> Behalf Of Joe Touch
> Sent: Wednesday, September 09, 2009 8:21 AM
> To: Carlos Pignataro (cpignata)
> Cc: Smith, Donald; 'tcpm Extensions WG'; 'David Borman'; Fernando Gont
> Subject: Re: [tcpm] WG Last Call for ICMP Attacks
> 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.
> Joe
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkqnx90ACgkQE5f5cImnZrvguwCgrm7/fLMiKak8gGb0QYQsROeK
> 5bcAn0fxfPIznaScGG9Tx0oq0OjCHk8x
> =xegI
> _______________________________________________
> tcpm mailing list