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
- [tcpm] ICMP attacks draft (issue 1): hard errors … Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Ted Faber
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Lloyd Wood
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Jakob Heitz
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Ted Faber
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Fernando Gont
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Lloyd Wood
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Ted Faber
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Ted Faber
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Ted Faber
- Re: [tcpm] ICMP attacks draft (issue 1): hard err… Joe Touch
- tcpm-antispoof and TCP's weakness [Re: [tcpm] ICM… Pekka Savola
- Re: tcpm-antispoof and TCP's weakness [Re: [tcpm]… Joe Touch
- Re: tcpm-antispoof and TCP's weakness [Re: [tcpm]… Pekka Savola