[tcpm] Some comments on tcpsecure

Fernando Gont <fernando@gont.com.ar> Fri, 04 April 2008 18:32 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 AB3E63A6988; Fri, 4 Apr 2008 11:32:43 -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 8CB913A6902 for <tcpm@core3.amsl.com>; Fri, 4 Apr 2008 11:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 cVA9cRiombNu for <tcpm@core3.amsl.com>; Fri, 4 Apr 2008 11:32:40 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8B7F43A68B5 for <tcpm@ietf.org>; Fri, 4 Apr 2008 11:32:39 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 063F55A8B32 for <tcpm@ietf.org>; Fri, 4 Apr 2008 15:32:47 -0300 (ART)
Received: from notebook.gont.com.ar (host138.190-139-181.telecom.net.ar [190.139.181.138]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m34IWTC5025090 for <tcpm@ietf.org>; Fri, 4 Apr 2008 15:32:31 -0300
Message-Id: <200804041832.m34IWTC5025090@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 04 Apr 2008 15:30:24 -0300
To: tcpm@ietf.org
From: Fernando Gont <fernando@gont.com.ar>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 04 Apr 2008 15:32:42 -0300 (ART)
Subject: [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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Folks,

I have not yet reviewed the entire document (but will do). However, 
reading the security considerations section (and at the risk of 
sounding our own horn?), I see this document does not reference two 
closely related wg documents of the tcpm and tsvwg working groups.

The first one is the ICMP attacks draft 
(draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the security 
implications of ICMP on TCP conenctions, it does not reference the 
I-D. IIRC, this had already been pointed out by Joe (?). As far as 
the specifications are concerned, you shouldn't bother to fix 
TCP-based reset attacks if you don't fix the the ICMP-based ones.

The other doc is the port randomization draft 
(draft-tsvwg-port-randomization). All the math in the "Slipping in 
the window" paper assumes TCP implementtions use a small port number 
subspace for selecting the ephemeral ports. And also assumes that 
implementations use a trivially-predictable sequence. Clearly, port 
randomization is a trivial mitigation for both these and all other 
off-path attacks that require the attacker to guess or know the 
four-tuple that identifies the connection to be attacked.

Thanks,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




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