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

"Valery Smyslov" <> Tue, 11 December 2012 12:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E16BA21F8818 for <>; Tue, 11 Dec 2012 04:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6MJuG8yURjUq for <>; Tue, 11 Dec 2012 04:16:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 191B921F8810 for <>; Tue, 11 Dec 2012 04:16:34 -0800 (PST)
Received: by with SMTP id d3so3116015lah.31 for <>; Tue, 11 Dec 2012 04:16:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=P1eCH2FtZEDL9KjGn8hKkdOQR9vcN9qW83eXrlw1M7k=; b=Fx30xVWYPhddXb/XbKsSRP3q1gnp6lEsKqj5S0hsZCnUXg/LPu7qJE38arQmmv/gxT cG0FGUvLh7MkWxjy2ajRSVoBx26Mjxj61MulB4kxHrP0m0L/eFvolDUa1OnEv3TuJa+t jCBw0ibcHDyurRcYuCEYuZpyyz6uL9l4VKolKqVpip2LZ0Bc33ppDHb2ucrRbhoTYcdF qLS88FxSnxTQLNHYEHJzddaCyqimnX2ipyLdDviQPnJNUsHtcDE0GeW4MkGT3BdkWWWw V1IGsyrB+oVyF7wp2QpZQ3ieWIQLQwYi7JUBG44Djs9h1G9wwMpi/YYzgPVCpOWAf5Vy Bl9g==
Received: by with SMTP id j8mr7616136lbh.0.1355228194086; Tue, 11 Dec 2012 04:16:34 -0800 (PST)
Received: from buildpc ([]) by with ESMTPS id ne2sm2183818lab.10.2012. (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 04:16:32 -0800 (PST)
Message-ID: <E7FA5DBC7DB747779E6E6D73460A6615@buildpc>
From: Valery Smyslov <>
References: <>
Date: Tue, 11 Dec 2012 16:16:18 +0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="ISO-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
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: Tue, 11 Dec 2012 12:16:36 -0000


I'm a bit uncomfortable with the requirement that IKE peer "MUST"
advertise NAT device port if it is reachable and "MUST NOT"
if it isn't. I think, that IKE Initiator in most cases cannot
reliably determine whether it is reachable or not. For example,
even if you manually configured port forwarding on your home
network border NAT box and then configured IKE to advertise this
port, that wouldn't imply that this port is actually reachable
as your ISP may have another NAT and, as CGN become more
common, number of those nested NAT's will increase.
Even STUN might not be a good solution - it is pretty 
expensive in terms of round trips, requires the presence of STUN 
server in the same network segment as IKE Responder,  
utilizes TLS and, most important, deals with UDP only (AFAIK).

So, I think that the requirement for IKE Initiator to advertise
its support for TCP and port it thinks it is reachable at
should be listed as "SHOULD" or even "MAY". Otherwise
it sounds like a paradox - protocol requires IKE to do
or not to do some action depending on condition 
that IKE in most cases is unable to determine.

Related issues.
- in description to TCP Port field in IKE_TCP_SUPPORTED Notification 
    it is written that "If the sender is not subject to network address 
    translation, the port SHOULD be 500." Again, IKE Initiator
    cannot reliably determine whether it is behind NAT or not.
    It becomes clear only after initial request completes and
    NAT_TRAVERSAL_*_IP are processed.
- as it is quite possible that the port advertised by IKE Initiator
    in IKE_TCP_SUPPORTED Notification is actually 
    not reachable, I think it is worth to mention, that if original
    Responder after IKE SA is established wants to 
    make some request using TCP port advertised by
    original Initiator and this port appears to be not reachable,
    this Responder MUST NOT tear down IKE SA but MUST 
    instead fall back to UDP transport.

Valery Smyslov.