Fwd: ISMS working group and charter problems

[Rich Morin <[e-mail]>]

What he said...  Firewalls are a fact of life; ignoring their
existence is silly.  Regardless of whether this solution is THE
appropriate one, the problem needs to be addressed.

-r

  --- Begin Forward ---

  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

  --- End Forward ---

-- 
email: [e-mail]; phone: [phone]
http://www.cfcl.com        - Canta Forda Computer Laboratory
http://www.cfcl.com/Meta   - The FreeBSD Browser, Meta Project, etc.

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