On Wed, Aug 10, 2022 at 4:37 PM, Valery Smyslov <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 :-)) 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
