I find myself repeating statements I've made recently, and so I'd
propose that you catch up on my other messages. But for the record...
I have, of course, read the draft that you cited below, but the term
"call home" is not defined or used in that draft...
Because it wasn't necessary to do so, as you allude below. The draft
you haven't yet read is SNMP/SSH. The working group decision was made
absent a draft. Doesn't that bother you at all?
The document does discuss the concept that either end of the SNMP
exchange could initiate the BEEP connection at the transport level, but
I don't see that it explains anywhere how/when/why a command responder
would _decide_ (or even know how) to contact a command requestor and/or
how a command responder could find a command requestor if it were not at
a fixed, globally addressable location.
As I wrote previously this is a matter for configuration and policy.
There are some obvious configurations (some are obviously good and
others are obviously bad ;-) and some non-obvious ones. It is also a
matter for a working group to discuss. The conversation within the WG
has thus far been cut short by AD decree.
IMO, there is a lot more to building a system that is capable of SNMP
initiation in both directions than simply having a mechanism to set-up
the transport connection from the command responder to the command
Of course there is. Nobody said otherwise. There are matters of end
point authentication, for instance. But these problems are not
insurmountable. Perhaps you would like to participate in those
discussions, assuming we can find a place where they are not ruled out
It would also be possible to set-up an SSH connection from
either end, but I don't see how that even begins to offer the benefits
that you've attributed to "call home".
You asked me for a concrete proposal. I responded with one using BEEP
as an example. BEEP / SSH are bits on a wire. Either can be used, but
as I've written previously the horse I have in the game is whether CH is
supported and whether trap-based polling will properly function through
firewalls (something very much in doubt at this point), and not whether
we're talking about BEEP or SSH.
None of this seems very material to the ISMS discussion, though...
As I've written, The reason it is relevant at all is that the ISMS
working group has decided to make use of a transport where firewall
traversal becomes a real possibility, and I (and others) have needs for it.
Today SNMP (whether it is running over UDP or TCP) doesn't have the call
home feature. Do you really think it is reasonable to tie the addition
of that feature to the definition of a new security mechanism for the
existing SNMP protocol? If so, why?
Margaret, if I only thought it was reasonable to tie these two functions
together we wouldn't be having this discussion amongst a the IETF and
IESG. I think it is UNREASONABLE and a huge waste of resources to
consider an SSH/TCP solution without taking into account connection
direction. Here's why:
- in its current direction the protocol will fail to be useful in
the face of firewalls. In this day and age that is a foolhardy
approach. [It would be excusable failure if SNMP were to
remain UDP-based since firewall/NAT traversal is already
problematic.] Under the current approach the basic concept of
trap-based polling will fail in the face of firewalls.
- why now? because as I wrote earlier we really don't want to churn
SNMP continuously. Put yourself in the position of a tools
developer. What sort of investment am I going to put into
development, q/a, release engineering, documentation now when I
know this is hanging over my head?
In short, if we're going to turn the crank at all on SNMP, let's make
sure the resultant will work and will be useful for a while without
having to go do it again six months or a year down the road.
IMO, we need to try to do our work in manageable chunks in the right
groups/areas. A security area working group working on a new security
mechanism for the existing SNMP model is one chunk. Perhaps an OPS area
WG working on an optional SNMP call home mechanism is another...?
Yes, you've repeatedly said this. And I've repeatedly responded with
two reasons why this work should continue in a single working group:
1. The ISMS working group has had the correct set of people with eyes
on the problem, including security experts who ought to see their
concerns (such as those raised by Steve Bellovin and others) addressed
as well as network management people.
2. And as has been pointed out repeatedly (first by Steve Bellovin and
then by others), there are security implications here. We currently
need and have the correct the mix of security and management people in
the working group to both develop and properly vet the work being done.
don't see how the level of change/disruption to the vendor community is
substantially affected by whether these two separate mechanisms are
defined in one IETF working group or two.
Because you view the mechanisms as separate. As currently envisioned
the approach proposed will fail in the general case in the face of
firewalls and NATs(*).
ps: I agree with Melinda that there are differences between the two, but
for common cases the results are the same.
Ietf mailing list