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

"David T. Perkins" <dperkins@dsperkins.com> Wed, 28 September 2005 15:55 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKeHM-0006Ib-4q; Wed, 28 Sep 2005 11:55:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKeHK-0006Hh-Sz for call-home@megatron.ietf.org; Wed, 28 Sep 2005 11:55:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16033 for <call-home@ietf.org>; Wed, 28 Sep 2005 11:55:28 -0400 (EDT)
Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKeOn-0000f1-Oc for call-home@ietf.org; Wed, 28 Sep 2005 12:03:15 -0400
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j8SFtGBT009600; Wed, 28 Sep 2005 08:55:16 -0700
Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j8SFtAK2018557; Wed, 28 Sep 2005 08:55:10 -0700
Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j8SFt8i0018540; Wed, 28 Sep 2005 08:55:10 -0700
X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs
Date: Wed, 28 Sep 2005 08:55:07 -0700 (PDT)
From: "David T. Perkins" <dperkins@dsperkins.com>
X-Sender: dperkins@shell4.bayarea.net
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
Subject: Re: [Call-home] Why not IPsec with IKEv2 + NAT-T?
In-Reply-To: <7F8A2E5A-90A9-404E-9247-DBF93FAB367A@nomadiclab.com>
Message-ID: <Pine.LNX.4.10.10509280854230.15135-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: call-home@ietf.org
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

HI,

Please describe the credentials that would be used by each
end. And send that to the list.

Thanks,
/david t. perkins

On Wed, 28 Sep 2005, Pekka Nikander wrote:

> >>> 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
> Call-home@ietf.org
> https://www1.ietf.org/mailman/listinfo/call-home
> 


_______________________________________________
Call-home mailing list
Call-home@ietf.org
https://www1.ietf.org/mailman/listinfo/call-home