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
