Re: [tcpm] Some comments on tcpsecure

Joe Touch <touch@ISI.EDU> Sat, 05 April 2008 20:37 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E7A28C36C; Sat, 5 Apr 2008 13:37:02 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC893A6BC0 for <tcpm@core3.amsl.com>; Sat, 5 Apr 2008 13:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7SvvJIGr9+D for <tcpm@core3.amsl.com>; Sat, 5 Apr 2008 13:37:01 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2B2713A69A0 for <tcpm@ietf.org>; Sat, 5 Apr 2008 13:37:01 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-105-89-117.lsanca.dsl-w.verizon.net [71.105.89.117]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m35KaWO8019494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 5 Apr 2008 13:36:33 -0700 (PDT)
Message-ID: <47F7E2D0.8010802@isi.edu>
Date: Sat, 05 Apr 2008 13:36:32 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu> <200804050557.m355vAjU013266@venus.xmundo.net> <47F7B43E.6010004@isi.edu> <200804052024.m35KOlmj018418@venus.xmundo.net>
In-Reply-To: <200804052024.m35KOlmj018418@venus.xmundo.net>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Some comments on tcpsecure
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0872641951=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org


Fernando Gont wrote:
> At 02:17 p.m. 05/04/2008, Joe Touch wrote:
> 
>>>>> And, for what is worth, strictly speaking there's no such a thing 
>>>>> as a TCP MSL, either. TCP's MSL is based on the assumption that the 
>>>>> IP TTL is decremented at least once every second. And this is not 
>>>>> warranted, either. There's not such enforcement as there is in, 
>>>>> e.g., Delta-t.
>>>>
>>>> If there's no MSL, then that's even more reason not to use window 
>>>> information to determine the validity of an ICMP.
>>> And no reason to use sequence numbers at all, and no reason for TCP's 
>>> quiet time, and no reason for TCP's TIME-WAIT state, etc., etc., etc. 
>>> From that purist (??) point of view, TCP would not even work at all.
>>
>> Absolutely - that's the absurdity of *your* point about there being no 
>> such thing as MSL. However, MSL is irrelevant to ICMP even if 
>> (contrary to your point above) MSL is meaningful to TCP.
> 
> The ICMP attacks drafts used to propose (unfortunately, right now it 
> only "documents") a number of mitigation techniques for ICMP-based 
> attacks. Among these were:
> 
> 1) Require ICMP messages to be in window.
> 2) Don't reset connections in the synchronized (>ESTABLISHED) states 
> upno receipt of the so-called ICMP hard errors.
> 
> You argument against (1) is that there's not such a timing requirement 
> for ICMP messages. If that's your argument, then please also propose to 
> remove any sequence number checks and any other assumptions on the MSL 
> (e.g., quiet time concept, TIME-WAIT state) that are based on timing 
> assumptions of TCP segments (and hence IP datagrams) that are *not* 
> required in the protocols, *either*. Or well, that at least cannot be 
> enforced. (Again, if you want this, you want something like Delta-t).

As I said before:

	TCP *has* an MSL requirement (RFC793)
		this means that TCP segments should not live
		in the network beyond approx 2 minutes

	ICMP does *not* have a requirement to respond with an MSL
		so a TCP segment's header can exist inside
		an ICMP packet long after the segment's MSL period

As a result, it remains incorrect to validate a TCP segment inside the 
ICMP as needing to be "in window".

> Your argument against (2) is that...mmm... that would be incorrect, 
> because it would assume that every packet is an attack. But you do want 
> to advocate ICMP filtering at firewalls.

Correct. If an individual host or subnet wants to assume that ALL ICMPs 
are suspect, then that's its decision - and that already happens at some 
firewalls.

However, it is incorrect to *assume* that a particular kind of ICMP is 
an attack and another is not simply because it is unexpected. That's the 
flaw in #2.

What "everyone implements" isn't the issue; that is covered in BCPs when 
the IETF agrees with it and things like RFC 2525 (Known TCP 
Implementation Problems) when the IETF does not feel it is appropriate 
to change the standard merely to align with what is deployed.

In this case, since ICMPs *are* delayed, I don't think it is appropriate 
to align ICMP checks with what is deployed.

Joe

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