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

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

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 199E121F8C69 for <ipsec@ietfa.amsl.com>; Tue, 4 Dec 2012 23:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5ySmf-a41iNn for <ipsec@ietfa.amsl.com>; Tue, 4 Dec 2012 23:59:38 -0800 (PST)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8DDFA21F8C50 for <ipsec@ietf.org>; Tue, 4 Dec 2012 23:59:37 -0800 (PST)
Received: by mail-bk0-f44.google.com with SMTP id w11so2076603bku.31 for <ipsec@ietf.org>; Tue, 04 Dec 2012 23:59:36 -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:subject :content-type:content-transfer-encoding; bh=7ftO8OO22FhJeKDlj0m7kv64RrSgCiiAxZ4l8c3nrk0=; b=n0U/9s7c/S1Nlv3kjkP0IGvl4+tUc28d3Q4C0E1yxWW/vvC0I8rqfudUIxga2lH0OJ zaVAeSAq24/DRJjWET06aPcaiObWSDeZg/GP76Qvlq+Zm3S28d4nXgVTL54dqPjmUs8w tJeVFn92/5yhHGABr+hp7wh1erlWSoZooCUXvHij4ntUnIAvpsKgyYSQuG/DvV37ZcW7 f+7zdKlGs58LcCN0rHlmskEDY4wP9BloHib/Pe6SruKp2prZvayLh9KHwwXbvETdgsd7 3J5O/lLZ01YlQEVG06u+8S8FTF6tb4DdViaVSXQOYuUxobTU0PlwBwtYWFvyY7bltNr0 GBkg==
Received: by with SMTP id 20mr5093234bkx.33.1354694376589; Tue, 04 Dec 2012 23:59:36 -0800 (PST)
Received: from [] ( []) by mx.google.com with ESMTPS id o9sm2800507bko.15.2012. (version=SSLv3 cipher=OTHER); Tue, 04 Dec 2012 23:59:35 -0800 (PST)
Message-ID: <50BEFEE5.9050900@gmail.com>
Date: Wed, 05 Dec 2012 09:59:33 +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: IPsecme WG <ipsec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [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 07:59:39 -0000


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.


- 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'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?

- Also, given the port advertising, do we still need the liveness check 
described at the end of Sec. 3.2?