Subject: Re: [Call-home] draft now posted; BoF?

From: Josh Littlefield <[email-masked]>
Date: Tue, 27 Sep 2005 12:57:17 -0400

> Bert> I find your examples weak. I am not aware of wide-use of SNMP to
> Bert> manage/monitor laptops or wireless phones. If others are, then
> Bert> 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.

Service providers wishing to manage home devices in the face of 
household NATs are at a loss.  The SIPPING WG has defined a 
configuration framework for deliverying device configuration profiles 
across a NAT to SIP devices in a call-home fashion triggered by SIP 
NOTIFY messages, but they have no solution for management.  The DSL 
Forum has defined a call-home style protocol (TR-069), using a form of 
SOAP sitting somewhat backward on HTTP, for combined configuration and 
management of conformant devices.  In other technologies, operators 
happily using SNMP for management of non-NATed subscriber devices now 
are being forced to consider a variety of non-SNMP alternatives to 
support management and diagnosis of new devices in the home.

If the IETF chooses not to consider and solve the call-home problem in 
the face of new SNMP transports, it is essentially abandoning management 
of this large new class of devices, and leaving it to the industry to 
create a hodge-podge of solutions.

Josh

_______________________________________________
Call-home mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/call-home

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 28 Sep 2005 14:06:39 +0200

>>> 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.

> 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

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 28 Sep 2005 08:55:07 -0700 (PDT)

HI,

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

Thanks,
/david t. perkins

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Sep 2005 11:50:16 -0500

> I must be really dense today, but why can't we use IPsec with IKEv2  

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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 28 Sep 2005 19:25:07 +0200

>> 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.

> "kick" the managed node and tell it to build up a connection to its  

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

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Sep 2005 12:49:56 -0500

On Sep 28, 2005, at 12:25 PM, Pekka Nikander wrote:

>> "kick" the managed node and tell it to build up a connection to  
>> its management agent.
>>
>

That's true, and on-demand IPSEC would have less "impact" than  
permanently nailed-up IPSEC would.

--
Dean

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Sep 2005 18:19:36 +0200

> 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.

Well, define "that much".  Somehow one guy needs to know they're
managing and that the other guy is available.  So the managed device can
establish an IPSEC connection to the manager?  Now the manager needs to
know to manage.  How does that occur?  How will dispatch occur?

Eliot