[IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ipsecme-tcp-encaps-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This draft suggests that ports that are assigned to other services can
simply be used. This is not okay. If a port is assigned to a certain
service, this service and/or the respective RFC defines how this port is
used. Simply changing the specified behavior by requiring a check for a
magic number cannot be done without updating the RFC that the port
assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
the IANA registry would need to be updated.

Further, as also mentioned in the tsv-art review (Thanks Wes!), this
draft does not sufficiently handle the case of TCP in TCP encapsulation.
Here a copy of the tsv-art review:

Reviewer: Wesley Eddy
Review result: On the Right Track

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.