Mirja Kühlewind has entered the following ballot position for charter-ietf-ipsecme-10-00: Block
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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Similar to Spencer's commet I have problems understanding what the following really means: "To make IKE work in these environments, IKE packets need to be encapsulated in a TCP tunnel. The group will define a mechanism to tunnel IKE and IPsec over a TCP-based connection. This method is intended to be used as a fallback when IKE cannot be negotiated over UDP. The group will create a method where IKEv2 and IPsec packets can be encapsulated in the TCP connection." Based on Tero's mail I understand how the stack looks like but that's not clear from the text because there is not really anything like a TCP tunnel. So the big question is, based on the stack indicated by Tero, do you have two full TCP connections running with two congestion control loops and retransmission mechanisms on two different endpoints? That's nothing I would recommend. I fully understand the need for a fallback mechanism to TCP but depending on what you actually aim for I'm not sure if this is the right wg for it; therefore my block for now. I hope we can resolve that quickly! _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
