Early Review of draft-ietf-tcpm-fastopen-08
review-ietf-tcpm-fastopen-08-secdir-early-emery-2014-04-03-00

Request Review of draft-ietf-tcpm-fastopen
Requested rev. no specific revision (document currently at 10)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2014-08-19
Requested 2014-03-13
Draft last updated 2014-04-03
Completed reviews Genart Last Call review of -09 by Meral Shirazipour (diff)
Genart Telechat review of -09 by Meral Shirazipour (diff)
Secdir Early review of -08 by Shawn Emery (diff)
Assignment Reviewer Shawn Emery
State Completed
Review review-ietf-tcpm-fastopen-08-secdir-early-emery-2014-04-03
Reviewed rev. 08 (document currently at 10)
Review result Has Nits
Review completed: 2014-04-03

Review
review-ietf-tcpm-fastopen-08-secdir-early-emery-2014-04-03












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