Yoav Nir writes: > 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).
If initiator is behind NAT and uses some of those protocols to talk to the NAT / FW and request a TCP port that will get forwarded to it then this sending that port number inside the IKE notify payload would be useful, in case the responder ever needs to reconnect back to him. Also quite often firewalls have been set up so that all incoming connections not explicitly allowed are forbidden, but all outgoing connections not expiicitly forbidden are allowed. Now when the initiator sets up the TCP listener port by talking to the NAT / FW, then responder can connect to that port if needed, and responders NAT / FW most likely will allow responder to connect to that port without any special configuration. > 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. This is because firewalls try to do this without the help of the FTP client / server. There are now protocols which allows client / servers to connect to the NAT / FW and ask for this kind of services, thus there is no need for NAT / FW to look inside the data packets and find out the 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. You are assuming that only reason to use TCP is because the IKE_AUTH packet is so big it gets fragmented. There has been also some comments that using TCP also helps going through NAT / FW boxes, in which case TCP is required to do any exchanges. I have not read the latest version, it is on my todo list, I will get back with more specific comments when I have time to read it. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
