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 >
- [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments Yaron Sheffer
- Re: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments Yoav Nir
- Re: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments Yaron Sheffer