Hi, I am not promoting (nor discouraging) SNMP for home networks, but if you're going to discuss it, let me just make sure the WG understands some of the features of SNMP designed to be relevant to an IT department managing a home network remotely (and other cross-admin domain use cases).
You want to avoid SNMPv1 and SNMPv2 over an untrusted network, because they have only minimal security based on a shared password passed in cleartext in every message a community string. The IETF has declared SNMPv1 and SNMPv2 Historic and NOT RECOMMENDED, so certainly you should not write any recommendations for their use in homenet. SNMP is a protocol designed to carry MIB information. That separation of message from content is critically important, to enable protocols other than SNMP to also carry MIB information. If most end users do not use SNMPv1 because **MIB-based management** is too complex and user-unfriendly for home use, SNMPv3 will not solve that problem. It uses the same MIB. SNMPv1 is quite easy to configure you just point it at an address and give it the right community string. SNMPv3 was designed to be secure, and has lots of security setup that would baffle most home users. However, IT departments wanting SNMP to reach into the home could consider SNMPv3. SNMPv3 offers authentication using negotiated methods - its own security, SSH and TLS. (all IETF standards). It offers authorization on a per-user-session basis using RADIUS, tied into SSH and/or TLS. While SNMPv1 and SNMPv3 both run over ports 161/162, SNMPv3 can distinguish whether the authentication is done using community strings, SSH, TLS or the SNMPv3 built-in security, and allow/deny accordingly. SNMPv3 supports security fallback e.g., if the network is flaky and you cannot reach a CA, it can fall back to using the built-in SNMP security. SNMPv3 offers MIB database access control (who can perform what operations on which information) Access control uses a tree-based approach, much like many graphical backup applications; this allows policies to be defined, for example, at the everything, the MIB module level, table level, or the object-level. Access can be dynamically configured by using RADIUS to assign a user to a predefined access policy (e.g., engineering vs accounting, Boston vs San Jose, home vs in-office, help-desk vs routing-admin, and so on). The authentication/authorization/MIB access control can be used to allow users to manage certain aspects of their network, such as device discovery and fault monitoring and host resources (RFC2790), while also allowing an ISP to manage aspects of the home network. SNMPv3 provides agents with a global identifier independent of their current address. This was designed specifically to handle dynamically-changing addresses, such as from DHCP and NAT, or recognizing that a single agent is using multiple interfaces with different addresses (important for correlating the data received via multiple addresses for the same agent). There is an SNMP proxy-mib that provides a message-header rewrite (but not payload) between security approaches. The proxy-mib can be used for proxying between SNMPv1 and SNMPv3 security. For example, SNMPv1 can be used managing a trusted internal network or a network with no SNMPv3 support, like a homenet, and then proxy to SNMPv3 for carrying the data over an untrusted network like the Internet. If no proxy rule applies, the message gets dropped, like a firewall. In a NAT environment, or other environment that uses aggregation, you may or may not want an ALG to do address translation in the payload. If you are looking at a server farm, some uses might be better served by seeing this as one abstract aggregation; For performance and fault monitoring, you might want to look at each individual server. See RFC2962. I hope this helps provide more detail about relevant aspects of SNMP for home networks. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) [email protected] +1-603-828-1401 From: Jason Livingood <[email protected]> Date: Fri, 9 Mar 2012 04:42:02 +0000 To: Michael Richardson <[email protected]>, "[email protected]" <[email protected]> Cc: Dave Taht <[email protected]> Subject: Re: [homenet] snmp for monitoring home network > I think that E2E into the home for SNMP is perhaps one of the things that > would motivate an ISP to support homenet. E2E network management and/or monitoring, yes. SNMP, at least on a public interface, maybe not so much. We may be entering a phase where ISPs consider blocking TCP/UDP 161. The reason is that SNMP is becoming more and more widely abused. I still have no idea why for example (1) some gear ships with public as the default string and the daemon running by default as such, (2) some gear does not present the user with an interface to turn off SNMP or change the community string at all (so you may be stuck with on/public). So maybe on SNMP, tread carefully. ;-) Jason _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
