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

Paul Wouters <> Fri, 14 December 2012 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83EC721F888E for <>; Thu, 13 Dec 2012 22:04:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id odWBxZqLDaJH for <>; Thu, 13 Dec 2012 22:04:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4401221F8882 for <>; Thu, 13 Dec 2012 22:04:35 -0800 (PST)
Received: by (Postfix, from userid 500) id A4B4B829B2; Fri, 14 Dec 2012 01:03:30 -0500 (EST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97DEC829A3; Fri, 14 Dec 2012 01:03:30 -0500 (EST)
Date: Fri, 14 Dec 2012 01:03:30 -0500
From: Paul Wouters <>
To: Valery Smyslov <>
In-Reply-To: <B1F8AE12E3604526980FA756C8F2DB09@buildpc>
Message-ID: <>
References: <> <E7FA5DBC7DB747779E6E6D73460A6615@buildpc> <> <B1F8AE12E3604526980FA756C8F2DB09@buildpc>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc:, Yoav Nir <>
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt
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: Fri, 14 Dec 2012 06:04:37 -0000

On Fri, 14 Dec 2012, Valery Smyslov wrote:

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

That's too bad, but I agree it added a lot of complexity. What is the
blocking rate for TCP 500 in the wild? And does anyone know why Cisco
moved to port 10000? A higher port does seem to have a better chance
at not being blocked.

> Fully agree. And in this case please add the following to the list:
> 4. We remove TCP_SUPPORTED notification from Initiator's message
>   (as it becomes redundant for most use cases).

So if the responder falls back to TCP, and later becomes the initiator,
should it assume TCP 500 is available, or do we go through another round
of udp fail to tcp? As implementor, I see no issue remembering TCP is
supported as longe as we have a parent SA. We don't need the TCP_SUPPORTED
notification in the original initiator for that. But firewall rules
might not be symmetric, and an outgoing TCP might work while an incoming
TCP is blocked. But I guess if UDP isn't working well, there is not much
choice left but try TCP.