Subject: ISMS working group and charter problems

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Sep 2005 19:37:01 +0200

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 [email-masked] and [email-masked] 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 [email-masked] and
[email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Sep 2005 11:00:44 -0700

Eliot,

> working group in the IETF.

Your note is clear and logical, and seems quite compelling.

Is there any chance of getting a proponent of the working group's decision to 
post a defense?

(By the way, I am awestruck at the potential impact of changing SNMP from 
UDP-based to TCP-based, given the extensive debates that took place about this 
when SNMP was originally developed.  Has THIS decision been subject to adequate 
external review, preferably including a pass by the IAB?)

-- 
 
   d/

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Daniel Senie <[email-masked]>
Date: Tue, 06 Sep 2005 14:21:00 -0400

At 02:00 PM 9/6/2005, Dave Crocker wrote:

>Is there any chance of getting a proponent of the working group's 
>decision to post a defense?
>
>(By the way, I am awestruck at the potential impact of changing SNMP 
>from UDP-based to TCP-based, given the extensive debates that took 
>place about this when SNMP was originally developed.  Has THIS 
>decision been subject to adequate external review, preferably 
>including a pass by the IAB?)

I agree the argument is well laid out, and would be interested in 
hearing the thinking of ISMS in response.

I'm more than a bit concerned, however, when folks start talking 
about solutions that will permit things to pass through firewalls 
without configuration. Those in charge of firewalls are often 
purposely setting policy. If there is a perceived need for a policy 
that prevents SNMP traffic, then it should remain possible for the 
administrator of that network element to make that call. I must say I 
have some concern with overlaying SNMP on SSH, since that precludes 
the firewall knowing whether the traffic is general SSH keyboard 
traffic or network management.

Let's hear more about the thinking involved.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 6 Sep 2005 20:28:36 +0200

On 6-sep-2005, at 19:37, Eliot Lear wrote:

> envisioned approach will not work through firewalls

I consider the fact that random people across the internet can't  
manage my equipment a feature rather than a bug.

> and NATs.

The IETF has been doing extensive work on NAT traversal, have a look  
and see if you can reuse some existing mechanism.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Sep 2005 14:35:43 -0400

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave> (By the way, I am awestruck at the potential impact of
    Dave> changing SNMP from UDP-based to TCP-based, given the
    Dave> extensive debates that took place about this when SNMP was
    Dave> originally developed.  Has THIS decision been subject to
    Dave> adequate external review, preferably including a pass by the
    Dave> IAB?)

Certainly one of the reasons I requested IETF-wide review for the ISMS
recharter is so that decisions like this can be reviewed by the
community.  The IAB gets to see charters at about the same time as the
IESG does; they have sent no negative comments to this charter.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Sep 2005 20:36:57 +0200

Daniel,

All solutions will use a different SSH port as part of the standard just
so that firewall administrators have the ability to block.

Eliot

Daniel Senie wrote:
> I'm more than a bit concerned, however, when folks start talking about
> solutions that will permit things to pass through firewalls without
> configuration. Those in charge of firewalls are often purposely setting
> policy. If there is a perceived need for a policy that prevents SNMP
> traffic, then it should remain possible for the administrator of that
> network element to make that call. I must say I have some concern with
> overlaying SNMP on SSH, since that precludes the firewall knowing
> whether the traffic is general SSH keyboard traffic or network management.
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Sep 2005 20:43:41 +0200

Hi Iljitsch,

> I consider the fact that random people across the internet can't  manage
> my equipment a feature rather than a bug.

Use of a well known port that you can block will actually make it EASIER
for you to make use of that "feature".  Today if you leave your PC up
with various forms of commercial software, you have no idea who is
connecting to what.

> and see if you can reuse some existing mechanism.

All mechanisms used with the possible exception of an additional SNMP
table will be re-used from existing IETF work (mostly SSH with help from
the fact that it's based on TCP).

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Sep 2005 14:51:11 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Daniel, All solutions will use a different SSH port as part
    Eliot> of the standard just so that firewall administrators have
    Eliot> the ability to block.

I don't actually think this has been decided yet.  I believe arguments
were presented on both sides of the different port question and I
don't recall a clear consensus.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 06 Sep 2005 14:55:14 -0400

In message <[email-masked]>, Dave Crocker writes:

>external review, preferably including a pass by the IAB?)

When I was the sponsoring AD for the group, I pushed back hard on this 
point.  The WG opted for the present path.  I'm not saying they're 
right -- in fact, I disagreed -- but the decision wasn't made by 
default.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Sep 2005 21:57:13 +0300 (EEST)

> so that firewall administrators have the ability to block.

FWIW, I'm a bit concerned as well.  I don't see clearly which 
scenarios you have in mind when you say you want better firewall/NAT 
traversal capabilities.

In the scenarios I see, it's a Good Thing that as a network admin I 
can block all [incoming] SNMP traffic (whether ISMS or not), and 
moreover, that it's blocked by default if I create a typical policy; I 
want to do that in the future too.  Using a different port is 
obviously the first step here.

But if a different port is being used, I don't see what more is 
absolutely required.

Are you saying some of the following:

  1) ISMS specs should specify that the monitored hosts can/should 
certainly keep open a TCP session so the network management (in both 
ways) can happen over that session.  (This seems pretty trivial..)

  2) We should specify how network management hosts could reside behind 
a firewalls which block the management ports (I don't think this is 
needed or should be done).

  3) ISMS specs should specify network management hosts' capability to 
poll hosts behind a firewall, which blocks incoming ISMS port by 
default -- by using a mechanism where outgoing "I want to be monitored 
using ISMS!" messages would open pinholes in the firewalls.  (Is there 
sufficient benefit in this compared to 1) as you still can't monitor 
the hosts when you want to unless they are constantly polling you?)

Something else?  Please be a bit more specific about what you think 
the "NAT/FW problem" is in this context, and what you'd like to see 
done about it.

(Personally, I'm not sure if I buy the whole ISMS thing at the moment, 
because the operators AFAICT are sufficiently happy with the SNMPv1/2 
security model -- so whatever you build, it has to be at least that 
simple otherwise it won't be used.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Sep 2005 12:08:30 -0700

>>...Has THIS decision been subject to adequate 

Well, I was not at all trying to raise questions about IETF process, but now 
that you mention it...

It strikes me that this is a remarkably constructive example of why ADs should 
less often "make decisions" or debate solely within the IESG, and more often 
should "recruit rough consensus from the larger IETF community."

That is, the major benefit in the broad and deep expertise of an AD like Steve 
is to detect major issues and to raise a warning to the larger community.

Then they can seek broader review and consensus for questionable working group 
choices that might have much larger impact.

-- 
 
   d/

  Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Sep 2005 21:11:30 +0200

Hi Pekka,

Pekka Savola wrote:
>  2) We should specify how network management hosts could reside behind a
> firewalls which block the management ports (I don't think this is needed
> or should be done).

Depending on what you mean by "network management hosts" it could be (1)
or (2) ;-)  I'm saying if there is a device that wishes to to be managed
through a firewall, allow it to open a connection on a specified port
(just so that firewalls can block it).  Remember, your laptop does this
today with HTTP on port 80 or HTTPS on port 443 (worse because you can't
even inspect).

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 Sep 2005 13:05:49 -0700

> IESG does; they have sent no negative comments to this charter.

Sam, I've tried to search the ietf-announce archives, google, etc. for any sort 
of announcements, outside of the isms working group, concerning the draft 
re-chartering text for isms.  Unfortunately I have not been able to find it, so 
I do not know what request of yours you are referring to.

In any event, I think the significance of Eliot's (and Steve Bellovin's) 
postings have less to do with a chartering event and more to do with decisions 
made DURING a working group's normal activities.  In particular, when a working 
group gets to the point of making a decision that has broad architectural or 
operational impact, it is the expertise of ADs, IAB members, and other senior 
participants, that can serve to raise a question to the larger community, 
exactly as Eliot is now doing.

What I took from Steve Bellovin's posting was the implication that his valid 
concerns were expressed in a more limited context.  What I am suggesting is that 
we should get into the habit of having such concerns raised in the broader 
community, when the impact is this large.

-- 
 
   d/

  Dave Crocker

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 6 Sep 2005 23:21:42 +0200

[dropping NANOG]

On 6-sep-2005, at 20:43, Eliot Lear wrote:

>> manage

> with various forms of commercial software, you have no idea who is

Ok.

> the fact that it's based on TCP).

You do realize that you import all the weaknesses of TCP then, don't  
you?

I'm not too familiar with NAT traversal techniques, but AFAIK there  
isn't a good match between these mechanisms and what you want to do  
here. You may want to consider looking at the mechanism for HTTPS  
proxying. This works by having the client connect to the proxy,  
optionally authenticating itself, and then asking the proxy to  
connect it to the ultimate destination. The encryption is end-to-end  
and thus opaque to the proxy, but the proxy does have the opportunity  
to assert access restrictions. You'd probably need a mechanism for  
internal to-be-managed systems to register their manageability with  
the proxy.

A simple split horizon (in addition to the normal layers of access  
control) could avoid these proxies from being abused for spam and the  
like.

Obviously the SSL in HTTPS is a bit different from SSH, but that  
shouldn't be too hard to fix one way or another.

---

From: "Thomas Gal" <[email-masked]>
Date: Tue, 6 Sep 2005 15:00:01 -0700

> table will be re-used from existing IETF work (mostly SSH with help 
> from the fact that it's based on TCP).

Perhaps then it's time we consider mandating a "NAT-Traversal" section to
standards track documents much like IANA and Security considerations have
become common place to this day. Anything that's not covered by the BEHAVE
work already done should be covered there, as the IETF seems to have indeed
accepted the proliferation and widespread acceptance of NAT functionality.

-Tom

---

From: Daniel Senie <[email-masked]>
Date: Tue, 06 Sep 2005 18:16:19 -0400

>accepted the proliferation and widespread acceptance of NAT functionality.

Actually, a "Firewall Considerations" section would make sense. That 
section might indeed be a good place to discuss NAT issues, if any, 
but firewall interactions with protocols exist in many cases where 
NAT is in use. Though many have expressed their hope that NAT does 
not persist in the IPv6 world, there should be no doubt in anyone's 
mind that firewalls will be with us permanently.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 06 Sep 2005 18:28:15 -0400

In message <[email-masked]>, Daniel Senie 
>mind that firewalls will be with us permanently. 

Indeed.  In Hal Burch's dissertation, he concluded that 

	at least 93% of hosts attached to the Internet are behind
	a ltering device of some type. Because this excludes hosts
	behind rewalls that block all incoming connection attempts,
	the true percentage is even higher than 93%. Clearly,
	rewalls are an important consideration when designing
	protocols and developing models for the Internet.

More of his measurements concluded that at least 56% of hosts are
behind a firewall that blocks by default.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Sep 2005 00:30:40 +0200

On 7-sep-2005, at 0:16, Daniel Senie wrote:

> Actually, a "Firewall Considerations" section would make sense.

What would be in such a section? There are only three possibilities:

1. There is no firewall: no need for text.
2. There is a firewall, and it doesn't try to block the protocol: no  
need for text.
3. There is a firewall, and it tries to block the protocol.

So what text would be helpful in case #3? Either the firewall  
successfully blocks the protocol and the firewall works and the  
protocol doesn't, or the firewall doesn't manage to block the  
protocol and the protocol works but the firewall doesn't. So whatever  
happens, someone is going to be unhappy.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 06 Sep 2005 19:04:50 -0400

In message <[email-masked]>, Iljitsch van Beijn
>happens, someone is going to be unhappy.
Not at all.  Often, a firewall needs to know a fair amount about the 
protocol to do its job.  FTP is the simplest case -- it has to look for 
the PORT (and, in some configuration, the PASV) command.  H.323 and SIP 
are more complex.  

But for complex protocols, we need to go a step further.  SIP has, 
built-in, provision for gateways.  There are a number of reasons for 
this, but firewall friendliness is certainly one of them.  The proper 
question is this: would adding something to the protocol enable it to 
operate properly in the presence of a firewall *without* subverting 
site security policy.  The lack of that latter consideration has led to 
people using http as the universal firewall traversal protocol, with 
the obvious bad side-effects.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 06 Sep 2005 19:13:55 -0400

>well be sitting behind a firewall such as the one you have at home.

Eliot, I have very grave reservations about this.  Quite frankly, I 
don't think that arbitrary management stations should have any right 
whatsoever to connect to my devices.

I agree that the functionality you suggest is useful.  The trick is to 
permit that without permitting misbehavior.  (I'll note here that the 
interests of vendors and the interests of users are not identical.  
More and more, vendors like subscription-based models, where users keep 
on paying, to give just one example.)  This requires not just a 
view-based access control model -- where the view might be "MIB 
variables for this call only" -- but an express intent by the user to 
permit the access for that particular call.  This demands a different 
notion of "view" than has been traditional; it also implies a user 
interface issue and -- given the existence of firewalls -- a multi-
party protocol:  my endpoint, your endpoint, my management proxy (which 
is accessible through the firewall), your management proxy, and the 
vendor's diagnostic station.  I'd be hard-pressed to see this as within 
scope for ISMS.  It may, however, be a very nice subject for a separate 
working group.

>too is likely to reside behind a firewall.

Not if the site is properly managed.  The manager's port should be 
exposed to the outside.  Just as web servers have to permit inbound 
port 80 and mail servers have to permit inbound port 25, a management 
station has to accept its own traffic.  A firewall can, at best, 
protect the other ports on the machine -- but those should be turned 
off anyway.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Sep 2005 01:34:17 +0200

On 7-sep-2005, at 1:04, Steven M. Bellovin wrote:

>> Either the firewall

> the PORT (and, in some configuration, the PASV) command.  H.323 and  

I'm not very comfortable with the notion of having a third party  
device deciding what is valid communication between two hosts  
connected to the internet. This is just too fragile. For instance, a  
popular filter on *BSD (they're all named [i]pf[w] so I can never  
remember which is which) is unable to handle RFC 1323 window scaling  
properly. PIX firewalls truncate(d) EDNS0 packets. ICMP packet too  
bigs are filtered in many places, as is ECN.

I recognize that carrying all existing firewalls to the scrap heop  
won't immediately solve our problems, but we do have to realize that  
current filter practice do almost as much harm as they do good. We  
really need better stuff here.

(It's amusing to see that to some people, security means encrypting  
their communication, while to others it means inspecting that same  
communication.)

---

From: "Thomas Gal" <[email-masked]>
Date: Tue, 6 Sep 2005 16:43:30 -0700

>>> Actually, a "Firewall Considerations" section would make sense.

Agreed.

>>protocol doesn't, or the firewall doesn't manage to block the protocol 
>>and the protocol works but the firewall doesn't. So whatever happens, 
>>someone is going to be unhappy.
>>
protocol to do its job.  FTP is the simplest >case -- it has to look for the
PORT (and, in some configuration, the PASV) command.  H.323 and SIP are more
>complex.

Exactly, ignoring the particulars of a protocol and choosing to just
block/not block it doesn't really make the firewall useful to that protocol.
That's certainly one of the valid choices for a firewall to take, however.

>But for complex protocols, we need to go a step further.  SIP has,
built-in, provision for gateways.  There are a >number of reasons for this,
but firewall friendliness is certainly one of them.  The proper question is
this: 
>>would adding something to the protocol enable it to operate properly in
the presence of a firewall *without* 
>>subverting site security policy.  The lack of that latter consideration
has led to people using http as the 
>>universal firewall traversal protocol, with the obvious bad side-effects.

Indeed this section could be a way of documenting the proper behavior of a
firewall in the context of a certain protocol. For example a firewall could
say with regard to protocol X I either:

A) treat it as unknown/don't recognize the protocol <- this is fine if you
don't use the protocol
B) meet the full criteria specified in the "Firewall Considerations" section
<-this may be a factor if the particular protocol receives heavy use in your
organization
C) Do something inbetween, which while possibly helpful should not be
considered compliant for the sake of differentiating devices.

Much like you can configure port forwarding and a DMZ among a multitude of
other things commonly on firwall/nats allowing for the possibility of
consistent behavior/options relating to a new protocol among firewall
vendors MUST be better than leaving it to itself like has happened with the
NAT situation.

-Tom

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 06 Sep 2005 19:54:21 -0400

In message <[email-masked]>, Iljitsch van Beijn
>their communication, while to others it means inspecting that same  
I opt for each in its place.  I'm also an advocate for distributed 
firewalls.  But I *really* don't want to refight the whole firewall 
issue yet again; I've been through that too many times in the last 
decade or so.

For right now, though, the issue is engineering.  Again, the vast 
majority of hosts are behind firewalls.  Is the philosophical issue 
that important that we should ignore it?  I don't think so.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Sep 2005 20:12:12 -0700

Hi -

> From: "Eliot Lear" <[email-masked]>
> To: "IETF Discussion" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Tuesday, September 06, 2005 10:37 AM
> Subject: ISMS working group and charter problems
...
> is one) will be the use of SSH at all and the use of TCP.
...

Regardless of whether "call home functionality" as you defined it is
desirable, I disagree with the claim that it wouldn't represent a
major architectural change to SNMP.  For notification originators, it
is a quite natural extension, and I have no problem with it.  For command
responders, I think this would be a fairly significant addition to the architecture.
I'm neutral on the question of whether it is needed, and perhaps we only
differ in what we perceive as "major", but I think we need to be clear that
it would indeed require changing the SNMP architecture.

I also disagree that it is the use of SSH or TCP that results in the architectural
changes.  TCP use without "call home" (as in RFC 3430) requires no
architectural changes.

Randy

---

From: Eliot Lear <[email-masked]>
Date: Wed, 07 Sep 2005 07:46:15 +0200

Hi Steve,

> scope for ISMS.  It may, however, be a very nice subject for a separate 

I think there are a few models that could be considered.  The first is
where a single administrative domain is at play, where really my
management proxy = your management proxy.  This might be an optimization
of what you're saying.  Arguably you're already talking to my management
proxy through SIP.  An alternative model that has been mentioned is a
way to query OIDs over SIP.  I'm not a SIP guy so I don't know if the
SIP proxy can even initiate queries.

In the case you mentioned, with four proxies, I'm okay with that as long
as it's not mandated in the model.  Anything that requires four of
anything is never going to survive the Internet.  e2e is hard enough
with 2 devices ;-)

> protect the other ports on the machine -- but those should be turned 

You can't really tell where the firewalls area going to be in the
general case.  And with mobile managed devices, you really can't tell,
because access will vary.  My point was that in the case where a
notification connection is initiated in one direction and a request
connection is initiated in another, you're all but guaranteed that one
or the other will fail in the face of a firewall, and that is the
current envisioned approach.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 07 Sep 2005 07:53:16 +0200

Randy,

> it would indeed require changing the SNMP architecture.

There is a difference between a connection and a request.  Reversing the
transport connection direction doesn't say that we reverse request
directions or notification directions.  Quite the contrary.  They stay
the same.  To me that means no substantial change over what is already
proposed.

Indeed the currently envisioned approach guarantees that either
notifications or requests will be broken because one connection will
initiate in one direction and another will initiate in the reverse.  FTP
all over again, as I said.

> changes.  TCP use without "call home" (as in RFC 3430) requires no

Clearly since SSH is now carrying authentication information there is a
substantial change, where SNMP inherits bonafides from the process
below.  That is not the case in 3430.

Eliot

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 07 Sep 2005 00:26:54 +0200

--On 6. september 2005 11:00 -0700 Dave Crocker <[email-masked]> wrote:

> UDP-based to TCP-based, given the extensive debates that took place about
> this when SNMP was originally developed.  Has THIS decision been subject
> to adequate external review, preferably including a pass by the IAB?)

just a formality note (and dropping nanog and the IESG):

I believe that the ISMS WG's proposal is about ADDING the possibility of 
SNMP over TCP, not about CHANGING SNMP to use TCP.
UDP will still work.

And I believe Eliot's concern is about letting the TCP session that carries 
the SNMP PDUs be opened from the agent to the manager, rather than from the 
manager to the agent (yes I know - this is SNMPv1 terminology, but I've 
forgotten the SNMPv3 terminology); that is another feature that comes in 
addition to what the group is apparently currently working on.
And just BTW: I find "call home" reasonable to specify too, once you've 
done TCP. It's obvious enough that I think it will be added to 
implementations whether or not we specify it, so we should have very strong 
reasons not to do so.
I don't even believe you need to "turn" the session, since SNMPv3 doesn't 
recognize the concept of a "direction" for a session.... just let the PDUs 
flow....

Disclaimer: I, too, have not seen the charter being proposed, and I have 
not followed the ISMS group. I have, however, once upon a time been 
responsible AD for the SNMPv3 WG.

                           Harald

---

From: Dave Singer <[email-masked]>
Date: Wed, 7 Sep 2005 09:44:31 +0200

At 0:30  +0200 7/09/05, Iljitsch van Beijnum wrote:
>protocol and the protocol works but the firewall doesn't. So 
>whatever happens, someone is going to be unhappy.

It could at least discuss the question "is the protocol designed in 
such a way that firewall management is reasonably enabled?" .  Two 
obvious counter-examples come to mind:  non-passive-mode FTP, and the 
use of RTSP with RTP (and having to enable traversal for the RTP/RTCP 
ports).

Then it could discuss whether this protocol can be individually 
isolated and decisions on firewall handling be made in isolation for 
it, or whether it is effectively bundled with other protocols which 
will have to be handled together, and whether that 'bundle' is in 
fact appropriate (e.g. if it layers on HTTP, is that appropriate?).

There are probably other questions as well.
-- 
David Singer
Apple Computer/QuickTime

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Sep 2005 09:55:16 +0200

> issue yet again; I've been through that too many times in the last

:-)  Well I wouldn't mind having this fight if I thought it would do  
any good, but that doesn't seem likely. What _could_ do some good is  
come up with better stuff than just observe packets on the wire. The  
exact same packet can either be completely harmless or be part of a  
huge security breach, depending on what software sent it / will  
receive it. It would be great if a security device could block  
packets sent by Apache 2.8 while allowing the same packets if sent by  
Apache 2.81.

> that important that we should ignore it?  I don't think so.

Well, I had occasion to write a NAT and firewall considerations  
section for a draft not long ago, but the trouble is: what should go  
in there? As long as there are no guidelines on how to interact with  
firewalls such sections will generally reflect the private opinions  
of the authors, which may or may not be useful on a case-by-case basis.

(In this case, my main concern was that certain signalling traffic  
would be handled the same as certain other signalling traffic by  
firewalls, and it would be good if we could make both types of  
signalling be treated the same as the data traffic, but that didn't  
seem doable.)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Sep 2005 11:17:20 +0200

Harald Tveit Alvestrand wrote:
> And I believe Eliot's concern is about letting the TCP session that 
> carries the SNMP PDUs be opened from the agent to the manager, rather 
> than from the manager to the agent (yes I know - this is SNMPv1 
> terminology, but I've forgotten the SNMPv3 terminology); that is another 
> feature that comes in addition to what the group is apparently currently 
> working on.
> implementations whether or not we specify it, so we should have very 
> strong reasons not to do so.

"Call home" is IMHO a fairly radical departure for SNMP and
raises trust model questions that I don't find easy to get
hold of. It seems quite distinct from both firewall traversal
and NAT traversal, conceptually, even if they might be
a side-effect of calling home.

> I don't even believe you need to "turn" the session, since SNMPv3 
> doesn't recognize the concept of a "direction" for a session.... just 
> let the PDUs flow....
> 
> Disclaimer: I, too, have not seen the charter being proposed, 

It should be on the ietf-announce list sometime today.

> and I have 

    Brian

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 07 Sep 2005 11:27:44 +0200

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        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 Sep 2005 13:01:54 +0300

Juergen Quittek wrote:

> SNMP into existing user and key management systems.

Yes.

> sure that ISMS is the right place to do so.

"Call home" is a feature that would be very useful. I'll just note
that the group's intended SSH approach (is there a draft? I
did not see one) does not appear to be in contradiction with
the ability to cross firewalls. SSH connections can be set up
so that you go through a device in the demilitarized zone
to reach something inside a network.

--Jari

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 07 Sep 2005 12:36:54 +0200

--On 9/7/2005 1:01 PM +0300 Jari Arkko wrote:
> "Call home" is a feature that would be very useful.

In which scenarios do you consider it very useful?

I am not at all saying that it is not useful.  Still, I want to learn
about where and how it would be required. And I am not sure if ISMS is
the right place for this discussion.

It would already be a nice achievement if the ISMS WG solves the
problem of integrating the existing SNMP into user and key
management systems.

>                                                      I'll just note
> did not see one)

Not yet.

>                  does not appear to be in contradiction with

Thanks,

    Juergen

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 Sep 2005 13:51:52 +0300

> In which scenarios do you consider it very useful?

Management of devices when you are outside the
network. E.g., managing my home network when
I'm at the office. And outsourced management services --
my employer does a lot of this. Or central management
of large networks that have internal firewalls or NATs.

> the right place for this discussion.

I'm not sure either. As noted, it may be possible already,
given their choice of technology.

Yes.

--Jari

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 07 Sep 2005 13:34:02 +0200

> 3. There is a firewall, and it tries to block the protocol.

actually I would put it differently....

1. There is no firewall: no need for text
2. The firewall manager desires to let the connection go through
   (while not making any other changes in policy)
   2a. The firewall allows the manager to express this desire in policy
   2b. The firewall does not allow the manager to express this desire
3. The firewall manager desires to block this type of connection
   (while not making any other changes in policy)
   3a. The firewall allows the manager to express this desire in policy
   3b. The firewall does not allow the manager to express this desire

2a is the common case (I think) if the firewall has NAT as part of the 
"defense" mechanism; you can't get from the "outside" to the "inside" even 
if you want to (unless you do <ugly stuff>, of course)

3b is the common case for protocols tunneled over HTTP with simple-minded 
firewalls; that's why "deep packet inspection" products sell so well....

A "firewall considerations" section (ObRant: Mandatory Sections Are Bad) 
would discuss how to turn 2a and 3b into 2b and 3a.... for instance, such a 
section on RTP/SIP might discuss what you need to snoop on in order to open 
the proper "media holes" in your firewall, and why signing your SIP 
requests is better than encrypting them in this scenario <architectural 
choking sounds deleted>.......

                     Harald

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Sep 2005 07:41:11 -0400

> behind a firewall that blocks by default.

It should be pointed out here that the problems
introduced by NATs are not quite the same as
problems introduced by firewalls.  While they
both impair reachability NATs cause NATted hosts
to be unable to determine their own address (or
indeed to have an addressable presence at all
without initiating contact with another host).

In any event I think that it's a mistake to
assume that a firewall or NAT can inspect or
rewrite the contents of a data stream.  I'm not
sure that it's a good idea for the IETF to
tacitly (or otherwise) discourage encryption or
authentication.

I'm sort of "meh" on the idea of a mandatory firewall/
NAT/middlebox/filters section in protocol documents.
I'm not sure that there's a widespread problem that it
would solve.  In the case where there is a problem,
like this one, sharp eyes tend to catch it early.
We have mandatory security sections because securing
a particular protocol can be subtle and idiosyncratic
because of trust relationships and operating environment,
and firewall/NAT problems tend to be pretty much the
same from protocol to protocol with hard problems cropping
up in a small number of cases.

Melinda

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 7 Sep 2005 09:05:12 -0400

Hi Eliot,

[I am writing as a participant in ISMS and other SNMP-related WGs. 
This note is not intended to represent the reasoning that I would use 
ot make a decision about the ISMS charter in an IESG context.]

As you know, I disagree with your opinion that call-home 
functionality should be added to the ISMS charter for three reasons:

(1) I don't think that call home fits within the scope of the ISMS 
group.  I am not necessarily saying that we shouldn't do this 
somewhere in the IETF, just not in this WG.

IMO, the ISMS group has one very important purpose:  Many people are 
using SNMPv1/v2 today and have not upgraded to SNMPv3 because of the 
(perceived) cost and complexity of deploying SNMPv3 security.  ISMS 
will integrate SNMP security with existing, widely-deployed security 
infrastructure such as SSH and RADIUS, so hopefully people will start 
using SNMP security.

This is a security area WG.  It is not charged with producing a 
next-generation of SNMP, just with the (important) task of 
integrating the current generation of SNMP with more widely-deployed 
security mechanisms.  I personally think that tightly-scoped WGs are 
good.  I also think that it would be inappropriate to add new 
architectural features to SNMP in a security area WG.

(2) I do think that call home represents a significant architectural 
change to SNMP, for the same reasons that Randy Presuhn has offered. 
I'd also like to emphasize one of his points -- we have already 
defined how SNMP runs over TCP (in RFC 3430), so ISMS is not the 
first group to consider this.  Running SNMP over TCP did not require 
the types of operational changes that you are discussing.

IMO, the idea of an SNMP command responder (agent) initiating the 
communication is not as simple as you have portrayed it.  There are 
many open questions, like:  How would the command responder know what 
manager(s) to contact? When should the command responder try to 
initiate the communication? How often should it re-try if the initial 
contact fails?  What should it do if the connection drops?

SNMP command responders are stateless entities that simply respond to 
the queries they receive in the order that they receive them. 
Changing them so that they can initiate and effectively manage a 
communication connection to the manager is a pretty big change, IMO.

(3) I am not certain that there are a large number of people who want 
to initiative SNMP management communication through a NAT/Firewall 
who do not have the ability to allow/tunnel an SSH connection through 
that same NAT/Firewall.

In my experience, NATs and Firewalls are usually placed at the 
boundaries of an administrative area.  In many cases, they are 
intentionally used to prevent access to internal systems from the 
outside.  I have not run into many cases where a network 
administrator has wanted to allow management access to systems from 
outside of the local network, but perhaps you have?

If you do believe that this is a common need, I think that you will 
need to better define/explain your use cases.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 7 Sep 2005 09:42:33 -0400

At 12:26 AM +0200 9/7/05, Harald Tveit Alvestrand wrote:
>I believe that the ISMS WG's proposal is about ADDING the 
>possibility of SNMP over TCP, not about CHANGING SNMP to use TCP.
>UDP will still work.

That is correct.  UDP and the current SNMPv3 USM security mechanisms 
will still work.  They will also remain mandatory parts of SNMPv3.

>carries the SNMP PDUs be opened from the agent to the manager, 
>rather than from the manager to the agent (yes I know - this is 
>SNMPv1 terminology, but I've forgotten the SNMPv3 terminology); that 
>is another feature that comes in addition to what the group is 
>apparently currently working on.
>And just BTW: I find "call home" reasonable to specify too, once 
>you've done TCP. It's obvious enough that I think it will be added 
>to implementations whether or not we specify it, so we should have 
>very strong reasons not to do so.
>doesn't recognize the concept of a "direction" for a session.... 
>just let the PDUs flow....

Unless I am seriously misunderstanding something, this is a bit more 
complicated than you and Eliot seem to think that it is...  The 
command responder (agent) is a stateless piece of software that 
simply responds to queries as they are received.  It has no way to 
anticipate when queries will be received, and no concept of what 
other systems it would like to receive queries from.  So, where would 
it get the information necessary to open a connection to the manager? 
How would it know what to do if the manager could not be reached? 
How would it know when he connection should be taken down?

Now, I am not saying that I couldn't come up with an answer to these 
questions -- it seems likely that we'd have to grow another SNMP MIB 
that would control how/when/if the command responder would attempt to 
establish a communication connection with the command generator, etc. 
I agree that SNMP over TCP might be an important element of this 
solution, but it is already defined in RFC 3430.  So, if there really 
is sufficient interest in adding call home capability to SNMP, I 
don't see why the IETF couldn't do this work.

But, why does anyone think that we should do this work in the 
Security area in a WG that is tasked with integrating the SNMP 
security model with SSH and RADIUS?

Margaret

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2005 08:41:31 -0700

Brian E Carpenter wrote:
>> you've done TCP. It's obvious enough that I think it will be added to 

Really? What is a trap/inform but a "call home" by another
name?

In answer to Margaret's question about how it would know
where to "call home", it seems to me to be about the same
problem as with traps/informs. I haven't had anything to do
with this wg, but it seems pretty plausible that you'd
initiate the session from the agent using a trap/inform
over tcp/ssh/whatever and then just reuse the connection
for subsequent pdu's sort of akin to http 1.1 reuse. It
would just all sort of fall out of the overall snmp
architecture.

		Mike

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 7 Sep 2005 12:18:45 -0400

Hi Mike,

>would just all sort of fall out of the overall snmp

So, every time a notification sender sends a trap or notification it 
would set-up a TCP connection to each of the notification receivers 
in its list and keep that connection up indefinitely?  Would it 
reestablish ithose connections when they fail?  How long would it 
keep a connections up if it never receives a command request on that 
particular connection?  Please remember that not all notification 
receivers _are_ command requestors, and not all command requestors 
are notification receivers.

I do think that if you built a mechanism for a command responder to 
open a connection to a command requestor, the MIB for configuring the 
new mechanism might resemble the MIB that is used to determine 
notifications should be sent, but I don't think that it will be 
identical and I do not think that the current MIB should be 
overloaded in this way.

BTW, nothing about your note explains to me why you think that this 
mechanism should be defined in a Security area WG that is working on 
a completely separable problem.  If you really think that defining 
call home for SNMP is something that the IETF should do, I would 
encourage you to get together with Eliot and request a BOF in the OPS 
area.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Sep 2005 17:12:01 -0400

>> Certainly one of the reasons I requested IETF-wide review for
    >> the ISMS recharter is so that decisions like this can be
    >> reviewed by the community.  The IAB gets to see charters at
    >> about the same time as the IESG does; they have sent no
    >> negative comments to this charter.

    Dave> Sam, I've tried to search the ietf-announce archives,
    Dave> google, etc. for any sort of announcements, outside of the
    Dave> isms working group, concerning the draft re-chartering text
    Dave> for isms.  Unfortunately I have not been able to find it, so
    Dave> I do not know what request of yours you are referring to.

There's a bit of a lag from the IESG's decision to send a charter out
for review and the actual announcement of the charter text.  The IESg
requested review of the charter at last Thursday's telechat; Eliot was
reacting to that but wanted to get discussion started without waiting
for the formal announcement to ietf-announcce.  I agree that Eliot's
concerns do not need to wait for a formal message to ietf-announce
before we consider them.

    Dave> In any event, I think the significance of Eliot's (and Steve
    Dave> Bellovin's) postings have less to do with a chartering event
    Dave> and more to do with decisions made DURING a working group's
    Dave> normal activities.  In particular, when a working group gets
    Dave> to the point of making a decision that has broad
    Dave> architectural or operational impact, it is the expertise of
    Dave> ADs, IAB members, and other senior participants, that can
    Dave> serve to raise a question to the larger community, exactly
    Dave> as Eliot is now doing.

I actually disagree with you in this instance but agree that what you
are talking about can and does happen.

In this instance, the whole point of the charter was to reach a
direction within the working group that has broad architectural impact
and then to review that decision with the community.  So, I think
Eliot and Steve's concerns are directly tied to the chartering event.

--Sam

---

From: Dave Crocker <[email-masked]>
Date: Wed, 07 Sep 2005 10:18:53 -0700

> Eliot and Steve's concerns are directly tied to the chartering event.

Sam, thanks for pursuing this.  I had misunderstood the timeline, and thought 
that Eliot was raising a post-chartering issue.

As we seem to agree, such issues do arise in working groups, so the question of 
seeking broad review of major decisions DURING the wg process is a valid issue, 
albeit apparently not this time.

My own, very strong bias on situations like the current one, certainly is to 
make a charter as precise and complete as possible.  The more a charter can 
state basic assumptions and constraints, the better, from what I have seen. 
Including conceptual and architectural impacts (or issues) can only be helpful.

-- 
 
   d/

  Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Sep 2005 13:28:14 -0700

Margaret Wasserman wrote:
> would set-up a TCP connection to each of the notification receivers in 
> its list and keep that connection up indefinitely?  Would it reestablish
> ithose connections when they fail?  How long would it keep a connections 
> up if it never receives a command request on that particular 
> connection?  Please remember that not all notification receivers _are_ 
> command requestors, and not all command requestors are notification 
> receivers.

I think there's a fair amount of room between "never" and
"indefinitely" on how/when to keep a connection up. As I
mentioned, http 1.1 seems to handle this and if nothing
else we certain have a lot of data about its efficacy.

> I do think that if you built a mechanism for a command responder to open 
> a connection to a command requestor, the MIB for configuring the new 
> mechanism might resemble the MIB that is used to determine notifications 
> should be sent, but I don't think that it will be identical and I do not 
> think that the current MIB should be overloaded in this way.

Correct me if I'm wrong, but I thought that http 1.1 was
pretty spartan on any sort of settings and/or negotiation
of the kinds of parameters you brought up. That is, each
side decides for itself what those values ought to be, and
the provisioning of them is out of scope. Since the web is
essentially an any-any kind of environment, is there some
reason to believe that a more restrictive relationship --
as one would expect manager to managed to be -- would bring
new or  different considerations than we already have a lot of
experience with?

> mechanism should be defined in a Security area WG that is working on a 
> completely separable problem.  If you really think that defining call 
> home for SNMP is something that the IETF should do, I would encourage 
> you to get together with Eliot and request a BOF in the OPS area.

That's because I haven't formed an opinion on it. My main point
is that this doesn't seem to me to be any sort of wildly divergent
architectural proposition, at least on the front of who "initiates"
a connection. As Harald pointed out, I really can't see how you'd
prevent some industrious developers from using SNMP in this way
regardless of how the working group is chartered, and from that
standpoint it might be better to get ahead of the ball on it if
it were inevitable, and it does seem to have a fair number of
security considerations.

The question I have for Eliot though is why he believes that SNMP
is the right vehicle for this kind of "call home" functionality
in the first place. Maybe it's my own prejudice, but SNMP seems
a little klunky for what I'd envision "call home" is trying
to achieve.

		Mike

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Sep 2005 08:42:53 +0200

Margaret,

My apologies for my delayed response.  I've been away.  The timing of
this charter review was unfortunate.

> group.  I am not necessarily saying that we shouldn't do this somewhere
> in the IETF, just not in this WG.

> next-generation of SNMP, just with the (important) task of integrating
> the current generation of SNMP with more widely-deployed security
> mechanisms.  I personally think that tightly-scoped WGs are good.  I
> also think that it would be inappropriate to add new architectural
> features to SNMP in a security area WG.

How many times shall we change SNMP?  ISMS will represent a substantial
change, no matter how it is done.  There will be a new packet format,
and there will be a new authentication architecture for SNMP.  Whether
or not somebody's idea of an architecture for SNMP is changed at this
point is irrelevant.  All tools that use this solution will change.

Doing yet another round of changes to accomplish CH will cause a
continuously unstable network management standard for some period to
come.  It is at best an overly bureaucratic reasoning that says that X
work has to be done in X area when Y group has already opened the
protocol in Y's area.

As I've previously written, all the interest parties from the O&M area
have been in the room.  As others have written, CH requires security
review.  What, then, is the problem?

> change to SNMP, for the same reasons that Randy Presuhn has offered. I'd
> also like to emphasize one of his points -- we have already defined how
> SNMP runs over TCP (in RFC 3430), so ISMS is not the first group to
> consider this.  Running SNMP over TCP did not require the types of
> operational changes that you are discussing.

Beyond what I wrote above, as others have written, a substantial
architectural change is moving from packet based to session based
security.  Furthermore, had I been paying attention to the SNMP over TCP
discussions at the time I would have raised this concern at that time.

> communication is not as simple as you have portrayed it.  There are many
> open questions, like:  How would the command responder know what
> manager(s) to contact? When should the command responder try to initiate
> the communication? How often should it re-try if the initial contact
> fails?  What should it do if the connection drops?

These are valid questions, and worthy of discussion.  They are not
insurmountable questions, however.  I could right now give you my own
proposed answers for each of these, but I propose that they are best
answered in a working group!

> the queries they receive in the order that they receive them. Changing
> them so that they can initiate and effectively manage a communication
> connection to the manager is a pretty big change, IMO.

No it is not.  All that is required is an understanding that responses
to a manager will travel via a pre-established SSH connection.  For
example (and only example), we have an SNMP-TARGET-MIB that already
identifies in the case of a notification the method to communicate.
Conveniently the aforementioned TCP communication has great examples of
precisely how to populate this MIB in its appendix.

> 
> (3) I am not certain that there are a large number of people who want to
> initiative SNMP management communication through a NAT/Firewall who do
> not have the ability to allow/tunnel an SSH connection through that same
> NAT/Firewall.

I believe you are conflating two issues here.  The first is that one can
use SSH tunneling over which to route SNMP queries or responses.  The
second is the ability to cause the remote command generator to use that
tunnel.

> outside.  I have not run into many cases where a network administrator
> has wanted to allow management access to systems from outside of the
> local network, but perhaps you have?

I have, as has Eric, as have the many others who have written to you to
say this at this point.  Any overlay network or service provider that
wishes to offer a managed service to his or her customer will have run
into this problem.  Any enterprise with mobile devices will run into
this problem, particularly with phones.  Now you can say that
enterprises should simply bring up VPNs to solve the problem, and while
that's likely to sell more Cisco hardware, it may not be the right
solution for everyone, particularly if the phones are managed by a vendor.

> 
> If you do believe that this is a common need, I think that you will need
> to better define/explain your use cases.

Margaret, I'm surprised that the one use case I mentioned in my original
note did not resonate with you.  If you run Windows or MacOS or most
commercial variants of Linux your own computer already calls home to
have certain functions managed.  Why is it so difficult to believe that
a device within a network would want to accomplish the same objective
with the existing SNMP framework?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Sep 2005 12:52:17 +0200

Brian,

> a side-effect of calling home.

I do not believe - nor have I seen document demonstrating that - you can
practicably achieve the two classic functional goals of query/response
and unsolicited notification without implementing CH in the face of a
firewall/NAT.

Another way of putting it is that if firewalls are to be dealt with (and
in this day and age we should presume this), this functionality has been
prematurely ruled out of scope and must be considered in order to that
need ANYWAY.

Eliot

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 12 Sep 2005 11:20:28 -0700

>>>>> On Wed, 7 Sep 2005 09:42:33 -0400, Margaret Wasserman <[email-masked]> said:

>> possibility of SNMP over TCP, not about CHANGING SNMP to use TCP.

Margaret> That is correct.  UDP and the current SNMPv3 USM security
Margaret> mechanisms will still work.  They will also remain mandatory
Margaret> parts of SNMPv3.

Though it's important to note that the reason for the creation of the
WG was that although the security features in SNMPv3 definitely
worked, they were hard to use.  Thus operators didn't always deploy
SNMPv3 because it was a pain to set up the user base.  By saying that
we're going to now allow SNMPv3 over TCP to use their existing user
infrastructures, I agree that you are not saying you can't use
SNMPv3/USM over UDP as you've always been able to.  However, since
many don't want to use that today I think their choice will still boil
down to SNMPv3/ISMS/TCP or nothing if they're unwilling to take the
deployment hit that was already preventing wider adoption of
SNMPv3/USM in the first place.  Yes, SNMPv3/USM/UDP will still be just
as usable as it was before.  But it still won't be used as much as it
should be.

-- 
Wes Hardaker
Sparta, Inc.