[tcpm] Q&C regarding tcpsecure-09 recommendations

Andre Oppermann <andre@freebsd.org> Sun, 01 June 2008 22:30 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 [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 782673A689B; Sun, 1 Jun 2008 15:30:10 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id E6A2E3A6778 for <tcpm@core3.amsl.com>; Sun, 1 Jun 2008 15:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2Xw9CNxd7-Gb for <tcpm@core3.amsl.com>; Sun, 1 Jun 2008 15:20:11 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch []) by core3.amsl.com (Postfix) with ESMTP id 726E63A68DD for <tcpm@ietf.org>; Sun, 1 Jun 2008 15:17:45 -0700 (PDT)
Received: (qmail 57209 invoked from network); 1 Jun 2008 21:14:49 -0000
Received: from localhost (HELO []) ([]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <tcpm@ietf.org>; 1 Jun 2008 21:14:49 -0000
Message-ID: <48432005.2070201@freebsd.org>
Date: Mon, 02 Jun 2008 00:17:41 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Thunderbird (Windows/20071210)
MIME-Version: 1.0
To: tcpm@ietf.org
Subject: [tcpm] Q&C regarding tcpsecure-09 recommendations
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

I'm reworking/refactoring/rewriting the FreeBSD TCP input path (in a separate
perforce tree at the moment) and in that process I'm evaluating all assumptions
and test them against a close reading of all relevant RFCs.

While reading and applying draft-ietf-tcpm-tcpsecure-09.txt I've come across a
couple of inconsistencies and issues that require further clarification:

Section 3.2 Mitigation of Blind RST

  [Real world observation]
  Some implementations send the RST not on rcv_nxt but on rcv_nxt-1 or
  rcv_nxt+rcv_win.  Thus we accept three small windows of rcv_nxt(+-1),
  last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1).

  Of course the challenge ACK should have the same effect at the expense
  of another round trip.  While these three (two in case of rcv_nxt == last_ack_sent)
  do increase the chances of a succesful attack (only every third seq# has to
  be probed plus the average hit rate is increased due to having two/three
  different places that match) real world behavior and interop should be
  considered and discussed.


Section 4.2 Mitigation of Blind SYN

  [Possible inconsistency in text]
  The test in 4.2 eq. 1) is a little different.  In RFC793 it is:


  in tcpsecure it is described as one byte larger beyond the real window:


  This seems to be incorrectly transcribed.

Section 5.2 Mitigation of Blind data injection attack

  Data that doesn't satisfy the new check in first paragraph MUST be discarded
  silently. Before RFC793 used to require an ACK to be sent back. This change
  is not sufficiently explained and lacks an obvious rationale.

  The second related issue is where this check should be placed relative to
  RFC793 ordering?  Before the fifth check, last sentence (page 72) "If the ACK
  acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the
  segment, and return." or right after it?  This has implications on the response
  as tcpsecure requires to silently discard the segment.  If it weren't for the
  silent discard the new tcpsecure check could simply replace/extend the fifth
  check from RFC793.

Feedback appreciated.



tcpm mailing list