Re: [tcpm] WG Last Call for ICMP Attacks

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

Return-Path: <touch@ISI.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD6C128C426 for <>; Wed, 9 Sep 2009 09:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 87mDYU3ncRah for <>; Wed, 9 Sep 2009 09:03:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1265428C449 for <>; Wed, 9 Sep 2009 09:03:57 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id n89G4ABK011251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Sep 2009 09:04:12 -0700 (PDT)
Message-ID: <>
Date: Wed, 09 Sep 2009 09:04:07 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <>
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" <>, "Carlos Pignataro (cpignata)" <>, 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 16:03:58 -0000

Hash: SHA1

Hi, Anantha,

Anantha Ramaiah (ananth) wrote:
> 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.

Please just put this in the doc. This issue comes up. It may not affect
this solution, but it is important to include it - to say that it isn't
an impact. I have asked for similar language in the long-delays doc, but
I'm not sure what the impact there is.

> 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. 

No quantification. A version of what's above is what I'm seeking, though
if we're considering everything we never see in the wild theoretical, we
can gut a lot of complexity out of TCP. IMO, this isn't theoretical -
it's *compliant*, and you can make the case that you do no harm when it
happens. That's the point, and that's what needs to be in the doc, IMO.

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