Dear Communities, I need your help to correct for an impending mistake by the ISMS working group in the IETF. Short Version The ISMS working group is chartered to find a way for SNMP to make use of existing authentication mechanisms. The current proposed approaches will make use of TCP. I seek a change to the proposed ISMS charter that requests the working group pay attention to firewall and NAT concerns. The current envisioned approach will not work through firewalls and NATs. I specifically request that the working group be directed to consider "Call Home" functionality as a non-exclusive alternative, where the managed device contacts the manager much the same way as your PC contacts Microsoft, Apple, etc for updates. The addition of call home functionality won't represent a major architectural change to SNMP. The major architectural change (if there is one) will be the use of SSH at all and the use of TCP. If you agree with me, I ask that you respond to this note including the ietf@xxxxxxxx and iesg@xxxxxxxx so indicating. Reasoning Long gone are the days when the IETF can simply ignore firewalls, as this working group is currently planning. An approach that demonstrates robustness in the face of firewalls is required. Long Version SNMP version 3 has a unique authentication mechanism that does not easily integrate with other AAA systems such as radius or kerberos. After many years of complaints and lack of deployment of SNMPv3, a working group called ISMS was chartered last year to address this problem. At IETF 63 the working group decided to move forward with an approach based on SSH. As you all know, SSH is TCP-based. This represents a substantial change for SNMP. It also represents a substantial opportunity to extend manageability through firewalls. Currently, if you want to manage devices with SNMP through firewalls you must either have the firewall run an application layer gateway or you must poke a hole in the firewall based on UDP ports. If you do not control the network element, the network manager, AND the firewall, you assuredly have no hope of getting SNMP through. Even if you DO control the firewall, configuration of authorized address mappings may make it prohibitively difficult to allow management protocols through, especially in the face of dynamic address assignment mechanisms such as DHCP and PPP. Because we now are considering a TCP-based approach we have the opportunity to fix this huge problem. Why is this important? Firewalls exist today throughout our infrastructure. There's a good chance you have a simple one at home. Indeed firewalls exist between departments within enterprises. As companies add services and functions onto the Internet their ability to manage these services with SNMP deteriorates, requiring the need for expensive custom solutions and out of band management. Furthermore, many telcos today offer managed services, where they manage enterprise and consumer devices (routers, switches, etc). The whole concept of an enterprise network has, if you will, become virtualized. Today SNMP does not offer any joy to those who want to build a unified management system. More and more voice over ip (VoIP) has gained acceptance in the market place. However, the ability to debug end points real time is limited. Wouldn't it be nice for a manager to query a phone to determine how many data packets it thinks it has sent to a far end and then follow that stream to determine who is dropping? In order to accomplish this task, the manager has to have access to a phone which, if remote, may well be sitting behind a firewall such as the one you have at home. Furthermore, if the phone wants to send a notification to a manager, it too is likely to reside behind a firewall. Networks are certainly not the only functions to be managed. One could easily imagine power management services making use of standard MIBs as well as enterprise MIBs to handle capacity planning as well as dispatch in the face of live problems. What is currently envisioned by ISMS? What is currently being discussed is the traditional model, where if you want to request information you open up an SSH connection and make an SNMP query on top of it once you've authenticated. If the managed device resides behind a firewall, you lose. Worse, the currently envisioned solution calls for a separate connection to be opened to send notifications (traps). This time, if the network management station resides behind you lose again. What this means is that if there exists a firewall anywhere between the firewall and the management station, the currently proposed solution will fail. The astute will note that this approach looks a lot like old fashion FTP and will break just in just the same way. What is needed? I propose a flexible standard mechanism where either the device or the manager can be configured to initiate a connection, and that notifications occur either across the same TCP stream, when it exists. For instance, if in the classic case of a manager connecting to the element the manager requests the "snmp-request" ssh service, we also simply allow for the device to also initiate a connection but instead ask for the "snmp-turn" service (with all due credit to the authors of SMTP who first anticipated this problem over 20 years ago!). The same for notifications. This "-turn" approach is sometimes referred to as "Call Home" (CH) functionality. CH has an added advantage as well. Many devices come and go from the network, and it is not reasonable, scalable, or cost effective to poll such devices if they are not there. CH provides a natural discovery mechanism for such devices because they initiate request for management. This proposal does NOT represent a dramatic architectural change to SNMP. The dramatic architectural change will be the use of SSH at all, and not who initiates the connection. What I'm asking you to do The good news here is that all you have to do is drop the IETF and the IESG a note, saying you want to a solution. This is one of those times when you don't even need to fix it yourself. Please reply to this message, CCing the iesg@xxxxxxxx and ietf@xxxxxxxx indicating that you agree that ISMS should not miss the opportunity now take into account firewalls. If you do nothing, the problem will probably be ignored by ISMS. SNMP will continue to serve the needs it serves today, but likely no more. Proprietary and competing standards approaches will continue to be developed. Multiple standards in this space would be a waste of effort on the part of implementors and operators alike. Don't let this happen! Eliot _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf