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

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 05 December 2012 10:55 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434F721F86B5 for <ipsec@ietfa.amsl.com>; Wed, 5 Dec 2012 02:55:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL5I1cxFQGJO for <ipsec@ietfa.amsl.com>; Wed, 5 Dec 2012 02:55:35 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11ED221F86A3 for <ipsec@ietf.org>; Wed, 5 Dec 2012 02:55:34 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so4383844lbk.31 for <ipsec@ietf.org>; Wed, 05 Dec 2012 02:55:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.152.144.164 with SMTP id sn4mr16106731lab.57.1354704933905; Wed, 05 Dec 2012 02:55:33 -0800 (PST)
Received: from [10.0.0.13] ([93.173.108.159]) by mx.google.com with ESMTPS id oj5sm1852553lab.8.2012.12.05.02.55.31 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 02:55:32 -0800 (PST)
Message-ID: <50BF2821.2020204@gmail.com>
Date: Wed, 05 Dec 2012 12:55:29 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
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 <ynir@checkpoint.com>
References: <50BEFEE5.9050900@gmail.com> <4613980CFC78314ABFD7F85CC30277210EDD3BBB@IL-EX10.ad.checkpoint.com>
In-Reply-To: <4613980CFC78314ABFD7F85CC30277210EDD3BBB@IL-EX10.ad.checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=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 <yaronf.ietf@gmail.com>
> 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
>> IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
>>
>> Email secured by Check Point
>