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

Pekka Nikander <> Wed, 28 September 2005 17:25 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1EKfgN-0000LZ-Sy; Wed, 28 Sep 2005 13:25:27 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1EKfgM-0000K1-Qb for; Wed, 28 Sep 2005 13:25:26 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id NAA23947 for <>; Wed, 28 Sep 2005 13:25:23 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1EKfnp-00049E-92 for; Wed, 28 Sep 2005 13:33:11 -0400
Received: from [] (localhost []) by (Postfix) with ESMTP id 5B9DA212C46; Wed, 28 Sep 2005 20:25:09 +0300 (EEST)
In-Reply-To: <>
References: <> <> <>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: Pekka Nikander <>
Subject: Re: [Call-home] Why not IPsec with IKEv2 + NAT-T?
Date: Wed, 28 Sep 2005 19:25:07 +0200
To: Dean Willis <>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion of issues relating to &quot; call home&quot; functionality and firewall traversal" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

>> I must be really dense today, but why can't we use IPsec with  
>> IKEv2 and NAT-T?
> You're suggesting that the managed node open an IPSEC SA back to  
> the management agent and maintain this SA persistently so that it  
> can be managed via plain old SNMP over this channel?

Not necessarily.  If the alternative is use SSH or TLS, I don't see  
any big difference in terms of CPU power or set up time compared to  
opening up an IPsec SA on demand.  In practical terms, instead of  
opening a TCP session and negotiating session keys with SSH or TLS,  
you negotiate session keys with IKEv2 and open the TCP connection  
over the SA.  As this is needed for calling home and must pass  
firewalls and NATs, that clearly needs to use UDP encapsulation  
(IPsec NAT-T), and therefore *can* be (almost) as easily implemented  
in user level as SSH or TLS, if that is an issue.

Sure, the lack of high quality open source user level IPsec  
implementations might be an impediment here, but I wouldn't consider  
it *that* hard to go and create one.

The potential benefit is that you don't need to change your  
application model that much, and that you may even be able to use  
current credentials more easily.

>> So, what I am missing?

<snipping arguments on nailing up>

> There's also an issue with many older but widely deployed  
> residential NAT routers that allow only one (or a fixed, relatively  
> small number of) IPSEC connections to pass-through.

I don't see that an issue if you are using UDP encapsulation anyway.   
But, again, maybe I am missing something here.

> This has led to discussions about using some non-SNMP mechanism to  
> "kick" the managed node and tell it to build up a connection to its  
> management agent.

AFAICT, that is a different question and basically orthogonal on  
whether you want to use IPsec, SSH or TLS for security.  On-demand  
IPsec, as alluded above, also needs such "kicking".

--Pekka Nikander

Call-home mailing list