Last Call Review of draft-ietf-ipsecme-tcp-encaps-09
review-ietf-ipsecme-tcp-encaps-09-tsvart-lc-eddy-2017-04-11-00

This document is clear and well-written.  It can easily be implemented based on
the description.

There are a few additional issues that should be considered with advice to
implementers in Section 12 on performance considerations: 1) Invisibility of
packet loss - Inner protocols that require packet losses as a signal of
congestion (e.g. TCP) will have a challenge due to not being able to see any
packet losses since the outer TCP will repair them (unless sending into a full
outer TCP socket buffer shows up back to the inner TCP as a packet loss?). 2)
Nesting of ECN -  Inner TCP connections will not be able to use effectively ECN
on the portion of the path covered by the outer TCP connection. 3) Impact of
congestion response on aggregate - The general "TCP in TCP" problem is
mentioned, and is mostly appropriate for a single flow.  If an aggregate of
flows is sharing the same outer TCP connection, there may be additional
concerns about how the congestion response behavior impacts an aggregate of
flows, since it may cause a shared delay spike even to low-rate flows rather
than distributing losses proportional to per-flow throughput. 4) Additional
potential for bufferbloat - Since TCP does not bound latency, some applications
in the IPsec-protected aggregate could drive latency of the shared connection
up and impact the aggregate of flows that may include real-time applications. 
The socket buffer for the outer TCP connection might need to be limited in size
to ensure some bounds?

Not addressing these could lead to poor experiences in deployment, if
implementations make wrong assumptions or fail to consider them.

In the security considerations section, there are several RFCs on mechanisms to
increase robustness to RST attacks and SYN floods that could be mentioned if
it's worthwhile.