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
- [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- [tcpm] ICMP error origination timeliness Pekka Savola
- Re: [tcpm] ICMP error origination timeliness Joe Touch
- Re: [tcpm] ICMP error origination timeliness Anantha Ramaiah (ananth)
- Re: [tcpm] ICMP error origination timeliness Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)
- Re: [tcpm] Some comments on tcpsecure Ted Faber
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Joe Touch
- Re: [tcpm] Some comments on tcpsecure Fernando Gont
- Re: [tcpm] Some comments on tcpsecure Anantha Ramaiah (ananth)