ISMS working group and charter problems

[Brent Chapman <[e-mail]>]

I'm not sure if it's too late to speak up on this issue or not (I've 
been on vacation), but I strongly support Eliot's position here, 
particularly the statement that

	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.

I'd like to think that I know a little bit about firewalls and their 
impact on network design and management; while firewalls are no 
longer the focus of my network architecture consulting business, I'm 
one of the coauthors of the O'Reilly & Associates book "Building 
Internet Firewalls", as well as the founder of the Firewalls mailing 
list.


-Brent
--
Brent Chapman <[e-mail]> -- Great Circle Associates, Inc.
Specializing in network infrastructure for Silicon Valley since 1989
For info about us and our services, please see http://www.greatcircle.com/
Network Automation blog: http://www.greatcircle.com/blog/network_automation


>Message-ID: <[e-mail]>
>Date: Tue, 06 Sep 2005 19:37:01 +0200
>From: Eliot Lear <[e-mail]>
>To: IETF Discussion <[e-mail]>,  [e-mail],  [e-mail]
>Subject: ISMS working group and charter problems
>
>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 [e-mail] and [e-mail] 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 [e-mail] and
>[e-mail] 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


-- 
Brent Chapman <[e-mail]> -- Great Circle Associates, Inc.
Specializing in network infrastructure for Silicon Valley since 1989
For info about us and our services, please see http://www.greatcircle.com/
Network Automation blog: http://www.greatcircle.com/blog/network_automation

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf