[Call-home] Why not IPsec with IKEv2 + NAT-T?

Pekka Nikander <pekka.nikander@nomadiclab.com> Wed, 28 September 2005 12:07 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKaiE-0005yX-Ai; Wed, 28 Sep 2005 08:07:02 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKaiD-0005yO-5p for call-home@megatron.ietf.org; Wed, 28 Sep 2005 08:07:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01609 for <call-home@ietf.org>; Wed, 28 Sep 2005 08:06:59 -0400 (EDT)
Received: from n2.nomadiclab.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKapd-0002d7-Mj for call-home@ietf.org; Wed, 28 Sep 2005 08:14:43 -0400
Received: from [] (localhost []) by n2.nomadiclab.com (Postfix) with ESMTP id 87441212C46 for <call-home@ietf.org>; Wed, 28 Sep 2005 15:06:40 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <433979ED.1000000@cisco.com>
References: <433979ED.1000000@cisco.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7F8A2E5A-90A9-404E-9247-DBF93FAB367A@nomadiclab.com>
Content-Transfer-Encoding: 7bit
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
Date: Wed, 28 Sep 2005 14:06:39 +0200
To: call-home@ietf.org
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Subject: [Call-home] Why not IPsec with IKEv2 + NAT-T?
X-BeenThere: call-home@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion of issues relating to &quot; call home&quot; functionality and firewall traversal" <call-home.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/call-home>
List-Post: <mailto:call-home@ietf.org>
List-Help: <mailto:call-home-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=subscribe>
Sender: call-home-bounces@ietf.org
Errors-To: call-home-bounces@ietf.org

>>> I find your examples weak. I am not aware of wide-use of SNMP to
>>> manage/monitor laptops or wireless phones. If others are, then
>>> please let me/us know about that.

>> Bert I suspect one of the reasons you don't find that is that it is
>> indeed difficult.  I've worked in many environments where desktop
>> machines were managed at least in part using SNMP.  When you don't
>> know the final transport address to manage a laptop, of course you
>> couldn't do it today.  That's his point.
> Yes, that's exactly the point.
> Using SNMP today to manage devices behind a NAT or firewall is  
> difficult and can require STUN or ICE.  In general, it is not worth  
> the trouble. An SSH-based SNMP will present even more difficulty.

I must be really dense today, but why can't we use IPsec with IKEv2  
and NAT-T?

Maybe I have misunderstood something completely, but as far as I have  
understood, IPsec with IKEv2 and NAT-T uses a well defined port (and  
could easily be configured to use a different one if needed), takes  
care of NAT traversal, allows TCP and UDP traffic to flow through the  
tunnel in both directions, and allows one to use different  
credentials thanks to being able to run EAP inside of IKEv2.

If you compare IPsec and SSH, the actual crypto load is about the  
same.  If you are going to run it over NAT-T (i.e. UDP encapsulated)  
anyway, you can easily implement it on the user level with no kernel  
changes requires.

The only bigger issue that I can see (but there *must* be others, I  
am sure) is the complexity of IKEv2.  Hence, maybe it would make  
sense to define a simplified profile for IKEv2 just for this purpose,  
with all features that are not needed for SNMP/Netconf/... removed?

Taking yet another angle, in the case of roaming laptops you already  
now often have an IPsec based VPN back to your home network, and you  
indeed can use the resulting tunnel for calling back to the laptop  
and do network management through it.

Or is TCP encapsulation a requirement?  Or channel bindings, i.e.,  
cryptographically binding the IKEv2 identity with the network  
management credentials?  If that is the issue, the actual  
implementation should be fairly easy in a user-space-only integrated  
implementation, and the BTNS WG is working towards the required  
mechanisms in the case of a kernel-based IPsec.

So, what I am missing?

--Pekka Nikander

Call-home mailing list