IETF Logo Mail Archive

Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states)

Fernando Gont <fernando@gont.com.ar> Thu, 29 September 2005 18:09 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2qm-00038P-W4; Thu, 29 Sep 2005 14:09:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2ql-00038H-DL for tcpm@megatron.ietf.org; Thu, 29 Sep 2005 14:09:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26068 for <tcpm@ietf.org>; Thu, 29 Sep 2005 14:09:41 -0400 (EDT)
Received: from server.frh.utn.edu.ar ([170.210.17.146] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2yQ-0000oE-Hm for tcpm@ietf.org; Thu, 29 Sep 2005 14:17:41 -0400
Received: (qmail 13832 invoked from network); 29 Sep 2005 18:09:01 -0000
Received: from 200-70-177-2.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.177.2) by server.frh.utn.edu.ar with SMTP; 29 Sep 2005 18:09:01 -0000
Message-Id: <6.2.0.14.0.20050929150021.0428acc8@pop.frh.utn.edu.ar>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 29 Sep 2005 15:01:41 -0300
To: Jakob Heitz <jheitz@redback.com>, tcpm@ietf.org
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states)
In-Reply-To: <433C2573.40904@redback.com>
References: <6.2.0.14.0.20050923075214.0428faa8@pop.frh.utn.edu.ar> <433411E2.3020005@isi.edu> <6.2.0.14.0.20050923125332.04320008@pop.frh.utn.edu.ar> <4334345F.2060301@isi.edu> <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar> <4339AB09.70501@isi.edu> <6.2.0.14.0.20050928034642.08012bf0@pop.frh.utn.edu.ar> <433BDFB8.4090407@isi.edu> <6.2.0.14.0.20050929120406.03d79008@pop.frh.utn.edu.ar> <433C0C47.3080207@isi.edu> <6.2.0.14.0.20050929125335.03d67e90@pop.frh.utn.edu.ar> <433C2573.40904@redback.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc:
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At 02:33 p.m. 29/09/2005, Jakob Heitz wrote:

>>At 12:46 p.m. 29/09/2005, Joe Touch wrote:
>>>That presumes I think that there is a viable way to secure ICMP, which I
>>>don't so far.
>>
>>No. That means you are making an argument for a protocol which is already 
>>unreliable.
>
>...but it's useful.
>IP and UDP are unreliable too, but they're useful.

Of course. That's why I don't propose to "drop all ICMP", or simply drop 
the so-called "ICMP hard errors:.

Perform checks, and if you are to fail, fail for the sake of 
robustness/security.


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org






_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email