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

"Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com> Mon, 31 March 2014 06:49 UTC

Return-Path: <michael.scharf@alcatel-lucent.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ABE1A096E for <secdir@ietfa.amsl.com>; Sun, 30 Mar 2014 23:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0ccyg72Tq0a for <secdir@ietfa.amsl.com>; Sun, 30 Mar 2014 23:49:10 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6F91A0444 for <secdir@ietf.org>; Sun, 30 Mar 2014 23:49:09 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s2V6n2Ic006178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 31 Mar 2014 01:49:06 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2V6n1l9030910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 08:49:02 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.224]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 31 Mar 2014 08:49:01 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: Shawn M Emery <shawn.emery@oracle.com>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Review of draft-ietf-tcpm-fastopen-08
Thread-Index: AQHPTGgGVJ4kIXErBE2cItqpXr9aeJr6wCKo
Date: Mon, 31 Mar 2014 06:49:00 +0000
Message-ID: <655C07320163294895BBADA28372AF5D26343D@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <52DEB7D6.6050308@oracle.com>,<53389B18.9060305@oracle.com>
In-Reply-To: <53389B18.9060305@oracle.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [155.132.188.47]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D26343DFR712WXCHMBA15zeu_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hwRz45DZfUJWTRmOH2jrpKAwDKg
X-Mailman-Approved-At: Mon, 31 Mar 2014 03:22:01 -0700
Cc: "draft-ietf-tcpm-fastopen.all@tools.ietf.org" <draft-ietf-tcpm-fastopen.all@tools.ietf.org>
Subject: Re: [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: Mon, 31 Mar 2014 06:49:12 -0000

Hi Shawn,

Many thanks for your early SECDIR review!

I'll then move the document forward to the AD/IESG.

Best regards

Michael


________________________________
Von: Shawn M Emery [shawn.emery@oracle.com]
Gesendet: Montag, 31. März 2014 00:30
An: secdir@ietf.org
Cc: draft-ietf-tcpm-fastopen.all@tools.ietf.org; iesg@ietf.org
Betreff: Review of draft-ietf-tcpm-fastopen-08



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:

None.

Editorial comments:

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

Shawn.
--