Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 13 December 2012 17:27 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 A395821F8B1B for <ipsec@ietfa.amsl.com>; Thu, 13 Dec 2012 09:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 ceZFcaXBnU8f for <ipsec@ietfa.amsl.com>; Thu, 13 Dec 2012 09:27:04 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF9C21F8B96 for <ipsec@ietf.org>; Thu, 13 Dec 2012 09:27:04 -0800 (PST)
Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qBDHQmXV039403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 10:26:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com>
Date: Thu, 13 Dec 2012 09:26:48 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <27020E4B-C496-4BC3-BA75-1AEC4FCC42EE@vpnc.org>
References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <E7FA5DBC7DB747779E6E6D73460A6615@buildpc> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com>
To: Yoav Nir <ynir@checkpoint.com>
X-Mailer: Apple Mail (2.1499)
Cc: "<ipsec@ietf.org>" <ipsec@ietf.org>, Valery Smyslov <svanru@gmail.com>
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt
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: Thu, 13 Dec 2012 17:27:04 -0000

On Dec 13, 2012, at 9:20 AM, Yoav Nir <ynir@checkpoint.com> wrote:

> Hi Valery
> 
> Thinking it over, I kind of regret adding the port field to the TCP_SUPPORTED notification. We don't have any mechanism for alternate UDP ports. Yes, UDP has cheap liveness checks to keep the mapping in the NAT so that requests can be initiated to the original initiator, while TCP does not. 
> 
> But your points are well taken. Leaving the advertised TCP port to configuration or auto-discovery is error prone and adds unnecessary complications to the protocol.  
> 
> I propose that:
> 1. We remove the port from the Notify
> 2. All connections will be done to port 500.
> 3. We warn against trying to use TCP to a peer behind NAT
> 
> This loses the ability to use port forwarding to have a reachable TCP port (unless that port is 500), but I think the simplification justifies it.

+1. It was getting too complex and iffy.

--Paul Hoffman