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

Yoav Nir <> Wed, 05 December 2012 09:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E89121F8CAC for <>; Wed, 5 Dec 2012 01:41:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.466
X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NiUOTrEYGmf2 for <>; Wed, 5 Dec 2012 01:41:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3345021F8C9F for <>; Wed, 5 Dec 2012 01:41:13 -0800 (PST)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id qB59f9vZ026292; Wed, 5 Dec 2012 11:41:09 +0200
X-CheckPoint: {50BF166F-2-1B221DC2-2FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 5 Dec 2012 11:41:08 +0200
From: Yoav Nir <>
To: Yaron Sheffer <>
Thread-Topic: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments
Thread-Index: AQHN0r5+hrRKPfFxi02auVilIkihkpgJ0kaA
Date: Wed, 05 Dec 2012 09:41:07 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11903f2e4d402ff5f18e12a665700b0558f9c538af
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <>
Subject: Re: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Dec 2012 09:41:15 -0000

Hi Yaron

On Dec 5, 2012, at 9:59 AM, Yaron Sheffer <> 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'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.

> - 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.

> Thanks,
>    Yaron
> _______________________________________________
> IPsec mailing list
> Email secured by Check Point