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. 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. I can only imagine why they do it, my guess is "just in case". 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. 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. 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
