Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt

[Yoav Nir <[e-mail]>]

Hi Valery

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

This loses the ability to use port forwarding to have a reachable TCP port (unless that port is 500), but I think the simplification justifies it.

Yoav


On Dec 11, 2012, at 2:16 PM, Valery Smyslov <[e-mail]> wrote:

> Hi,
> 
> I'm a bit uncomfortable with the requirement that IKE peer "MUST"
> advertise NAT device port if it is reachable and "MUST NOT"
> if it isn't. I think, that IKE Initiator in most cases cannot
> reliably determine whether it is reachable or not. For example,
> even if you manually configured port forwarding on your home
> network border NAT box and then configured IKE to advertise this
> port, that wouldn't imply that this port is actually reachable
> as your ISP may have another NAT and, as CGN become more
> common, number of those nested NAT's will increase.
> Even STUN might not be a good solution - it is pretty expensive in terms of round trips, requires the presence of STUN server in the same network segment as IKE Responder,  utilizes TLS and, most important, deals with UDP only (AFAIK).
> 
> So, I think that the requirement for IKE Initiator to advertise
> its support for TCP and port it thinks it is reachable at
> should be listed as "SHOULD" or even "MAY". Otherwise
> it sounds like a paradox - protocol requires IKE to do
> or not to do some action depending on condition that IKE in most cases is unable to determine.
> 
> Related issues.
> - in description to TCP Port field in IKE_TCP_SUPPORTED Notification    it is written that "If the sender is not subject to network address    translation, the port SHOULD be 500." Again, IKE Initiator
>   cannot reliably determine whether it is behind NAT or not.
>   It becomes clear only after initial request completes and
>   NAT_TRAVERSAL_*_IP are processed.
> - as it is quite possible that the port advertised by IKE Initiator
>   in IKE_TCP_SUPPORTED Notification is actually    not reachable, I think it is worth to mention, that if original
>   Responder after IKE SA is established wants to    make some request using TCP port advertised by
>   original Initiator and this port appears to be not reachable,
>   this Responder MUST NOT tear down IKE SA but MUST    instead fall back to UDP transport.
> 
> Regards,
> Valery Smyslov.
> 
> 
> Email secured by Check Point