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

Fernando Gont <fernando@gont.com.ar> Tue, 27 September 2005 06:22 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK8qm-0005uI-GS; Tue, 27 Sep 2005 02:22:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK8qj-0005tm-TC for tcpm@megatron.ietf.org; Tue, 27 Sep 2005 02:21:58 -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 CAA16866 for <tcpm@ietf.org>; Tue, 27 Sep 2005 02:21:56 -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 1EK8xg-0002aX-FY for tcpm@ietf.org; Tue, 27 Sep 2005 02:29:23 -0400
Received: (qmail 13637 invoked from network); 27 Sep 2005 06:20:52 -0000
Received: from unknown (HELO fgont.gont.com.ar) (gont-fernando@200.70.146.149) by server.frh.utn.edu.ar with SMTP; 27 Sep 2005 06:20:52 -0000
Message-Id: <6.2.0.14.0.20050927013116.03fedc70@pop.frh.utn.edu.ar>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 27 Sep 2005 01:54:24 -0300
To: Joe Touch <touch@ISI.EDU>
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: <4334345F.2060301@isi.edu>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: tcpm@ietf.org
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 01:59 p.m. 23/09/2005, you wrote:

> >> > Issue 1 is: When a so-called ICMP "hard error" is received for a
> >> > connection in any of the synchronized states (ESTABLISHED and so on),
> >> > treat the error message as a soft error (i.e., do NOT abort the
> >> > corresponding connection).
> >>
> >> WHY? Such an error could occur due to a reboot. It is legitimate
> >> operation.
> >
> >
> > In that case you should receive an RST, not an ICMP message.
>
>Not if there is no TCP running, or none over IPv4 (i.e., convert to IPv6).

Despite how likely or unlikely you consider this scenario to happen (if you 
are thinking about IDSes/firewalls, then there are other more-specific 
codes to use), why, if TCP was disabled during the life of a connection, 
couldn't it be re-enabled again?



> > In one case (soft errors draft), an ICMP error message is received
> > during connection-establishment.
> > In this case, (ICMP attacks draft), I'm talking about ICMP error
> > messages received during the life of a connection.
>
>But why should one be considered less hard, and one more hard? It's
>basically reaction to the _inferred_ cause of such a message - in the
>first case you assume it's benign and use it to fail-over, and in the
>second you assume it's an attack and want to ignore it.

It's a matter of mechanism / policy separation.

The fact that the mechanism is the same does not mean the *policy* has to 
be the same.

There's a rationale on this very same issue in D. Clark's paper, which is 
cited in my draft. There are other works on mechanism/policy separation.

I have not invented anything.



>I don't agree with inferring things this way, esp. since such inferences
>are based on a snapshot of typical use at the time the ID is published.

Do not infer things... i.e., do not infer attack. Just infer the message 
indicates it's a *soft* error. (Yes, maybe the draft could be tweaked a 
*bit* on this)

BTW, I don't think this reflects "typical use at the time the ID is 
published", unless you are thinking of a time frame of at least fifteen years.



> > An ICMP error message is just a hint. As per D. Clark's paper, depending
> > on the time you receive the message, the meaning may be different.
>
>Agreed - but the meaning should always be considered benign before it is
>considered an attack. If a benign cause _could_ have resulted in the
>message, it seems inappropriate to react as if it's an attack.

I disagree. First, a spurious message is not benign. Unless you would also 
call "benign" a spurious message that resets your connections every other 
second, for example.

Other than that, the current environment is *not* benign.

There's a chance someone can break the door of my house, the window of my 
house or even the wall of my house to save me from a fire, or whatever 
(maybe it's just someone that just fell over them!). However, it seems to 
be fair to think that if someone does break my window, door, or wall, there 
are much more likely reasons for doing this, than "benign" ones.

Anyway, again: the draft describes possible attacks, and possible ways to 
address them. No need to "infer": Implement this if it's one of the 
described attacks that is taking place, it will protect you. If it's not, 
it won't hurt you.

Kindest regards,

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






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