On Jun 7, 2012, at 8:26 PM, Nico Williams wrote: > On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: >> On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: >>> Also, if we are doing this, I'd prefer to be able to signal which tcp >>> port to use, to make it more flexible to bypass port 500 blocks (which >>> is part of the tcp 10000 implementation I believe) >> >> That seems fine to me. However, assuming that a firewall that blocks TCP/500 >> will not block TCP/somerandomnewnumber is not wise. > > Use port 80.
Well, we came up with IKE-over-TCP for clients in 2002. That worked OK with broken routers and NAT devices, but not with firewalls. So in 2003 we came up with sending both IKE and IPsec over port 443 (because at the time few firewalls other than ours validated that what goes on port 443 looks like SSL). Finally in 2005 we came out with a client that actually uses SSL for traffic, so that firewalls have to either be SSL proxies or do traffic flow analysis to recognize non-HTTPS. But this arms race between tunneling clients and firewalls is not the issue here. Without getting into the whole net neutrality controversy, ISPs are not supposed to, nor are they trying to block the creation of tunnels. What they are doing is saving themselves the need to keep state on received fragments, which allows better scale and better performance with the same hardware. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
