From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments
Thread-Index: AQHN0r5+hrRKPfFxi02auVilIkihkpgJ0kaA
Date: Wed, 5 Dec 2012 09:41:07 +0000
Message-ID: <4613980CFC78314ABFD7F85CC30277210EDD3BBB@IL-EX10.ad.checkpoint.com>
References: <50BEFEE5.9050900@gmail.com>
In-Reply-To: <50BEFEE5.9050900@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0406B6AEE995DB4FAEB8101BD069AF88@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments
Precedence: list

Hi Yaron

On Dec 5, 2012, at 9:59 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Hi,
>=20
> In general, it seems to me we are trying to solve more than we should, an=
d 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 r=
egistration.
>=20
> Specifically:
>=20
> - In the new text re: the Initiator sending IKE_TCP_SUPPORTED, I would ch=
ange "prevented... by network address translation" to "prevented by policy"=
. There are different ways to prevent a peer from being a responder, includ=
ing 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 cr=
eate a protocol to subvert policy, and NATs are not generally a tool for po=
licy enforcement. They do, however, cause issues with connecting to port 50=
0 of a host that's behind them. If the host is unreachable, it should not a=
dvertise 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 "po=
rt forwarding") then it should advertise that port. I think this would be i=
mplemented as a configuration option, which you set after setting up the po=
rt forwarding, but if there's an automated way of doing this, that would al=
so work, and I agree that we should not specify which it is.

> - I'm feeling uncomfortable with the rudimentary NAT bypass mechanism tha=
t we are proposing here: you're supposed to advertise a port number on anot=
her device (on the NAT box). I am sure there are loads of problems this wil=
l 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 t=
he source IP address of the initial IKE request?

I'm not assuming that the original responder learns the IP address of the o=
riginal initiator by the source of the request. If it is so, then we need s=
omething better like an SRV record.

> - Also, given the port advertising, do we still need the liveness check d=
escribed at the end of Sec. 3.2?

Sure. The liveness check clears the way and tests reachability for IPsec, b=
y using the same ports as IPsec.

>=20
> Thanks,
>    Yaron
>=20
>=20
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
> Email secured by Check Point