On Fri, 14 Dec 2012, Valery Smyslov wrote:
Thinking it over, I kind of regret adding the port field to the
TCP_SUPPORTED notification.
We don't have any mechanism for alternate UDP ports. Yes, UDP has cheap
liveness checks
to keep the mapping in the NAT so that requests can be initiated to the
original initiator, while TCP does not.
But your points are well taken. Leaving the advertised TCP port to
configuration or auto-discovery is error
prone and adds unnecessary complications to the protocol.
I propose that:
1. We remove the port from the Notify
2. All connections will be done to port 500.
3. We warn against trying to use TCP to a peer behind NAT
That's too bad, but I agree it added a lot of complexity. What is the
blocking rate for TCP 500 in the wild? And does anyone know why Cisco
moved to port 10000? A higher port does seem to have a better chance
at not being blocked.
Fully agree. And in this case please add the following to the list:
4. We remove TCP_SUPPORTED notification from Initiator's message
(as it becomes redundant for most use cases).
So if the responder falls back to TCP, and later becomes the initiator,
should it assume TCP 500 is available, or do we go through another round
of udp fail to tcp? As implementor, I see no issue remembering TCP is
supported as longe as we have a parent SA. We don't need the TCP_SUPPORTED
notification in the original initiator for that. But firewall rules
might not be symmetric, and an outgoing TCP might work while an incoming
TCP is blocked. But I guess if UDP isn't working well, there is not much
choice left but try TCP.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
