Re: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-11.txt

Fernando Gont <fernando@gont.com.ar> Mon, 03 November 2008 05:08 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 [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E332D3A688E; Sun, 2 Nov 2008 21:08:24 -0800 (PST)
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 5A30E3A688E for <tcpm@core3.amsl.com>; Sun, 2 Nov 2008 21:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.991
X-Spam-Level:
X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808]
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 ib6rBMH0UrLO for <tcpm@core3.amsl.com>; Sun, 2 Nov 2008 21:08:23 -0800 (PST)
Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 72AED3A6866 for <tcpm@ietf.org>; Sun, 2 Nov 2008 21:08:22 -0800 (PST)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E81DA6B6598 for <tcpm@ietf.org>; Mon, 3 Nov 2008 02:08:23 -0300 (ART)
Received: from notebook.gont.com.ar (201-254-57-122.speedy.com.ar [201.254.57.122] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mA3583sM005136 for <tcpm@ietf.org>; Mon, 3 Nov 2008 03:08:04 -0200
Message-Id: <200811030508.mA3583sM005136@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 03 Nov 2008 02:00:33 -0300
To: tcpm@ietf.org
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <20081103041501.D744C3A6B67@core3.amsl.com>
References: <20081103041501.D744C3A6B67@core3.amsl.com>
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]); Mon, 03 Nov 2008 02:08:22 -0300 (ART)
Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-11.txt
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-Archive: <https://www.ietf.org/mailman/private/tcpm>
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At 01:15 a.m. 03/11/2008, Internet-Drafts@ietf.org wrote:

>TCP has historically been considered protected against spoofed off-
>path packet injection attacks by relying on the fact that it is
>difficult to guess the 4-tuple (the source and destination IP
>addresses and the source and destination ports) in combination with
>the 32 bit sequence number(s).  A combination of increasing window
>sizes and applications using longer term connections (e.g.  H-323 or
>Border Gateway Protocol [RFC4271]) have left modern TCP
>implementations more vulnerable to these types of spoofed packet
>injection attacks.

It was pointed out by a number of us (e.g., Joe Touch and me) that 
this document should probably reference the ongoing work at tsvwg on 
port randomization 
(http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-02.txt).

Considering that nowadays TCP implementations such as that FreeBSD, 
OpenBSD, Linux, and Cisco itself do implement some form of ephemeral 
port randomization, some statements in the document wrt port 
randomization seem inacurate. (e.g., do *current* TCP implementations 
used for servicing BGP not randomize their ephemeral ports).

(FWIW, I don't care about our doc being referenced.... but talking 
about guessing the connection-id while ignoring what is currently 
being done about ephemeral port selection doesn't seem quite right to me).

Thanks!

Kind regards,

--
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