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

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