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

Dean Willis <dean.willis@softarmor.com> Wed, 28 September 2005 16:50 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKf8W-0004uk-VR; Wed, 28 Sep 2005 12:50:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKf8V-0004ub-V3 for call-home@megatron.ietf.org; Wed, 28 Sep 2005 12:50:28 -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 MAA19459 for <call-home@ietf.org>; Wed, 28 Sep 2005 12:50:25 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKfFx-0002I5-Ha for call-home@ietf.org; Wed, 28 Sep 2005 12:58:12 -0400
Received: from [64.101.149.214] (deanwillis-comp.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j8SGt2pY021811 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 28 Sep 2005 11:55:03 -0500
In-Reply-To: <7F8A2E5A-90A9-404E-9247-DBF93FAB367A@nomadiclab.com>
References: <433979ED.1000000@cisco.com> <7F8A2E5A-90A9-404E-9247-DBF93FAB367A@nomadiclab.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <900D9AC5-1AB6-4063-9AEE-C227F94BDBA9@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Call-home] Why not IPsec with IKEv2 + NAT-T?
Date: Wed, 28 Sep 2005 11:50:16 -0500
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
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

On Sep 28, 2005, at 7:06 AM, Pekka Nikander wrote:
>
> 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?


> So, what I am missing?


This has HUGE scaling implications if left "nailed up", which would  
be required for management-agent initiated transactions (polls). It  
also raises some questions about high-availability and failover. To  
make it work right, we'd probably need a diverse pair of SAs to  
paired management agents with state sharing, or at least a rapid-loss- 
detect and failover mechanism.

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.

How about something simpler, like a persistent TLS connection from  
the managed node to the management agent? For many applications, like  
call routing, I've been told by many that even this doesn't scale.  
I'd like to see one the order of 1e6 managed nodes per management  
agent cluster, and TLS as I understand it gets us closer to 1e5.

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.

For residential VoIP nodes that are frequently behind NATs but have  
to maintain SIP visibility in order to achieve their mission as VoIP  
nodes, I've been looking into using some sort of SIP-based "kick"  
mechanism. One approach that might work is a SIP event package that  
the node would SUP SUBSCRIBE to on startup. Then when the management  
agent needs it to call home, we'd send it a SIP NOTIFY message.

--
Dean

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