Please see inline.
On Wed, Aug 10, 2022 at 4:37 PM, Valery Smyslov < <mailto:s...@elvis.ru> s...@elvis.ru> wrote: Hi Warren, thank you for this discussion, please see inline. 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! By no means :-) 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. This document is not intended to provide a mechanism to bypass intentional security controls. Excellent! In most cases IKE is blocked not because operators want do DLP etc., but because operators of small hotels, cafe, internet kiosks often block all UDP except DNS and sometimes block all TCP except http / https too. Yup. I can only imagine why they do it, my guess is "just in case". Yup, agreed. This is a real problem and our experience shows that it's impossible to solve by an IPsec user who appeared in the situation when UDP is blocked in a hotel he stayed in. Oh, yeah, I fully agree. Operators wanting to block IKE because of security implications may also block TCP port 4500 and use DLP to filter out TCP streams started with IKETCP, so they can deal with this specification. Yes, yes they can — but I suspect that many currently aren't. What would satisfy me would be something like a sentence saying something along the lines of "Operators who intentionally want to block IKE because of security implications should also block TCP port 4500 and use DLP to filter out TCP streams started with IKETCP". This seems like a simple addition to help prevent people shooting themselves in the foot (or, at least that we can point to if they do :-)) I've added the following text at the end of the Middlebox Considerations section: Operators who intentionally block IPsec because of security implications may want to also block TCP port 4500 or use DLP to filter out TCP connections started with IKETCP stream prefix. Is it OK? (Tommy will review the changes, so he may want to make some additional tweaks). Regards, Valery. W Besides, there may be future IKE extensions that rely on TCP transport (e.g. for transferring large PQ public keys, see draft-tjhai-ikev2-beyond-64k-limit). In this case TCP is used not because UDP is blocked, but because sending 1MB data over UDP with no congestion control is not a good idea. This is not yet a WG document, so it is not referenced in the draft, but we keep it in mind. Hope this helps. Regards, Valery. 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
