Martin Duke has entered the following ballot position for
draft-ietf-ipsecme-rfc8229bis-07: No Objection
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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
--
COMMENT:
--
Thanks to Joe Touch for the TSVART review. There are no showstoppers in this
document, but some non-normative text makes inaccurate statements about TCP and
RFC6040, and there are some odd decisions with respect to TLS that are worth
asking about:
(Sec 9.1)
"TCP-in-TCP can also lead to "TCP meltdown", where stacked instances
of TCP can result in significant impacts to performance
[TCP-MELTDOWN]. For the case in this document, such meltdown can
occur when the window size of the outer TCP connection is smaller
than the window sizes of the inner TCP connections. The resulting
interactions can lead to packets backing up in the outer TCP
connection's send buffers. In order to limit this effect, the outer
TCP connection should have limits on its send buffer size and on the
rate at which it reduces its window size."
Which "window" are you referring to? Receive window, congestion window, or the
send buffer? My reading of [TCP-MELTDOWN] is that the tunnel ingress should set
its send buffer size to the BDP of the tunnel, which is easier said than done.
It appears you are using "window" and "send buffer" interchangeably here in a
way that is confusing.
(9.5)
Implementations SHOULD follow the ECN compatibility mode for tunnel
ingress as described in [RFC6040]. In compatibility mode, the outer
tunnel TCP connection marks its packet headers as not ECN-capable.
If upon egress, the arriving outer header is marked with CE, the
implementation will drop the inner packet, since there is not a
distinct inner packet header onto which to translate the ECN
markings.
This is not an accurate summary of compatibility mode. In compatibility mode,
the outer packet is marked Not-ECT, which means it will not be marked CE. In
normal mode, the outer packet is marked as the inner, and this might result in
an outer CE marking.
It's a shame that there is no attempt to figure out a mapping between inner and
outer that would make normal mode work, as this reviewer is optimistic that ECN
marks will become increasingly important. But regardless, this section should
be clear and make correct statements.
(Appendix A) Why not provide an in-band way to determine TLS support? There
could be another port number, or different magic bytes to indicate that TLS
handshake messages follow.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
