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

Yaron Sheffer <> Wed, 05 December 2012 10:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 434F721F86B5 for <>; Wed, 5 Dec 2012 02:55:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LL5I1cxFQGJO for <>; Wed, 5 Dec 2012 02:55:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 11ED221F86A3 for <>; Wed, 5 Dec 2012 02:55:34 -0800 (PST)
Received: by with SMTP id y2so4383844lbk.31 for <>; Wed, 05 Dec 2012 02:55:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6Y91SnPA0DpwaHiD8MsViHuZQMczTSLd4lyiPFdxBGA=; b=mYcdz9LPGkwJOphu1X4yv2Cvh4BwBGtwxq7PQC2Eg9rAIkmed/M58Aynfikb16QRHT eqIquGFsyqtY7u3GkzI3BufQ5Y/QAbFd6rFA5blnTU98kFGZLaXs9ue6G+nxMFwTGEdJ 9Jk3snnhqf0u5WLIxrUDZ5FRzETDOPqEllWQgKr7yC/S3HQN38CXCl6CC+rXefaliT8/ m6fvtBz35+j365gBLdNHQbr5yZAuQzEqPmoI5/djFk7Ml3Qus3Lsmb6ajgpfanx3wC9K YGrjo4LqLh/6elXbosCOH5VCIhFXvjGT2w29DL2pZeyPN0u+THeb0mgfQNGR2kXajUZc dXBA==
Received: by with SMTP id sn4mr16106731lab.57.1354704933905; Wed, 05 Dec 2012 02:55:33 -0800 (PST)
Received: from [] ([]) by with ESMTPS id oj5sm1852553lab.8.2012. (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 02:55:32 -0800 (PST)
Message-ID: <>
Date: Wed, 05 Dec 2012 12:55:29 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Yoav Nir <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 10:55:36 -0000

Hi Yoav!

On 12/05/2012 11:41 AM, Yoav Nir wrote:
> 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 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.

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