On Wed, Aug 10, 2022 at 5:39 PM, Valery Smyslov <s...@elvis.ru> wrote:
> Please see inline. > > > > On Wed, Aug 10, 2022 at 4:37 PM, Valery Smyslov < <s...@elvis.ru>svan@ > 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). > Awesome, thank you very much for so quickly addressing my concerns - I have cleared my discuss and balloted Yes. Thanks again, W > > 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
