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
