On Mon, 15 Oct 2012, Paul Hoffman wrote:
Greetings again. draft-ietf-ipsecme-ike-tcp-00.txt has been out for over a month and has received no discussion. Please review this short draft and comment on the mailing list.
Thanks for the reminder. I've read the draft and discussed it in Vancouver as well. I'm in favour of adopting it. Some notes, I know no one wants to define this for IKEv1, but I'd still prefer to keep this in sync between IKEv1 and IKEv2. I don't neccessarilly agree with the 1.1 non-goals. While I understand this is not done primarily to avoid administrative filters, I see no reason why to go out of our way to make it easy to filter IKE/IPsec. If IKE could signal a TCP port along with the IKE_TCP_SUPPORTED payload this would allow people so more freedom with running on different ports, or even kickstarting IKE over another protocol (instant message, whatever). I think the two octets are well spent for this. Should the initiator also send IKE_TCP_SUPPORTED to the responder? The initiator/responder roles could switch around at rekey, and it would be useful to the initial responder (now initiator) whether or not it can or should just start with TCP. Although it could deduce this from having received a connection on TCP in the previous exchange. I'm not sure on this one. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
