[IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)
Warren Kumari 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: -- Thank you for addressing my DISCUSS! I think that this document is both cool and useful ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-multi-sa-performance-06: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-multi-sa-performance-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-multi-sa-performance/ -- DISCUSS: -- Be ye not afraid -- see https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ on handling ballots, especially DISCUSS ballots... A DISCUSS is a request to have a discussion, and this is especially true in this case, because my mental model is somewhat hazy here... The document talks about negotiating multiple "Child SAs with the same Traffic Selectors". In my mental model, this looks sort of analogous to multiple parallel paths. The document doesn't seem to discuss how implementations should share traffic across these "paths" -- should it do something like ECMP and hash to try and keep packets in a flow tied to the same CPU? Or is this something that is done automatically by the OS already (e.g because the existing L3 logic would just view these as parallel links) and it already knows what to do? Or is this something that IPSEC implementations handle themselves? Or is my mental model so broken that my question doesn't even make sense? The document also says that "if an implementation finds it needs to encrypt a packet but the current CPU does not have the resources to encrypt this packet, it can relay that packet to a specific CPU that does have the capability to encrypt the packet, although this will come with a performance penalty.". Cool... but does this lead to the potential of out of order packets? Is that what the "this will come with a performance penalty" is implying (in which case I'd suggest being a bit more explicit). -- COMMENT: -- I think that this document is both cool and useful -- my discuss ballot is because I'd like to better understand how this works ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Yes on draft-ietf-ipsecme-labeled-ipsec-11: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-labeled-ipsec-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-labeled-ipsec/ -- COMMENT: -- Thank you for this document - I had a few minor nits and suggestions. Feel free to address, or not (they are just editorial suggestions). 1: "For example a Traffic Selector of TS_TYPE TS_IPV4_ADDR_RANGE for UDP traffic in the IP network 198.51.100.0/24 covering all ports, is denoted as (17, 0, 198.51.100.0-198.51.100.255)" As this is an introductory example, I think it would be helpful to explain where the numbers (17, 0) come from -- e.g "For example a Traffic Selector of TS_TYPE TS_IPV4_ADDR_RANGE for UDP (IP protocol 17) traffic in ..." or similar. Huh. It turns out that I only had one nit/suggestion, so s/had a few minor nits and suggestions/a suggestion/ :-P ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-ikev1-algo-to-historic-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-ikev1-algo-to-historic/ -- DISCUSS: -- Be ye not afraid -- see https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ on handling ballots, especially DISCUSS ballots... Can the IETF actually deprecate / make a protocol historic? (as stated in "Internet Key Exchange version 1 (IKEv1) has been deprecated" and "IKEv1 has been moved to Historic status.") I agree that **making the documents that describe these** be historic is the right thing to do, and also that the IETF can strongly recommend that people don't use/deploy/whatever IKEv1, but I don't really know if we (or anyone) have the power to deprecate a protocol. We are not the protocol police, and we cannot instruct people to e.g deploy protocol foo, so I don't know if we can deprecate a protocol either -- but I suspect that this might be because I don't actually know what "IKEv1 has been deprecated" actually *means*. Again, I'm not trying to block what this document is attempting to *do*, but rather make it clear what it is actually doing. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
Warren Kumari 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: -- Thank you for writing this document (and also making it easy for someone like me to understand :-)) Also thanks to Geoff Huston for his DNSDOR review (https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-10/) I have a few non-blocking comments -- feel free to address them or not. I think that moving Section 2, Bullet 2 towards to top of the document would help the reader better understand why this document exists... 1: "While solving such a problem remains difficult with current computing power, it is believed that general purpose quantum computers will be able to solve this problem, implying that the security of IKEv2 is compromised." 'solving such a problem remains difficult with current computing power' implies that they *can* be solved with current computing power, while 'it is *believed* that general purpose quantum computers will be able to solve this problem' implies that quantum only *might* be able to solve them...this makes it sound like quantum machines are less of a concern than current ones :-). Perhaps 'general purpose quantum computers will *easily* be able to solve this problem'? Or 'solving such a problem is infeasible with current computing power'? (handwaving away trivial parameters) My suggestion isn't great, but hopefully I've managed to explain my concern? 2: Design Criteria - 3) Focus on post-quantum confidentiality. I understand what this is trying to say, but it feels very disjointed. I don't really have any suggested test to fix it, but just dropping the last sentence (or folding it into an earlier one) would make it much much easier to read. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-iptfs-17: 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: -- [ Chat with Christian Hopps on the telechat -- I explained my concerns and Christian will add some text around how to deploy this safely / some background context. Even if you are the network admin and in complete control of the network, having some "here are some things to keep in mind when deploying, like that that will ALWAYS use the configured bandwidth so make sure you will always have that free during failures and congestion and things like that..." type warnings are helpful. ] Clearing my discuss. -- COMMENT: -- Much thanks to Bo Wu for the OpsDir review, and to the authors for addressing / incorporating the comments. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-yang-iptfs-09: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-yang-iptfs-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-yang-iptfs/ -- COMMENT: -- Thank you very much to the authors and WG for this document, and to the OpsDir reviewer (Sarah Banks) for the OpsDir review. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Warren Kumari 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: -- I supporting Lars' DISCUSS points, especially that around Section 2.4.1, paragraph 3: The packet send rate is constant and is not automatically adjusted regardless of any network congestion (e.g., packet loss). For similar reasons as given in [RFC7510] the non-congestion- controlled mode should only be used where the user has full administrative control over the path the tunnel will take. This is required so the user can guarantee the bandwidth and also be sure as to not be negatively affecting network congestion [RFC2914]. In this case, packet loss should be reported to the administrator (e.g., via syslog, YANG notification, SNMP traps, etc.) so that any failures due to a lack of bandwidth can be corrected. This is a largely unrealistic requirement -- unless you are specifically meaning "a bump-in-the-wire deployment over a point to point link" users fairly much never have control over the path that the tunnel will take. At some point the primary path **will** go down, and the tunnel will route over some backup path, most likely at 3AM on the Sunday that the CEO's daughter is getting married... It what you are describing really is "only ever use this as a bump-in-the-wire over a PtP interface" or "make sure that the configured bandwidth is many many magnitudes smaller than the smallest link in the network, even when congested", then please state that instead. As written, this text seems dangerous: you are basically handing an enterprise network admin a DoS cannon and washing your hands of the consequences. -- COMMENT: -- Much thanks to Bo Wu for the OpsDir review, and to the authors for addressing / incorporating the comments. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT)
Warren Kumari 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: -- Thank you very much for addressing my DISCUSS concerns. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-rfc8229bis-07: (with DISCUSS)
Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-rfc8229bis-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/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/ -- DISCUSS: -- Do not panic! This should be trivial to address, probably by pointing me at something that I missed (very likely), or by dropping in a sentence to two into the document. The document starts off with: "This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP." As far as I can tell (and again, it is likely that I missed something!) it doesn't really discuss the fact that the operator may be intentionally blocking IKE. For example, many enterprises really don't want their users to be building IPSec tunnels into/out of their network because they want to do DLP, firewalling, and so they block IKE to block IPSec. This may be a flawed concept, and you and I may think that it's a losing battle, but I really think that the document needs to at least discuss that this potentially bypasses intentional security controls. See: https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
