Re: ISMS working group and charter problems

[Jim Thompson <[e-mail]>]

I agree with Eliot on this subject.

> From: Eliot Lear <[e-mail]>
> Date: September 6, 2005 7:37:01 AM HST
> 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
>
>
>
>


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