Hi Yoav!
On 12/05/2012 11:41 AM, Yoav Nir wrote:
Hi Yaron
On Dec 5, 2012, at 9:59 AM, Yaron Sheffer <[email protected]>
wrote:
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 strongly disagree with this. As section 1.1 says, we are not trying
to create a protocol to subvert policy, and NATs are not generally a
tool for policy enforcement. They do, however, cause issues with
connecting to port 500 of a host that's behind them. If the host is
unreachable, it should not advertise its support for IKE over TCP. If
it uses STUN and friends so that it is reachable at the NAT address
on some port (usually referred to as "port forwarding") then it
should advertise that port. I think this would be implemented as a
configuration option, which you set after setting up the port
forwarding, but if there's an automated way of doing this, that would
also work, and I agree that we should not specify which it is.
I think we are saying the same thing here, and it's a question of
wording. The Initiator should not send the notification if it cannot be
reached (or does not want to be reached) for any reason at all.
- 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?
I'm not assuming that the original responder learns the IP address of
the original initiator by the source of the request. If it is so,
then we need something better like an SRV record.
Now I'm not following. If the original responder does not _learn_ the IP
address, then presumably the address is configured. In that case, you
might as well configure the port number, too, and be rid of the
advertising mechanism.
- Also, given the port advertising, do we still need the liveness
check described at the end of Sec. 3.2?
Sure. The liveness check clears the way and tests reachability for
IPsec, by using the same ports as IPsec.
OK.
Thanks, Yaron
_______________________________________________ IPsec mailing list
[email protected] https://www.ietf.org/mailman/listinfo/ipsec
Email secured by Check Point
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
