On Oct 16, 2012, at 5:14 AM, Paul Wouters wrote: > 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.
Well, you got it. It's already a working group draft. > 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 agree, and there's nothing stopping you (or me) from implementing this for IKEv1, but the group has spoken. See similar discussions about Brainpool curves. > 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. True. But do you think it's a common case, where the responder is behind a filter that drops TCP port 500, but that responder knows of a different port that is open? I suppose the responder could be behind some NAT device with the ability to map a forwarded port on the NAT device. I guess this makes sense. But then you have the initiator opening a connection to a random port. That has a far greater chance of getting filtered on the initiator side (firewalls tend to drop what they don't recognize). At least in our firewall, FTP got special treatment - the control connection is monitored to recognize and allow the ports that are used by the data connections, but I don't think we can expect the firewall makers repeat this effort for IKE with random ports. > 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. I guess, but rekey doesn't require TCP, as it doesn't have the IKE_AUTH exchange. It may be useful so that next time the original responder can begin the Initial exchange with TCP. > > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
