Re: ISMS working group and charter problems

[Juergen Quittek <[e-mail]>]

The main goal of the ISMS WG is finding a solution that integrates
SNMP into existing user and key management systems.  That's why
this group is located in the security area and not in the OaM area.

The original charter (online) aims at setting a technical direction
towards this goal.  The work done by the WG resulted in a new, more
concrete charter proposal (that will hopefully be distributed soon
on the announce list).

Eliot's request is adding a new goal to the ISMS charter: extending
SNMP such that it operates well across NATs and firewalls.  I am not
sure that ISMS is the right place to do so.

I agree that the ISMS activities might be opportunity to do so,
because when we are defining an integration into user and key
management systems, there might be a chance to solve firewall
and NAT traversal for SNMP at the same time.

However, I am not sure this is the right way to do so.  So far, I have
not seen a clear analysis of the SNMP requirements for FW/NAT traversal.
I think we still need this analysis and a decision on whether or not
the IETF should add FW/NAT traversal functions to SNMP.  If yes, we need
to decide further which functionality should be covered by such an
extension.  Probably this work should rather be done in the OaM area and
not in the security area (although we have an OaM AD and a significant
part of the SNMP community actively participating in ISMS).

Thanks,

    Juergen
-- 
Juergen Quittek        [e-mail]       Tel: [phone]
NEC Europe Ltd.,       Network Laboratories        Fax: [phone]
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de


--On 9/6/2005 7:37 PM +0200 Eliot Lear wrote:

> 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



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