[secdir] Review of draft-ietf-tcpm-fastopen-08

Shawn M Emery <shawn.emery@oracle.com> Sun, 30 March 2014 22:31 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 945451A07DF; Sun, 30 Mar 2014 15:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CSBB-AR_7uwj; Sun, 30 Mar 2014 15:30:58 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8F0381A0344; Sun, 30 Mar 2014 15:30:58 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com []) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2UMUnI0007780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Mar 2014 22:30:52 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com []) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2UMUmeu003920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Mar 2014 22:30:49 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com []) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2UMUmBJ003917; Sun, 30 Mar 2014 22:30:48 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 30 Mar 2014 15:30:48 -0700
Message-ID: <53389B18.9060305@oracle.com>
Date: Sun, 30 Mar 2014 16:30:48 -0600
From: Shawn M Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140222 Thunderbird/17.0.6
MIME-Version: 1.0
To: secdir@ietf.org
References: <52DEB7D6.6050308@oracle.com>
In-Reply-To: <52DEB7D6.6050308@oracle.com>
Content-Type: multipart/alternative; boundary="------------030306010200060501040800"
X-Source-IP: acsinet22.oracle.com []
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/9o3I_Y2UcjY-4xUK544KpY4Eiyc
Cc: iesg@ietf.org, draft-ietf-tcpm-fastopen.all@tools.ietf.org
Subject: [secdir] Review of draft-ietf-tcpm-fastopen-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Mar 2014 22:31:00 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This experimental draft describes a way for TCP to include data in the SYN and SYN-ACK
exchanges when establishing an initial connection.  As you've probably already guessed
there are number security ramifications with this feature.  One is that the server
applications receive the SYN packet before the three-way handshake is complete.
This opens up various DoS attacks that would otherwise be thwarted by TCP filtering,
receive queues, etc.

The proposed solution against such attacks involves a server derived MAC that the client
requests during a TCP connection establishment.  The client subsequently uses this MAC in
subsequent three-way handshakes with the server.

The security considerations section does exist and reiterates the DoS attacks that this
protocol opens.  To help prevent DoS attacks the server keeps track of pending requests
and compares this against PendingFastOpenRequests in order to limit resources taken by
an attacker.  If the limit is exceeded then the protocol reverts to regular TCP, which
has the traditional techniques to thwart SYN floods.  The section goes on to state that another
possible attack would be to trick a number of servers to send a large response to an unsuspecting
host.  It prescribes that the server could not respond with data until the handshake completes.
I believe the various risks associated with this protocol are outlined in the draft and provides
sufficient techniques for mitigating against such attacks.

General comments:


Editorial comments:

s/cause firewall/causing firewall/
s/case it may/cases it may/