[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-multi-sa-performance-08: 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-multi-sa-performance/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-multi-sa-performance-08 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus (including the 'competitive' draft) and the justification of the intended status. Other thanks to Tim Winters, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-ipsecme-multi-sa-performance-08-intdir-telechat-winters-2024-04-30/ I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Unbalanced ? It has been a long time since I worked with IPsec, but I have a small concern about this proposal: one peer will use its own selector/SADB to select a child SA and the associated SPI based on *local* state (e.g., CPU utilization) but the selected SA/SPI may end up on the remote peer on a heavily loaded CPU. If this is an issue, then should it be documented somewhere in this document (the remote can shuffle of course the SA among its CPUs)? ## Section 1 I am intrigued by the lack of linearity in the implementation result: 1 CPU -> 5 Gbps then 30 CPUs -> 60 Gbps (i.e., 2 Gbps/CPU). Some explanations would be appreciated + reference to the implementation itself. Does the amount of core per CPU have any impact ? `PFP is also not widely implemented.` a reference would be welcome as this statement does not appear to be based on facts (I do not dispute the validity of the statement). # NITS (non-blocking / cosmetic) ## Section 4 s/a 1RTT delay/a 1 RTT delay/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-ikev2-auth-announce-09: 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-ikev2-auth-announce/ -- COMMENT: -- # Éric Vyncke, INT AD, comments fordraft-ietf-ipsecme-ikev2-auth-announce-09 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract As the I-D is about authentication methods, I wonder whether `with multiple different credentials` is the right wording, should it rather be "different authentication methods" ? (of course with some text repetition). ## Section 3.1 `Regardless of whether the notification is received,` may be I am mis-reading this, but why would the responder send the notification if the initiator does not care anyway ? ## Section 3.2 While the readers may guess some details, but let's be clear in a proposed standard I-D: 1) `Notification Data field` does not appear in figure 4 2) role of C flag and its value 3) value of Protocol ID 4) saying that reserved field must be set to 0 by sender and ignored on the receiver ## Section 3.2.1 Let's be crisp and specify that the length is in octets. Is there a registry for authentication method ? or should this specification be updated for every new authentication method ? # NITS (non-blocking / cosmetic) ## Section 1 The last sentence of the 2nd paragraph is rather long and I think that "that" should be used in `the peer which supports wider range of`. ## Section 3.2.1 Missing closing parenthesis in the last paragraph. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-add-ike-11: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-add-ike-11: 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-add-ike/ -- COMMENT: -- Thank you for the work put into this document. It really helps to achieve the goals of the ADD WG :-) (only regret is that the IPSECME WGLC was not formally extended to the ADD WG, a little more of cross-WG collaboration is always welcome even if authors are also very active in ADD). Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Other thanks to Patrick Mevzek, the DNS directorate reviewer, please consider this dns-dir review: https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-11-dnsdir-telechat-mevzek-2023-04-04/ (and I have read Med's reply so all it good) and the previous https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-09-dnsdir-lc-mevzek-2023-03-16/ (and the authors/chairs have also replied) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) I second Paul Wouters' DISCUSS point #2 and Zahed's one (even if this may be the IPSECME WG usual process, it is not the IETF process). ## Section 1 In the discussion about private CA / address for the DNS resolver, one more sentence stating the obvious (when using a private CA then the client may use the digest info payload) would be welcome. Alternatively, moving this paragraph before the reference to the appendix will make it clearer the link with ENCDNS_DIGEST_INFO. ## Section 2 Should RFC 8499 be normative (note RFC 7296 is normative and used in the same way)? ## Section 3.2 What is the responder behaviour when receiving a CFG_REQUEST with "ADN Length" different from 0 ? Symmetrical case for the initiator when "Num Hash Algs" is not 1 in a CFG_SET. If the generic behaviour described in section 4 (`As a reminder, badly formatted attributes or unacceptable fields are handled as per Section 2.21 of [RFC7296].`), then why other fields (notably "R") have specific text ? The reminder of section 4 should rather be in section 3 (but this is a matter of taste). `Note that SHA2-256 is mandatory to implement` does this mean that SHA2-256 identifier *MUST* always be in the list or is it implicit and does not have to be in the list ? # NITS (non-blocking / cosmetic) ## Appendix A.1 No need to expand VPN as it is both well-known and used before without expansion ;) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-labeled-ipsec-11: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-labeled-ipsec-11: 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-labeled-ipsec/ -- COMMENT: -- Thank you for the work put into this document. It is easy to read and can be useful is specific use cases. 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 and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## SPD interaction While this I-D is about IKEv2, there is little mention of interaction with IPsec SPD beside "pass the TS to the SPD". I wonder whether there must be more than a simple "pass to the SPD" operation on the responder side as the TS is opaque to IKE, so it is SPD/IPSEC that must decide whether to accept this TS, i.e., it is more than a unilateral "pass" operation. ## Section 2.2 `an Error Notify message containing TS_UNACCEPTABLE MUST be returned.` should the obvious be stated, i.e., the process stop and the proposal is not accepted ? ## No IPv6 examples in 2023 ? Examples are always interesting and useful, but why not using IPv6 ? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-ikev2-multiple-ke-10: 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-ikev2-multiple-ke/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-ikev2-multiple-ke-10 CC @evyncke Thank you for the work put into this document. Even if my IPsec knowledge is now very dated, I find it relatively easy to read. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tero Kivinen for the shepherd's write-up including the WG consensus *but* the justification of the intended status is missing. Other thanks to Geoff Huston for his Last Call DNS directorate review at: https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-10/ Please note that Charles Perkins is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Charles will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/reviewrequest/16618/ I hope that this review helps to improve the document, Regards, -éric ## COMMENTS Out of all Paul Wouters's points, I support the last one about AH (I am not experience enough to appreciate the other ones). It is also related to bullet 3) of section 2. ### Missing reference RFC 8247 As indicated by idnits tool, RFC 8247 is used as a reference but is not defined ;-) ### Section 2 The bullet 2) is a nice explanation about *why* there must be multiple key exchanges with different methods. Until reading that part, I was really wondering why this I-D was about the link with PQC and multiple key exchanges. Should this be mentioned in the abstract already ? Should "FIPS" be prefixed by "USA" as in "USA FIPS" ? ## NITS ### Section 1.2 `payloads longer than 64k` suggest to specify the units of measure. ## 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
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-mib-iptfs-07: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-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-mib-iptfs/ -- COMMENT: -- Thank you, Don, for quickly addressing my DISCUSS and COMMENT points from my ballot. I sincerely hope that this discussion has improved the document. Please do not forget to also update the tree with the right OID prefix ;-) but I am trusting you and the AD, Roman. For archive: the previous DISCUSS ballot is at https://mailarchive.ietf.org/arch/msg/ipsec/sbb3MSPy8XwkHPIZCNt9ZRCd6BQ/ Regards -éric ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-mib-iptfs-06: (with DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-06: 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/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-mib-iptfs/ -- DISCUSS: -- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-mib-iptfs-06 CC @evyncke Thank you for the work put into this document (even if I am balloting a DISCUSS); Please find below one blocking DISCUSS points (easy to address), 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. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Inconsistent intended status & use of experimental code point This document is standard track, but the OID used in section 4.1 is 'experimental' and in section 4.2 `experimental 500` per https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml. Please request IANA to assign an OID from the 1.3.6.1.2.1 tree. -- COMMENT: -- ## COMMENTS ### Section 1 ``` Note an IETF MIB model for IPsec was never standardized however the structures here could be adapted to existing MIB implementations. ``` Perhaps clarify "existing MIB implementations" ? I guess this is about proprietary IPsec MIBs, but clarification will be welcome. ### Section 4.2 Should the construct with `` be used to allow for easy file extraction ? `mailto:ekinzie.labn.net` is probably wrong ;-) `l2FixedRate`and `l3FixedRate` have 'counter64' type, RFC 2578 section 7.1.10 defines this type as monotically increasing. I understand that there are no interger64 in RFC 2578 but why not using a different unit than 'bps' for those two items ? ### Section 5 The IANA section should probably follow more closely RFC 8126, notably specifying the right registry (e.g., "SMI Network Management MGMT Codes Internet-standard MIB") ### Section 8.1 Unsure whether I-D.ietf-ipsecme-yang-iptfs (and perhaps I-D.ietf-ipsecme-iptfs) is a normative reference (i.e., I can implement this I-D MIB without accessing the YANG module). ## NITS ## 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
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-iptfs-19: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-iptfs-19: 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-iptfs/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-iptfs-13 CC @evyncke Thank you for the work put into this document and the quick reactions on my original DISCUSS ballot on -14. Having a proper IP protocol number is the right way to proceed. I am still uneasy with the ICMP text though, but not to point of blocking this document any further. I have now cleared my DISCUSS. I was about to ballot ABSTAIN because I am still concerned about the ICMP processing, about not specifying a generic tunnel rather than something specific to IPsec, but this does not fit the ABSTAIN per https://www.ietf.org/standards/process/iesg-ballots/, hence my no objection. My previous COMMENTS are still there as most of them have not been replied/addressed AFAIK, this is non blocking, but the intent of those COMMENTS is to improve the document quality. The same applies for Antoine Fressancourt’s review https://mailarchive.ietf.org/arch/msg/ipsec/4u9zP9mkITwUWPfjPBg_abo4r54/ A reply by the authors will also be welcome. Please find below *for archiving only* my DISCUSS points, some non-blocking COMMENT points, and some nits. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus, alas the justification of the intended status is missing :-( Please note that Tatuya Jinmei is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well: https://datatracker.ietf.org/doc/review-ietf-ipsecme-iptfs-13-intdir-telechat-jinmei-2022-08-18/ I hope that this review helps to improve the document, Regards, -éric ## Previous DISCUSS kept for archiving As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Section 6.1 ``` An AGGFRAG payload is identified by the ESP Next Header value AGGFRAG_PAYLOAD which has the value 0x5. The value 5 was chosen to not conflict with other used values. The first octet of this payload indicates the format of the remaining payload data. ``` This is in direct conflict with RFC 4303 (see below) IMHO as 5 is already allocated to ST (RFC 1819, which is still 'current' even if it was never used). But ESP RFC 4303 section 2.6 says that this is an IP protocol number (and 5 is already allocated by the IANA): ``` The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP. ``` I.e., either this document needs to formally update RFC 4303 by allowing any number or another IP protocol number must be requested to the IANA. ### Section 2.1, generic tunnel capability ``` Other non-IP-TFS uses of this AGGFRAG mode have been suggested, such as increased performance through packet aggregation, as well as handling MTU issues using fragmentation. These uses are not defined here, but are also not restricted by this document. ``` Moreover, while IPSECme charter includes: ``` The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. ``` it says nothing about a generic tunnelling protocol, which is usually INTAREA topic, and I cannot refrain from thinking that this tunnelling mechanism could be used on any connection-less transport, e.g., UDP or IP. Hence, this DISCUSS point is only to initiate a discussion with IPSECME chairs and AD; Christian Hopps has already given some explanations when I deferred this I-D. I understand that I am in the rough here (no reaction on int-area and int-dir review is positive). ### Section 2.2.6 Please also mention hop-limit and RFC 8200. ### Absence of ICMP considerations Should there be an equivalent of section 6 of RFC 4301 about ICMP ? As several unprotected
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-yang-iptfs-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-yang-iptfs-10: 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-yang-iptfs/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-yang-iptfs-08 CC @evyncke Thank you for the work put into this document and for addressing my previous DISCUSS and COMMENT points (kept below for archiving only) Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus even if there is no justification for the intended status. I hope that this review helps to improve the document, Regards, -éric ## Previous DISCUSS kept for archiving As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Section A.2 wrong prefix size ? ``` 2001:DB8::0/16 2001:DB8::1:0/16 ``` Beside the lack of RFC 5952 (see my comment below), is it on purpose that both prefix with a /16 are identical ? The authors probably mean a different prefix size rather than /16. ## Previous COMMENTS kept for archiving ### Useless BCP 14 template ? As indicated by id-nits, the BCP 14 template is included but there is no normative 'upper case' language in the document. ### Section A.2 Please ensure to follow RFC 5952 to represent IPv6 addresses, i.e., lowercase and maximum 0 compression. ## NITS ### Spelling of yang s/yang/YANG/ at least in the abstract. ## 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
[IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-yang-iptfs-08: (with DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-yang-iptfs-08: 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/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-yang-iptfs/ -- DISCUSS: -- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-yang-iptfs-08 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points (very easy to address ;-) ), some non-blocking COMMENT points (also very easy to fix), and some nits. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus even if there is no justification for the intended status. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Section A.2 wrong prefix size ? ``` 2001:DB8::0/16 2001:DB8::1:0/16 ``` Beside the lack of RFC 5952 (see my comment below), is it on purpose that both prefix with a /16 are identical ? The authors probably mean a different prefix size rather than /16. -- COMMENT: -- ## COMMENTS ### Useless BCP 14 template ? As indicated by id-nits, the BCP 14 template is included but there is no normative 'upper case' language in the document. ### Section A.2 Please ensure to follow RFC 5952 to represent IPv6 addresses, i.e., lowercase and maximum 0 compression. ## NITS ### Spelling of yang s/yang/YANG/ at least in the abstract. ## 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
[IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-iptfs-14: 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/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-iptfs/ -- DISCUSS: -- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-iptfs-13 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus, alas the justification of the intended status is missing :-( Please note that Tatuya Jinmei is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well: https://datatracker.ietf.org/doc/review-ietf-ipsecme-iptfs-13-intdir-telechat-jinmei-2022-08-18/ I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Section 6.1 ``` An AGGFRAG payload is identified by the ESP Next Header value AGGFRAG_PAYLOAD which has the value 0x5. The value 5 was chosen to not conflict with other used values. The first octet of this payload indicates the format of the remaining payload data. ``` This is in direct conflict with RFC 4303 (see below) IMHO as 5 is already allocated to ST (RFC 1819, which is still 'current' even if it was never used). But ESP RFC 4303 section 2.6 says that this is an IP protocol number (and 5 is already allocated by the IANA): ``` The Next Header is a mandatory, 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an IPv4 or IPv6 packet, or a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 indicates TCP. ``` I.e., either this document needs to formally update RFC 4303 by allowing any number or another IP protocol number must be requested to the IANA. ### Section 2.1, generic tunnel capability ``` Other non-IP-TFS uses of this AGGFRAG mode have been suggested, such as increased performance through packet aggregation, as well as handling MTU issues using fragmentation. These uses are not defined here, but are also not restricted by this document. ``` Moreover, while IPSECme charter includes: ``` The demand for Traffic Flow Confidentiality has been increasing in the user community, but the current method defined in RFC4303 (adding null padding to each ESP payload) is very inefficient in its use of network resources. The working group will develop an alternative TFC solution that uses network resources more efficiently. ``` it says nothing about a generic tunnelling protocol, which is usually INTAREA topic, and I cannot refrain from thinking that this tunnelling mechanism could be used on any connection-less transport, e.g., UDP or IP. Hence, this DISCUSS point is only to initiate a discussion with IPSECME chairs and AD; Christian Hopps has already given some explanations when I deferred this I-D. I understand that I am in the rough here (no reaction on int-area and int-dir review is positive). ### Section 2.2.6 Please also mention hop-limit and RFC 8200. ### Absence of ICMP considerations Should there be an equivalent of section 6 of RFC 4301 about ICMP ? As several unprotected packets can be bundled together, some guidance to the implementers will be welcome. -- COMMENT: -- ## COMMENTS ### Yet another fragmentation above layer 3 No need to reply on this comment, but I cannot refrain from wondering how many fragmentation mechanisms above layer 3 have been specified by the IETF... We could end up running this specification over IPsec over TCP ;-) ### draft-templin-intarea-parcels Are the authors/WG aware of draft-templin-intarea-parcels ? This draft was not adopted by intarea (lack of interest mainly) but also aggregates packets into "parcels". Christian has already replied to this comment when I deferred the IESG evaluation. This is only kept for archiving. ### Section 1 s/(indicated
[IPsec] Éric Vyncke's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)
É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
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-ikev2-intermediate-09: 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-ikev2-intermediate/ -- COMMENT: -- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Yoav Nir for the shepherd's write-up including the section about the WG consensus. I hope that this helps to improve the document, Regards, -éric ## Abstract The abstract would benefit by adding a few use cases / applicability statement (per the shepherd's write-up and introduction, i.e., a hint for PQ crypto). ## Section 1 s/If size of a message is large enough, IP fragmentation takes place/If size of a message is larger than the MTU, IP fragmentation takes place/ RFC 7383 is dated 2014, is it still applicable in 2022 ? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-ipv6-ipv4-codes-05: 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/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-ipv6-ipv4-codes/ -- COMMENT: -- Bonjour Med, Thank you for the work put into this document. The shepherd write-up is really terse but reflects that it was a rough consensus. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- The one-line abstract does not really explain/summarize what this document is about. E.g., nothing is mentioned about 3GPP origin. Expanding the abstract with something like "by allowing the responder to signal to the initiator which address families are supported". -- Section 1 -- The sentence "When the UE attaches the network using a WLAN access by means of IKEv2 capabilities, there are no equivalent notification codes ..." looks cryptic to me. What is the link with WLAN access and IKEv2 ? -- Section 5 -- "If a dual-stack initiator requests only an IPv6 prefix (or an IPv4 address) but only receives IP4_ALLOWED (or IP6_ALLOWED) notification status type from the responder, the initiator MUST send a request for IPv4 address(es) (or IPv6 prefix(es))." Is it really a "MUST" and not a "SHOULD" or even "MAY" ? A constrained UE may have IPv6-only applications and, even if OS is dual-stack, not bothers to have a useless IPv4 address. The paragraph after this one mimics the 3GPP PDP behavior, but, does it make sense for IKEv2 ? == NITS == In several places, the word "responder" is misspelled. In some places, a ':' is followed by a capitalized word which looks weird to my French-reading eyes... ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-qr-ikev2-10: 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/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-qr-ikev2/ -- COMMENT: -- Thank you for the work put into this document. I found it very interesting to read BTW. I have only one minor non-blocking comment: please read RFC 8126 to have a correct IANA section about "type 16435" (and others). Same applies for section 5.1. I hope that this helps to improve this document or any future one of yours, Regards, -éric ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's No Objection on charter-ietf-ipsecme-12-00: (with COMMENT)
Éric Vyncke has entered the following ballot position for charter-ietf-ipsecme-12-00: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ -- COMMENT: -- While I have no objection to the charter, I would suggest to coordinate to compressed ESP/IKEv2 of this charter with the compression work done in LPWAN (mainly or only for the non-encrypted parts). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-implicit-iv-08: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-08: 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/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-implicit-iv/ -- COMMENT: -- Thank you for addressing the DISCUSS and my COMMENTS. I leave my previous comments here for log purpose == COMMENTS == -- Section 5 -- C.1) "inside the SA Payload" probably worth being a little more descriptive here (for instance, "SA payload in the IKE exchange" ?). Also suggest to use "IKE Initiator Behavior" for the section title. -- Section 8 -- C.2) please use the usual text for IANA considerations (notably asking IANA to register as this is not this document that registers the codes). == NITS == In several places, s/8 byte nonce/8-byte nonce/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-implicit-iv-07: 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-implicit-iv/ -- DISCUSS: -- Thank you for the work put into this document. I am trusting the security AD to check whether it is safe not to have a 'random' IV. I have one trivial-to-fix DISCUSS and a couple of COMMENTs. It is also unclear at first sight whether the 'nonce' built from the sequence number is actually the IIV. Regards, -éric == DISCUSS == -- Section 1 -- D.1) Please use the RFC 8174 template ;) -- COMMENT: -- == COMMENTS == -- Section 5 -- C.1) "inside the SA Payload" probably worth being a little more descriptive here (for instance, "SA payload in the IKE exchange" ?). Also suggest to use "IKE Initiator Behavior" for the section title. -- Section 8 -- C.2) please use the usual text for IANA considerations (notably asking IANA to register as this is not this document that registers the codes). == NITS == In several places, s/8 byte nonce/8-byte nonce/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
