Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-rfc8229bis-07: Yes
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: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-rfc8229bis-07 CC @evyncke Thank you for the work put into this document. There must be several use cases for it. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus, but it lacks the justification of the intended status. Thanks as well to Brian Haberman for his INT directorate review, his review has a 'ready' status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### UDP blocked even with QUIC As there are more and more traffic relying on QUIC (a wild guess of mine...), is it still the case that middle boxes are blocking UDP ? Just out of curiosity... feel free to ignore. ### Section 1 ``` Devices on these networks that need to use IPsec (to access private enterprise networks, to route Voice over IP calls to carrier networks, or because of security policies) are unable to establish IPsec SAs. ``` The above appears like an exhaustive list while it is not. Suggest to add ", etc.". ### Section 1 `Some peers default to using UDP encapsulation` is "peer" so well-defined in the IPsec world ? 'some' is also rather vague, perhaps cite one implementation ? or use "some peers may default to" ? ### Section 2 Should "Implementations of this specification" be used in `Implementations MUST support TCP encapsulation on TCP port 4500, which is reserved for IPsec NAT traversal.` ? ### Section 3 No AH Even if AH is nearly no more used, I wonder whether there is a reason why AH is not supported by this I-D. The sentence about AH should really come earlier in the document. ### Section 3 ``` Although a TCP stream may be able to send very long messages, implementations SHOULD limit message lengths to typical UDP datagram ESP payload lengths. ``` What is the 'typical' length ? ### Section 3.1 Suggest to add a description of "Non-ESP" header field below the description of the "length" field rather than in the text above. ### Section 5.1 `Since UDP is the preferred method of transport for IKE messages,` hem... previous text (and common sense) stated that direct is the preferred method. ### Section 6.1 what about IP address changes ? ``` Since new TCP connections may use different ports due to NAT mappings or local port allocations changing, the TCP Responder MUST allow packets for existing SAs to be received from new source ports. ``` For some NAT devices (or IPv6 nodes w/o NAT but with temporary addresses), the IP address could also change. This document should describe what to do in this case. ### Section 6.5 The very last sentence deserves a paragraph on its own. ### Section 6.7 Please add that the DF bit is obvioulsy only for IPv4 (Hi, Tommy, I had to insert my mandatory IPv6-related comment ;-) ) ### Section 9.3 I am not a transport person, but I would have used "MUST NOT" rather than "MAY NOT" in: ``` Individual packets SHOULD NOT use different markings than the rest of the connection, since packets with different priorities may be routed differently and cause unnecessary delays in the connection. ``` Even if somehow obvious, should there be a statement about the IPv6 Flow-ID header field ? ### TCP Fast Open support Is TCP fast open supported by this doc ? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
