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: <431DD3BD(_dot_)9090108(_at_)cisco(_dot_)com>
Date: Tue, 06 Sep 2005 19:37:01 +0200
From: Eliot Lear <lear(_at_)cisco(_dot_)com>
To: IETF Discussion <ietf(_at_)ietf(_dot_)org>, nanog(_at_)merit(_dot_)edu,
iesg(_at_)ietf(_dot_)org
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 ietf(_at_)ietf(_dot_)org and iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org and
ietf(_at_)ietf(_dot_)org 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: rdm(_at_)cfcl(_dot_)com; phone: +1 650-873-7841
http://www.cfcl.com - Canta Forda Computer Laboratory
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf