[IPsec] draft-ietf-ipsecme-ike-tcp-01 comments

[Yaron Sheffer <[e-mail]>]

Hi,

In general, it seems to me we are trying to solve more than we should, 
and we should punt on some of the NAT use cases, leave them to 
configuration or to out-of-protocol solutions like STUN and friends. 
Maybe even DNS SRV registration.

Specifically:

- In the new text re: the Initiator sending IKE_TCP_SUPPORTED, I would 
change "prevented... by network address translation" to "prevented by 
policy". There are different ways to prevent a peer from being a 
responder, including firewalls, NAT or plain configuration. All should 
be included here.

- I'm feeling uncomfortable with the rudimentary NAT bypass mechanism 
that we are proposing here: you're supposed to advertise a port number 
on another device (on the NAT box). I am sure there are loads of 
problems this will open up. Here's one: if we're talking about a very 
large NAT device (one that uses multiple public addresses), isn't it 
possible that the IP address allocated for the static NAT of the IKE 
listening port is different from the source IP address of the initial 
IKE request?

- Also, given the port advertising, do we still need the liveness check 
described at the end of Sec. 3.2?

Thanks,
     Yaron